Re: Valid Numeric Suffixes for Verilog-A/AMS

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