Certainly no problem with the simulator detecting I(p, n) <+ $mfactor*V(p, n); and reff = R / $mfactor; I(p, n) <+ V(p, n) / reff; as errors. The check here is just to see if for any given branch there is a direct or indirect dependency on the $mfactor system task and this sort of dependency tracking is done in lots of places. Similarly reff = R + $rdist_normal(myseed, 0, stddev/sqrt($mfactor)); I(p, n) <+ V(p, n) / reff; is also easy to detect. Just need to define a list of functions/tasks where the $mfactor dependency doesn't carry through (I guess all?). Currently though the LRM allows $mfactor as part of a parameter override (by default of it being classed as a parameter and hence "constant") module top; electrical a,b; child #(.scale($mfactor)) ch1(a,b); endmodule module child(p,n); electrical p,n; parameter scale = 0; parameter R = 1k; analog I(p,n) <+ V(p,n) / (R / scale); endmodule Tracking the dependencies for the parameter 'scale' through the hierarchy is a little more painful. Although it is doable, it is probably best avoided. I think this use should be restricted but can't come up with a nice way to word it. Dave Geoffrey.Coram wrote: > I have vague recollections of this, and whether we expected the > simulator to always be able to tell if the use of $mfactor is > correct or not. > > Eg > I(p, n) <+ $mfactor*V(p, n); > is clearly wrong; similarly, > reff = R / $mfactor; > I(p, n) <+ V(p, n) / reff; > is wrong. > > But > I(p, n) <+ V(p, n) / R; > reff = R / $mfactor; > is correct (reff assumed to be an operating-point value, > and not used in any contributions). > > There were also cases where one might have > reff = R + $rdist_normal(myseed, 0, stddev/sqrt($mfactor)); > I(p, n) <+ V(p, n) / reff; > and this should be allowed, since mismatch is reduced by > the square root of $mfactor. > > So, can the simulator always detect when it's an error? > Or did we decide that this would be too much work for the > simulator, and had the LRM say a simulator "may" issue > a warning if it detects improper use? > > -Geoffrey > > > > > Boris Troyanovsky wrote: >> Hi Geoffrey, >> >> I'm not sure when the $mfactor example was added or who the author was. >> >> One thing that I do think should be clarified is whether doing >> >> I(p, n) <+ $mfactor*V(p, n); >> >> is an error or merely a warning. My recollection was that it was intended >> to be an error, but the LRM currently mentions both "warning" and "error" >> for this situation. >> >> - Boris >> >>> Hi, Boris, et al: >>> Anyone know who made up the example with the illegal $mfactor? >>> I thought I had let it get into LRM 2.2, but now I see that >>> Draft 2 had: >>> NOTE to self: add an example or two to this section >>> >>> and then Draft3 had that note struck out, but no change-bars >>> to indicate that the examples had been added, so maybe that's >>> why we hadn't thoroughly reviewed the examples. >>> >>> I noticed three more glitches: >>> 1) module_a in test_module should have .$mfactor(3), else >>> where did the factor of 3 come from? >>> >>> 2) the line right above Example 2 is a sentence fragment. >>> >>> 3) In Example 2, module_a is similarly missing .$xposition = 1.1u >>> >>> -Geoffrey >>> >>> >>> >>> Boris Troyanovsky wrote: >>>> Hi, >>>> >>>> I think there may also a pair of issues relating to the $mfactor >>>> specification. >>>> >>>> Issue #1: >>>> In section 6.3.6 (p. 123), the LRM states: "The simulator shall issue a >>>> warning if it detects a misuse of the $mfactor in a manner that would >>>> result in double-scaling." However, just a few lines down, the LRM >>>> states: >>>> "The simulator will generate an error" for this situation. So I >>>> think we >>>> should clarify whether this is in fact an error or a warning (my >>>> recollection is that the original intent was to make it an error). >>>> >>>> Issue #2: >>>> In Section 9.18 (page 221 / Example 1) the following module has an >>>> error: >>>> >>>> =========================== >>>> module module_c(p,n); >>>> inout p,n; >>>> electrical p,n; >>>> parameter r=1.0; >>>> analog begin >>>> I(p,n) <+ V(p,n)/(r/$mfactor); // the effective resistance = 1/42 >>>> end >>>> endmodule >>>> =========================== >>>> >>>> This usage of $mfactor is prohibited; we can't make explicit >>>> contributions >>>> that depend on $mfactor. The example should probably be removed or >>>> altered. >>>> >>>> Regards, >>>> >>>> - Boris >>>> >>>> -------------------------------------------------------------------------- >>>> >>>> >>>>> Hi Sri, Stu, >>>>> >>>>> I have still a few minor items that I found when scanning again >>>>> through >>>>> the >>>>> document: >>>>> >>>>> p.vii, ToC, item 5.9.3 is in italics while it should be regular >>>>> p.14, 2.6.2, 1st line "IEEE STD-754-1985" should use the same notation >>>>> as >>>>> the references to IEEE 1364 - it should be written as "IEEE std >>>>> 754-1985". >>>>> >>>>> On page 17 in sectins 2.8.3 and 2.8.4 the system tasks and functions >>>>> and >>>>> the compiler directives are described. However, both these sections >>>>> wrongly >>>>> say that the Verilog-AMS standard does not introduce new system tasks >>>>> or >>>>> compiler directives. To remedy that the following changes are needed: >>>>> >>>>> p.17, 2.8.3, 1st paragraph, 1st line: change "three" into "five". >>>>> p.17, 2.8.3, 1st paragraph, two new bullets after the 2nd bullet: >>>>> " - Additional $identifier system tasks and functions defined in >>>>> Clause >>>>> 4 >>>>> and Clause 9 of this standard.", and >>>>> " - Additional $identifier system tasks and functions defined using >>>>> VPI >>>>> as >>>>> described in Clause 11 and Clause 12 of this standard." >>>>> p.17, 2.8.3, 2nd paragraph, remove the last sentence "Additional >>>>> system >>>>> tasks and functions with the $identifier construct are not part of >>>>> this >>>>> standard." >>>>> p.17, 2.8.4, 2nd paragraph, 1st line: change "two" to "three". >>>>> p.17, 2.8.4, 2nd paragraph, one new bullet after the 1st bullet: >>>>> " - Additional `identifier compiler directives defined in Clause 10 of >>>>> this >>>>> standard." >>>>> p.17, 2.8.4, remove last line of the page "Additional compiler >>>>> directives >>>>> with the `identifier construct are not part of this standard." >>>>> >>>>> p.209, 9.7.3, the message arguments of the $fatal, $error, $warning, >>>>> and >>>>> $info system tasks are not described in the text. I propose to add >>>>> after >>>>> the current last line of the section the following text (taken from >>>>> IEEE >>>>> 1800-2007, 17.2, p.245, 7th paragraph): >>>>> >>>>> "Each system task can also include additional user-specified >>>>> information >>>>> using the same format as the Verilog $display." >>>>> >>>>> Cheers, >>>>> Marq >>>>> >>>>> >>>>> owner-verilog-ams@server.eda.org wrote on 15-05-2008 20:15:57: >>>>> >>>>>> Stu, >>>>>> >>>>>> I have minuted the changes discussed in today's meeting. Hopefully i >>>>>> have got the points across clearly on the different points (and >>>>>> specifically on chapter 9 changes). Please let me know if you need >>>>>> any >>>>>> additional clarification on these. >>>>>> >>>>>> Date: 15 May 2008 >>>>>> >>>>>> Geoffrey Coram, Analog Devices >>>>>> Marek Mierzwinski, Tiburon >>>>>> Martin O'Leary, Cadence >>>>>> Stu Sutherland, Sutherland HDL >>>>>> Patrick O'Halloran, Tiburon >>>>>> Dave Cronauer, Synospsys >>>>>> Ken Bakalar, Mentor Graphics >>>>>> Jonathan David, Qualcomm >>>>>> Marq Kole, NXP >>>>>> Sri Chandra, Freescale >>>>>> >>>>>> Chapter 1: Verilog-AMS introduction >>>>>> * [clause 1.1, pg 15]: remove Verilog-D reference and the text within >>>>>> () >>>>>> * [clause 1.1, pg 15]: Add "as described in Annex C" in the Verilog-A >>>>>> reference --> ("also referred to as Verilog-A as described in Annex >>>>>> C") >>>>>> >>>>>> Chapter 3: Data types >>>>>> * [Syntax 3-2, Pg 41]: In value_range syntax definition, the wrong >>>>>> type >>>>>> of ` has been used (should not be a back-tick). Same update needs to >>>>>> be >>>>>> done in Annex A also. >>>>>> * [clause 3.4.6, pg 44]: typo on "transistortype" >>>>>> >>>>>> Chapter 4: Expressions >>>>>> * [Table 4-14, pg 71]: Use ">=" for sqrt() >>>>>> * [Table 4-15, pg 72]: Use "<=" for acos() >>>>>> * [clause 4.5.6, pg 65]: remove ";" in the general form for the ddx() >>>>>> expression >>>>>> * [clause 4.5.6, pg 65]: move inout declaration before electrical >>>>>> declaration in both the diode examples >>>>>> * [cluase 4.5.6, pg 65, 66]: font correction (bold) for limexp and vt >>>>>> in >>>>>> both the diode examples >>>>>> * [clause 4.5.11.5, pg 88]: fix font on laplace_zp example for >>>>>> "white_noise". Should be bold. >>>>>> * [clause 4.6.4, pg 94]: fix the BNF for noise_table (same fix to be >>>>>> done in Annex A.8.2) >>>>>> | noise_table (constant_concatenation | string [, string ]) >>>>>> >>>>>> Chapter 6: Hierarchical structures >>>>>> * [clause 6.4, pg 140]: The .model card statement should refer to >>>>>> nmos >>>>>> instead of nmos3 >>>>>> * [clause 6.6.2, pg 154]: ";" missing in module pipeline_adc on the >>>>>> top >>>>>> of the page >>>>>> >>>>>> Chapter 7: Mixed signal >>>>>> * [clause 7.3.2, pg 165]: add "inout anet" to the converter example. >>>>>> * [clause 7.3.2, pg 165]: add "output dnet" to the converter example. >>>>>> * [clause 7.3.2, pg 165]: The last statement in the analog block >>>>>> should >>>>>> say V(anet) <+ dnet; instead of V(anet) <+ 1'bz; >>>>>> >>>>>> Chapter 9: System tasks and functions >>>>>> * [syntax 9-8, pg 224]: remove ";" >>>>>> * [clause 9.13.1, pg 224]: Remove the first half of the "if" >>>>>> clause in >>>>>> the last sentence in paragraph beginning with "The random_seed >>>>>> argument >>>>>> may take one of several forms"...The last sentence will just read >>>>>> "The >>>>>> function returns a new 32-bit random number each time it is called." >>>>>> * [clause 9.13.1, pg 224]: In the paragraph starting with "$arandom >>>>>> supports the seed argument..." >>>>>> The second sentence should say the following: "The >>>>>> analog_random_seed >>>>>> argument can also be a parameter or a constant, in which case the >>>>>> system >>>>>> function does not update the parameter value". (added parameter >>>>>> before >>>>>> value to make it more explicit). >>>>>> * [clause 9.13.1, pg 224]: Please add the following new sentence >>>>>> after >>>>>> the second sentence in the same paragraph: >>>>>> "However an internal seed is created which is assigned the initial >>>>>> value of the parameter or constant and the internal seed gets updated >>>>>> every time the call to $arandom is made." >>>>>> * [clause 9.13.1, pg 224]: Change cross-reference to 6.3 instead of >>>>>> 6.4 >>>>>> * [Syntax 9-9, pg 225]: remove ";" for the distribution functions. >>>>>> * [Syntax 9-9, pg 225]: fix font for ")" in rdist_t syntax >>>>>> * [clause 9.13.2, pg 225]: In bullet point #3 add the above two fixes >>>>>> done for $arandom with parameter seed (adding parameter and inserting >>>>>> the new sentence): >>>>>> "... upon successive calls to the system function. If the seed >>>>>> argument is parameter or constant, then the system function does not >>>>>> update the parameter value. However an internal seed is created which >>>>>> is >>>>>> assigned the initial value of the parameter or constant and the >>>>>> internal >>>>>> seed gets updated every time the call to $arandom is made. This makes >>>>>> the system function useable for parameter initialization." >>>>>> >>>>>> Chapter 10: Compiler directives >>>>>> * [clause 10.6, pg 254]: ";" missing in "input sin;" in the >>>>>> example at >>>>>> the very bottom of the page. >>>>>> * [clause 10.6, pg 255]: Add the following note before the example >>>>>> for >>>>>> VAMS-2.3 >>>>>> Note: The identifier logic is not a keyword in Verilog-AMS v2.3, >>>>>> and >>>>>> is a keyword in the P1800-2005 System Verilog standard. >>>>>> * [clause 10.6, pg 255]: "electrical" and "logic" should not be bold >>>>>> in >>>>>> the example given to describe VAMS-2.3 >>>>>> >>>>>> Annex A: Formal syntax definition >>>>>> * [A.2.5, pg 343]: use correct ` (tick) for the value_range_type. >>>>>> * [A.8.2, pg 359]: fix syntax definition for noise_table >>>>>> | noise_table (constant_concatenation | string [, string ]) >>>>>> >>>>>> Annex D: Standard definitions >>>>>> * [Annex D.1, pg 372]: domain discrete needs ';' >>>>>> >>>>>> Annex E: Spice Compatability >>>>>> * [Annex E.1.2, pg 378]: the blank bullet (bullet # 4) to be deleted. >>>>>> * [Annex E.1.2, pg 378]: Bullet #3 and #5 to be merged into one. >>>>>> >>>>>> Annex G: Open issues >>>>>> * Annex G to be deleted from the LRM. >>>>>> >>>>>> Annex H: Change history >>>>>> * [Table H.4, pg 398]: Items 14 & 16 are duplicates. Stu to verify. >>>>>> * [Table H.4, pg 398]: In item 17, cross/timer/above have an >>>>>> additional >>>>>> enable argument. >>>>>> * [Table H.4, pg 398]: Items 33 and 34 can be merged into single item >>>>>> * [Table H.4, pg 399]: Add new item saying "Annex G of LRM v2.2 has >>>>>> been >>>>>> deleted. Annex C of LRM v2.2 has been split and the section >>>>>> describing >>>>>> the changes from previous LRM versions has been documented in this >>>>>> Annexure (Annex H)." >>>>>> * [clause H.1.1, pg 399]: Clause H.1.1 should become H.2 >>>>>> >>>>>> Next Committee Meeting: >>>>>> * Planned for Monday, May 19th 7am Pacific time >>>>>> * Stu plans to release the next version of the document before the >>>>>> end >>>>>> of this week. Stu will send across two versions, one with change bars >>>>>> (to reflect the changes from today's meeting) and one without change >>>>>> bars - the official draft4 version. >>>>>> * Once all the changes are ratified by the committee, the clean LRM >>>>>> v2.3 >>>>>> draft4 version will be submitted to the Accellera board from approval >>>>>> >>>>>> Regards, >>>>>> Sri >>>>>> -- >>>>>> Srikanth Chandrasekaran >>>>>> Design Technology (Tools Development) >>>>>> Freescale Semiconductor Inc. >>>>>> T:+91-120-439 5000 p:x3824 f: x5199 >>>>>> >>>>>> -- >>>>>> This message has been scanned for viruses and >>>>>> dangerous content by MailScanner, and is >>>>>> believed to be clean. >>>>>> >>>>> -- >>>>> This message has been scanned for viruses and >>>>> dangerous content by MailScanner, and is >>>>> believed to be clean. >>>>> >>>>> >>>> >>>> >>> -- >>> This message has been scanned for viruses and >>> dangerous content by MailScanner, and is >>> believed to be clean. >>> >>> >> > -- ============================================== -- its another day for you and me in paradise -- -- David Miller -- Design Technology (Austin) -- Freescale Semiconductor -- Ph : 512 996-7377 Fax: x7755 ============================================== -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.Received on Wed May 21 13:23:22 2008
This archive was generated by hypermail 2.1.8 : Wed May 21 2008 - 13:23:28 PDT