> -----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 10:50:27 2004
This archive was generated by hypermail 2.1.8 : Mon Apr 05 2004 - 10:50:33 PDT