All, I feel I have to vent a little and provide an opinion... I have seen more than one well known tools doing things like this: 1.23456e+3pF to describe a 1.23456nF capacitance, for example. PLEASE, PLEASE, PLEASE!!! Anyway, having a very bad memory for names, stories, and similar subjects, I think it is much more useful to have exponential notation (something like 1.234e+2) and engineering notation (exponent going in increments of 3). For doing visual comparisons this seems to be a lot more useful than having to remember which one is larger when it comes to z or a or y... I think we need to think practical here and provide a system that helps the engineers to get a quicker mental idea for what the size is. (This is similar to the problem of tool units, such as drill bits. I can tell a lot quicker in a decimal metric system which drill bit is bigger than the other, than having to compare a #1 drill bit with a 15/32 or 29/64 size...) The "convenience" of using letters is actually a nuisance especially when we consider that lot of tools have a problem with case sensitivity. Take for example HSPICE, which uses x for mega, simply because they cannot distinguish between an upper case and lower case "M". Add to this the total chaos of incorrectly spelled units in many well known tools, or papers/presentations. I see way too many times nano-seconds spelled with a capitol "S", like "nS" which actually means nano-Siemens, a unit of conductance, not time, or mb for Mega-Byte, mhz for Mega-Hertz, etc... The sad part is that the usual reaction I get from people when I start correcting such things is that they feel that they are right, because they learnt these spellings from their favorite text books in their favorite school, etc... When I point out that there are official IEEE documents defining spelling rules, most responses I get are along the lines of who cares, nobody follows those rules anyway... Sorry, but I had to let this out. I feel better now... I guess, the bottom line is that I prefer numbers over letters, and I like the option of having increments of 3 in the exponent in many situations. I think mixing letters and numbers based on a decision of "well known" or "lesser known" would be a mistake. Familiarity and fluency with the meaning of these letters depends on which discipline one works in most of their time. An astronomer may know the high end letters better, but a quantum physicist may be familiar with the low end letters. It will depend on who you ask, kind of like the statements in text books: "This obvious ... is left to the student to prove... or derive..." Yeah, right, obvious to the student who has never heard about it... My $ 0.02... Arpad ================================================================ ________________________________ From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On Behalf Of Marq Kole Sent: Monday, March 13, 2006 6:57 AM To: verilog-ams Subject: Re: Valid Numeric Suffixes for Verilog-A/AMS 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 > > > > >Received on Tue Mar 14 19:01:16 2006
This archive was generated by hypermail 2.1.8 : Tue Mar 14 2006 - 19:01:18 PST