This is an error in traditional Verilog and a unsupported feature in
SystemVerilog. Fail gracefully with a suitable error/sorry message.
Do the same for task declarations.
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.
It is possible for an assignment statement to be part of a
grander complex that has lots of outputs, not all handled
by this particular assignment. In that case, the assignment
may need to figure out which output it is supposed to bind to.
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.
Some types, i.e. vector types with parameterized dimensions,
may have different elaboration results in different scopes.
Handle those cases in the elaboration caches.
When the clock enable is not generated, don't try to hook it
up then detach it. That will make a mess that needs clean up.
Instead, leave unused ce pins (Enable) unconnected.
Signals are collected in a link map that uses the Link class so that
it doesn't need to save Nexus objects. But naked uses of Link don't
set the node_ and pin_zero_ members. So initialize them to zero so
that Nexus scanners can skip these naked Links.
If statements within blocks can confuse the synthesizer when there
are outputs that are assigned ahead of the if statement. This patch
handles that case.
Some of the SDF warnings were mixing some of the scope path with the
instance name. These are now separated into just scope and instance name.
There was also a place where vpi_get_str() was being called twice in a
single print statement. This is illegal since vpi_get_str() uses a single
buffer and multiple calls will overwrite the buffer.
This function was apparently not well tested, because any use of
acc_handle_object() triggered a use of vpi_handle_by_name that was
buggy.
The implementation was awkwardly written, to parts of it were redone.
The tf_igetlongtime function may pass in any kind of object, so the
scale() function may need to convert an object handle to the handle
for the objects parent scope.
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.
Get rid of the data_type, signed_flag, and range arguments to the
pform_module_define_port because they add no value within the
parse.y parser. Cleaning these out will hopefully ease the addition
of new functionality.
This can be handled entirely in the parser, where we rewrite the
syntax to me a begin/end block that contains the index variable
declaration and the for loop.
The root cause was that NetESignal::dup_exr() was not copying the calculated
type (signed/unsigned) of the expression.
In passing, found and fixed a similar issue when calculating a blended value
for a constant ternary expression.
%exec_ufunc assumed that because a function can never block, a call to
vthread_run() on the function code would only return when the final %end
instruction had been executed. This is not true if the function contains
a named block, which will be executed via a %fork instruction, allowing
the main function thread to suspend after a %join instruction. The fix
is to break %exec_ufunc into two instructions, the first setting the
function inputs and executing the function code, the second collecting
the function result. This provides the opportunity for the parent thread
to suspend after the %exec_ufunc instruction until all its children have
completed.