Subject: RE: [IBIS-Users] Questions Regarding Bird 75.8
From: Muranyi, Arpad (arpad.muranyi@intel.com)
Date: Thu Jan 09 2003 - 14:58:16 PST
Al,
I am glad that we are converging... and thanks for your continued comments
and suggestions. Here are a few responses.
> It is for things like Vmeas, which isn't represented in Spice.
> The BIRD should say this.
We could add something to the "Introduction" of Section 6b to make this
clearer, but I will have to consult the other authors of the BIRD too before
it will happen. Also, there is another, non-technical reason for keeping IBIS
as a wrapper with these languages.
Current tools include or accept much more information than just buffer data.
Package, board and system interconnects are modeled today using a variety of
methods: physical geometries (through field solvers), s-parameters and the like.
While many of these formats and methods can be duplicated in AMS, there isn't
yet an open library of such solutions available, nor do most SI engineers have
the AMS background to create them. Having an AMS-IBIS interface enables
users and tools to continue to model and simulate non-buffer system components
under these other methods while taking advantage of AMS's flexibility in
modeling buffers. Your implication is correct: were a standard library or
set of conversion routines available, an AMS-only simulation environment might
indeed be able to model system SI as well as or better than today's methods
allow.
> I must confess .... It is a lot better in .7 .. Bob's files
> help, too. It would be clearer if [External Model] and
> [External Circuit] were different BIRDs, since they don't
> depend on each other.
Thanks! FYI, the latest is 75.8, not .7 (just in case you missed it), but the
changes are minimal. Regarding making two separate BIRDS, I think there is
a strong relationship between the keywords -- the same external languages are
used in both, plus many other details -- which would make two
independent BIRDs have big overlaps and probably too repetitious. Either way,
none of us wants to start over rewriting these. It took long enough as it is...
> It said those keywords are optional when [External] is used,
> but didn't say how it is resolved. I interpreted it to mean
> that both circuits are present, and the external one is added
> to the old style one.
>
> Apparently, what you mean is that when both are present, the
> simulator must choose one or the other. Both cannot be active
> at the same time. If I interpret it this way, it makes sense
> and answers #3.
Yes, they were intended to be alternates, not additive. We should perhaps
make the text clearer on that. Good comment.
> Given this approach, it is unreasonable to have only one old
> style keyword, say [Pullup] without the complete set. The BIRD
> makes it look like you can have only one. I propose that it be
> documented that if any old style parameters are present, there
> must be a complete model.
> I think a better approach is to disallow the old-style
> parameters when [External Model] is used. The functionality
> can be provided with [Model Selector].
There are two problems with completely disallowing the "old-style
parameters":
1) measurement and voltage supply levels, and reference loads
2) backward compatibility
For (1), we have required some traditional IBIS threshold information
to ensure that tools can evaluate system response using the new
buffer data according to user needs. The voltage supply information
ensures that the buffer is correctly powered in simulation and that
corner variations are correctly included. Put another way, [External Model]
provides the "training wheels" necessary to get IBIS users into
the AMS world while maintaining familiar and useful aspects of
traditional IBIS.
For (2), BIRD 75 makes it possible for model makers to provide both
AMS/SPICE model data and native IBIS model data to users, in case
their tools do not support the new keywords. [Driver Schedule],
you may recall, does much the same thing.
Besides being a hassle, to require complete native IBIS
model data means that model makers would no longer have the choice of
whether to be a good "IBIS citizen" and provide both sets of data or not.
This would make it nearly impossible to "move beyond" the current IBIS
keyword limitations, which was the whole intent behind BIRD 75. You are
right that having a [Pullup] by itself is permitted under the current BIRD
language. Though not what we intended nor very likely, this could be
used as a kind of "golden waveform" for comparison against the AMS or
SPICE data.
> I noticed that the list of optional old-style keywords did not
> include driver schedule and submodels.
>
> Please confirm that my new interpretation is correct.
You saw this correctly, however, I need to explain it, because I
don't think you understood it completely. The list of "optional
old-style keywords" was intended to tell you which keywords that
used to be required are not required any more. The [Driver Schedule]
and [Submodel] keywords were not required, so they do not need to be
listed in that list. Whatever was optional still remains optional
and doesn't need to be talked about in that context.
> What I mean is to say something like: an IBIS [Model] is
> equivalent to a Spice ".subckt" with a specified name
> convention, and a particular node list. That way, it could be
> substituted easily in the simulator's native way.
>
> If you look at mixed Spice - Verilog-A simulators, they don't
> distinguish which is which externally. A Verilog-A "module"
> looks just like a subckt (X...) in Spice format. Likewise, a
> Spice .subckt can be called by Verilog mode, just like a module.
>
> Some simulators do this already, but all different. There
> would be significant value in standardizing this.
I wonder what you would like to standardize. The syntax of the
ports of a *-AMS module and SPICE subcircuit, so that this BIRD
wouldn't have to handle them as different cases? Or the number
of ports an [External Model] has (perhaps 7)? If so, I think
that would be a much bigger task than this BIRD can handle. If
not, I would like you to explain this a bit more to me.
> Well, obviously to read an IBIS file it must be capable of
> reading an IBIS file. I was thinking of analog-digital
> interfacing. IBIS can provide significant advantages here, but
> I need to be convinced that this version does.
I am not sure I understand what you are getting at here. Please
explain more what you mean by "analog-digital interfacing".
> This comment was directed at the fact that developing and
> testing models is now a problem, and has always been. Certain
> issues seem to come up way to often, and are often answered
> incorrectly, so the confusion continues. IBIS 3 and 4 added
> several new features that are difficult to measure and validate
> in practice.
>
> By the way .... How do you measure the 4-part C_comp on a real
> circuit?
Yes, in later version of IBIS we started to deviate from the original
goal of having only such data in IBIS that can be measured on the
bench. However, there are tricks you can do. For example, if you
can't measure the C_comp_pullup and C_comp_pulldown, etc. separately
on the bench, you can measure the total C_comp, correlate that to the
total C_comp you measure on your SPICE model, then get proportions
off of your SPICE model for the 4 subsets of that capacitance through
simulations and apply those coefficients to the measured value. This
is just one way I could think of. But this is a subject that will
require cleverness on the part of the model maker, and just as I can't
teach the ***art*** of circuit design to a student, I can't teach the
***art*** of modeling either. This subject goes way beyond the scope
of this BIRD or even the spec itself.
Arpad Muranyi
Michael Mirmak
======================================================================
-----Original Message-----
From: Al Davis [mailto:aldavis@ieee.org]
Sent: Thursday, January 09, 2003 1:48 AM
To: Muranyi, Arpad; ibis-users@eda.org
Subject: Re: [IBIS-Users] Questions Regarding Bird 75.8
I am beginning to see some value, and it is clearing up.
On Wednesday 08 January 2003 11:36 am, Muranyi, Arpad wrote:
> Regarding your request for the examples demonstrating that
> this approach is superior to a SPICE or *-AMS only approach I
> wonder what kind of superiority you think of?
There must be some, otherwise the proposal has no value. You
tell me!
> ...... A SPICE or
> *-AMS model will result in the same waveforms and/or
> accuracy, regardless whether they are embedded in this IBIS
> wrapper, or not. So from that point of view I don't see any
> difference there.
That's what I mean. If there is no difference, why bother?
> .... However, from the user's perspective,
> there are some usage model differences which makes the life
> of the user easier. The IBIS wrapper provides additional
> information for the simulation tool, helping in automating
> the measurement tasks, and providing information about
> reference loads, etc... without effecting the model behavior
> itself. That is the benefit of having these languages
> embedded in IBIS.
ok. That's what I was looking for.
With the examples, I see that now ....
It is for things like Vmeas, which isn't represented in Spice.
The BIRD should say this.
> 2) You mention that this approach is confusing. Could you
> please elaborate on what the confusing part is, so that we
> could address it if possible?
I must confess .... It is a lot better in .7 .. Bob's files
help, too. It would be clearer if [External Model] and
[External Circuit] were different BIRDs, since they don't
depend on each other.
> 3) You say that "it doesn't even come close to solving the
> problem". I am not sure what you are referring to. Could you
> please give a problem statement as you see it? We can't
> solve a problem if we have a different opinion on what it
> is...
Let me think about this one.
> 4) The BIRD allows for an "old fashioned" model under the
> [Model] statement to coexist with the new [External Model]
> keyword that provides the SPICE or *-AMS description of a
> device. It is up to the model maker to make a duplicate
> model of the device both ways. If they write such a duplicate
> with the old [Model] keyword, tools which cannot process the
> new keywords can simulate just like today. If the model maker
> doesn't care to do that, you may be out of luck.
That is another thing that I found unclear, but I think I see
it now.
It said those keywords are optional when [External] is used,
but didn't say how it is resolved. I interpreted it to mean
that both circuits are present, and the external one is added
to the old style one.
Apparently, what you mean is that when both are present, the
simulator must choose one or the other. Both cannot be active
at the same time. If I interpret it this way, it makes sense
and answers #3.
Given this approach, it is unreasonable to have only one old
style keyword, say [Pullup] without the complete set. The BIRD
makes it look like you can have only one. I propose that it be
documented that if any old style parameters are present, there
must be a complete model. It should also be documented that if
both new and old forms are present, they are treated as
alternatives.
I think a better approach is to disallow the old-style
parameters when [External Model] is used. The functionality
can be provided with [Model Selector].
I noticed that the list of optional old-style keywords did not
include driver schedule and submodels.
Please confirm that my new interpretation is correct.
> 5) I do not understand your question: "How it is superior to
> documenting an equivalence between the languages, like the
> equivalence between Spice and Verilog-A is documented."
> Please explain what you mean by "documenting equivalence
> between languages".
What I mean is to say something like: an IBIS [Model] is
equivalent to a Spice ".subckt" with a specified name
convention, and a particular node list. That way, it could be
substituted easily in the simulator's native way.
If you look at mixed Spice - Verilog-A simulators, they don't
distinguish which is which externally. A Verilog-A "module"
looks just like a subckt (X...) in Spice format. Likewise, a
Spice .subckt can be called by Verilog mode, just like a module.
Some simulators do this already, but all different. There
would be significant value in standardising this.
> 6) Regarding "How it impacts mixed mode simulators", it
> depends on whether they have a parser that can read the IBIS
> file. They should certainly be able to process the *-AMS
> portion of the IBIS file without difficulty. However, in
> order to read and make use of the rest of the information, an
> IBIS parser would need to be implemented. This should not be
> a large undertaking, however.
Well, obviously to read an IBIS file it must be capable of
reading an IBIS file. I was thinking of analog-digital
interfacing. IBIS can provide significant advantages here, but
I need to be convinced that this version does.
> 7) Regarding "How such a model can be developed and tested",
> this is a complicated question, because of the freedom these
> languages provide. There are zillions of ways to write a
> model. One way would be an equivalent IV and Vt table based
> equivalent in one of the AMS languages. Another way would be
> to use the same data, but curve fit them to equations and
> write those equations up in AMS syntax. For SPICE lovers, I
> could imagine someone to write up the transistor equations in
> AMS syntax, and provide the usual process file information
> and netlist of transistors in the AMS file. I can also
> envision many other ways using higher level behavioral
> techniques, some of which may even be proprietary and
> patentable.
This comment was directed at the fact that developing and
testing models is now a problem, and has always been. Certain
issues seem to come up way to often, and are often answered
incorrectly, so the confusion continues. IBIS 3 and 4 added
several new features that are difficult to measure and validate
in practice.
By the way .... How do you measure the 4-part C_comp on a real
circuit?
There is a new validation capability here that probably should
be exploited. The external and old style can be validated
against each other. It was not clear originally that this
could be done.
> I hope I answered some of your concerns.
Yes. Thank you.
|------------------------------------------------------------------
|For help or to subscribe/unsubscribe, email majordomo@eda.org
|with just 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 written 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 Jan 09 2003 - 15:10:59 PST