This patch adds the power operator for unsigned bit based values
in a continuous assignment. It also refactors the power code for
normal expressions and continuous assignments.
User functions called in a continuous assignment were not getting
their scope mangled. This is needed to handle arrayed instances and
possibly other things.
This patch adds bit based power support to normal expressions.
It also pushes the constant unsigned bit based calculation to
the runtime until the bit based method can be copied to the
compiler. Continuous assignments also need to use this type
of calculation.
This patch add delays in continuous assignments for the shift operators,
concatenations and replications. It also reports an error if the user
attempts to take the modulus of a real value.
This patch uncovers a couple other problems in the system. I am trying
to fix one of them. I will report the other problem shortly.
This patch fixes some of the delays in bit based continuous
assignments (unary -, unary +constants, string constants,
reduction operators and user functions).
Use draw_lpm_output_delay() in all functions that need it.
When used in continuous assignments, user defined functions may have
delayed output. Handle that by generating the proper .delay node when
needed to delay the output of a .ufunc node.
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).
Rework the encoding of a real value in the Cr<> label to be similar to
the format used by the %loadi/wr instruction. This mantissa-expoment
format better carries all the bits of the desired real value with
plenty of fidelity and range.
Rework the ivl_file_table_* interface to be more generic and easier
to use. Also all the vvp examples except for memory.vvp have been
fixed to run correctly with the current vvp. Someone with a bit more
experience will need to fix memory.vvp.
With this change, local symbols are not emitted in the vvp target,
but are marked as local. When thus marked, the vvp run time does not
offfer any VPI access and the signals (net or var) are effectively
invisible.
CMOS gates like NMOS and PMOS have a strength aware output.
They were missed when the NMOS and PMOS were fixed. "cmos.v"
will now pass in the test suite.
Modpaths need to be in the proper scope in order to be available to
vpi functions. The code generator manages that by writing the modpath
records with scope switch functions. Batch the modpath records at the
end of the structural stuff so that the scope switching doesn't cause
trouble.
Also seperate the modpath code into its own source file.
Signed-off-by: Stephen Williams <steve@icarus.com>
Constant propagation incorrectly elided an entire constant net node
if only the LSB of the driven vector was HiZ. This caused the entire
vector to look like HiZ. Also, the code generator for writing the
constant values missed bits.
Signed-off-by: Stephen Williams <steve@icarus.com>
This patch adds ivl_scope_time_precision() to the compiler which can
be used to extract the local scope precision. tgt-stub and tgt-vvp
have been modified to use this new function and output a value that
is appropriate. The vvp runtime has been altered to use this new
data which is accessed with the vpip_time_precision_from_handle()
function. vpiTimePrecision uses this function to return the correct
precision.
The outputs to bufif and nmos/pmos devices are always strength-aware,
so should have their outputs connected to a net8 device.
Signed-off-by: Stephen Williams <steve@icarus.com>
Arrays of nets that have all their words collapsed together can become
a collapsed array as a whole. Add support for this case in the vvp code
generator and runtime.
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.
Cary R
Stephen Williams
steve