Subject: Re: Reading Spice?
From: Kevin Cameron x3251 (Kevin.Cameron@nsc.com)
Date: Tue Feb 20 2001 - 10:05:41 PST
> From jons@cadence.com Tue Feb 20 00:57:22 2001
>
> The bounds of this leap is pretty far from the LRM. The LRM does not discuss
> reading SPICE netlists except as a black box subckt but it does discuss
> accessing internal analog primitives, lets just assume SPICE primitives, in
> a Verilog structural netlist. You would need to extend the LRM to not only
> support Verilog structural but SPICE structural for what you are asking for, and
> then one might ask which version of SPICE?
I don't want to specify a lot of stuff about how people should write Spice for
compatibility, "black box" is fine - but currently there is not even a formal
declaration mechanism for "black box" stuff. I'll assume the mechanism is something
like the "external module" proposal
(http://www.eda.org/verilog-ams/htmlpages/tc-docs/issues/0006/index.html),
and although it's primarily aimed at Spice compatibility, there's no reason that
it couldn't be other languages.
Currently I'm not looking for support beyond specifying primitives and doing
SPF back-annotation.
> So the answer to your question from the Verilog-AMS LRM, no. Support of
> SPICE netlists are vendor specific features in which the three vendors I have
> seen lately deal with this completely differently. This should be thought of as
> a migration tool only. Trying to define this would be defining a standard connection
> to a non-standard language, something I would be opposed to. Likewise
> producing a flow that still requires SPICE netlists is moving backwards and will
> prevent us from ever becoming a true standard. Of course if your view is that
> Verilog-AMS is just an analog behavioral modeling tool then one could
> potentially argue for this.
My problems are back-annotation and tool migration. I'm not a purist, most of the
tools we currently have are using spice netlist, and that will not change overnight.
If I want to accelerate the adoption of Verilog-AMS we need defined methods for
interoperability.
> Why not solve this with what the LRM gives you? If you use the language then
> you have a chance of getting all of the vendors to support your request. Why not
> enhance your SPF tool to produce VerilogAMS structual? it really is just a issue
> for the formatter. Doing this would allow OOMRs to work and all within the legal
> limits of the language. Of course whether OOMRs will work and the issue of
> not renetlisting are not guarantee to be solved by this.
The problem is that it's not my SPF tool. If I write a translator I introduce an
extra source of errors and suck up more gigabytes of disk space, and it's
longer before we can use a full Verilog-AMS flow (i.e we don't buy as many licenses).
At a minimum I would need a formal mechanism in Verilog-AMS for "piping" Spice into
the simulator through a translator to avoid the disk-space problem - possibly as part
of the external module definition.
> -jons
I think you're throwing rocks :-)
If everybody can read SPF and do the OOMRs, then this shouldn't be a big deal from
either a language specification or implementation standpoint.
Kev.
This archive was generated by hypermail 2b28 : Tue Feb 20 2001 - 10:20:57 PST