#17 request support for run-time vpiParameter

[mike]

vpiParameter support is incomplete, vpiParameters which
are not "string" types are simply not passed to vvp.

I have created an example patch against 0.8.1 which
"fixes" this. I have not yet ported this to the cvs
branch due to unrelated assertion failures in that area
which break my environment.

This patch provides vpiStringVal support for fetching
parameters at runtime. Other format types are NOT
supported and would require a more invasive set of edits.

vpiParameters may now be fetched either by scan/iterate
and/or vpi_get_handle_by_name direct reference. They
also appear as you would expect with the "list" command
when $stop'd.

[mike]

Logged In: YES
user_id=1422121

Testing my patch, I have concluded that I over simplified
the problem a little too much...

It needs to retain the difference between "string" and
"number" to ensure that the vpiType returned is correct at
run-time...

So, please hold off on consideration of this patch, it will
need some work to add a second path through the tgt-vvp and
vpi_scope code to allow for a numeric paramter as well as a
string parameter...

[mike]

Logged In: YES
user_id=1422121

New patch. This does all the stuff I tried to avoid in the
prior patch, but now, you can distinguish at run-time
between a string based parameter and a numeric parameter.

It also now allows all the various retreival types
(vpiHex/Dec/Int etc...)

It creates a path parallel to the "string_param" code path
that now creates something that looks more like a
_vpiDecConst than a __vpiStringConst.

[mike]

[Stephen Williams]

Logged In: YES
user_id=97566

I've attached a patch that applies to the 20060216 snapshot. It is also
checked into CVS and will be included in subsequent snapshots. There
is also a listparam test in the ivtest suite that checks the behavior.