[Fwd: simparam]

In Monday night's AMS conference call, Martin expressed an interest
in having additional entries in the table of $simparam arguments.
Below are his suggestions.

He points out in (2) that $simparam's return value is not fixed.
Without the *Name arguments, $simparam always has a numeric
return value; one could say it is always real and just
coerce "iteration" (and simulatorVersion, if necessary).

In the minutes from July 29, we dropped the request for a
$simulator(string) function that would return 0 or 1 depending
on whether the string matched the current simulator version.
We did this because Jeroen pointed out that all the
functionality needed from $simulator was obtainable from
`ifdef __SIMULATOR__.

I would like to re-state that conclusion to say we don't
need $simparam("simulatorName"), and that $simparam's value
should always be real.

Does anyone feel strongly about simulatorName?

Martin - can you think of a way you might accomplish the
same functionality using $simparam with a numeric return
value? Eg, you could say $simparam("spectre") and get
a 1 if spectre is responsible for that block of code.
Would you ever want to know the digitalKernel inside
an analog block (or vice-versa)?

-Geoffrey

Martin O'Leary wrote:
>
> Geoffrey,
> Here is my feedback on simparam.
> Issue (2) I see as critical.
> Thanks,
> --Martin
>
> (1) First of all would like the following addition arguments;
>
> simulatorSubSubversion - the simulators sub-sub-version
> (Cadence would likely use this to indicate the hotfix number)
>
> simulatorName - the name of the simulator
>
> And as many companies build mixed signal simulators using existing analog and digital simulators;
>
> analogKernelName - the name of the analog kernel
> analogKernelVersion - the version of the analog kernel
> analogKernelSubversion - the subversion of the analog kernel
> analogKernelSubSubversion - the sub-subversion of the analog kernel
>
> digitalKernelName - the name of the digital kernel
> digitalKernelVersion - the version of the digital kernel
> digitalKernelSubversion - the subversion of the digital kernel
> digitalKernelSubSubversion - the subsubversion of the digital kernel.
>
> (2) simparam doesn't have a consistent type for its return value
> Somethings it is real, string and perhaps even integer!
> This makes life difficult for an implementer as the type of an expression involving $simparam cannot be determined statically.
>
> The specification of $value$plusargs provides a cleaner way to do this by having a format character in the string, just like fscanf in C e.g.;
>
> if ($value$plusargs ("FINISH=%d", stop_clock))
>
> The %d indicates that the return type is meant to be integer.
> %f %s are supported also.
>
> (3) Also it is stated in V2001 for $value$plusargs;
> If a string is found, the function returns a non-zero integer.If no string is found matching,the function returns the integer value zero and the variable provided is not modified. No warnings shall be generated when the function return zero (0).
>
> Like this feature aspect of $value$plusargs too but you understand the application of $simparam better so this is just a suggestion.
Received on Wed May 26 06:36:30 2004