If all three rise/fall/decay delay values are constant, we can use
the vvp .delay statement variant that takes three literal numbers.
If not, we have to use the variant that takes three net inputs. If
some of the delay values are constant, we need to create constant
drivers for those delay inputs.
These checks are not needed since we have already verified that
we have a 64 bit immediate value. This is likely old code that
should have been removed when the original functionality was
changed.
To match the behaviour of other simulators, delayed bit-based signals
should have the value 'x' and delayed real valued signals should have
the value 0.0 until the true initial value has propagated. This patch
provides this behaviour.
The .delay (x,y,z) functor and the get_number_immediate() function
only supports 32 bit delay values. This patch adds an error message
if the user passes a larger, but valid value.
This patch cleans up some unneeded code. Releases some allocated
memory before the compiler quits and fixes a couple minor memory
leaks in the compiler and vvp code generator.
This patch fixes the code generator to correctly create three value
constant delays. It also fixes a bug in the compiler related to the
precalculation of the high-Z delay when only two delays are given.
Previously if was using a pointer not a value comparison to find
the minimum value.
Variable delays should work when one or three values are given.
For the two value case we need to do a comparison at run time and
that will require changing the compiler/run time interface so that
can only go into the V0.10 branch. This patch can be applied to
both development and V0.9. I have added a sorry message and an
assert for this case. I will add the variable two delay case at a
later time. We also do not support mixing constant and variable
delays on a single statement. That is a much bigger change and
can wait until someone asks for it.
Actually, the immediate value handling is a little chaotic and should
be cleaned up. This patch opens the door for allowing signed immediate
values, and uses them in a few places where they are explicitly handled.
We must go through the opcodes that can take immediate values and make
explicit whether they are signed/unsigned/etc, and what their size
limits are.
The draw_input_from_net function was being used to access words of
a var array, which doesn't work. Have the draw_input_from_net punt
on that case, and by the way the mux inputs don't need to use that
function, instead they should use the general draw_net_input function
to get the input labels.
Previously only the logical operators (~, &, |, ^, etc.) supported a
delayed value in a continuous assignment. This patch should extend this
to all operators. An extensive check of real values was done. The same
will be done shortly for bit based nets.
Checks for constructs currently unsupported in continuous assignments
provide a more explicit message (** operator, real user functions,
{!, && and ||} operators with a real argument).
more general concept of arrays. The NetMemory and NetEMemory
classes are removed from the ivl core program, and the IVL_LPM_RAM
lpm type is removed from the ivl_target API.
Martin Whitaker
Cary R
Stephen Williams
Arun Persaud
steve