RE: SPICE compatibility issues

Of course, that is certainly an option.  It's just that
we may not want to end up with two libraries having the
same list of elements (R, L, C, E, F, G, H, M, J, D, etc)
but have slight differences making them incompatible with
each other, and perhaps even be mutually exclusive as far
as the usage model goes...

Arpad
===========================================================

-----Original Message-----
From: Kevin Cameron [mailto:kevin@sonicsinc.com] 
Sent: Monday, July 25, 2005 1:31 PM
To: Muranyi, Arpad
Cc: verilog-ams@eda.org
Subject: Re: SPICE compatibility issues


Don't know much about IBIS, but I'm sure we could have more than one 
standard library - e.g. we could start with a SPICE compatibility 
library, and then add others for IBIS or language interfaces.

Kev.

Muranyi, Arpad wrote:

>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
>>    
>>
>
>
>  
>