Re: percent codes for analyses (was: Feb 8 2007 minutes)

Marq Kole wrote:
>
> All,
>
> First, a word of warning: in C/C++ for multiple character percent 
> codes the base code is at the back of the sequence, the other 
> characters are merely modifiers. The problem is that if you don't do 
> this and you want the percent code to be followed directly by a normal 
> character sequence you don't know where the percent code ends and the 
> normal character sequence starts. So if you want to use %a for 
> analysis, you'd have to think of some of the leftover characters as 
> modiers. Unless you always want a multi-character code, but there is 
> no precendent for that -- in any language that supports printf-like 
> functionality!
>
> This whole dealing with special percent codes in the first argument of 
> $fopen() appears to me as quite awkward. It will change the definition 
> of $fopen in a way that has no advantages for digital Verilog or 
> SystemVerilog. I expect a lot of users will try to give additional 
> arguments as though it was a full fledged printf-like functionality. 
> Once you start thinking about different values to be returned by the 
> various %a codes you will likely run into implementation dependent 
> ways of retrieving the data.

The  "..." in the earlier post was to indicate  that you could use it 
like a printf (is there a compelling reason not to?).

>
> If I'm allowed to make another suggestion: we currently support string 
> parameters in Verilog-AMS. Can't we also support local string 
> parameters and define a system function that does a $sformat() that 
> outputs a value for a string parameter or string localparam? As a 
> suggestion:
>
> *$pformat*( /format_string/, /args.../)
>
> where the return value is an initializer for a string parameter or 
> string localparam. Additionally retrieve the name of the analysis 
> using a specific system task, say $analysis_name. Then it could be 
> used as:
>
> localparam string dump_name = $pformat("dump.%s.txt", $analysis_name);
>
> analog
>   $fopen(dump_name);

Doesn't seem to have any advantage over:

   analog
     $fopen("dump.%s.txt", "pw",$analysis_name);

>
> The advantages are that you do not have to change the definition of 
> $fopen -- as the proposed extension is much more for analog than for 
> mixed-signal, let alone digital, the side effects on digital Verilog 
> and SystemVerilog are less if we just add a system function. Next to 
> that, we do not have to use the %a or a multi character code, but can 
> better take this (global) information from the $analysis_name system 
> task and use optional arguments for this system task to get different 
> or more information.
The definition of $fopen would be extended rather than changed i.e. 
would be entirely backward compatible. I can't see digital users 
complaining about the additional functionality, it saves fiddling with 
string variables.
>
> $analysis_name returns the name of the analysis, or if the simulator 
> does not support naming of analyses the analysis type plus an ordinal, 
> e.g. "dc1".
> $analysis_name("name") is equivalent to $analysis_name -- "name" is 
> the default argument.
> $analysis_name("type") returns the analysis type. The type name is 
> taken from the possible arguments for the analysis() function (LRM 
> 2.2, section 4) to achieve optimal portability.
> $analysis_name("simulator") returns the name of the simulator.
> $analysis_name("user") returns the name of the process owner.
> etc.
>
> There is a parallel with the $simparam() system function, but while 
> that function always returns a real, this function will always return 
> a string value. The standard should give a minimal set of arguments 
> that must be supported while allowing additional implementation 
> dependent ones.
That does have the advantage that you can do a PLI implementation if you 
need to.

Kev.
>
> Cheers,
> Marq
>
>
> Marq Kole
> Competence Leader Robust Design
>
> Research
> NXP Semiconductors
>
>
> owner-verilog-ams@server.eda.org wrote on 12-02-2007 21:46:25:
>
> > Geoffrey, Kevin, Jonathan
> > thanks for your input.
> > Comments below.
> > --Martin
> >
> > -----Original Message-----
> > From: owner-verilog-ams@eda.org [mailto:owner-verilog-ams@eda.org] On
> > Behalf Of Geoffrey.Coram
> > Sent: Monday, February 12, 2007 4:52 AM
> > Cc: verilog-ams
> > Subject: percent codes for analyses (was: Feb 8 2007 minutes)
> >
> > Martin O'Leary wrote:
> > >
> > > * Add percentage codes for analysis that can be used to uniquely name
> > > a file generated by an analysis.
> > > It a file is not uniquely name, it will be overwritten if there are
> > > multiple analysis opening, closing and writing to the file.
> >
> > Let's be sure that SV is going to go along with this; there are only 26
> > percent codes, and most of them are already used.  We don't want SV to
> > assign a different meaning.
> >
> > What does this code look like?  If I put "results_%a" to I get files
> > like "results_dc" "results_ac" ...
> >
> > oleary>My take that we should use multiple character percentage codes in
> > order to avoid conflict with the SV standard or reserving too much of
> > the name space. They would all start with '%a' or '%A' - a/A for AMS.
> > e.g. %aa for analysis, %as for simulator name, etc ...
> > As suggested %a and %r would then need to be reserved for use by
> > Verilog-AMS only.
> > This I hope would address
> > 1) the risk of SV and Verilog-AMS coming into conflict
> > 2) allow a mechanism for the Verilog-AMS to expand the percentage code
> > capabilities easily
> > 3) consumming too much of percentage code name space.
> >
> >
> > Or are the names more like the temporary filenames generated by the C
> > function "tmpnam"?
> >
> > On one hand, it would be nice to know that dc results are in
> > "results_dc"; on the other, I don't want the results of the second dc
> > analysis in a single netlist to overwrite those of the first dc
> > analysis.
> >
> > Some simulators have names for the analysis, eg "dc1" in this:
> > dc1 dc start=0 stop=5
> > Will the percent code use this name?  On one hand, this would give good
> > control to the user; on the other hand, it may be inappropriate to
> > dictate this for the simulator in an HDL manual.
> >
> > oleary>The file would be named after the analysis name (ie. dc1 ) not
> > the analysis type (dc).
> > I believe many simulators already have some kind of analysis
> > naming/tagging scheme if only to determine the name of the different
> > transient output waveform files when multiple transient analyses are
> > being conducted.
> >
> > -Geoffrey
> >
> >
> > Codes used in Verilog 1364-2005:
> > b,c,d,e,f,g,h, ,l,m, ,o, ,s,t,u,v, ,z
> >
> > C uses i,n,p,x in some implementations, though %i looks to the same as
> > %d; %x is "unsigned hex" in C, whereas %h is "hex" in Verilog.  Also, %u
> > is "unsigned decimal"
> > in C, but "unformatted 2-value" in Verilog.  (%p is for a pointer. %n is
> > strange: printf outputs nothing but instead stores back into the
> > corresponding argument the number of characters printed so far.)
> >
> > I don't see any new ones in 1800-2005.  AMS uses %r.
> >
> > That leaves: a,j,k,q,w,y  %a sure would be nice for analysis ...
> >
> > --
> > This message has been scanned for viruses and dangerous content by
> > MailScanner, and is believed to be clean.
> >
> >
> > --
> > This message has been scanned for viruses and
> > dangerous content by MailScanner, and is
> > believed to be clean.
> >
> >
>
> -- 
> This message has been scanned for viruses and
> dangerous content by *MailScanner* <http://www.mailscanner.info/>, and is
> believed to be clean. 

-- 
This message has been scanned for viruses and
dangerous content by MailScanner, and is
believed to be clean.