Subject: Re: [IBIS] BIRD 75 comments
From: Ross, Bob (bob_ross@mentorg.com)
Date: Thu Sep 19 2002 - 12:38:26 PDT
Arpad:
Thank you for your comments and off-line discussion.
I agree that the definition is mis-leading and will plan
to add text to clarify that BIRD75.4 will support a
very powerful capability. [External Circuit]s can
be defined in a manner to support any type of circuit,
passive or active. For example, operational amplifier
models could be defined and attached directly to pins.
[External Circuit]s can be connected to other [External
Circuit]s as well. [Model]s (whether exising IBIS
or with [External Model]) are NOT required.
However, the [Model]/[External Model] capability
extends the existing IBIS simulation controls, information,
and reports to other languages in a standardized manner.
I/O buffers could be configured within [External Circuit]s,
but the user has to then configure through direct connections
and interfaces/scripts or whatever the control and reporting
of such buffers.
Bob Ross
Mentor Graphics
"Muranyi, Arpad" wrote:
>
> 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.
>
-----------------------------------------------------------------
|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 : Thu Sep 19 2002 - 12:57:09 PDT