[ibis-macro] An interesting Verilog-AMS effort
- From: "Muranyi, Arpad" <arpad.muranyi@xxxxxxxxx>
- To: <ibis-macro@xxxxxxxxxxxxx>
- Date: Mon, 25 Jul 2005 12:28:42 -0700
Hello,
I am forwarding a message I just sent to the Verilog-AMS list
to ourselves. This is a response to the discussion on the
bottom. Please read it over and comment.
We can discuss this in our meeting tomorrow, which I hope
will not be cancelled...
Thanks,
Arpad
=============================================================
-----Original Message-----
From: Muranyi, Arpad
Sent: Monday, July 25, 2005 12:24 PM
To: 'owner-verilog-ams@xxxxxxx'
Subject: RE: SPICE compatibility issues
Hello everyone,
This thread caught my eyes, because there is a very similar
effort in progress as we speak in one of the IBIS Open Forum
subcommittees.
The details of why we are doing this may take too long to
explain here, so I am not going to go into that right now.
Let it be enough for now that in order to overcome a serious
modeling need, AND to prepare the way for wider acceptance
of Verilog-AMS (and VHDL-AMS) for behavioral I/O buffer
modeling, we are now working on a "standard library" which
would contain a set of SPICE primitives (elements) written
with the (analog only features of the) *-AMS languages. This
would primarily cover the basics, R, L, C, and the controlled
sources. I am not sure whether we are also going to include
active elements, such as diodes BJT-s, MOSFET-s, but for
behavioral modeling these would be less of an importance.
This effort is very similar to the suggestion that came up
in the "compatibility" discussion of this thread. And the
reason I am writing this is to raise awareness in both groups
about this, so that we wouldn't end up with two different
libraries which attempt to achieve the same thing.
Now, the difference between these two ideas is the purpose.
In the IBIS subcommittee, we are doing this to enable those
SPICE vendors who do not yet have an *-AMS engine to simulate
the *-AMS models. The idea is that if an (analog only) *-AMS
model is written using the "building blocks" of the "standard
library" we are in the process of writing, then the SPICE
engine could easily convert the netlist to their own SPICE
syntax, and then replace the standard library building blocks
of the *-AMS model by direct substitution with their own
SPICE elements, and simulate.
From this thread, I sense that the purpose is quite the opposite,
it is to enable the Verilog-A(MS) tools to take SPICE netlists
and simulate them without any conversion steps.
Regardless of what the reasons are, the outcome seems to be almost
the same, a library which contains SPICE elements converted to
Verilog-A(MS). As I stated earlier, I would like to make sure
that these libraries could be one and the same, to reduce
redundancy and confusion, etc... in the user community.
Thanks,
Arpad
==================================================================
-----Original Message-----
From: owner-verilog-ams@xxxxxxx [mailto:owner-verilog-ams@xxxxxxx] On
Behalf Of Kevin Cameron
Sent: Friday, July 22, 2005 10:01 AM
To: Marq Kole
Cc: verilog-ams@xxxxxxx
Subject: Re: SPICE compatibility issues
Marq Kole wrote:
>
> All,
>
> With respect to the Verilog-AMS LRM Annex E on SPICE compatibility I
> would like to make a few comments - and a donation.
>
> In table E.1 the names diode, bjt, mosfet, jfet and mesfet are
> essentially marked as specific use only, but at the same time their
> use in this particular form is prevented from occuring due to the
> limitations of SPICE-descendent circuit simulators - limitations, by
> the way, that do not apply to all analog circuit simulators . I think
> these names should be removed from the table E.1.
>
> If a certain primitive is not available in a circuit simulator that
> supports Verilog-A(MS), it should be possible to create a module in
> Verilog-A that operates exactly like that particular primitive. In
> that way these primitives can be used in all Verilog-A(MS) and they
> really can be depended on to be available in an implementation.
> This is possible for all primitives in the table E.1 except vpwl and
> ipwl. These two sources use a "wave" which is an arbitrary length
> array of time/value pairs. To make an Verilog-A implementation of such
> a source the arbitrary length array should be replaced with a
> parameter-length array, with the length parameter given before the
array.
I agree that these things should not be "built in" to the standard. In
particular Verilog-AMS netlists should be usable in different tools
which have varying levels of support. This was brought up many years ago
in the general discussion of "representation stops", and how do you
allow a netlist to carry multiple represenations of the same component
for different uses e.g. a digital simulator may want to use an nmos
primitive, but the analog simulator might want to use a spice model for
the same transitor instance - while it is possible to do this with
`ifdefs and re-netlisting, it is preferable that the language support
the both views simultaneously so that tools can automatically verify
that different views are functionally equivalent.
[Old proposal -
http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0019/index.html]
> Now the donation: I have created Verilog-A versions of all primitives
> in table E.1 and I am willing to donate these to Accellera as a set of
> basic primitives that can be used in all simulators that support
> Verilog-A(MS). This also includes vpwl and ipwl, only with the
> modified interface that includes a length parameter. Would this be an
> acceptable addition to the standard or would it have to have another
> status?
I don't think they need to be part of the language standard, but they
sound like they would be useful as part of the validation suite, or as a
seperate "standard primitive model library" (given that it will be a
while before there is another LRM released). What license are you
thinking of releasing them under?
I think having a sub-committee to handle both the validation suite and a
standard primitive model library makes sense - it could take
responsibility for adding new primitive models (e.g. BSIM*) as they
appear.
Regards,
Kev.
> Regards,
> Marq
>
>
> Marq Kole
> Competence Leader Analog Simulation, Philips ED&T
Other related posts:
