Subject: RE: [IBIS] BIRD 75 comments
From: Muranyi, Arpad (arpad.muranyi@intel.com)
Date: Wed Sep 18 2002 - 16:33:36 PDT
Chris, Bob,
This is in response to the lines I preceded with "-->" in the message below.
The following is a cut and paste from BIRD75.4:
| The [External Circuit] keyword is used to describe paths that can connect
| some or all of a [Model] to the 'Die Nodes' as shown in the diagram below.
| The connections between [Model] and [External Circuit]s are always through
| nodes. 'Internal Nodes' are shown for some connections and need to be
| declared. The diagram shows 'Die Nodes' designated by corresponding pin
| numbers, and 'Internal Nodes' by alpha characters. This diagram is used
to
| illustrate the new keywords discussed later.
Even though this paragraph doesn't say that the [External Circuit] is not
allowed to have active circuitry, or is not allowed to provide the model
for the buffer itself, this paragraph implies (or puts a very strong
influence on the reader) that it is supposed to describe only passive on-die
interconnect structures.
So your statement about being able to put even a buffer description into an
[External Circuit] keyword seems to be the exception, or so to speak using
the
loophole or backdoor in the spec type approach. I strongly disapprove of
writing a spec that can (or is encouraged to) be used like that.
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 Sep 18 2002 - 16:46:47 PDT