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