A function call returning an enumeration value can be assigned to an
enumeration variable without an explict cast.
(cherry picked from commit bd0133b386)
If the condition expression is 2-state, the result won't be blended, so
the result will be a valid enum value if both true and false expressions
return the same enum type.
(cherry picked from commit 82c8a49573)
The reported problem was caused by a null statement in a case statement,
which caused the check for an infinite loop to fail. Further testing
exposed more problems with null statements in loop statements - these
caused crashes earlier in elaboration.
When for example assigning to foo[<x>] within a contitional, and
doing synthesis, we need to create a NetSubstitute device to manage
the l-value bit selects.
This generates an EQZ LPM device that carries the case-z-ness to
the code generator.
Also add to the vvp code generator support for the EQZ device so
that the synthesis results can be simulated.
Account for the wildcard devices in the sizer.
In a design, there may be lingering NexusSet objects, or the
nodangle may itself use NexusSet objects. This creates links,
and this should not confuse the functor.
While we are at it, clean up some handling of events structures.
This required keeping for-loops as actual things through the
netlist form so that the synthesizer can get at and understand
the parts of the for-loop. This may improve vvp code generation
in the future, but for now continue to present to the vvp code
generation the block-while form.
The netparray_t::slice_dimensions bug was the most insidious and
caused all manner of confusion. Also fix some other packed array
and unpacked array (and mixed) indexing calculations.
If the l-value is an unresolved wire, then elaboration can allow
the assignment as long as it is to bits that are not otherwise
driven. Handle this in some simple cases.
If a signal s driven by multiple non-overlapping NetPartSelect(PV)
objects, then combine them into a single NetConcat object. This
eliminates the need for resolvers in the target.
Add properties to the classes, and elaborate expressions that
have class properties. Describe class object property references
all the way down to the stub target.
Added: basic vpiPort VPI Objects for vpiModulkes
vpiDirection, vpiPortIndex, vpiName, vpiSize attributes
Since ports do not exist as net-like entities (nets either side
module instance boundaries are in effect connect directly in
the language front-ends internal representation) the port information
is effectively just meta-data passed through t-dll interface and
output as a additional annotation of module scopes in vvp.
Added: vpiLocalParam attribute for vpiParameter VPI objects
Added: support build for 32-bit target on 64-bit host (--with-m32
option to configure.in and minor tweaks to Makefiles and systemc-vpi).