Parameter Declarations

[Geoffrey]

The CMC R2 and R3 models use a set of macros to declare parameters,
such as:

`ifdef __VAMS_COMPACT_MODELING__
`define MPRcc(nam,def,uni,lwr,upr,des) (*units=uni, ask="yes",
desc=des*) parameter real nam=def from[lwr:upr];
`define IPRcc(nam,def,uni,lwr,upr,des) (*units=uni, type="instance",
ask="yes", desc=des*) parameter real nam=def from[lwr:upr];
`else
`define MPRcc(nam,def,uni,lwr,upr,des) parameter real nam=def
from[lwr:upr];
`define IPRcc(nam,def,uni,lwr,upr,des) parameter real nam=def
from[lwr:upr];
`endif

`MPRcc( tmin ,-100.0 ,"degC" ,-250.0, 27.0, "minimum
ambient temperature")


The BSIMSOI model does not use these macros; it puts a comment after
each declaration:
parameter real SA = 0.0 from [0:inf); // distance between OD
edge to poly of one side

nor does HICUM, which puts a descriptive comment above sets of
parameters:
//Base-Emitter tunneling current
parameter real ibets = 0.0 from [0:1];
parameter real abet = 40 from [0:inf);

PSP uses a different syntax:
parameter real TR = 21.0 `from( -273.0,inf )
`P(info="nominal (reference) temperature" unit="C" );

though in the current release, macros `P and `from have empty
definitions.


The open-source Verilog-A compiler ADMS uses the "type" attribute
(Verilog-A attributes are the things inside the special parentheses (*
attrib_name=attrib_value *) ) to differentiate between model and
instance parameters. One commercial simulator requires an attribute
on the module (rather than on the parameters) to indicate all the
instance parameters for the module.

I believe the `P macro can be defined such that ADMS will make use of
the information, but I don't think this fits standard Verilog-A.
Using the `from macro makes it difficult to differentiate between open
and closed ranges: (0:inf) versus [0:inf).


What recommendations should we make regarding parameter declarations?

[Geoffrey Coram]

Along the same lines, there are 3 ways to differentiate between
instance and model parameters:

1) The open-source Verilog-A compiler ADMS uses the "type" attribute,
specified in front of each parameter, to differentiate.

2) One commercial simulator requires an attribute on the module

(rather than on the parameters) to indicate all the instance
parameters for the module.

(* compact_module = "mosfet" *)
(* instance_parameter_list = "L,W" *)
module newmosmodel( d, g, s, b);

3) The Verilog-AMS LRM has a powerful system called "paramsets" to
specify this.

At the CMC meeting last week, there was some preference for 1) for two
reasons: first, that an open-source tool uses it, and second, that the
R2_CMC and R3_CMC models use this syntax. Are there any objections to
making this a CMC recommendation?

[Geoffrey Coram]

Should we recommend that parameters be UPPER or lower case?

If we use lower case -- which would match the way built-in
model parameters are done in case-sensitive simulators --
we have a problem when the parameter conflicts with a
Verilog-AMS keyword.

For example, in BSIMSOI, there is a parameter "LN" -- we
can't use "ln" because that conflicts with the natural log.

[Selim, Mohamed]

It is a common practice in most of the models, if not all, that parameters are written in the Verilog-A file in upper case. It should continue the same way.

[Geoffrey Coram]

Selim, Mohamed wrote:
> It is a common practice in most of the models, if not all, that
> parameters are written in the Verilog-A file in upper case.
> It should continue the same way.

r2_cmc and r3_cmc use lowercase, as does Hicum.

However, more use uppercase: Mextram, BSIMSOI, PSP, Mosvar,
HiSIM-HV, diode_cmc.

[Boris Troyanovsky]

Hi Geoffrey,

To avoid conflicts with keywords in the case of lower-case parameters, we
can recommend using escaped identifiers:

===========================================
module testme;

parameter real \if = 1.2M;

analog begin

if(\if < 0) $strobe("Warning!");

end

endmodule
===========================================

This is LRM-compliant and reasonably straightforward. Adding the backslash
is a little bit of a hassle, but sure beats having to type all the
parameters using uppercase in the model body.

- Boris

[Selim, Mohamed]

One of the requirements is to implement the model as is.
What will be the situation with escaped identifiers when the model is implemented inside a simulator? Would having the name 'if' be acceptable especially with the new wave of legal agreements that prohibit the change of anything in the standard model or should we force users to have the name '\if' ?

-----Original Message-----
From: cmc-ve...@googlegroups.com [mailto:cmc-ve...@googlegroups.com] On Behalf Of Boris Troyanovsky
Sent: Friday, December 16, 2011 12:08 AM
To: cmc-ve...@googlegroups.com
Subject: Re: [cmc-verilog-a] Re: Parameter Declarations

[Boris Troyanovsky]

At the simulator netlist level, the parameter name would simply be "if"
with no leading backslash character (assuming that "if" is not a keyword
in the simulator's model-specification context -- if it was, the
simulator's own keyword-escaping mechanism would have to be used there as
well). The backslash is simply the Verilog-A standard mechanism for
escaping parameters; it's invisible to the simulator, and the leading
backslash would never be exported out of the module.

For Geoffrey's example, any current netlist using "ln" at the netlist
level would transparently work with a Verilog-netlist using "\ln "
internally. And of course for a non-keyword, having an escape is
equivalent to not having it (ie, "\hello " and "hello" are the same entity
in Verilog-A/D/AMS).

[Geoffrey Coram]

The model author would need to put the backslash in --
if I had written BSIMSOI with the parameters in lower-case,
it would not have been legal to use "ln" as the parameter
name, and compilers/simulators would have rejected the code.
If the model code is illegal, then certainly the CMC would
direct the model author to change the code before
standardization.

I chose to make all the parameters upper-case; Boris is
pointing out that I could have used "\ln"

I happen to like code that uses upper-case parameter names,
because then it's easy to tell, as I read the code, what is
a parameter and what is a variable.