Re: SPICE compatibility issues

Muranyi, Arpad wrote:

>Kevin,
>
>First I feel I need to apologize for writing so much.  I am
>usually not this active on email reflectors, but these subjects
>are quite interesting, and close to my work...
>
>You are making a good point.  I think we need to distinguish
>between wanting to be compatible and making (automated)
>translations as easy as possible.  But even for the latter,
>the language must provide features which make the translation
>easy, without having to come up with all kinds of wrappers,
>hooplas and (excuse me my language) half-assed workarounds
>to get it done.  Case in point, my "define and strings" thread.
>
>Regarding making a library of standard models "that most
>vendors, users and foundries agree on" this will be tough.
>  
>
Verilog-AMS is different from Spice in that the user community can do 
this for itself rather than waiting for vendors to implement the models 
(as is the case with Spice), so simulator vendor buy-in is not required 
(I was think more of folks doing tools for parasitic extraction etc.). 
Foundaries have an incentive to make it easier to get designs onto their 
processes and users like stuff to be less error-prone so standard 
libraries are a plus. So I don't see it being too much of a hard sell. 
The simulator vendors can provide optimized compiled models for the  
standard library components,  and if they already  have other optimized  
models  they could contribute  equivalent (less optimal) Verilog-AMS  
models  to  the standard library.

>Not that it couldn't be done, I think I have already seen
>various university projects which have done it, or have even
>automated it, but there is another issue, IC vendor proprietary
>model files.  Companies like Intel will not make available their
>transistor equations (and the associated process parameters) to
>the public, so you will not be able to write a Verilog-AMS
>module for such transistors.  The only reason you see HSPICE
>models on occasions is because they can be encrypted (oooooouch,
>I bit my mouth), but even for those you have to sign your life
>away to get them.  Now, the funny thing is that even these
>HSPICE models are kind of fake, because the Intel internal
>SPICE simulator's transistor equations are completely different,
>so in order to generate the HSPICE models, you have to translate
>them.  And as with any translation, you have to make compromises,
>which costs you accuracy...
>
>  
>
Supportting encrytion is a language issue that we can address on another 
thread, but you can view a standard library as just a standard interface 
and substitute different model implementations if  that suits you. The 
important thing with the library is to define the names for the devices 
and the parameter sets, the actual implementation may be secondary 
(though it would be good to have a reference implementation for 
verification/validation).

Kev.

>Well, there, I spilled another can of worms...
>
>Arpad
>================================================================
>
> 
>
>-----Original Message-----
>From: Kevin Cameron [mailto:kevin@sonicsinc.com] 
>Sent: Wednesday, July 27, 2005 10:02 AM
>To: Muranyi, Arpad
>Cc: Geoffrey.Coram; verilog-ams@eda.org
>Subject: Re: SPICE compatibility issues
>
>
>I don't think it's the Verilog-AMS committee's job to work out exactly 
>how to migrate old simulator netlists into Verilog-AMS. The language 
>itself should (as much as possible) support re-writing the primitive 
>models of  old simulators in portable Verilog-AMS - it's up to the 
>vendors/users to do the translation.
>
>Going forward it would be good to have a standard library of models for 
>use with Verilog-AMS that have well defined parameters and behavior that 
>most vendors, users and foundaries agree on - I'm assuming these will 
>look pretty much like the current popular device models  used  by the 
>various Spice simulators, but are unlikely to match any specific Spice 
>exactly.
>
>IMO the activity of defining and developing standard libraries should 
>stay with Accellera, and the Verilog-AMS language development should 
>move to an IEEE SystemVerilog subcommittee.
>
>Kev.
>
>
>  
>