Subject: RE: Reading Spice?
From: Ian Wilson (imw@antrim.com)
Date: Wed Feb 21 2001 - 12:34:43 PST
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.
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.
============================================================================
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".
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.
--ian
This archive was generated by hypermail 2b28 : Wed Feb 23 2000 - 06:48:48 PST