This commit includes PR #6688.
It adds support for `vpiForceFlag` and `vpiReleaseFlag` to
`vpi_put_value`. `vpi_get_value` is updated to return the value of
either the signal itself, or the `__VforceVal` control signal, depending
on whether the forcing is active.
The functionality is tested in the tests `t_vpi_force`, which tests that
forcing and releasing works on a clocked register being forced with a
VpiIntVal, as well as `t_vpi_forceable_bad`, which tests that attempting
to force a signal without marking it forceable causes an error. The
tests were run under Verilator (based on dc00bf248 with the commit for
isForceable applied), `Icarus Verilog version 13.0 (devel)
(s20251012-20-gcc496c3cf)`, and `xrun 24.09-a071`.
The implementation is simply done using string concatenation of the
signal name with the __VforceEn and __VforceVal suffixes. The signal vop
that the vpi_put/get functions operate on is then pointed towards either
the base signal or the __VforceVal signal (for vpi_put) or the
__VforceRd signal (for vpi_get).
While it works and passes the newly implemented tests, this solution is
quite brittle and in part re-implements existing functionality by
recreating the `__VforceRd` signal, so once #6705 is completed, it
should extend `VerilatedVar` to hold information about the force control
signals, which is provided at Verilation time, rather than a runtime
lookup.
Because `valuep` should get set to the value of the signal after
forcing when `vpi_put_value` is called with `vpiReleaseFlag`, this
commit also adds information about `isContinuously` to the
`VerilatedVarFlags`.
Lastly, since unpacked arrays cannot be forced (#4735), a Verilation
time check for this was added and tested in `t_forceable_unpacked_bad`,
which simplifies the error handling in `vpi_put_value` and
`vpi_get_value`. The same was done for forceable strings, which is
tested in `t_forceable_string_bad`.
Fixes#5933
Note this might miss some cases where a sub-tree within an And/Or/Xor
tree is optimizeable, but not the whole tree, but in practice this seems
to work better than the alternative of keeping a set of failed nodes and
bail early.
Now that we have an efficient algorithm to analyse which bits in a
combinational cycle are not dependent on the cycle, can simplify the
cycle fixup algorithms. Remove FixUpSelDrivers: this was a heuristic
to save on the expensive independent bits analysis, but itself can
cause a performance problem on certain inputs that result in a large
number of attempted fixups. Doing this simplifies the driver tracing
algorithm, and because we now only attempt to trace drivers that are
known to be independent of the cycles, it should always succeed...
Unless of course there is a mismatch between the independent bit
analysis ant the driver tracing algorithm. In such case (when we managed
to prove independence, but then fail to trace a driver), we will crash,
which is still easier to sv-bugpoint than a performance bug.
Fixes#6744
Forceable/externally written variables cannot be used as the canonical
result variable for a Dfg value as the variables value can be
inconsistent with its Dfg drivers (e.g. when forced).
Christian Hecken
github action
Wilson Snyder
Thomas Dybdahl Ahle
Luca Colagrande
Todd Strader
Dan Ruelas-Petrisko
Geza Lore
Ryszard Rozak
Krzysztof Bieganski
Alex Solomatnikov
em2machine
Yilou Wang
Pawel Kojma
Aliaksei Chapyzhenka
Christian Hecken
Matthew Ballance