Arpad,
As I meant to say, I do not have the time or resources at this time to
contribute to a specification that I do not think can be accomplished with
the people resources we have in the IBIS-ATM committee. This includes not
having the time to pour through BIRDs 124 and 145 to see how they can be
adapted to satisfy all of the Levels described below. When you have
updated these BIRDS to reflect these requirements I will be happy to
review them, particularly how they address the Level 1 and Level 2
requirements.
Walter
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi,
Arpad
Sent: Thursday, July 19, 2012 1:29 PM
To: ibis@eda.org
Subject: RE: [IBIS] IBIS-ISS Package Modeling Status/Overview
Walter,
I believe all those levels (and more) can be done with BIRD 125 + 145.
Please correct me if I am wrong on that.
The only thing that I see missing in BIRD 125 is the ability to associate
a package (or on-die interconnect) model with a buffer instead of pin or
pad or die-node. I do recognize that this is a nice feature to have when
the package or interconnect model is not pin specific. But I think we
could make changes to BIRD 125 to address this usage model.
Thanks,
Arpad
==========================================================================
=
From: Walter Katz [mailto:wkatz@sisoft.com]
Sent: Thursday, July 19, 2012 12:23 PM
To: Muranyi, Arpad; ibis@eda.org
Subject: RE: [IBIS] IBIS-ISS Package Modeling Status/Overview
Arpad,
I refer to my comment "IBIS has sufficient resource to accomplish this
task."
If you think that you can come up with a syntax for IBIS that satisfies
all of the Levels I describe (so that it can get into IBIS 6.0) then
please do.
Walter
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Muranyi,
Arpad
Sent: Thursday, July 19, 2012 1:07 PM
To: ibis@eda.org
Subject: RE: [IBIS] IBIS-ISS Package Modeling Status/Overview
Walter,
In my opinion, we should not have to deal with any of these
distinctions in a specification. The specification should
have the means to define the pins/balls, pads/bumps, on-die
nodes around the buffer and anywhere else, and provide a
mechanism to place an IBIS-ISS subcircuit between any of
these points.
Whether this IBIS-ISS subcircuit has a single ended line or
multiple differential channels in it, or whether it is signal
or power, coupled or uncoupled, high frequency or low frequency
makes no difference. Either one of these need nodes to be
connected to and that's it. I would just like to find a good
syntax to define the nodes and how the IBIS-ISS subcircuits are
instantiated and connected to these nodes, and be done. The
rest should be up to the model maker.
As soon as we put problem specific solutions into the specification
we submit ourselves to limitations and rigidity in the spec, which
IBIS is famous for. As you know it full well, it takes a lot of
time to make changes to the specification, and if we put such
limited capabilities into the spec, we will be forced to start making
changes to the spec as soon as it is released.
In this case it would not make a big difference to define a more
general syntax right now than take incremental baby steps with
limited functionalities. This stuff is really not all that complicated.
Thanks,
Arpad
=========================================================================
From: owner-ibis@eda.org [mailto:owner-ibis@eda.org] On Behalf Of Walter
Katz
Sent: Thursday, July 19, 2012 11:20 AM
To: ibis@eda.org
Subject: [IBIS] IBIS-ISS Package Modeling Status/Overview
All,
This e-mail is a summary of applying IBIS-ISS to IBIS package modeling for
IBIS 6.0. This summary is based on discussions in IBIS-ATM, and private
communications with Brad Brim, Arpad Muranyi, Michael Mirmak and various
IC Vendors.
Definitions:
Pin The connection point of a package model to a
board.
Pad The connection point of a package model to the
die.
Channel Either a single ended connection between a single
Pin and a single Pad, or a differential connection between two Pins and
two Pads.
Finally, I will describe the package modeling solution for several Levels
of package model complexity.
Level 1
Package models for a single Channel without coupling to either Power or
other Channels.
Useful to have multiple Channels point to the same IBIS-ISS subckt,
passing a unique Length for each Channel.
Important to have more than 3 corners.
Level 2
Package models for a single Victim Channel with coupling to other
Aggressor Channels in the same bus but without coupling to Power.
Useful to have multiple Channels point to the same IBIS-ISS subckt,
passing a unique Length for each Channel.
This assumes that the Aggressor Channels have the same length as the
Channel.
Important to have more than 3 corners.
Level 3
Package models for a multiple Channels with coupling between them but
without coupling to Power.
Channels may be in multiple buses
Package model may be for complete package or for a slice of the package..
Level 4
Package models for Power and Ground.
No coupling to Channels.
May require multiple Pads for the Power and Ground Nodes.
In general there will be a different number of Pads and Pins
Level 5
Package models for a multiple Channels, Power and Ground with coupling
between Channels and between Channel and Power.
Channels may be in multiple buses.
Package model may be for complete package or for a slice of the package.
Recommendations:
I recommend that IBIS 6.0 should fully address Level 1 and Level 2 for the
following reasons:
IBIS has sufficient resource to accomplish this task.
Gives package information to Users/EDA tools to enable users to make
engineering decisions.
Is in accordance with many industry standards package model
specifications.
I recommend that IBIS 6.0 should be enhanced to enable EDA tools to uses
Level 3, 4 and 5 models that publish their connections ports with
something like MCP.
Walter
Walter Katz
wkatz@sisoft.com
Phone 303.449-2308
Mobile 303.335-6156
--------------------------------------------------------------------
|For help or to subscribe/unsubscribe, e-mail majordomo@eda-stds.org
|with the appropriate command message(s) in the body:
|
| help
| subscribe ibis <optional e-mail address, if different>
| subscribe ibis-users <optional e-mail address, if different>
| unsubscribe ibis <optional e-mail address, if different>
| unsubscribe ibis-users <optional e-mail address, if different>
|
|or e-mail a request to ibis-request@eda-stds.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda-stds.org/pub/ibis/email_archive/ Recent
| http://www.eda-stds.org/pub/ibis/users_archive/ Recent
| http://www.eda-stds.org/pub/ibis/email/ E-mail since 1993
Received on Thu Jul 19 10:40:15 2012
This archive was generated by hypermail 2.1.8 : Thu Jul 19 2012 - 10:43:02 PDT