__vpiVThrVec4Stack::vpi_get_value_int_ was always treating the thread variable
as unsigned, rather than observing the value of __vpiVThrVec4Stack::signed_flag_.
Not sure why this was done - none of the regression tests broke when I changed
this.
This causes vvp to evaluate all the input expressions for a user
function call before assigning any of them to the function input
variables. This stops the input variables being overwritten if
the same (non-automatic) function is used in one of the input
expressions.
When performing constant propagation, we need to take into account
values driven through a tran object. For now, be pessimistic, and
assume that all tran objects connect to a variable driver.
A disable statement can terminate a thread whilst it still has
local variables on the stack (e.g. the loop counter for a repeat
statement). We need to clear the thread stacks when this happens.
Using a UL constant in a unit64_t context does not work on a 32-bit
machine since UL is 32-bits. Instead create uint64_t constants using
static casts and the appropriate bit operators.
If either the index or part offset expressions generate an undefined
value then the assignment is skipped. This patch reworks the code that
handles the flags used to detect this. For some simple cases a global
flag is not needed, but for other cases one is needed since there are
two expressions that can generate an error and even when there is only
a variable expression this error state needs to be preserved if there
is a variable delay. An undefined delay value defaults to zero and is
not an error.
This should not change the functionality, but to save space trim any
unneeded bits from a binary constant. Also for the case of emitting
a signed undefined value when the allow signed flag is not set add
the width to the constant.
Cary R
Martin Whitaker
Stephen Williams