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.
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.
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, and is
believed to be clean.
Received on Tue Feb 13 04:50:49 2007