The tests/verilog/*_if_enc.ys scripts instantiate simple encoder
modules, both with and without the SystemVerilog priority/unique/unique0
keywords, and check for consistency between the two for the subset
of inputs where the priority/unique/unique0 "if" result is
well-defined.
These tests vacuously succeed at the moment, since priority/unique
keywords are silently ignored and therefore the generated logic is
trivially identical. But the test cases will be capable of detecting
certain types of unsound optimisation if priority/unique handling is
introduced later.
Add support to the "read_verilog -sv" parser to validate the
"unique", "unique0", and "priority" keywords in contexts where
they're legal according to 1800-2012 12.4.2.
This affects only the grammar accepted; the behaviour of conditionals
is not changed. (But accepting this syntax will provide scope for
possible optimisations as future work.)
Three test cases ("unique_if", "unique_if_else", and
"unique_if_else_begin") verify that the keywords are accepted where
legal and rejected where illegal, as described in the final paragraph
of 12.4.2.
Calling `throw dst_end_of_data_exception()` when the desired number of cycles has been reached means that the fst reader can't tidy up after itself and leads to memory leaks.
This doesn't happen when the `-stop` flag is used because the `Yosys::FstData` struct tracks the end time and skips the outer callback if the simulation has gone past the desired end time.
Move cycle checking into the inner callback along with the time checking means that the outer callback no longer needs to throw an exception in order to stop checking further values, while still allowing the fst reader to finish reading and deallocate memory.
libfst is no longer included in gtkwave and instead has its own repo. There has also been some refactoring, so the patches need to update to match, as does sim.cc.
When building `WITH_PYTHON`, where a global list of modules is maintained, deleting a module also erases the entry in said global list. This can lead to memory corruption if the global list is destructed before the module.
Using `on_shutdown()` instead means the module destructor is explicitly called before the global list can be destructed, preventing the issue.
Also add a comment to `Pass::~Pass()` to suggest the same for future passes that might try to use that (and see this commit in the blame if they need a reason why).
Using `:=` while providing an override (either in Makefile.conf or on the command line) does not correctly apply the override in other simply expanded variables (using `:=`). Instead, passing an explicit `PYTHON_EXECUTABLE=python3.15` while leaving `PYTHON_CONFIG` implicitly defined results in it being set to `python3-config` instead of the expected `python3.15-config`.
