Subject: Re: [IBIS-Users] Questions Regarding Bird 75.8
From: Al Davis (aldavis@ieee.org)
Date: Thu Jan 09 2003 - 01:47:59 PST
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 - 02:00:55 PST