RE: Spice Netlist Translation Requests


Subject: RE: Spice Netlist Translation Requests
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Thu Feb 22 2001 - 13:20:24 PST


> From imw@antrim.com Thu Feb 22 11:19:48 2001
>
> > Since it may be necessary to translate back and forward between
> > Verilog-A[MS] and Spice, I think we should definitely find a
> > namespace and make the Annex E Table E.1 official primitives of
> > Verilog-A[MS]. Any parameters that can't be agreed on should be
> > passed by attributes, and any primitives we can't agree on will
> > be left until we have an accepted primitive declaration mechanism.
> >
>
> Verilog-AMS at present doesn't add any primitives to the language.
> Adding them at this stage would require detailed definition of where
> such primitives could be used, what their connection rules are,
> whether analog UDPs can be written, etc... This seems like a lot of
> extra work at this stage of the language's life.

The choice (IMO) is either an official set of primitives or some
external/primitive module definition mechanism that translators can
use. If we can use Verilog-2000 configuration semantics somehow to
make defining an official set work I'd recommend that, if that isn't
an option then we need some kind of aliassing mechanism in the primitive
declaration that will make designs fully portable. E.g. something like:

   `ifdef __VAMS__
   repstop nmosfet(d,g,s,b);

        alias spice::mosfet(d,g,s,b); // if we are handling spice
           // ^^^^^^^^^^^^^ Spice equiv (As in Annex E))
              parameter model = "NMOS3"; // base object overrides
        endalias;

        alias digital::rnmos(d,s,g); endalias; // for Verilog-D

        alias bsim4.5(d,g,s,b); // use if found
              parameter model = "N*";
        endalias

   endrepstop
   `endif

- syntactically and semantically much the same as a macro module, just
pick the applicable alias. I used 'repstop' for "representation stop"
because 'primitive' is already taken. Translators would create such a
block to match their output.

> Parameters: note that the SPICE treatment of default values is quite
> different from Verilog's (SPICE makes use of the fact that no value
> has been specified for a parameter to interpret other parameters).

Do we have any proposal for getting the same behavior? Anyway, I think
the requirement is more that it should be possible to translate a Spice
netlist at a structural level into Verilog-AMS and get the right parameter
values on each device in simulation, rather than a direct source code
device instance translation.

Kev.



This archive was generated by hypermail 2b28 : Wed Feb 23 2000 - 09:33:20 PST