When the continuous assignment is signed, then sign-extend the r-value
in the few cases where the expression is stubbornly smaller then the
desired width.
When multiply is done in native words, the conversion to words from the
vp_vector4_t vectors must be done signed. This only matters if the
input operands are different sizes (and themselves signed) but will
not hurt even if we want an unsigned result.
Logical (in)equality needs to look at all the bits of both operands,
and cannot short circuit the test unless defined bits differ. If there
are undefined bits, the equality is undefined at that point, but return
x only if there are not other bits that make the results clearly
unequal.
When nets are assigned directly to a net, we need to create a driver
to carry the strength. Normally, the implied drive of a continuous
assignment is carried by whatever gate the r-value expression ends
with, but with simble net-to-net assignment, there is no net so we
need to install a BUFZ to carry the assignment.
convert the continuous assign elaboration to use elaborate_expr
and synthesize methods instead of the elaborate_net methods of
PExpr. This exposes problems with the synthesize methods, but it
is a better way to do it.
In preparation for using the synthesize method to replace the
elaborate_net method of PExpr, rework the interface to the
synthesize() method. This changes no fnctionality, but does set
up the infrastructure for the next step.
When elaborating a parameter expression fails we need to set the
expression to 0 since it has already been partially allocated.
Doing this allows us to not evaluate the dummy expression later.
This patch adds the time and realtime properties for user
task and function arguments. It also make a common rule
for real and realtime since they are the same.
This patch fixes a bug in the VVP code generator that causes syntactically
incorrect code to be generated if an event expression contains a memory or
array port.
The list of defparams in the pform module definitions (in class Module)
should not be consumed when they are used. The module may be instantiated
moltiple times, so consuming the defparams during elaboration will cause
subsequent instantiations to not have the defparams. That's wrong.
When driving an input port to a module, watch out for the case where
the net is also driven within the instance. If this is the case, take
pains to make sure what goes on in the instance doesn't leak out
through the input port. Add a BUFZ (continuous assignment) to isolate
the context from internal driving.
The old code returns a vpiIntVal for $fscanf("%d") format strings. This
limits the maximum input range arbitrarily to 32 bit.
This patch implements %d parsing similiar to %b and %x.
'?' and 'X' chars are not accepted for %d format.
The double to vvp_vector4_t constructor was not using the correct
declaration for the bit words. This worked as long as unsigned and
unsigned long were the same size (usually).
The preprocessor was incorrectly setting the line when starting
an include file to the line it was called from instead of 1.
This would give incorrect line numbers for errors/warnings in
the included file.
The new real to int conversion was incorrectly setting the
bits for minus infinity to all ones. This is incorrect in a
two's complement encoding where the largest negative number
would be a leading 1 followed by an infinite number of zeros.
This patch updates the %cvt/vr command to use the new double to vector
constructor. This allows the resulting bit pattern to be larger than
a long. The old method was producing incorrect results without a
warning for large bit values.
This patch makes .part/pv strength aware, resolv vec8_pv
aware. vvp_net_fun_t adds vec8_pv as a virtual function
with an appropriate error default. vvp_fun_signal should
full support vec8_pv (not tested and may not be needed).
This patch fixes a bug where a local parameter with only a range
was incorrectly setting the default parameter type to IVL_VT_NO_TYPE.
This would create a compile time assert for any untyped
parameter/localparam immediately following it.
When generate schems and instance arrays are nested, it takes
multiple iterations of elaborate scope, defparams and evaluate
parameters before everything is worked out. Rework the work item
processing so that the loop elaborates scopes and runs defparams
in phases. The phases are needed so that we can tell when the
remaining defparams are orphaned.
Modules mentioned within generate schemes are not candidates for
defaults guesses at root modules. They are, obviously, used within
the generate schem.
We must run generate schemes after running defparams because the
defparams may define the results of the generate schemes. So put
the generate schemes for a module scope into elaborator work items.
The l-value of a defparam assignment is a hierarchical name that may
include array selects to select scopes from module arrays. Therefore
it makes no sense to store parsed defparams in a map. Instead, they
should go into an ordered list. This also maked more sense because later
defparams *may* have the same name as a previous defparam, and will
override the previous defparam. So replace the map of parsed defparams
with a list of parsed defparams.
Also, as soon as the defparam expression is elaborated, the list entry
is no longer needed, so delete it. Save memory.
It is possible for defparams to not find their target the first time
around, because the elaboration of the target scope is not yet done.
So retry the defparams once for each scope by putting it on a work
item in the elaborator_work_items list.
Stephen Williams
Cary R
Martin Whitaker
Nick Gasson
Holger Wächtler
nog