Jonathan, There are not two proposals. I am very happy with the language as it is currently defined in this regard. My position was simply that if the exotic scale factors are added, they should only be added for reading, not writing. My preference would be to not add the two %codes you are suggesting as they seem low value. Your first is only different from %r in unusual cases, and your second is not much more readable than conventional floating point notation. However, it is not a strong preference. -Ken Jonathan David wrote: > While I won't completely agree, some of those points > are valid.. > > However, I don't think I can separate the "machine > consumption" output data from the "for human > consumption" in my Verilog-A/Verilog-AMS models.. Most > times the output is DUAL purpose. - but that point > being taken I'll probably HAVE to support processing > ALL the suffixes as WELL as exponential format in > every postprocessing script, no matter what the spec > does.. > I'll also agree that > even the SI defined range of suffixes is not suffient > to cover every number we might output for formatting > this way.. doing "+-inf" and "eff0" would not really > be helpful. > > So lets take that off the table. > > BUT - I would like a "readable - but machine > processable" Engineering Format.. (exponential, but > exponent is multiples of three, and Manissa ranges > between 1000 and 1) ie Engineering format w/o the SI > suffixes. > > ------------------------ > My informal survey locally here shows that the systems > tool we use doesn't support the use of numeric > suffixes (AKA "scale factors") at all. > I don't think that helps me draw a conclusion. > > My proposal is for a simpler standard and description, > and use of the definitive "commonly used" set as > defined in the SI standard, to be supported for both > number definition, and the %r output format. > > My concern is disappointed users.. (1.2y) worked in > the noise definition, but it printed out as 1.2e-21 > when it went to the output file with %r.. How do I get > the same numeric format on all lines in the file? > The prototype user in this category is MySelf. > I am counting on the (eventual) exposure to the rest > of the set - (ie to those NOT commonly used) will > resolve any confusion with using this format. > > Ken's concern is confused users (in seeing suffixes > they are not "used to"), and Proposes to use a more > limited set of suffixes for the %r numerical formated > output.. (basically the same set currently defined in > the Verilog-2001 spec - and the original verilog-A > spec..) but to allow use of the full SI set > for numeric description. > > A compromise that would probably satisfy everyone's > desired features would be two add ANOTHER output > format that would use the full SI set of suffixes. > (as well as the one to do the engineering-Exponential > format.. ) > > If we were using Roberts Rules here, its time for the > Moderator to Call for Order, and to request that a > motion be made and seconded before we continued the > debate. > My view is that we have two motions proposed and > (currently) no seconds. > (I am not under the delusion that we are subject to > Roberts Rules of Order, but suspect rather that there > is an analog for this in the rules this group is > subject to.. ) > > I'd like to know what others think .. > > > > > > --- Ken Kundert <ken@designers-guide.com> wrote: > >> Marq and Jonathan, >> I don't believe that accepting all known scale >> factors on input but >> only using the commonly known scale factors on >> output is a serious point >> of confusion. After all, Verilog-AMS will always >> consume what it >> produces. It has never been a point of confusion in >> Spectre, which has >> been doing this for 20 years. >> >> However, printing infinity for anything equal to or >> larger than 1e27 and >> printing 0 for anything smaller than 1e-24 seems a >> questionable practice >> to me. And the only justification for doing any of >> this is to make >> easier to write a script to parse the output >> produced by Verilog-AMS. >> But really in this case, people should not be using >> %r at all. One uses >> %r when the output is meant to be read by people and >> %e when it is meant >> to be read by machines. >> >> I have been monitoring use of these scale factors >> for years, and I have >> never seen z, y, Z, and Y in use. I have >> occasionally seen P and E used >> when talking about things like worldwide information >> storage capacity, >> but never in a electrical design or modeling >> setting. >> >> -Ken >> >> Marq Kole wrote: >>> Jonathan, Ken, >>> >>> Do we know of any prior art in this field? Are >> there any tools around >>> that already do output engineering notation with >> scale factors, and what >>> do they do at the far ends of the scale? >>> >>> I have no preference for either solution, but >> would warn against a too >>> narrow view of what are "well-known" scale >> factors. Are there any >>> physical domains where 'z', 'y', 'Z', and 'Y' are >> more generally used >>> than in electronics? >>> >>> Mind that 8 prefixes were added to SI in years >> 1964 (femto, atto), 1975 >>> (peta, exa) and 1991 (zetta, zepto, yotta, yocto). >> So even femto is not >>> that old - what is the expected life time of >> Verilog-AMS and is it >>> likely that in that time zetta will become more of >> a household scale >>> factor than it currently is? >>> >>> regards, >>> Marq >>> >>> >>> owner-verilog-ams@eda.org wrote on 11-03-2006 >> 05:09:43: >>>> My thought process is a little different.. >>>> >>>> I'd be more confused if one tool writes out with >> one >>>> set of suffixes (say the 1964 set of SI prefixes >> Ken >>>> is asking for) and reads a different set (perhaps >> the >>>> FULL set of SI prefixes - 10^24 -10^-24) as >> defined >>>> today ( http://www.bipm.org/en/si/prefixes.html ) >>>> >>>> On top of that, Kens proposal complicates my >> (probably >>>> perl) routine to post process the results where I >> now >>>> have to handle all the codes, and exponential >> format, >>>> and may find either in a single set of data.. >> (not to >>>> mention that the exponential format takes 3 more >>>> characters on the line possibly messing up my >> careful >>>> format selection to get the columns to line up!!) >>>> >>>> Ken's argument doesn't change what I want.. >>>> If I specify %r (or what ever the FULL SI suffix >>>> supported formatting code is %u? ) then I don't >> want >>>> to see any numbers in exponential format -- its >> maybe >>>> restrictive.. but anything smaller I'd accept as >>>> "+/-zero" and anything larger as "+/-inf.." >>>> >>>> I'd like a Third format option(assuming I can't >>>> convince Ken - in which case this becomes the >> second., >>>> an Exp3 format which uses exponential format but >>>> powers are in multiples of 3. >>>> >>>> I'll have to look at the present version of the >> spec >>>> and see what codes are available. >>>> Jonathan >>>> >>>> BTW: I have to APPOLOGIZE >>>> y != Yeta.. Y = YETA and y = yocto ) >>>> z = zepto and Z = ZETA .. >>>> ------------------------------- >>>> >>>> >>>> >>>> >>>> >>>> --- Ken Kundert <ken@designers-guide.com> wrote: >>>> >>>>> Jonathan, >>>>> The basic problem is that very few people >> would >>>>> know what 1.3z was, >>>>> whereas everyone knows what 1.3e-21. The >>>>> desirability of %r drops >>>>> considerably if there is a chance it could >> produce >>>>> results that many >>>>> people would not know how to read. >>>>> >>>>> My preference is to allow any scale factor to >> be >>>>> used as input, but only >>>>> to output the common ones. If it is important >> that >>>>> we have a consistent >>>>> set, I would definitely recommend going with >> the >>>>> reduced set. >>>>> >>>>> I suspect that if you asked 100 engineers what >> zepto >>>>> was, I bet that >>>>> most one or two would know that it was 1e-21. I >>>>> expect that most people >>>>> would think it was a Marx Brother. >>>>> >>>>> -Ken >>>>> >>>>> Jonathan David wrote: >>>>>> Why? if the number is in that range, and you >> are >>>>>> printing with format %r, I would want it to >> use >>>>> the >>>>>> suffix/Scalefactor rather than switching to >> e-21 >>>>> when >>>>>> printing! >>>>>> + we only have to change 1 paragraph in the >> spec, >>>>>> 2.5.3!! - to split we'd have to modify TWO >>>>> paragraphs! >>>>>> that's MHO.. >>>>>> Jonathan >>>>>> >>>>>> >>>>>> >>>>>> --- Ken Kundert <ken@designers-guide.com> >> wrote: >>>>>>> Geoffrey, >>>>>>> Cool! Somehow I missed that. >>>>>>> >>>>>>> If the list of scale factors are expanded as >>>>>>> Jonathan requests, it would >>>>>>> probably be best to make the two lists >> distinct >>>>> as I >>>>>>> believe very few >>>>>>> people know y, z, Y, or Z. Even E and P are >>>>> dubious. >>>>>>> The idea being that >>>>>>> the language would accept all as input but >> only >>>>>>> output the most common ones. >>>>>>> >>>>>>> -Ken >>>>>>> >>>>>>> Geoffrey.Coram wrote: >>>>>>>> Ken - >>>>>>>> Your suggestion was already incorporated in >> LRM >> > === message truncated ===> begin:vcard >> fn:Ken Kundert >> n:Kundert;Ken >> org:Designer's Guide Consulting, Inc. >> adr:;;101 First Street, #150;Los Altos;CA;94024;USA >> email;internet:ken@designers-guide.com >> tel;work:+1-650-968-8291 >> note:Public key for encrypted email: >> http://www.designers-guide.com/kens.key >> x-mozilla-html:FALSE >> url:http://www.designers-guide.com >> version:2.1 >> end:vcard >> >> > >
This archive was generated by hypermail 2.1.8 : Tue Mar 14 2006 - 18:31:50 PST