Re: $mfactor in Verilog-style netlists

Peter Liebmann wrote:

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

You could tweak the syntax to be either a range or a multiplier, and you
could add extra functionality/syntax to the module declaration to
indicate that it will handle multipiers internally when possible (rather
than actually having multiple instances).

The advantage of the integer range is that it is compatible with both
analog and digital module instantiation, so the parent module doesn't
need to differentiate - and it's backward compatible.

> 3. Some voltage sources (like inductors) will not converge in DC in
> many simulators
> due to a voltage source loop.
>

How is that related?

Anyway, I'd probably go for something like a modified module declaration
e.g.:

   module bsimX (inout g,s,d);
      multiplier mfactor = 1.0; // gets overriden at elaboration
                                // with actual multiplier

or if you want 2-D multipliers:

   module bsimX (inout g,s,d);
      multiplier xfactor = 1.0,
                 yfactor = 1.0;
....

   bsimX bigT [4.4,8.5] (g1,s1,d1); // xfactor = 4.4, yfactor = 8.5
   bsimX bigT2[0:6,0:8] (g1,s1,d1); // xfactor = 7, yfactor = 9

If there is no "multiplier" in the module you just do multilple
instantiations.

Kev.

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

-- 
Kevin Cameron, CPU Technology, CA 94588, Tel.: (925) 225 4862