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).
The previous commit introduced code that optimizes the activation
patterns to be able to generate smaller activation logic. The resulting
supercell was then enqueued as shareable using those optimized
activation patterns. The condition represented by the optimized patterns
is an over-approximation of the actual activiation condition. This means
using it as activiation for the supercell loses precision and pessimises
sharing of the supercell with further cells, breaking the sat/share
test.
This commit fixes that by using the optimized activiation patterns only
for the generation of activation logic and using the original patterns
for enqueuing the supercell.
In case the two sets of activation patterns are mutually exclusive
without considering the logic feeding into the activation signals, an
activation condition can only be relevant if present in both sets with
opposite polarity.
This detects pattern-only mutual exclusion by running an additional SAT
query before importing the input cone logic. If that is already UNSAT,
we remove all non-relevant condition and re-simplify the remaining
patterns.
In cases of pattern-only mutual exclusion, this will often produce much
smaller selection logic and avoid the more costly SAT query that
includes the input cones.
Partially reverts commit 9c5bffcf93.
The reasoning behind this is that setup.py is intended to strictly consume the Makefile and not be consumed by it. The attempt at using them recursively has caused a number of issues and has rendered Pyosys unusable to some users: See https://github.com/YosysHQ/yosys/issues/5012
Additionally, unlike the previous pyosys installation target, the wheel installation does not respect PREFIX=, only venvs.
For installation inside a venv, the intended method should remain a user manually executing `pip3 install .` instead of relying on the Makefile.
