This fixes an issue introduced in commit 26644ea due to which flip-flops
are inadvertently ignored when building up driver map. The mentioned
commit wasn't without functional change after all.
Depending on the WIN32 compilation mode, PathMatchSpec may expect a LPCSTR or
LPCWSTR argument. char* is only convertable to LPCSTR, so use that
implementation
Signed-off-by: Austin Rovinski <rovinski@nyu.edu>
This is an alternative to setting the dont_use property in lib. This brings
dfflibmap in parity with the abc pass for dont_use.
Signed-off-by: Austin Rovinski <rovinski@nyu.edu>
See the test case. PROC_ROM will consider this for evaluation, even
though -- without any actions -- lhs is empty (but still "uniform").
A zero-width memory is constructed, which later fails check with:
ERROR: Assert `width != 0' failed in kernel/mem.cc:518.
Ensure we don't proceed if there's nothing to encode.
A yosys build with verific support can act as a non-verific yosys with
`YOSYS_NOVERIFIC=1` in the enviornment, which is useful for quickly
testing code that works with either frontend without rebuilding yosys.
Before this change, this did not work with `make test` as it would only
consider the build time configuration to decide whether to run tests
that depend on verific support, immediately failing on those tests when
the enviornment contains `YOSYS_NOVERIFIC=1`.
This adds logic to the makefile that checks this enviornment variable
and also exports YOSYS_NOVERIFIC=1 to the enviornment when that is
present as a make variable to support `make test YOSYS_NOVERIFIC=1`
invocations.
Fixes a bug in the handling of the recently introduced $check cells.
Both $check and $print cells in clk2fflogic are handled by the same code
and the existing tests for that were only using $print cells. This
missed a bug where the additional A signal of $check cells that is not
present on $print cells was dropped due to a typo, rendering $check
cells non-functional.
Also updates the tests to explicitly cover both cell types such that
they would have detected the now fixed bug.
Before this commit, `at()` and `operator[]` did the same thing, making
one of them redundant. There was also a somewhat awkward `parts_at()`,
which is more generic than `at()`.
After this commit, `parts_at()` becomes `at()`, and `at()` becomes
`operator[]`. Any quick-and-dirty accesses should use `items["name"]`,
which expects a single-part item. Generic code should instead use
`items.at("name")`, which will return multiple parts. Both will check
for the existence of the name.
This is unlikely to break downstream code since it's likely been using
the shorter `operator[]`. (In any case this API is not stable.)