RE: $mfactor in Verilog-style netlists

From: Peter Liebmann <peterl@xpedion.com>
Date: Wed Apr 07 2004 - 10:01:37 PDT

There are a few problems with using instant arrays in this manner:
1. It only allows for integer m factors.
2. It creates n branches which cauld cause computational difficulties.
3. Some voltage sources (like inductors) will not converge in DC in many
simulators
    due to a voltage source loop.
 
 
------------------------------------------------------------------------
S. Peter Liebmann, Ph.D.
Xpedion Design Systems, Inc.
Tel: 408-449-4024
E-Mail: peterl@xpedion.com

-----Original Message-----
From: owner-verilog-ams-devmod@server.eda.org
[mailto:owner-verilog-ams-devmod@server.eda.org] On Behalf Of Kevin
Cameron
Sent: Wednesday, April 07, 2004 9:48 AM
To: Geoffrey.Coram
Cc: VerilogA Device Modeling Reflector
Subject: Re: $mfactor in Verilog-style netlists

Geoffrey.Coram wrote:

In the conference call yesterday (minutes coming soon),

we agreed that

a) we need a multiplicity factor

b) the simulator should handle all the "easy" rules

   automatically (scale "through" contributions by m,

   "through" sensors by 1/m, etc.)

c) mismatch and "rmin" are tough to handle automatically,

   so give access to the multiplicity for an instance

   through the function $mfactor

d) A model writer generally shouldn't use $mfactor, except

   perhaps to scale "output parameters," and the simulator

   should issue a warning if a contribution depends

   explicitly on $mfactor. (Colin will have to live with

   these warnings, or get his simulator to switch it off.)

e) For those Spice-like simulators that have an instance

   parameter for the multiplicity factor, eg "m", in a

   Spice netlist, this should be translated automatically

   (such that $mfactor returns the correct value and the

   rules in (b) are applied.

So, the missing piece is: how in a Verilog netlist does

one specify the multiplicity? Take the instance line

  bsim5 #(.l(90n),.w(1u),.type("nmos")) mn1(.d(d),.g(g),.s(s),.b(b))

How do we make 5 in parallel?

We could allow .$mfactor(5) in the parameter list, but only

because we're using named overrides, and the $things aren't

supposed to be assigned to.

We could put

  bsim5 #(.l(90n),.w(1u),.type("nmos");5) mn1(.d(d),.g(g),.s(s),.b(b))

Someone asked about the range item for an instance, I think

that would look like this:

  bsim5 #(.l(90n),.w(1u),.type("nmos")) mn[1:5](.d(d),.g(g),.s(s),.b(b))

Am I reading the BNF right? Doesn't this mean 5 instances

in parallel? The LRM says (p 7-4)

  One or more module instances (identical copies of a module definition)

  can be specified in a single module instantiation statement.

How does this differ from what we mean by multiplicity? Can one change

a parameter value for just one of the instances through a defparam

statement? If the ports/nets are buses, does one bit get assigned to

each instance?

-Geoffrey

  

Verilog does have instance multipliers, although it may only appear as
the "[range]" item in the instance
BNF in the newer LRMs ( I think generate is now the prefered mechanism).
Stu's quick ref . has it -

http://www.sutherland-hdl.com/on-line_ref_guide/vlog_ref_top.html
(instance_array_range)

- bsim5 #(...) mn1 [1:5] (...) would probably do the right thing.

Ask the BTF if you need clarification.

Kev.

-- 
Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862
Received on Wed Apr 7 10:01:45 2004

This archive was generated by hypermail 2.1.8 : Wed Apr 07 2004 - 10:01:46 PDT