Re: SPICE compatibility issues

Jonathan Sanders wrote:

> Marq,
>
> Whether to include in the LRM or as part of a example suite is a good 
> offer that we should consider.
>
> I've always looked at Annex E (was around back when it was being 
> written) as more of a methodology guide.   The first couple of pages 
> point out most of the issues when dealing with the reality of EDA 
> tools yet provide a methodology of how each of the vendors (and users) 
> could work through this.
>
> The place we have strongly pushed away from was trying to 
> "standardize" SPICE from within the Verilog-AMS LRM.   SPICE is a 
> completely different language (please forgive me for calling it a 
> language) so we focused more on interoperability . 

I think creating a library of standard Verilog-AMS modules based on the 
SPICE models makes good sense at this point in time. Netlists should be 
portable, tools that currently produce SPICE netlists will have to 
produce Verilog-AMS in the future. Also, I don't think developing a 
validation suite makes as much sense without some way of limiting the 
scope to what people will actually be using - i.e. the initial 
validation suite would validate implementation/execution for the 
standard libraries.

As you say: it doesn't need to be in the LRM - as the SystemC library is 
not part of the C++ LRM.

> Vendors like Cadence have done the same thing for making VHDL and 
> Verilog talk together as well as SystemC, Matlab, and other 
> languages/tools.    In the case of SPICE and Verilog-AMS there was too 
> much required interoperability to ignore this so a methodology using 
> "standard" or "common" primitives was provided with the hope of some 
> standardizing between the vendors.   Some of the names were changed as 
> folks felt the table looked too much like Spectre syntax but the goal 
> was just understandable names.

Given the lack of effort I saw put into language interoperability in the 
development of SystemVerilog (apart from the half baked rehash of PLI as 
DPI). I'll have to say leaving "interoperability" in the hands of 
Cadence (Synopsys or Mentor) doesn't appeal much.

Kev.

>
> Jon
>
> At 08:00 AM 7/22/2005, 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.
>>
>> 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?
>>
>> Regards,
>> Marq
>>
>>
>> Marq Kole
>> Competence Leader Analog Simulation, Philips ED&T
>
> ***********************************************************
> Jonathan L. Sanders                  
> Product Engineering Director
> Custom IC Solutions
> Cadence Design Systems, Inc.     
> 555 River Oaks Pkwy
> San Jose, CA. 95134
>  INTERNET:jons@cadence.com    Tel: (408) 428-5654      Fax : (408) 
> 944-7027
> ***********************************************************
>