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.)
Because all objects in C++ must have non-zero size, a `value<0>` has
a size of 4 despite consisting of a `uint32_t chunks[0]`. The debug
item assertions were not written expecting that and prevent any debug
items for such values from compiling.
The C API does not define exactly what happens for a zero-width debug
item, but it seems OK to say that they should refer to some unique
pointer that cannot be, in actuality, read or written. This allows
some techniques or optimizations that use `curr` pointers as keys and
assume they correspond 1-to-1 to simulation objects.
Miodrag Milanović
Martin Povišer
github-actions[bot]
Austin Rovinski
Claire Xen
N. Engelhardt
passingglance
Amelia Cuss
Ethan Mahintorabi
Jannis Harder
Ethan Mahintorabi
Catherine