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
> > 
> > 
>