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

Just a quick comment. You are going to have to eventually accept all of the new keywords in SystemVerilog anyway so the argument
that ref may collide (while true) is not particularly relevant. Changing the syntax will not be an option since SystemVerilog is now
an approved standard.

Regards

David

-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Kevin Cameron
Sent: Monday, April 05, 2004 10:50 AM
To: Geoffrey.Coram
Cc: Verilog-A Reflector; verilog-ams-devmod@eda.org
Subject: RE: V-AMS DevModeling meeting April 6, new proposal doc

> -----Original Message-----

> From: Geoffrey.Coram [mailto:Geoffrey.Coram@analog.com]

> Sent: Monday, April 05, 2004 6:06 AM

>

> 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.

I didn't want to use "ref", I proposed/voted for just using

C's '*' but that was rejected. So I agree with your concern.

However, two mechanisms for doing exactly the same thing are

unlikely to be allowed later when it comes to reconciling the

languages, so you might as well bite that bullet now.

> 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.

You may want to check for no external drivers/contributions/

receivers rather than "no connection", since the user may put

a wrapper round a model which connects the port but then the

wrapper port may not be connected. Also, hierarchical references

connect without ports.

> 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.

It's in the Verilog 200X LRM (I don't have a copy handy).

generate statements are evaluated at elaboration time dependent

on parameters etc. and let you choose different sub-modules and

behavior.

> 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.

As above, doing that works against reconciling the languages

later. Verilog-A already uses inheritance for disciplines and

natures.

SV "interfaces" could probably also be used for parameter set

storage.

> 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.

Parsers are the easy part of building (Verilog) HDL tools,

there are even some open-source Verilog tools that'll do

most of that for you, so I don't think that's an obstacle

(at least for the in-house folk).

Cadence & Synopsys will be integrating their Verilog-AMS

with SystemVerilog and are likely to change stuff they

don't like in the process (since they've got more clout

and resource), so my advice is to avoid conflict and go

with SV syntax now. NB: the number of people working on the

SV committees (& IEEE) far out-weighs the number working on

Verilog-A(MS).

> -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.

>

Ah, so you agree it's a problem then :-)

Part of the job of this kind of committee is to take ad-hoc

solutions and come up with formal (explicit) mechanisms in

the language that handle the cases in a portable way.

What I was looking for was syntax for device declaration that

lets the user specify (say) a multi-drain device, so that the

simulator can use a special model. E.g. if a device/module is

declared as mos(gate[],drain[],source[]) then you can instantiate

it as mos mos_d2 (.gate(g),.source(vss),.drain[0](d0),.drain[1](d1))

for a double drain. (See SV LRM 4.6 - Dynamic arrays).

The aim is to try to capture designer intent (as much as possible).

Kev.

Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862

>

> 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 11:21:11 2004