The old scheme of linking the VPI modules with the vvp exports meant they
did not work when loaded by the compiler. Instead, let each client create
a jump table for the VPI routines and pass that to each VPI module as it
is loaded.
In vvp, the __vpiSignal object holds a pointer to the scope containing
the signal. This was getting set to the current scope when the net was
finally resolved, rather than to the scope where the net was declared.
The .scope needs to be aware of return types so that the %call/vec4
function knows how to intialize the return value. We also need to
extend the %ret/vec4 to support writing parts of the return value.
When putting a value onto a wire, the value needs to be sent to the
filter, not the functor (the functor may be part of the expression
that drives the wire).
Force and release weren't implemented properly (or at all in the
case of real values). They need to behave the same as the force
and release operations in vthread.cc.
Second try cleaning up cast-alignment problems surrounding need_result_buf().
Clang gave a bunch of warnings like
vvp/vpi_const.cc:196:34: warning: cast from 'char *' to 'p_vpi_vecval' (aka 't_vpi_vecval *') increases required alignment from 1 to 4 [-Wcast-align]
This version is verbose and changes the prototype for need_result_buf().
But it is semantically (c++) correct, and makes need_result_buf() feel like malloc().
This means using some of the new vec4 infrastructure to get at the
data, instead of using the old thread bit pointers. In the process,
remove the vbit and vwid members that pointed to thread bits. Those
bits no longer exist.
Redsign the handling of the return value, including a rework of
the %vpi_func syntax to carry the needed information.
Add a few more arithmetic operator instructions.
Currently, when a variable expression is passed to a system task,
the expression value is stored in thread memory. Values stored
in thread memory cannot safely be passed to $strobe or $monitor,
because the thread memory may get reused or deallocated before
the $strobe or $monitor task actually executes. As a temporary
measure, we just trap this case and terminate with a "sorry"
message. A proper fix would require the expression value to be
calculated at the time the $strobe or $monitor executes, not at
the time it is called.
This provides the ivl_target.h interface for class definitions
and expressions, the vvp code generator support for class objects
and properties, and the vvp run time support. Trivial class objects
now seem to work.
Create stub class objects at the vvp level and generate the code
to invoke that stub. Implement the routines needed to implement
a test for null object references.