Subject: RE: [IBIS] BIRD 75 comments
From: Lynne Green (lgreen@cadence.com)
Date: Tue Aug 27 2002 - 13:17:58 PDT
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."
-----Original Message-----
From: Muranyi, Arpad [mailto:arpad.muranyi@intel.com]
Sent: Tuesday, August 27, 2002 12:12 PM
To: ibis@eda.org
Subject: RE: [IBIS] BIRD 75 comments
Bob,
This is a public reply so (hopefully) others can also join the
discussion.
Thanks for all the editorial fixes, clarifications. There are a few
technical items left which I would like to argue.
The biggest one is regarding whether the [External Model] keyword should
be inside or outside the old [Model] keyword. You call this debate
"practical" vs. "purity". You raised basically two reasons to keep it
inside. One is that taking it out would require a bigger editorial
effort to make all the necessary changes even in the old sections of the
spec. I agree that this would be a big job, but I feel that it would be
well worth it. (This is the "practical" part).
The problem I see with keeping it inside is that by doing that we
introduce a bunch of rules which do not necessarily make engineering
sense. (This would be the "purity" part). A newbe model maker would be
utterly confused about why certain things have to be in certain ways,
and we would have to end up teaching more history than technical content
in our IBIS classes. That is a very "practical" problem in my mind. We
need to be user friendly with our syntax, otherwise we will get more low
quality models. It is hard enough to characterize the behavior of the
buffers as it is, there is no need to make it harder with extra
historical baggage. There are other problems with this approach also.
The old [Model] keyword requires a few subparameters or keywords. Such
is the C_comp, but you did not mention in BIRD 75.3 that [Ramp] is also
required. What do we do with these? Put "NA" in them and still use
them just because the spec requires them, or establish new rules that
they are not required if the [External Model] keyword exist? In the
latter case we would introduce a bunch of conditionals which is also
"impractical" in my opinion.
Secondly, we have a few inconsistencies already because we didn't think
ahead in time that some parameters (such as Vinh, Vinl) will need typ
min max values. To solve these we invented the [Model Spec] keyword,
but this keyword may not have everything we may need in the future. I
am already starting to hear from design engineers that for differential
receivers we will need more than just Vdiff (Vcross seems to be a new
candidate) to do it right. These subparameters are still fixed, they are
not arbitrarily extendable.
The idea of having an [External Model] keyword outside the old [Model]
keyword could fix all of our historical shortcomings from the past. Yes,
there may be some overlap between the old parameters and the new
parameters, but that should not cause any conflicts, because I can't
imagine anyone using both [External Model] and [Model] for the same pin
(or buffer).
This leads me into the next subject which is related to
parameterization. Since we do not know what holds the future, we will
never know ahead of time what kind of (sub)parameters a model may need.
(One good example is the evolution of the [Model Spec] keyword). As I
mentioned above, this keyword may need further extensions maybe very
soon. Doing this through the BIRD process will take too long for every
change. Just like we wanted to get away from rigidity regarding the
buffer model characteristics, I think we should also make these
parameters flexible and extendable. Doing this would also allow
arbitrary parameterization with [External Model]s. What I have in mind
is a specification for an interface between the tool and the IBIS file,
rather than fixed parameters (such as Vinh and Vinl) which we have
today. The interface would allow the model maker to define a parameter
and provide data for it. The tool would then use the definition and set
up its actions based on that using the data from the IBIS file. This
would be similar to the way custom measurements work in some of the
already existing tools. Now don't ask me for details on this, because
this is a new idea to myself, and I am not a tools programmer either.
But this idea would keep the specification flexible and useful for a
longer period of time.
This is a smaller thing, but I would consider changing the word "port"
to "terminal". Especially because the way you define and use it. I
think many people would have a different idea about what a port really
means, and this usage may disturb them. To it seems that a terminal
could be a single node without any confusion, but ports always assume
two nodes whether one is an ideal ground node or not. Does anyone out
there know what the proper definition and usage of "terminal" and "port"
are?
Regarding my comments on [Series Current] and [Series MOSFET] (#19), I
think you misunderstood it. My point is that in the BIRD you didn't
list them as keywords which need the [Series Pin Mapping] keyword under
the interaction limits. I just mentioned that they should also be
listed there (if I understand it correctly).
That's it for now.
Thanks,
Arpad
========================================================================
-----Original Message-----
From: Ross, Bob [mailto:bob_ross@mentorg.com]
Sent: Wednesday, August 14, 2002 4:50 PM
To: Muranyi, Arpad; ibis@eda.org
Subject: Re: [IBIS] BIRD 75 comments
Arpad:
Thank you again for your thoughtful comments.
I am adding to the responses I gave earlier in preparation
for issuing BIRD75.3.
Some of your points could lead to long discussions. I tried
to keep the responses here short and/or just acknowledge that BIRD75.3
documented a choice among several possibilities.
Bob Ross
Mentor Graphics
"Muranyi, Arpad" wrote:
>
> All,
>
> This is a public posting of my message to Bob Ross from last night
> regarding BIRD 75. Based on some private discussions and the Open
> Forum meeting this morning, I added the last item (#20). Item #5 was
> my misreading of the BIRD, and it was clarified to me by Bob, I just
> left it in there for completeness, and to see if anyone else has a
> problem understanding it.
>
> I would like to encourage everyone to comment and express their
> opinions so we could come up with a robust solution for our needs.
>
> Thanks,
>
> Arpad
> ===================================================================
>
> Bob,
>
> Here are my comments on BIRD 75.2.
>
> Some of the wording is still not entirely to my liking, but I can live
> with that, or we can do an editorial session once again on section 6b.
> I think this is important, because we have to make sure that the
> reader who has never hear of this can understand what is being said
> here.
>
> Technical issues:
>
> 1) The 3rd and 4th drawings do not label the core side of the nodes. I
> think they should also be labeled.
I left the third drawing as is for a context diagram, but added the
ports for the External Circuit diagram so that the [External Circuit]
example would be clearer.
>
> [External Model] section:
>
> 2) In general, I wonder whether this is the right way of doing it, I
> mean to have this inside the [Model] keyword. Our last discussion on
> true differential buffers and the associate rules bothers me a lot. So
> I wonder what is the reason to want to have this [External Mode]
> keyword inside the [Model] keyword. Is it for its subparameters
> (C_comp, Model_type, Vinh, Vinl, etc)? For one, only two of these are
> required, all the other ones are optional. Second, if we had the
> [External Model] as an alternate to the [Model] then the [External
> Model] keyword could have its own set of (duplicate) subparameters
> analogous to the [Model] keyword. I know this is kind of duplication
> but this way some of those ugly rules would go away, and the two model
> keywords would be independent. (Similar to the [Nodal Path
> Description] and the [Tree Path Description] keywords in the ICM spec.
> Doing it this way would also make me happier because we could perhaps
> combine the [External Circuit] and [External Model] keywords as I
> commented the first time. This would also make BIRD 77 unnecessary,
> because those subparameters could be added for the [External Model]
> keyword. We could also combine everything that is under the [Model
> Spec] keyword and do it right for once all under the [External Model]
> keyword.
You may be right. However, the reason for the current approach is for
practical considerations rather than purity reasons. An [External
Model] keyword at the same level as [Model] would create some
documentation difficulties:
- Most, but not all locations of [Model] would have to be reviewed
and possibly changed to "[Model] and/or [External Model]" where
needed.
Such an exercise is subject to mistakes.
- Several but not all of the keywords and subparameters under
[Model] would have to be repeated causing documentation change
tracking problems.
So I felt it was easier to contain [External Model] under [Model]. This
also makes the IBIS compatibility/migration path easier with existing
IBIS models.
>
> 3) Regarding the typ., min., max corners, Lynne asked for capability
> of having more than just three.
The proposal is limited to just the three corners. This will make the
EDA tool migration easier since other "corners are not defined.
However, the user work-around is to create a separate ibis file or new
model. In one model, the min might be
low voltage/ low temp/ slow process
The second model might have the min column as
low voltage/ high temp/ slow process
Other variations could be configured by separate models, but each User
would have to configure their EDA tool to handle the cases in a vendor
specific manner - since there are no standardized conventions. Such
handling could be done through interfaces or scripts.
So any specific or unusual configuration (such as strong PMOS, weak
NMOS) could be constructed, but the user would then have to know what
the contents are and direct the analysis through different files or
problem specific scripts.
>
> 4) It is still not clear to me how the .LIB statement would work with
> the subcircuit calls as you show it. Process files are usually
> separate from the netlist, and here we only have netlist references
> only.
We did not know at the meeting whether .LIB was part of Berkeley Version
3F5. My understanding is that the .LIB statement provides a level of
indirection so that only specific files of interest are included.
The .LIB feature does appear in several SPICE implementations. A
Specific SPICE implementation might process it directly as one of the
Corner setups as long as the higher level entry is still through a
.subckt name. However, if the .LIB is itself the top level file, you
might have to bypass the .LIB and enter the filename and .subckt name
directly in the Corner lines.
>
> 5) Regarding Ports, it is not clear to me whether these include the
> internal nodes labeled (a) - (j) as well as the pad nodes which
> correspond to the inside of the package.
> *** This was my misunderstanding of the text, please ignore.****
(The Ports do not include nodes. The Ports are the [External Circuit]
or [External Model] terminal names.)
>
> 6) Regarding D_to_A and A_to_D it is not clear from this writing
> whether these are an "element" or parameters to an element. If they
> are elements, then I wonder whether they should be lifted out from
> being subparameters and make them keywords. If they are just
> parameters to an element that resides inside the [External Model]
> itself, then this needs to be explained more clearly.
The text defines D_to_A and A_to_D as subparameters of [External Model].
These "subparameters" have up to 7 entries. This was chosen as a more
compact way to enter in just one line the port and ramp informaton to
control SPICE circuits or to report logical state changes from threshold
values. The alternative could have been to spread this over several
lines. However, there would be more syntax checking rules regarding
possible omitted information.
>
> 7) In the port description under A_to_D and D_to_A you describe port1
> and port2 as 1 referenced to 2. In that case isn't this just one port
> having a + and a - node (two terminals).
Each port name is meant to name a particular terminal. There might be
an implicit two terminal definition of port if a global reference is
implied for the reference terminal. With a common implied global
reference, the plus and minus terminals can be used is if it were a two
terminal definition of a single port. However, in this document each
"port" name corresponds to a single terminal.
>
> 8) Also, I believe that you mistakenly used A_receive twice in this
> section instead of D_receive.
My mistake, this will be fixed.
>
> 9) In the "true differential" buffers section you also say "two
> differential ports", which is really ONE differential port.
I am consistent with the definition of 7) that each port is the name of
one terminal. So differential buffers have two ports.
>
> 10) The last section before the examples talks about the regular
> keywords under [Model] being useful for things if this is still not
> supported, etc. It would be nice to spell out what is required and
> what is optional from the old stuff if this new stuff is there.
Good point. The Other Notes section is revised to give a
minimal content rule.
>
> 11) The paragraph before the [External Circuit] is misleading, because
> it makes me believe that the [External Model] keyword can be placed
> anywhere in the document as it is with the [External Circuit].
A badly written clause that cause the confusion will be removed.
>
> 12) Regarding corners typ., min., max, comment same as above, Lynne
> wants more then three.
My response is similar to 3) above. Three corners consistent with
existing IBIS are defined. The user can work in more conditions with
extra files.
>
> 13) [Node Declaration] keyword is required for internal nodes. What is
> an internal node? Are the die pads considered internal nodes, since
> they are not listed on the pin list?
An editorial mistake causing this misunderstanding will be fixed. The
[Node Declaration] keyword documents internal nodes only.
>
> 14) The third [Circuit Call] example with BUS_SPI is confusing because
> the port names are not identified on the 4th drawing up front.
> Without those showing on the drawing I have a hard time to identify
> the connection between the pin to circuit, and then circuit to
> internal node, and then internal node to buffer port name.
The drawing is revised per 1), and the example should now be clearer.
>
> 15) There are a couple of "}" in this section.
Fixed, thank you.
>
> 16) The last paragraph before the true differential example uses 200m
> for Vlow etc. It should be spelled 200mV. Otherwise it means meters.
Fixed by using 200 mV.
>
> 17) In the example(s) you mention C_comp. This raises the question:
> With external models is it still required to have C_comp under the
> [Model] keyword? This is not mentioned anywhere (at least I couldn't
> find it). This doesn't make sense, because the external model could
> probably do a much better job in describing C_comp. On the other hand,
> if yes, than we need to have at least a C_comp_diff that is a
> capacitance between the two signal pins... Not to speak about the new
> ideas Luca proposed. I just found it now at the interaction limits.
> I wonder if it should be mentioned earlier.
Per our discussion, some things need to be stated more clearly. C_comp
and/or C_comp_* per existing rules is now required whether it is needed
or overridden. This will make checking simpler.
>
> 18) It should be mentioned somewhere in the "Reference Voltages"
> section that the an external model using SPICE should not have any
> global nodes (most often Vdd and Vss) because that will short them
> together across all of them, and thereby making the external circuit
> useless. (Global scaling factors could also be mentioned for similar
> reasons).
A caution statement is added.
>
> 19) In the interaction limits you mention "series switch" models using
> the [External Circuit] needing the [Series Pin Mapping]. I think this
> is also true for [Series Current] and [Series MOSFET] and I would
> mention them here too.
The statement is that BOTH Series and Series_switch models still need
the [Series Pin Mapping] keyword - if they are configured under the
[Model] keyword and/or use [External Model]. [Series Current] and
[Series MOSFET] keywords can be configured as Series models. So I
believe the specific keywords are already included - along with
[R Series], etc.
It is also possible to connect Series elements such as passive
components, diodes, etc. using [External Circuit] and the native
language elements. This is a way to bypass the [Model] keyword and
[Series Pin Mapping].
>
> 20) SPICE and AMS models can be parameterized very well. It would be
> a pity not utilizing this capability. However, I don't see any
> mention and provisions for bringing out the parameters from an
> [External Model] or [External Circuit] call to the user interface of
> the EDA tool. I think this could be done easily, we just need to
> define how.
This is an issue. While parameterizing model is useful, providing a
standard process may be difficult when supporting an number of language
variation. I choose to leave this as a function of the specific
external language.and have mentioned this under the EXTERNAL LANGUAGES:
heading.
>
> Arpad
> ===================================================================
-----------------------------------------------------------------
|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 : Tue Aug 27 2002 - 13:39:29 PDT