Subject: RE: VerilogAMS Committee Meeting Minutes - 15 December 2003
From: David W. Smith (David.Smith@synopsys.com)
Date: Wed Jan 07 2004 - 10:12:54 PST
Greetings,
Just a comment on the use of attributes for semantics. The way attributes
are defined in 1364 and in SystemVerilog is vendor dependent. There is no
provision in the current definition for defining attributes as part of the
standard nor anyway to enforce it. The current definition provides a way to
give a name plus a value that can be interpreted however a vendor desires or
ignored at the will of a vendor.
Jay Lawrence, from Cadence, has proposed something in both 1364 and
SystemVerilog to try to create a new kind of attribute (a system attribute)
which could be defined and required to be supported by Vendors. No such item
exists as of yet and the proposal has not been reviewed or approved.
Hopefully, at some point in the future, Verilog/SystemVerilog will have a
better extension mechanism but this is not currently it.
Regards
David
-----Original Message-----
From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf
Of Martin O'Leary
Sent: Tuesday, January 06, 2004 9:20 PM
To: Geoffrey.Coram
Cc: Chandrasekaran Srikanth-A12788; Verilog-AMS LRM Committee
Subject: RE: VerilogAMS Committee Meeting Minutes - 15 December 2003
> -----Original Message-----
> From: Geoffrey.Coram [mailto:Geoffrey.Coram@analog.com]
> Sent: Wednesday, December 17, 2003 11:56 AM
> To: Martin O'Leary
> Cc: Chandrasekaran Srikanth-A12788; Verilog-AMS LRM Committee
> Subject: Re: VerilogAMS Committee Meeting Minutes - 15 December 2003
>
> Martin O'Leary wrote:
>
> [Re: NMOS and PMOS as strings ...]
> > SV supports enums - is this a better way to do it rather than strings?
>
> I'm having my first glance through the SV 3.1 ballot draft 6.
> I see enums as variables, but not as parameters.
Good catch - didn't realize that it didn't apply to parameters although it
does seem like a reasonable extension.
> Can they
> be parameters? If so, then it looks like this would work,
> since it allows us to restrict the valid values to the
> enumerated ones, and detect which was specified. I guess
> it would look like this in the module:
>
> parameter enum {NMOS, PMOS} type;
>
Perhaps but the point you raise in the next paragraph suggests that some
care needs to be taken on how this is defined. In C, the typedef of an
argument passed to a function must be visible to both the function call and
the function definition so the same principle might need to apply here for a
clean language definition.
> What happens in a netlist, specifically whether the value needs
> to be quoted to prevent confusion with a netlist variable named
> NMOS, I guess is a simulator implementation detail.
If the netlist is a SPICE netlist, I agree but if the netlist is
Verilog-AMS, believe we need to standardize on this.
>
> > Sri or Geoffrey,
> > Can one of you define precisely what is meant by the term "visible" and
> "hidden"?
> > Does this means OOMRs are not supported? What features of Verilog(-AMS)
> are not supported for "hidden" variables?
> > Does it only mean that operating point parameters are not printed by a
> compliant simulator?
>
> For the purposes of the compact modeling extensions, the "visible"
> variables are meant to be those that would be printed as operating
> point parameters by a compliant simulator; many such simulators
> also allow plotting of these variables as a function of the sweep
> (eg, GM as a function of VGS). In Spectre, "save M1:all" if M1 is
> a Verilog-A module, results in an output file that contains
> datapoints for all the module-level variables.
>
> I do not mean to restrict any features or OOMRs. If you have a
> better term, I would welcome it.
This definition seems very specific to device models and not applicable to
Verilog(-AMS) modules in general - therefore I think hiding variables should
be handled by putting an attribute on the parameter declaration. Understand
that attributes were intended for application specific purposes such as
this.
Maybe this might be more typing for folks but if there are up to a 1000
parameters of bsim model, I expect cut-and-paste would be used by modelers
anyway so this attribute mightn't be such a chore to deal with.
--Martin
>
> -Geoffrey
>
>
> --
> Geoffrey J. Coram, Ph.D. Senior CAD Engineer
> Analog Devices, Inc. Geoffrey.Coram@analog.com
> 804 Woburn St., MS-422, Tel (781) 937-1924
> Wilmington, MA 01887 Fax (781) 937-1014
This archive was generated by hypermail 2b28 : Wed Jan 07 2004 - 10:15:32 PST