Re: request $fdebug system task

Kevin -
In fact, you can't write pure Verilog-A for this, because
the iterations of the analog solver are "hidden" with
respect to the language.

Since $debug is already in the LRM, it's extremely simple to
describe the behavior of $fdebug; coming up with the full
specification for the "general purpose additions" would be
a much larger endeavor.  Creating the "standard library"
is another major task.  As Marq noted, VPI support in
Verilog-A simulators is rare to nonexistent, and Verilog-A
modelers are not looking to learn the whole VPI system to
get a little bit of debugging.  (I frequently edit the 
auto-generated C code to add print statements, rather than
adding $debug to the Verilog-A code and re-running the
Verilog-A to C compiler.)

It's completely impractical to stop using $ functions
($temperature, $abstime).  And there efficiency thing is a
red herring, since no analog simulators support that
replacement; even Verilog-D is said to have methods of
restricting which $ functions can be replaced.

-Geoffrey


Kevin Cameron wrote:
> 
> What I was trying to say is that you have asked for fairly specific
> functionality where a couple of general purpose additions would suffice.
> The two pieces of functionality required being a) some way of telling
> that the print statement needs to be executed, and b) some way of
> processing (or re-using) the arbitrary list of arguments to the top
> level call. Also, $ functions can be replaced by users' PLI code which
> can make execution/compilation somewhat inefficient, so in my opinion
> it's better if folks stop using them and just supply pure Verilog-A
> source for functions where possible.
> 
> I'd rather see a standard library of (pure Verilog-AMS) functions
> seperate from the LRM for adding functions/tasks that need to be
> portable - much the same as C & C++ come with a standard run-time
> lirararies (independent of the actual language definition). The
> librararies can be extended easily by user contribution without having
> to change the LRM - which is particularly useful if the LRM has multiple
> years between revisions.
> 
> If I was going to do this kind of thing in C I'd be looking to write
> something like:
> 
>     inline fdebug(FILE *fp,const char *fmt,...) {
>         if  (global_flags.debug) {
>              va_arg ap = va_start(fmt);
>              vprintf(fp,fmt,ap); // use ... above
>              va_end(ap);
>         }
>     }
> 
> Note: ... argument processing is probably fairly easy to add since it
> already has to be supported for PLI functions to interrogate the
> simulator about their arguments.
> 
> Kev.