Subject: RE: [IBIS] BIRD 75 comments
From: Reid, Chris (chris_reid@mentorg.com)
Date: Wed Aug 28 2002 - 10:38:04 PDT
Arpad,
I've responded to your comments line-by-line below.
Chris Reid
Mentor Graphics Corporation
Work: 503-685-0731
Home: 503-624-8159
Mobile: 503-869-6703 (global enabled)
You wrote:
Chris,
Thanks for your comments and answers. In general, I feel that
there are a few things that you say here which do not come through
the BIRD as I read it. Let me respond to your points.
1) From this response I am starting to feel that the same buffer
could be written up four different ways in the same IBIS model.
However, reading BIRD75 it clearly states that there can be only
one [External Model] under each [Model] and I didn't get the notion
that the old [Model] should contain an equivalent "old style"
description of the same buffer that is described more accurately
in the [External Model] (as it was done with the [Driver Schedule]
keyword).
>chris> In general I think it is a good idea to have IBIS data
>chris> as a back-up for the [external model]. Its not required, but
>chris> from a model developer point of view it increases the number of
>chris> tools that will be able to use your model, even if not in its
>chris> most accurate form. This is similar to the situation with
>chris> the time waveforms. Early one some tools could not use them so
>chris> they reverted to ramps.
In the second paragraph you say: "With an [external model] you can
just specify it in the [pin] section of the [component]". I thought
that the [External Model] keyword could only be placed under the
old [Model] keyword. I don't understand this statement.
>chris> What I meant is that you can use an [external model] simply
>chris> by specifying the [model] name in the [pin] section of the
>chris> [component]. This is not true for an [external circuit]
>chris> which must be connected using [circuit call]s. The reason
>chris> for this difference is that the tool knows how to use an
>chris> [external model] automatically given its standard interface.
>chris> There is no such standard for [external circuit]s.
We also
would have to define the word "interface", because I am not sure
what you are talking about. It seems that you are more referring to
connectivity (nodes), but I was more talking about the specification
parameters (Vmeas, Vinh, Vinl, etc). which are also running out of
steam in the old IBIS spec. We have already done a major corrective
step in this regard when we introduced the [Model Spec] keyword, but I
think that this technique of having only a predefined set of parameters
is what is too limiting. Think of it as the .MEASURE statement of
HSPICE. They have rules for their syntax, but I can write all kinds
of very complicated measure statements with them (not just use a few
hard coded ones).
>chris> You're right. We are getting confused by using "interface"
>chris> for multiple things. To me the interface means the ports and
>chris> the generics that can be passed into the model. Also, I
>chris> agree that we should find a way to generalize measurements.
>chris> We may be able to do that by allowing the definition of additional
>chris> ports on the model that report various conditions. VHDL-AMS
>chris> has a lot of capability in that direction. For SPICE we would
>chris> need some other methods, but perhaps similar.
2) By parameterization I mean, for example, there is an equation
in the [External Model] which uses a coefficient that can turn that
equation into a typ., min, or max. case (or anywhere inbetween).
How can I pass a value into that coefficient? One way would be
to use a voltage that represents that value, but that is not always
nice. Plus, depending on the precision settings of the tool, some
times small voltage numbers get rounded to zero. (I had problems
expressing time as a voltage when it was just pico seconds, because
it got zeroed out). Of course, this is just one simple example...
>chris> This is actually a possibility that was considered here before
>chris> we issued the BIRD. I'm not sure how to do it, and we decided
>chris> to keep the BIRD relatively simple. Its a good idea, and
>chris> we should look at possible ways to make it happen.
Looking at this from a distance, this is the way I would summarize:
First we realized that IBIS was too rigid, so we asked the question
"Is IBIS dead, are we all going to turn back to SPICE"? Then we said
let's keep the good parts of IBIS, which are the specification related
parameters, formats, etc., so we came up with the nodal and macro
language ideas which later turned into BIRD75. This debate over the
position of [External Model] made me realize that the "good parts of
IBIS" are also too rigid, and I am starting to feel more that we need
to address those too. I agree that some of these ideas may seem to be
"luxurious" now, but we are making a quantum step now with BIRD 75.
BIRD75 is not just a patchwork on the old spec., it is a major change.
I don't know when we will make such a large step again, and keep writing
BIRDs for specification parameter changes for that long may not be a
good idea.
>chris> I agree. However, we might get there in multiple useful steps.
Thanks,
Arpad
=====================================================================
-----Original Message-----
From: Reid, Chris [mailto:chris_reid@mentorg.com]
Sent: Tuesday, August 27, 2002 1:46 PM
To: 'Muranyi, Arpad'; ibis@eda.org
Subject: RE: [IBIS] BIRD 75 comments
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)
-----------------------------------------------------------------
|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 Aug 28 2002 - 10:58:54 PDT