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 >> > >> 2.2, %r or %R >> > >>> for printing using "engineering notation, using >> > >> the scale >> > >>> factors defined in Section 2.5.3." >> > >>> >> > >>> -Geoffrey >> > >>> >> > >>> >> > >>> Ken Kundert wrote: >> > >>>> Jonathan, >> > >>>> The complete set can be found here: >> > >>>> http://physics.nist.gov/cuu/Units/prefixes.html >> > >>>> >> > >>>> Personally, I'd like to see us add a function >> > or >> > >> a special %code that >> > >>>> converts numbers into strings with scale >> > factors >> > >> and perhaps units. I >> > >>>> find the way verilog prints out real numbers to >> > >> be quite difficult to read. >> > >>>> -Ken >> > >>> 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 >> > >> >> > >> >> > > >> > > >> > > 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 - 14:29:13 PST