Subject: RE: [IBIS] BIRD 75 comments
From: Muranyi, Arpad (arpad.muranyi@intel.com)
Date: Thu Sep 19 2002 - 13:44:04 PDT
Bob,
Thanks for the planned clarification. I don't want to beat
the dead horse more to kill it, but I just found another section
that needs to be reworded. Here is the cut and paste from
BIRD75.4:
| Keyword: [External Circuit], [End External Circuit]
| Required: No
| Description: Used to reference an external code file for more detailed
| die interconnect description.
This clearly states an intension for [External Circuits] being
used for "die interconnects". It is true, it doesn't say that
it shouldn't be used for anything else, but if it is designed
to be used with other things too, that should be listed, or
stated
here.
Thanks,
Arpad
=================================================================
-----Original Message-----
From: Ross, Bob [mailto:bob_ross@mentorg.com]
Sent: Thursday, September 19, 2002 12:38 PM
To: Muranyi, Arpad
Cc: ibis@eda.org
Subject: Re: [IBIS] BIRD 75 comments
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 - 14:42:15 PDT