Turns out this is not strictly necessary for this PR but it's
still a good thing to do and makes it clearer that the stats
are not modified in a possibly racy way.
We will want to query `keep_cache` from parallel threads. If we compute
the results on-demand, that means we need synchronization for cache
access in those queries, which adds complexity and overhead. Instead, prefill
the cache with the status of all relevant modules. Note that this doesn't
actually do more work --- we always consult `keep_cache` for all cells of
all selected modules, so scanning all those cells and determining the kept
status of all dependency modules is always required.
Later in this PR we're going to parallelize `scan_module` itself, and that's also
much easier to do when no other parallel threads are running.
These updates should not be necessary. In fact, if they were necessary, this code
would be buggy, because the results would depend on the order in which wires are traversed:
If wire A is retained, which causes an update to `used_signals`, which then causes wire B
to be retained when it otherwise wouldn't be, then we would get different results depending
on whether A is visited before B.
These updates will also make it difficult to process these wires in parallel.
The negation here is confusing. The intent of the code is "if `s1` is preferred
over `s2` as the canonical `SigBit` for this signal, make `s1` the canonical `SigBit`
in `assign_map`", so write the code that way instead of "if `s2` is not preferred
over `s1` ...".
This doesn't change any behavior now that `compare_signals()` is a total order,
i.e. `s1` is preferred over `s2`, `s2` is preferred over `s1`, or `s1` and `s2` are equal.
Now, when `s1` and `s2` are equal, we don't call `assign_map.add(s1)`, but that's
already a noop in that case.
Currently when `s1` and `s2` are different bits of the same wire,
it is possible for both `compare_signals(s1, s2)` and `compare_signals(s2, s1)` to
return false. This means the calling code will call `assign_map.add()` for
both `s1` and `s2`, which doesn't make much sense --- one of `s1` or `s2`
should be consistently preferred.
So fix that by preferring the `SigBit` with the smaller bit offset.
This ensures that entering and leaving bufnorm followed by `opt_clean`
is equivalent to just running `opt_clean`.
Also make sure that 'z-$buf cells get techmapped in a compatible way.
Instead, change the default `Design::selected_modules()` to match the behaviour (i.e. `selected_unboxed_modules_warn()`) because it's a lot of files to touch and they don't really _need_ to be updated.
Also change `Design::selected_whole_modules()` users over to `Design::selected_unboxed_whole_modules()`, except `attrmap` because I'm not convinced it should be ignoring boxes. So instead, leave the deprecation warning for that one use and come back to the pass another time.
This does not correctly handle an `$overwrite_tag` on a module output,
but since we currently require the user to flatten the design for
cross-module dft, this cannot be observed from within the design, only
by manually inspecting the signals in the design.
This makes clk2fflogic add an attr to $ff cells that carry the state of
the emulated async FF. The $ff output doesn't have any async updates
that happened in the current cycle, but the $ff input does, so the $ff
input corresponds to the async FF's output in the original design.
Hence this patch also makes the following changes to passes besides
clk2fflogic (but only for FFs with the clk2fflogic attr set):
* opt_clean treats the input as a register name (instead of the
output)
* rename -witness ensures that the input has a public name
* the formal backends (smt2, btor, aiger) will use the input's
name for the initial state of the FF in witness files
* when sim reads a yw witness that assigns an initial value to the
input signal, the state update is redirected to the output
This ensures that yosys witness files for clk2fflogic designs have
useful and stable public signal names. It also makes it possible to
simulate a clk2fflogic witness on the original design (with some
limitations when the original design is already using $ff cells).
It might seem like setting the output of a clk2fflogic FF to update the
input's initial value might not work in general, but it works fine for
these reasons:
* Witnesses for FFs are only present in the initial cycle, so we do
not care about any later cycles.
* The logic that clk2fflogic generates loops the output of the
genreated FF back to the input, with muxes in between to apply any
edge or level sensitive updates. So when there are no active updates
in the current gclk cycle, there is a combinational path from the
output back to the input.
* The logic clk2fflogic generates makes sure that an edge sensitive
update cannot be active in the first cycle (i.e. the past initial
value is assumed to be whatever it needs to be to avoid an edge).
* When a level sensitive update is active in the first gclk cycle, it
is actively driving the output for the whole gclk cycle, so ignoring
any witness initialization is the correct behavior.
These can be used to protect undefined flip-flop initialization values
from optimizations that are not sound for formal verification and can
help mapping all solver-provided values in witness traces for flows that
use different backends simultaneously.
Previously, opt_clean would reconnect all ports (including FF Q ports)
to a "canonical" SigBit chosen by complex rules, but would leave the
init attribute on the old wire. This change applies the same
canonicalization rules to the init attributes, ensuring that init moves
to wherever the Q port moved.
Part of another jab at #2920.
