Subject: RE: VerilogAMS Committee Meeting Minutes - 15 December 2003
From: Chandrasekaran Srikanth-A12788 (Srikanth.Chandrasekaran@motorola.com)
Date: Wed Jan 07 2004 - 17:02:50 PST
From my understanding some of the attributes that we are planning to introduce for device modelling are going to be "standardized" attributes (ie the name of the attribute to be used would be specified and would have the same meaning across tools).
I agree that at this point there is no system defined attributes and its upto the tool/vendor to interpret these (name,value) pairs but does anybody see any problems the "standardized" ones being introduced through these VerilogA extensions tho' it doesn't exist in the digital language.
cheers,
Sri
> -----Original Message-----
> From: David W. Smith [mailto:David.Smith@Synopsys.COM]
> Sent: Thursday, January 08, 2004 4:43 AM
> To: 'Martin O'Leary'; 'Geoffrey.Coram'
> Cc: Chandrasekaran Srikanth-A12788; 'Verilog-AMS LRM Committee'
> Subject: RE: VerilogAMS Committee Meeting Minutes - 15 December 2003
>
>
> 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 - 17:03:41 PST