Re: V-AMS DevModeling meeting April 6, new proposal doc

Kevin -
I'm sorry you've missed some of these discussions in the
conference calls.

Those who were on the call felt that "ref" (the SV keyword
for pass-by-reference) was likely to collide with existing
Verilog-AMS modules. (Analog behavioral modules are VERY
likely to have a voltage reference pin.) Using inout or
output for analog functions just re-uses existing AMS
keywords, and from an analog simulation respect, there is
no difference in functionality.

Optional ports are already allowed in (digital) Verilog,
no need to go to SV. However, SV LRM 19.4, I don't see
method for determining whether the port is connected,
which is the only thing we're asking for in 4.1.

I could not find a section about "generate" in the SV LRM,
only the BNF snippets in the end. It's hard to see from
the BNF how this is intended to be used, or whether it
would address any of the paramset issues.

We also had a discussion about SV classes, although in the
context of hierarchy and inheritance. Al Davis says it's
really nice to build all your MOS models from a basic one,
then you only have to write the new things for each level.
However, we felt that this was akin to moving Verilog-A
from a C-like to a C++ like language, and this was too big
a jump for the functionality we need for compact modeling.

All of the extensions we are proposing are drawn from
existing functionality in SPICE-like simulators; hence,
implementation on the analog simulator side is simply a
matter of hooking up the Verilog-A compiler/interpreter
to use these existing functions.

If we try to get our extensions into SPICE-like simulators
by requiring implementation of huge chunks of a system-
level HDL, then perhaps Cadence and Synopsys would have the
resources to do it, but it leaves out all the smaller EDA
vendors and (particularly important from my perspective)
all the in-house simulators at semiconductor companies.
Our simulator does not implement the digital section even
of Verilog-AMS; so when V-AMS and SV merge, we will still
be concerned only with the analog subset.

-Geoffrey

PS: in re your multiple-whatever devices, netlists in our
internal simulator *do* carry that information; we had
multiple-gate rules defined well before BSIM4's "NF"
(number of fingers), and our characterization group has
special models/subcircuits for multi-emitter devices.

Kevin Cameron wrote:
>
> I was having a look at the proposals and it occurs to me
> that more stuff is being invented than is necessary.
>
> Since the long term aim is to combine Verilog-AMS and
> SystemVerilog, solutions should be taken from the SV LRM
> if possible. E.g. (SV LRM 10.5.2 Pass by reference) obviates
> section 3.1 (More flexible functions), and 4.1 (Optional ports)
> is probably covered by interface modports (SV LRM 19.4).
>
> Paramsets could probably be implemented on top of SV classes,
> and binning can probably be handled with "generate".
>
> http://www.eda.org/sv-ec/SystemVerilog_3.1_final.pdf
>
> BTW, an issue I tried addressing in the early days of Verilog-A
> was the use of multiple gate/source/drain or base/emitter/collector
> devices, after a designer friend told me that many design failures
> were due to people dumping devices into the same well and not getting
> the same results on Silicon as the simulator since the netlist didn't
> carry that information and the devices look independent. If anyone
> has suggestions for solving that problem I'm sure the users will
> appreciate it.
>
> Kev.
>
> Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862
Received on Mon Apr 5 06:06:10 2004