Re: new AMS LRM 2.2 draft c - parameter descriptions

> From - Wed May 26 19:55:54 PDT 2004
>
> Kevin,
>
> BSIM4 has nearly 400 parameters. How is creating 3 line functions for each
> of these 400 parameters less typing than "---"descr" at the end of each
> line? If every module had the same parameters then maybe this is true if
> say a CAD group provides a set of predefined parameters but my experience
> with hundreds of Verilog-A modules implies that this would not buy users
> much. Cannot imagine telling my users that to put a description on a
> parameter that they have to do this class programming stuff for each
> parameter and thus the description declaration would be separate from
> use. Likewise, the description is lost in the module for those debugging
> it since it is stored separately in the class and tools would need to read
> both the class and the module for the descriptions to be displayed, this
> may impact some tools in the flow.

I agree that if you have 400 different descriptions you'll want to minimize
your typing, the template approach does that - assuming a bunch of them will
be using "ohms" it would be something like -

   parameter Ohms#("Resistance") from [0:inf);

which is less typing than -

   parameter real "Ohms" from [0:inf) --- "Resistance";

Note: the class mechanism is user-extensible and potentially allows type/unit
checking which the other mechanism doesn't.
 
> At some point the boys in IEEE and SV need to be a bit more flexible and
> consider the needs of their analog brothers. If not then we will never
> sync the two standards together, we cannot force every analog requirement
> into a digital programming language. I think the only two options are
> putting more flexibility in attributes as Geoffrey proposed or something
> like Geoffrey and the team has proposed with the ---"string".
>
> Jon

This has little to do with analog vs. digital, the proposal is for a new way
to do something that is already mostly covered by the superior mechanisms
of SystemVerilog (already an Accellera standard) - which Verilog-AMS is
supposed to be merging with.

If you don't want to use the class stuff in Verilog-ams I would suggest using
attributes until the languages do get merged.

A more useful extension might be allowing multiple blocks of attributes so that
it's easier to use them in macros -

        attribute_instance ::=(*attr_spec {,attr_spec }*)

becomes -

        attribute_instance ::=attr_list {attr_list}
        attr_list ::=(*attr_spec {,attr_spec }*)

Then you can do -

  `define OHMS (*units="Ohms"*)
  `define RES (*description="Resistance"*)

   ...

  parameter real `OHMS `RES from [0:inf);

Kev.

>
>
>
>
> At 04:32 PM 5/26/2004, Kevin Cameron wrote:
>
> >I really don't think the syntax for units and descriptions will fly with
> >the SV & IEEE. SV has classes which makes it unnecessary to do it that
> >way: all you need is a base class which has the two strings or string
> >functions and you can create the types you need as subclasses e.g.:-
> >class unit_desc; // this could be a built-in
> > real value;
> > virtual function string unit(); endfunction;
> > virtual function string desc(); endfunction;
> >endclass
> >
> >// these would be in a header file
> >class Ohms extends unit_desc;
> > function string unit(); return "Ohms"; endfunction;
> >endclass
> >
> >class Resistance extends Ohms;
> > function string desc(); return "Resistance"; endfunction;
> >endclass
> >
> >....
> >// Your code -
> >
> >parameter Resistance from [0:inf);
> >
> >- lots less typing if you have a lot of thing you want to be of type
> >Resistance.
> >
> >You can also do paramaterized classes which would let you do something like:
> >parameter unit_desc#("Ohms","Resistance") from [0:inf);
> >
> >- but an approach that requires you to enter the strings for every
> >individual parameter is tedious and eror-prone, so you would probably do:-
> >typedef unit_desc#("Ohms","Resistance") Resistance;
> >....
> >
> >parameter Resistance from [0:inf);
> >
> >I would just scrub section 3.2.3.
> >
> >Kev.
> >
> >Geoffrey.Coram wrote:
> >>
> >>Hi -
> >>I've uploaded a new draft of the LRM to the eda.org web site.
> >>
> >
> >
> >--
> >Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862
>
> ***********************************************************
> Jonathan L. Sanders
> Product Engineering Director
> Custom IC Solutions
> Cadence Design Systems, Inc.
> 555 River Oaks Pkwy
> San Jose, CA. 95134
> INTERNET:jons@cadence.com Tel: (408) 428-5654 Fax : (408) 944-7027
> ***********************************************************
Received on Thu May 27 01:59:47 2004