Re: [Fwd: simparam]

Martin's proposal was to make $simparam more like $value$plusargs:
$simparam always returns an integer, 0 meaning not found, 1 meaning
found, and you give a format specifier:

integer found;
real gmin_val;
found = $simparam("gmin", "%f", gmin_val);
if (found==0) begin
  $strobe("no gmin in simulator??");
  $stop;
end

In this case, we are left with a user error when gmin is not
found, rather than a simulator error. My experience with
user errors is poor: one simulator would report the error
for one analysis, but then skip the check in the next
analysis and proceed to run it; another simulator forgets
to print the $strobe message.

I'm more concerned about a mismatch of value and specifier:
what if I had (mistakenly) typed
   found = $simparam("gmin", "%d", gmin_val);
(thinking "%d" is for double -- had an intern do that once)

$value$plusargs can work like sscanf, because it is trying
to parse the input string. But the simulator's gmin is
not in a string, so that analogy breaks down.

Perhaps it would be better to do:
   found = $simparam("gmin", real, gmin_val);
or even
   found = $simparam("gmin", gmin_val);
where the value the simulator has is coerced, if necessary,
to the type declared for the variable (gmin_val in this case).

-Geoffrey

Martin O'Leary wrote:
> 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
Received on Thu May 27 07:39:40 2004