Subject: RE: [IBIS] BIRD 75 comments
From: Muranyi, Arpad (arpad.muranyi@intel.com)
Date: Wed Aug 28 2002 - 09:41:16 PDT
Chris,
Thanks again for your quick response. I am sorry for being
on the negative side, but something really bothers me now.
I am getting this feeling that we are making more and more
recommendations for not using the keywords as they were
originally intended to be used.
1) From the BIRD I get the impression that the [External
Circuit] keyword describes stuff between the buffer and the
pad, ON the die. In your comment I get the feeling that it
can also be used to describe the package, that is clearly
not on the die. Further (and this may be a typo in your
writing) you state that "The [external circuit] can ... be
used to represent anything at all, including complicated
drivers". Now, this is news to me. I thought that drivers
were supposed to be described with the [External Model]
keyword, and that the [External Circuit] keyword could only
describe passive circuits. Of course, my comment from day
on was to combine these two keywords into one, because of
their similarity, but as the BIRD stands now they are two
separate keywords with two distinct purposes. I strongly
oppose of making use of keywords other than they intent.
It is too confusing, requires twisted thinking, and
indicates that we didn't know what we were doing in the
first place.
Going back to the original question about package models,
I would like to see two things: One, how is the new ICM
model going to be referenced from an IBIS model for describing
the package; two, how can the [External Circuit] reference
an ICM model in addition to the proposed three languages (SPICE,
VHDL-AMS, and VERILOG-AMS).
Regarding whether I have any ideas for what the interface
should look like, I am sorry, I don't. This is too new in my
mind, and I didn't get to the point of having any firm ideas
on how to go about it. I am just having a gut feeling that
this is the way it should go.
Arpad
=============================================================
-----Original Message-----
From: Reid, Chris [mailto:chris_reid@mentorg.com]
Sent: Wednesday, August 28, 2002 9:16 AM
To: 'Muranyi, Arpad'; ibis@eda.org
Subject: RE: [IBIS] BIRD 75 comments
Arpad and Lynne,
Complicated package models can be described using the
[external circuit] and [circuit call] constructions. That
was one of the design goals. The connections are all inside
the IBIS package model, if any exists. This was to make
the use of package models possible, not to exclude using
an [external circuit] to represent part or all of a package
or die interconnect. There is no restriction on what an
[external circuit] may contain, or on its interface.
Arpad, I like your metaphor of a four-function calculator
versus a full-featured one. Have you got any ideas on what
such an interface would look like? The [external circuit]
can, as I said, be used to represent anything at all,
including complicated drivers. If we added some conventions
about how to use it to get timing test waveforms then we
could use them as drivers. Maybe we are not as far from
your ideal as you may think.
The most difficult part is that the automatic tool needs
to know how to compute the timing test waveform for a given
driver so that it can make delay measurements. I think we
could come up with a syntax to allow that.
Chris
-----Original Message-----
From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
Sent: Wednesday, August 28, 2002 8:30 AM
To: ibis@server.eda.org
Subject: RE: [IBIS] BIRD 75 comments
Lynne,
Thanks for your comments. Regarding your last question, I was
wondering about that too, i.e. how can we reference the new
interconnect specification from the IBIS model. There is a
new keyword in BIRD75, [External Circuit], which inserts a
passive circuit description, but strictly speaking it was
designed to place that circuit between the buffer model and
the die pad. Therefore it doesn't seem to be intended to
reference any external interconnect models as I understand it.
However, I also feel that we should have a way to utilize our
new ICM spec for modeling these more elaborate on-die interconnects
as well as packages.
Regarding the required subparameters and keywords, my point was
not whether to keep them or not, but that they are also becoming
too rigid the way we had them so far. What if I make an [External
Model] which needs a parameter for Vcommon in addition to Vdif,
plus edge rate values at which the input signal is valid for the
differential receiver? Or what if the [External Model] has more
supply connections than just the four for which we now have the
reference voltage keywords? We won't be able to do it until a
new BIRD is written and approved. My suggestion is to make a spec
that allows the model maker to define their own parameters, and
actions that the parameter needs to achieve in the simulator and
then have the simulator parse it, and solve it. This is similar
to stepping up from a basic calculator which has only four functions
to a math software where you can write your own equations and have
it solve it for you.
The other point I was trying to make is that the current spec
requires some of the parameters/keywords under the old [Model]
keyword. It seems to be silly (and confusing) to have to define
C_comp and [Ramp] with zeroes or NAs in a model when they are
described much better in the [External Model], just because
the spec required their presence.
Arpad
==============================================================
-----Original Message-----
From: Lynne Green [mailto:lgreen@cadence.com]
Sent: Tuesday, August 27, 2002 1:18 PM
To: ibis@eda.org
Subject: RE: [IBIS] BIRD 75 comments
Great discussion thread so far. Arpad and Bob have
addressed some major points in depth.
Several keywords/subparameters we may want to keep,
whichever way the BIRD decides to go:
receiver thresholds
Vmeas, Cref, Rref, Vref
Enable polarity
all of the various test fixtures, including golden waveforms
Model_type
voltage range (perhaps extend to Vss as well as Vcc).
temperature range
reference voltages, external reference
[Ramp], because algorithms can use this to estimate
the edge rate for various calculations.
The suggestion of setting C_comp to 0pF if it is included in
the external model leaves the model maker a choice of
where to include it. Choice is good, unless it is confusing
to the model maker.
The "philosophy" appears to offer two choices:
Put [External Model] under [Model], and list all the things that
must NOT be included, or separate the two and list all the things
that MUST and CAN be included. Any insight on which might
be easier for a parser implementation?
One new question: Can an [External Model] be used to replace
a package model? This might be a way to address typ/min/max
package variations in a complex package.
Best regards,
Lynne
Lynne Green
Senior Member of Consulting Staff
Cadence Design Systems, Inc.
"All the world's an analog stage, whereon digital plays bit parts."
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.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 email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
-----------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.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 email a request to ibis-request@eda.org.
|
|IBIS reflector archives exist under:
|
| http://www.eda.org/pub/ibis/email_archive/ Recent
| http://www.eda.org/pub/ibis/users_archive/ Recent
| http://www.eda.org/pub/ibis/email/ E-mail since 1993
This archive was generated by hypermail 2b28 : Wed Aug 28 2002 - 10:14:53 PDT