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@eda.org [mailto:owner-verilog-ams@eda.org] On
Behalf Of Kevin Cameron
Sent: Friday, July 22, 2005 10:01 AM
To: Marq Kole
Cc: verilog-ams@eda.org
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