Subject: RE: Reading Spice?
From: Jonathan Sanders (jons@cadence.com)
Date: Sun Feb 25 2001 - 20:31:47 PST
Ian,
I think you did a good job at breaking this down into the bite-size (big bites)
issues and levels of support. I have a few comments below.
Jon
At 12:34 PM 2/21/01, Ian Wilson wrote:
>The Design Objective that addresses the SPICE issue places the emphasis
>on providing a migration path for existing (let's call it "legacy") designs
>consisting mostly of SPICE.
>
> >From an LRM point of view, this is important because it suggests that
>simulators may need to provide specific mechanisms for such legacy designs.
>Since there are many different flavors of SPICE in use, such mechanisms
>will a) have to be fairly general-purpose and b) there is little question
>of 'reading' SPICE decks without the aid of some kind of translator program.
>The LRM concerns itself only with the mechanisms that may be required.
>It is useful to identify several levels of SPICE 'support':
>
> 1. SPICE subcircuit = Verilog-AMS module
> 2. importing SPICE models
> 3. SPICE parameter mechanisms
> 4. SPICE global mechanisms
> 5. name space mappings & hierarchical structure
>
>Level 1 is straightforward: subcircuits and modules can be interchanged;
>SPICE subcircuit ports are assumed to be scalar and of some convenient
>discipline; SPICE parameters are mapped to Verilog pound params. The
>means for reading the SPICE definition are vendor-specific.
>
>Level 2 is required to support the typical SPICE scheme where models are
>placed in libraries and are used to resolve model name references. This
>may be a purely SPICE-level function or some language variants may benefit
>from the ability described in the LRM SPICE Annex whereby instances of
>SPICE devices requiring models can be instantiated using the model name.
This and Level 1 are somewhat linked as many foundries (TSMC) are now
providing subckts as models. They have accepted that SPICE is not a standard
and provide models in the formats of several key vendors. We have treated
the loading of SPICE models as outside of the language which works fine and the
instantiation of these models the same as Level 1.
>Level 3 is required because the SPICE and Verilog parameter resolution
>mechanisms are very different. It is not possible to solve some of these
>issues purely by translation, since not all the scoping information is
>available to the translator - it requires Verilog-AMS elaboration. These
>problems become very visible when intermixing SPICE and Verilog.
>
>Level 4 is required if equivalents to SPICE global nodes and parameters
>cannot be realized through translation. Simple approaches such as appending
>globals to translated module definitions become unworkable in practice.
>Level 5 is caused by clashes between the SPICE and Verilog name spaces.
>Some conflicts can be resolved by using escaped identifier mechanisms.
>Others, such as use of reserved words, may not. The hierarchical
>structure of a SPICE design is different from a Verilog design: the top
>level of SPICE can contain primitives, whereas the top level of Verilog
>contains modules without port bindings. This is important when working
>with tools with a specific view of names in the (legacy) design.
Note, the same issues for 3,4,5 also apply to mixed langauge (VHDL / Verilog)
and one might have to put restrictions in your flow in order to support this.
>============================================================================
>
>I would expect general agreement that 1 & 2 are a requirement - without
>these we cannot begin to satisfy the Design Objective. The real problems
>are concentrated in 3 & 4. What, if anything, needs to be added to the
>current language to support these?
>
>Putting my implementor hat on for a moment, the present Annex doesn't
>help much with importing legacy designs. I can see that it is a useful
>approach to adding instances of SPICE devices into a new design, however.
>This discussion focuses on implementors, since the user requirements
>are generally loud and clear: "keep it working the way it used to".
The only way for legacy designs is to either re-netlist the design into
Verilog-AMS
which from a schematic will be ok in most cases or instantiate it as a
subckt. The
latter assumes that you support the subckt syntax and features which is vendor
specific.
>Proposal: work from the Design Objective to determine what "providing a
>migration path" means in a practical context. Determine what level(s) of
>support is(are) required of a conforming simulator. Modify the Annex
>accordingly.
I agree and wonder if we are really that far off? We certainly went much
farther
than VHDL-AMS did.
>--ian
This archive was generated by hypermail 2b28 : Mon Feb 26 2001 - 09:02:05 PST