ISSUE 384

Add Proposal  Add Analysis  Edit Class, Environment, or Release
Number 384
Category enhancement
Synopsis add mfactor parameters
State open
Class enhancement
Arrival-DateJul 09 2003
Originator sharp@cadence.com
Release 2001b
Environment

Description
This is a request from my Verilog-AMS contact.

They would like to add a feature called mfactor for
Verilog parameters. I don't fully understand this, but
it involves special rules for passing parameter values
down the hierarchy, with the local value being set to
the locally defined value being multiplied by the value
passed in, instead of replaced by it. The current
mechanism they are using for this is an mfactor attribute.
This is a misuse of Verilog attributes, which should not
affect the language semantics. They would need to come
up with a different syntax/mechanism for this. I am not
sure how useful this feature would be for digital Verilog
users. I am just putting this in as a placeholder for
the request.
Fix

Audit-Trail
From: Shalom.Bresticker@freescale.com
To: btf-bugs@boyd.com
Cc:
Subject: Re: enhancement/384: mfactors (fwd)
Date: Tue, 11 May 2004 12:05:50 +0300 (IDT)

---------- Forwarded message ----------
Date: Mon, 10 May 2004 14:01:41 -0400
From: Geoffrey.Coram <Geoffrey.Coram@analog.com>
To: Shalom Bresticker <Shalom.Bresticker@motorola.com>
Subject: Re: mfactors

Shalom -
In analog design, it is often desirable to put down
several "identical" instances rather than one single one.

The idea is to use a "weak law of large numbers" approach
that means that the effective resistance of a string of
several random resistors will have a smaller variance
(by 1/sqrt(m)) than a single resistor -- assuming that
the randomness of the resistor is independent of that
of its neighbors.

And in fact, for differential signals, the "common mode"
randomness is eliminated by the design (if all the
resistors are 10% below nominal, then the differential
gain of the system is unchanged). So it is the local
randomization, due to different etch rates or differences
in the local topology (this resistor is next to a
transistor, so the poly doesn't grow quite the same as
the other one).

The m-factor provides an easy way to say: give me 10
identical resistors, rather than forcing the designer
to cut&paste 9 times.

-Geoffrey

From: Shalom.Bresticker@freescale.com
To: btf-bugs@boyd.com
Cc:
Subject: Re: enhancement/384: mfactors (fwd)
Date: Tue, 11 May 2004 16:20:01 +0300 (IDT)

---------- Forwarded message ----------
Date: Tue, 11 May 2004 08:45:42 -0400
From: Geoffrey.Coram <Geoffrey.Coram@analog.com>
To: Shalom Bresticker <Shalom.Bresticker@motorola.com>
Cc: Srikanth Chandrasekaran <Srikanth.Chandrasekaran@motorola.com>,
shekar@cadence.com
Subject: Re: mfactors

Presently in V-AMS, or specifically in the Verilog-A subset,
there is some support for M-factor in Spice netlists. That is,
some (most?) V-AMS simulators will allow you, in your V-AMS
design, to instantiate a block defined as a Spice netlist
(or even a Spice primitive), and this block may have the
m-factor defined. Traditional Spice simulators (like HSpice)
implicitly define the m-factor as a parameter for every
model they implement. V-AMS simulators, I guess, have an
analog engine that should handle the m-factor.

The issues that Shekar is supposed to address involve how
the m-factor can pass through the true digital parts of
the design properly. I don't know, from a digital
perspective, if a "mfactor=2" inverter should mean that
the digital block should have twice the drive strength
(I assume that digital tools do check the fanout of gates).
In the layout, though, one probably would not want two
identical inverters laid out next to each other, nor even
to have the transistors duplicated; instead, the transistors
would be made wider (I think).

-Geoffrey

From: Shalom.Bresticker@freescale.com
To: btf-bugs@boyd.com
Cc:
Subject: Re: enhancement/384: mfactors
Date: Tue, 11 May 2004 18:54:20 +0300 (IDT)

More on mfactor:

See the document (pages 5-6)
"Proposed Verilog-A Language Extensions for Compact Modeling"
at
http://www.eda.org/verilog-ams/htmlpages/public-docs/Verilog-A_Compact_Model_Extensions.pdf

Also "Verilog-AMS Compact Modeling Extensions" meeting minutes from
April 6 and 20 at
http://www.eda.org/verilog-ams/htmlpages/compact/minutes_apr6 and
http://www.eda.org/verilog-ams/htmlpages/compact/minutes_apr20

I will send each of these separately.

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Reuse Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only
[ ]Freescale Confidential Proprietary

From: Shalom Bresticker <Shalom.Bresticker@freescale.com>
To: btf-bugs@boyd.com
Cc:
Subject: re: enhancement/384: mfactor
Date: Tue, 11 May 2004 19:00:17 +0300

This is a multi-part message in MIME format.
--------------CCAF13546ADCD8F233AC1D56
Content-Type: text/plain; charset=us-ascii
Content-Transfer-Encoding: 7bit

v-ams minutes from apr 6,20

--
Shalom Bresticker Shalom.Bresticker @freescale.com
Design & Reuse Methodology Tel: +972 9 9522268
Freescale Semiconductor Israel, Ltd. Fax: +972 9 9522890
POB 2208, Herzlia 46120, ISRAEL Cell: +972 50 5441478

[ ]Freescale Internal Use Only
[ ]Freescale Confidential Proprietary
--------------CCAF13546ADCD8F233AC1D56
Content-Type: text/plain; charset=us-ascii;
name="minutes_apr6.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="minutes_apr6.txt"

V-AMS Compact Modeling Extensions subcommittee
Minutes of April 6, 2004

Attendees:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
Colin McAndrew, Motorola
Srikanth Chandrasekaran, Motorola
David Zweidinger, Texas Instruments
Peter Liebmann, Xpedion
Jim Barby, U Waterloo
Chris Nicklaw, Silvaco
Al Davis, Kettering U



1) Approval of previous minutes


2) Approval process for LRM 2.2

We had a brief discussion of the process by which the proposed
extensions would be approved as AMS LRM 2.2

- I will update LRM frame document and send it to the full
AMS committee as well as other Accellera TCC chairs

- May want another meeting of the main AMS committee to discuss,
similar to the meeting in January

- I will plan to present this at the Accellera board meeting
that we expect will happen in June during DAC; Jim noted that
answering the board's questions in real time will accelerate
the process

- Formal submission to the board will follow, after I address
any concerns; I will not try to have the LRM ready in May
(which would be necessary to have a vote on it at DAC)

Sri said that our subcommittee should focus on Verilog-A, and
not worry about the SystemVerilog integration; this is an
issue he has already addressed with Vassilios.


3) Limiting

Sri wants to see UDFs (user-defined functions) allowed for limiting.
I had taken it out as giving a model writer too much rope to hang
him/herself. However, Spice does not have a temperature limiting
algorithm, and some simulators (eg, zspice that works with ADMS)
may not have any limiting algorithms built in; this would give
users a way to do the limiting. (In e-mail after the call, but
before the minutes, Sri and I discussed that the simulator would
search for the limiting_identifier as a built-in function, then
in the module's analog functions; that way, a diode could have a
simple pnjlim UDF for distribution, but the simulator's own
(presumably enhanced) pnjlim would take precedence.)

We think that $discontinuity(-1) would be a reasonable way to signal
simulator that another iteration is required.


4) M factor

We considered pre-defining "parameter real mfactor = 1"
for every module, but Sri pointed out that this is a nuisance
for parameter overrides by ordered list.

We believe that the simulator should handle the four main rules
- current contribs scaled by m
- current probes scaled by 1/m
- noise currents scaled by sqrt(m)
- noise voltages scaled by 1/sqrt(m)

OOMRs may be handled according to rules in the proposal.

However, we think we should provide access to $mfactor in the
module, for minr, output parameters, and mismatch.

For the case of minr and output parameters, the simulator
should be able to determine that the use of $mfactor is OK;
output parameters should not affect the contributions, and
minr uses it to switch formulations entirely.

However, the simulator will probably need to generate a warning
for the use of $mfactor in mismatch equations, since it won't be
clear that the model writer isn't trying to do manual m-scaling.

Ilya mentioned a customer wanted m=0 for some reason.

Colin said we should insist that the $mfactor as seen by module
will be > 0 (strict); simulator may choose to accept $mfactor=0,
but it should not instantiate the device.

For Spice netlists, in which an mfactor is defined, usually as
an instance parameter "m=<value>", if the device is instantiated
as a Verilog-A primitive, then the simulator should:
a) follow the four simple rules as above
b) set the value of $mfactor to <value> (times whatever
hierarchical value is appropriate)

However, we got hung up trying to define a syntax for specifying
mfactor in a Verilog netlist.


5) Next meeting: 9AM Eastern (Daylight) Time, April 20

3PM Eastern is 4:30AM Australia, so we're moving back to mornings
(9AM EDT is 10:30PM for Sri). This is great for the Europeans,
but a nuisance for West Coasters. Sorry.


--------------CCAF13546ADCD8F233AC1D56
Content-Type: text/plain; charset=us-ascii;
name="minutes_apr20.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: inline;
filename="minutes_apr20.txt"

V-AMS Compact Modeling Extensions subcommittee
Minutes of April 20, 2004

Attendees:
Geoffrey Coram, Analog Devices
Ilya Yusim, Cadence
Laurent Lemaitre, Motorola
Colin McAndrew, Motorola
Srikanth Chandrasekaran, Motorola
Marek Mierzwinski, Tiburon
Jim Barby, U Waterloo
Al Davis, Kettering U


1) Approval of previous minutes (Apr 6)


2) DC Sweep
The dc sweep proposal was discussed last night by the main AMS
committee. Since compact modeling makes significant use of
dc sweeps, I was hoping to include this proposal in the LRM
revision for compact modeling.

However, significant questions persist about the specification
of a dc sweep for mixed-signal simulation. Hopefully, this
will be addressed soon; otherwise, we will define the behavior
for analog-only systems and include the mixed-signal questions
in Annex G (open issues);


3) M-factor in Verilog netlists

This item also requires action by the main AMS committee, which
plans to discuss it on May 3.

Last time, we had decided to handle mfactor automatically
for contributions, but allow the module to get the value
through the call $mfactor for tricky things like mismatch
and rmin.

Laurent made a new suggestion: if a module accesses $mfactor,
then the compiler should issue a warning and expect the
model writer to explicitly handle the mfactor for
contributions and elsewhere. If a module does not access
$mfactor, then the simulator handles the contribution rules
automatically.

This will make Colin's life difficult, since he'll use
$mfactor for mismatch and then be compelled to code it
explicitly for current contributions.

Marek pointed out that, for hierarchical instantiations
within a module that accesses $mfactor, we need to provide
a way to pass the mfactor to the instances, which goes
back to the need to provide a way to specify the mfactor
in a Verilog netlist.

4) Limiting syntax

Sri wanted to know about the syntax for the limiting function's name,
ie, the second argument to $limit; let's call it limit_fn_identifier.

Option 1:
limit_fn_identifier
: spice_identifier
| analog_fn_identifier

spice_identifier : pnjlim
| fetlim
| simulator_specific_lim

Option 2:
limit_fn_identifier:
string_identifier
| analog_fn_identifier

Option 3:
limit_fn_identifier:
string_identifier
| "analog_fn_identifier"


We dislike option 1, because it introduces pnjlim and fetlim
as keywords. In option 3, if you misspell "analog_fn_identifier",
then the simulator treats it as unknown (and applies some default
limiting), rather than giving a syntax error at compilation time.
Option 2 would give that error if it did not find the definition
of the analog function.

However, option 2 makes it more difficult to switch between a
UDF and a built-in limiting algorithm. There are two scenarios here:
a) Models (particularly for BJTs with self-heating) define templim as
a UDF; simulators start building in a templim that is tuned for
their algorithms; now, model-writers have to replace
templim with "templim" to access the built-in.
b) A model wants to provide a basic pnjlim for use in a simulator
that does not have it, but wants to use the built-in otherwise.

Marek suggested the syntax
$limit(V(a,c), "pnjlim", mypnjlim, vcrit)
where "pnjlim" is used if available, else mypnjlim is used.
This solves (b). (It has the side effect of shifting the
arguments, so that the 4th and subsequent arguments to $limit
become the 3rd and subsequent arguments to mypnjlim.)

Ilya cautioned against giving the user the impression that he/she
has final say; the simulator should be in charge of determining
which limiting algorithm is actually used. We've mentioned before
that the simulator can choose to ignore $limit, or just use it as
a flag to do something to the branch. Hence, Ilya suggested,
the model could call
$limit(V(a,c), pnjlim, vcrit)
where pnjlim is a UDF, but the simulator could decide to call its
internal "pnjlim" instead. Sri felt that it should be obvious
from reading the module code what algorithm is being used.
However, I don't think it's necessary to provide that
transparency for $limit.


5) Noise

I've had some trouble trying to implement the MOS11 noise model
in Verilog-A, despite our claim that an extension was not needed.
Part of the problem is that the C code from Philips does not
implement the model equations as written, but uses one expression
for "low" frequencies and another for "high." This can't be done
without explicit access to the frequency; however, it's not
really physically correct, either.


6) Next meeting: May 18 at 9AM ET
at which point I plan to have the LRM updated with what we have
agreed on, leaving the mfactor and dc sweep details until the
main AMS committee comes to some conclusion



-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

--------------CCAF13546ADCD8F233AC1D56--

Unformatted

Hosted by Boyd Technology