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
Allows runtime checking whether a signal is forceable without needing to
check the existence of the `__VforceEn` and `__VforceVal` signals. This
will be useful for a later implementation of `vpiForceFlag` for
`vpi_put_value`.
The Syms class can contain a very large number of VeriltedScope
instances if `--vpi` is used, all of which need a call to the default
constructor in the constructor of the Syms class. This can lead to very
long compilation times, even without optimization on some compilers.
To avoid the constructor calls, hold VeriltedScope via pointers in the
Syms class, and explicitly new and delete them in the Syms
constructor/destructor. These explicit new/delte can then be
automatically split up into sub functions when the Syms
constructor/destructor become large.
Regarding run-time performance, this should have no significant effect,
most interactions are either during construction/destruction of the Syms
object, or are via pointers already. The one place where we used to
refer to VerilatedScope instances is when emitting an AstScopeName for
things like $display %m. For those there will be an extra load
instruction at run-time, which should not make a big difference.
Patch 3 of 3 to fix long compile times of the Syms module in some
scenarios.
In order to avoid long compile times of the Syms constructor due to
having a very large number of member constructor sto call, move to using
explicit ctor/dtor functions for all but the root VerilatedModule. The
root module needs a constructor as it has non-default-constructible
members. The other modules don't.
This is only part of the fix, as in order to avoid having a default
constructor call the VerilatedModule needs to be default constructible.
I think this is now true for modules that do not contain strings or
other non trivially constructible/destructible variables.
Patch 1 of 3 to fix long compile times of the Syms module in some
scenarios.
Instead of using the number of processors in the host, use the number of
processors available to the process, respecting cpu affinity
assignments. Without pthreads, fall back and use the number of
processors in the host as before.
This is now applied everywhere so runing `nuamctl -C 0-3 verilator` or
`numactl -C 0-3 Vsim` should behave as if the host has 4 cores (e.g.
like in CI jobs)
Still some remains of the --threads 0 mode. Remove unnecessary complexity
from V3EmitCModel. (Also don't pretend there is an MTask in single
threaded mode, when there really isn't.)
It's unlikely one value fits all use case, so making VL_LOCK_SPINS
configurable at model build time.
For testing, we reduce the value as we expect high contention.
This API is used if the user copies the process using `fork`
and similar OS-level mechanisms. The `at_clone` member function
ensures that all model-allocated resources are re-allocated, such
that the copied child process/model can simulate correctly.
A typical allocated resource is the thread pool, which every model
has its own pool.
Pack the elements of VlTriggerVec as dense bits (instead of a 1 byte
bool per bit), and check whether they are set on a word granularity.
This effectively transforms conditions of the form `if (trig.at(0) |
trig.at(2) | trig.at(64))` into `if (trig.word(0) & 0x5 | trig.word(1) &
0x1)`. This improves OpenTitan ST by about 1%, worth more on some other
designs.
Christian Hecken
Aliaksei Chapyzhenka
Christian Hecken
Geza Lore
Wilson Snyder
Yilou Wang
Krzysztof Starecki
Tom Manner
Bartłomiej Chmiel
github action
Ryan Ziegler
Arkadiusz Kozdra
Todd Strader
Marlon James
Yinan Xu
Mariusz Glebocki
Eyck Jentzsch
Kamil Rakoczy