Add Proposal | Add Analysis | Edit Class, Environment, or Release |
Number | 384
|
Category | enhancement
|
Synopsis | add mfactor parameters
|
State | open
|
Class | enhancement
|
Arrival-Date | Jul 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