Re: percent codes for analyses

Marq Kole wrote:
>
> All,
>
> My suggestion is merely to keep the two functionalities separate: 
> opening a file and formatting a string. The language design will be 
> much cleaner without an extended $fopen. I do not particularly care 
> about the implementation details of the various possibilities as long 
> as this separation of functionality is maintained.

I partially agree, but isn't going to be cleaner if you have to add all 
the semantics for string / reg types to analog to do it. Also, from a 
performance/optimization perspective it's better not to have the 
intermediate data. Maybe you can bury the string formating in the 
$fopen  (e.g. $fopen(make_file_name(),"w");)  but I'm not sure if that 
is currently supported or what would be required to support it.

>
> As far as I can see this specific handling of $fopen is only needed 
> because the string parameters in Verilog-AMS are at this moment not 
> compatible with the register strings in 1364-2005 and SystemVerilog. 
> This incompatibility is (should be!) a temporary situation which needs 
> to be resolved ideally before Verilog-AMS is merged with SystemVerilog 
> - I do not see many users understanding the need for two different 
> kinds of string data types. Consequentially, when this is resolved all 
> the string handling and formatting system tasks and functions of 
> SystemVerilog will also be available for Verilog-AMS string 
> parameters. Then there will be no need for string formatting in the 
> $fopen system task.
When do you think the merger will happen?

Parameters are run-time constants, the requirement seemed to be the 
ability to open multiple differently named files in a single run.

Kev.
>
> As a second concern: retrieving the name of an analysis is only a 
> subset of much more string information that can be retrieved from the 
> simulator and that might be useful in various output strings: using a 
> system function such as the proposed $analysis_name gives that 
> opportunity in a much more flexible way than multiple character 
> percent codes ever could.
>
> Cheers,
> Marq
>
>
> Marq Kole
> Competence Leader Robust Design
>
> Research
> NXP Semiconductors
>
>
> Kevin Cameron <kevin@sonicsinc.com> wrote on 13-02-2007 00:33:06:
>
> > 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?).
>
> Separation of functionality
>
> >
> > >
> > > 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);
>
> Apart from keeping string formatting a separate action from opening a 
> file.
>  
> > >
> > > 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.
>
> OK
>
> > >
> > > $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.
>
> PLI is not a practical approach for most analog/mixed-signal solutions.
>
> -- 
> 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.