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
b0adf5f7af