Re: request $fdebug system task

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.

Marq Kole wrote:

> Kevin,
>
> There is no relation of $fdebug to any variable argument syntax 
> whatsoever. $debug itself is a purely analog functionality: it gives 
> output of the specified (format) string not only at the times of the 
> accepted time steps of the analog solver, but also during the Newton 
> process. Its primary use is in debugging analog Verilog-A models -- 
> you can see how a particular model implementation is influencing DC 
> and transient convergence.
>
> There is not PLI currently available to support $fdebug, at least not 
> in any practical implementation (is there any commercial or 
> proprietary Verilog-A capable analog simulator in use that supports 
> VPI?). Apart from the $debug call, there is no simulator-independent 
> way to get information during the Newton process on how convergence is 
> proceeding. Even with most simulator-dependent code, it is very hard 
> to get the output of one particualr device.
>
> $fdebug gives a little more support for compact model developers in 
> debugging and streamlining their code, and for compiler developers in 
> generating more optimal code. As this is purely analog code, there is 
> no relation to SystemVerilog whatsoever, so I personally do not see a 
> need to postpone this until after SystemVerilog integration (2008?).
>
> Regards,
> Marq
>
>
> Marq Kole
> Competence Leader Analog Simulation, Philips ED&T
>
>
>
>
>
>
>
>
>
> *edaorg@v-ms.com*
>
> Sent by:
> owner-verilog-ams@eda.org
>
> 10-12-2005 10:26
>
> 	
> To
> 	verilog-ams@eda.org
> cc
> 	Marq Kole/EHV/RESEARCH/PHILIPS@PHILIPS
> Subject
> 	Re: request $fdebug system task
> Classification
> 	
>
>
>
> 	
>
>
>
>
>
>
> Not sure what $debug does particularly, but it crosses my mind that
> we don't have the equivalent of C's ... argument handling in Verilog-AMS
> or SystemVerilog which would make it easier to write your own routines
> for this kind of thing. Maybe we should just add something like that
> which might be more generally useful.
>
> I assume you can currently get the $fdebug functionality through PLI etc.
> at the moment, so it's probably not an essential enhancement, and I would
> therefore suggest not adding it at this time but leave it until after
> merging with SystemVerilog.
>
> Kev.
>
> >
> > All,
> >
> > On behalf of the compact device modelling group in Philips Research 
> I have
> > the request for a $fdebug system call. This would essentially be the 
> same
> > as the $debug system call, but writing to specified file instead of the
> > regular (simulator-dependent) output. The rationale behind this is in
> > separating $debug calls from several devices, allowing regression 
> testing
> > of model performance vs. simulation algorithm, and more efficient
> > post-processing of large amounts of data from $debug calls.
> >
> > Here is an example of such use:
> >
> >         integer fp;
> >
> >         analog begin
> >           @(initial_step)
> >             fp = fopen("mosmodel.debug");
> >
> >           ...
> >           $fdebug(fp, "%M: Ids = %g", I(ds));
> >           ...
> >
> >         end
> >
> > Before I make an entry in the Mantis database, I would like to know
> > whether this would be an acceptable proposal.
> >
> > Regards,
> > Marq
> >
> >
> > Marq Kole
> > Competence Leader Analog Simulation, Philips ED&T
>
>