Subject: RE: [IBIS] BIRD 75 comments
From: Reid, Chris (chris_reid@mentorg.com)
Date: Tue Aug 27 2002 - 13:45:32 PDT
Arpad,
You raise some good points. Maybe we should get together
face-to-face to discuss your ideas. In the mean-time
here is a short response with my perspecitve on your issues.
1) The [external model] exists inside the [model] because
it is meant to replace the electrical contents of [model]
but still use the voltage references, etc. The strength of
this approach is that one model can have both IBIS and SPICE
or VHDL-AMS representations. If the tool can use the SPICE
or VHDL-AMS then fine, otherwise it can drop back to the IBIS
data. Thus it seems advantageous to keep the IBIS data at
least somewhat consistent with the [external model] behavior,
although this is not required.
The disadvantage is, as you say, constraining the new models
to an interface specified by old IBIS. But, don't forget that
the [external circuit] construction has no such restrictions.
An [external circuit] can have any interface at all, and the
cost you pay for that is that you must use [circuit call]s
to hook an [external circuit] up inside the [component]. With
an [external model] you can just specify it in the [pin] section
of the [component].
I have trouble imagining what the interface to a model should
be so that an automatic tool can use it but there is still
perfect freedom for the model developer. Of course we can
develop a new interface, or extend the existing one, but it
seems logical to start with the existing one.
2) Paramaterization of models: I'm not sure I understand what
you mean in that section. However, consider the logic thresholds.
The [external model] interface includes a digital terminal called
d_receive. That is where the logic decisions of the receiver
are supposed to appear. Tools computing delay should use the
output of that terminal in preference to some logic thresholds.
That gives the model designer complete freedom in designing the
logic decision circuitry of the model.
Similar things could be done for other measurements. For example
maybe there should be a terminal the model could use to signal
that the device is being driven so hard it is likely to fail in
pratice. This could replace the overshoot and undershoot paramters
with something more flexible.
Chris Reid
Mentor Graphics Corporation
Work: 503-685-0731
Home: 503-624-8159
Mobile: 503-869-6703 (global enabled)
You wrote:
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 - 14:06:09 PDT