Re: $mfactor in Verilog-style netlists

Silicon structures are two or three-dimensional and m-factor is only
going to give you one-dimensional control, so it seems to me that
something better is required. I think it would be better to work from a
new rationale/requirement that addresses the problems that m-factor is
currently being used to tackle, rather than trying to copy Spice
functionality exactly.

Having said that, for integer m-factor I think using the existing
instance range scheme is adequate since you can just leave it up to the
simulator to collapse the multilple instances to a single simulation
model as an optimization, and it should be transparent to the user (it
needs to be for backward compatibility with digital and to preserve the
name space when swapping digital implementation for analog).

Kev.

McAndrew Colin-rp3881 wrote:

>a comment on layout styles. we do indeed use the m-factor heavily.
>we also use "fingers" but primarily for RF layouts where the "m"
>does not represent what happens (not just plunking down parallel
>instances, but specific interdigitation and layout and contacting
>to minimize parasitics).
>
>we do not use "m" specifically to reduce mismatch, we adjust sizing and
>biasing to meet mismatch requirements. for big devices you do not want
>a single instance, for layout purposes, so a device is layed out in
>multiple segments. this is where we use m. for setting up integer
>ratios, which is standard practice in analog design, it is also used.
>we use it for BJTs, capacitors, and resistors as well as MOSFETs.
>
>note that you cannot do something like multiply width by m to mimic
>the effect, 1xw=10 is not the same as 10xw=1 because of narrow width
>effects.
>
>besides being used to define layout, I believe it is primarily
>used in SPICE for efficiency. simulation speed is roughly linear
>in the number of devices simulated, so scaling by m is m times
>faster than simulating m times.
>
>m is in all analog and "fast MOS" simulators I know, it is widely
>used, and it is not just simulators that know about it, layout
>extraction tools do also.
>
>colin
>
>-----Original Message-----
>From: owner-verilog-ams-devmod@eda.org [mailto:owner-verilog-ams-devmod@eda.org] On Behalf Of Geoffrey.Coram
>Sent: Friday, April 09, 2004 5:36 AM
>To: Kevin Cameron
>Cc: Peter Liebmann; 'VerilogA Device Modeling Reflector'
>Subject: Re: $mfactor in Verilog-style netlists
>
>
>Kevin Cameron wrote:
>
>
>>Mfactor appears to me to be Spice "hack" that doesn't really belong
>>in a proper HDL.
>>
>>
>
>Mfactor is a shorthand. I don't see how it's any different than the instance arrays, which are shorthand for having to write them out individually and connect the right bit of the bus.
>
>
>
>>The "right" answer? Since we are trying to model hardware I suspect
>>that linear scaling is never the right answer.
>>
>>
>
>The right answer from a simulation standpoint. If the two options
>are: write each instance individually, or write them with mfactor, then applying the simple rules makes these two give the same answer.
>
>Sure, there are differences from the hardware, eg the differences in interconnect to the multiple instances, but that's not the point of mfactor.
>
>In fact, at ADI, we don't make much use of m; we added "fingers" to our BSIM3 model to account for the reduced capacitance of multi-gate devices compared to individual parallel instances (standard BSIM4 now has it, too). But it is used, heavily I'm told, elsewhere, particularly it seems at Motorola for
>reducing the effects of mismatch.
>
>
> module my_res(inout a,b);
> parameter real r0 = 5;
>
> real reff (* desc="effective resistance" *)
>
> analog begin
> V(a,b) <+ I(a,b) * r0;
> reff = r0/$mfactor;
> end
> endmodule
>
>
>
>
>>Apart from it being in Spice what is the rationale for adding this
>>functionality? And under what circumstances would you require a
>>fractional multiplier?
>>
>>
>
>Apart from it being heavily used by analog designers, what rationale do I need?
>
>In the conf call Tuesday, Colin said designers sometimes use an mfactor of 1.667 on one device, leaving a second with mfactor=1, to model what will likely become a 5:3 ratio. You can use the fraction instead of having to convert it to a ratio of integers.
>
>-Geoffrey
>
>

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