RE: [Fwd: simparam]

> -----Original Message-----
> From: geoffrey.coram@analog.com [mailto:geoffrey.coram@analog.com]
> Sent: Wednesday, May 26, 2004 6:36 AM
> To: VerilogA Device Modeling Reflector; Martin O'Leary
> Subject: [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)?

My perspective is that if we are adding new features to the language we should try to make them reasonably generic so that they don't have to revised later.

I think the idea of being able to accessing simulator/kernel parameter values is a really great idea that will be very useful going forward and that there is likely to be pressure to extend it to support new parameters.

For this reason, I believe that $simparam only returning real is overly restrictive. Being able to access string information via this mechanism is an obvious extension - e.g. the find the simulator name, the analog kernel name, the name of the circuit being simulated, simulation accuracy mode (which in some simulators in an enum/string rather than a numeric value).

However as pointed out in the email Geoffrey forwarded, having $simparam be ambiguous about the type it returns leads to other issues.

There in that forwarded email, I proposed another way to define $simparam so that this issue could be addressed.

Thanks,
--Martin

>
> -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 17:11:33 2004