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