The `%disable` instruction will stop the execution of all active
threads of a specific scope. This is what is required to implement
the semantics of the Verilog `disable` statement.
But it is not suited to implement the SystemVerilog flow control
statements such as `return`, `continue` and `break`. These only
affect the thread hierarchy from which it is called, but not other
concurrently running threads from the same scope.
Add a new `%disable/flow` instruction that will only disable the thread
closest to the current thread in the thread hierarchy. This can either be
the thread itself or one of its parents. This will leave other concurrent
threads of the same scope untouched and also allows function recursion
since only the closest parent thread is disabled.
Note that it is not possible to implement this using `%jmp` instructions
since a block in a function with variable declarations will be its own
sub-thread, but using flow control instructions it is possible to exit from
that thread to the parent scope, which is not possible with `%jmp`
instructions.
Signed-off-by: Lars-Peter Clausen <lars@metafoo.de>
Previously both ':' and ';' were recognised as path separators on all
platforms, but ':' can't be used in Windows. So now we only recognise
';' when running in Windows and ':' when running in any other OS.
Array ports are created via a resolve list. We need to detect and
record whether they need to be created in an automatic context at
the point they are declared, not at the time they are created.
String literals may have escaped special characters in them. Make sure
we are processing all the special characters that the standard supports,
and also fix the handling of the assignment to strings. Note that the
vvp input has string literals sanitized so that the parser can handle
the various binary values. desanitize the strings when pushing string
literals into the string stack. This fixes string assignments, and other
string operations.
The old implementation connected all inputs to the same vvp_net_t port,
on the basis that we don't care about the data values or what port they
arrived on. But if one or more of the inputs fans out to multiple nets,
the chains get tangled, which either results in connections being lost
or inappropriate connections being made, depending on the order that
the inputs are linked.
This could have been fixed by using a standard wide functor. But as we
don't care about the data values, that would be unnecessary overhead.
We just need separate vvp_net_t objects to handle the input connectivity
and can keep using a single shared functor.
This is needed for the waveform dumpers now that vpi_iterate(vpiModule, NULL)
has been ficed to only return modules.
This includes recognising vpiProgram and vpiInterface, although the compiler
and vvp currently incorrectly classify them as modules.
The code assumed all handles stored in vpip_root_table were modules. This
is true for traditional Verilog, but not so for SystemVerilog.
Whilst here, also add support for iterating over packages.
This might come to pass for example when calling the function
$ivl_string_method$len(<expression>) where the expression is
calculated, and not simply a variable name.
In the rare cases where DARRAY signals are in the network, handle
them by creating the proper ivl_nexus_t node. This also implements
the receive of vvp_object_t objects bu vvp_fun_anyedge_sa. This
together makes it possible for IVL_VT_DQUEUE objects to be in
wait lists.
This fixes#412
sync_cb::run_run() attempts to cast the obj field of the callback data to a
__vpiSysTaskCall pointer. But a sync_cb object is only used for simulation
time callbacks, where the obj field is (mostly) not used, so I can't see
that would ever succeed. As the obj field is not required to be set by the
user, the dynamic cast results in undefined behaviour, so mingw32 is not to
blame.
This code was introduced by Johann Klammer in commit c79df7c44, but the user
klammerj and all trace of that pull request have vanished from GitHub, and
there is no associated regression test, so I can't establish the rationale
for it.
IEEE Std 1800-2017 Section 7.6 Array assignments
Assignment of a dynamic array creates a duplicate of the source,
so that assignments to the copy don't impact the original. Handle
all sorts of dynamic array base types.
Since commit 15cda5fe, forked threads are never embedded in the parent
thread, so we no longer need the special case code that ensured that
task/function calls were reaped before a join.
This also fixes GitHub issue #368.
Lars-Peter Clausen
Martin Whitaker
Stephen Williams
Cary R
Martin Whitaker
Miodrag Milanovic
Marlon James