Re: Valid Numeric Suffixes for Verilog-A/AMS

Hi Marq,
OK - to the first question I can answer that the
Cadence design environment does use these suffixes -
at least at the smaller end of the scale.. (this is
why I noticed that Verilog-A doesn't - I was trying to
reuse data.. )

I don't know about the second. 

- my preference would be just to reference the SI
scale. 


--- Marq Kole <marq.kole@philips.com> 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
> 
=== message truncated ===