RE: new AMS LRM 2.2 draft c - parameter descriptions

Geoffrey,

Why don't simply decide to use the (*...*) before all declarations (module, parameter, variable, discipline of node)
if this can make all people happy:

(* desc="bsim3 from silvaco" version="3.3.2" url=www.silvaco.com" *)
module bsim3 (dnode,gnode,snode,bnode);
...
(*desc="d node"*)
electrical d;
(*desc="g node"*)
electrical d;
...
(*desc="length"*)
parameter real l=1u from (0:+inf);
...
(*desc="effective length"*)
real leff;
...

For long lines in (*...*) I propose to make possible the use of multiple (*...*) like that:
(* version=`VERSION spice:prefix="m" spice:ntype="nmos" spice:ptype="pmos" spice:level="100"*)
(* company="Silvaco" info="bsim3 mosfet model from Silvaco (level 100)"*)
(* license="see http://www.silvaco.com/downloads/verilogADownloads.html" *)
module silvacobsim3 (drain, gate, source, bulk);
...

The use of the (*...*) construct is then close to what we do with /*...*/.

I am attaching the silvaco vla code of bsim3v3.2 + extensions.
Tell me if you think that the code is really unreadable.
This is the code that adms parses to create the full c code of bsim3 from spectre.

Quick question:
we have define aliasparameter. Do we have also aliasnode available?
Laurent Lemaitre
Freescale - Geneva

-----Original Message-----
From: owner-verilog-ams-devmod@eda.org [mailto:owner-verilog-ams-devmod@eda.org] On Behalf Of Jonathan Sanders
Sent: Thursday, May 27, 2004 2:16 AM
To: Kevin Cameron; Geoffrey.Coram
Cc: VerilogA Device Modeling Reflector; verilog-ams@eda.org
Subject: Re: new AMS LRM 2.2 draft c - parameter descriptions

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.

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

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