This commit adds a `debug_scopes` container, which can collect metadata
about scopes in a design. Currently the only scope is that of a module.
A module scope can be represented either by a module and cell pair, or
a `$scopeinfo` cell in a flattened netlist. The metadata produced by
the C++ API is identical between these two cases, so flattening remains
transparent to a netlist with CXXRTL.
The existing `debug_items` method is deprecated. This isn't strictly
necessary, but the user experience is better if the path is provided
as e.g. `"top "` (as some VCD viewers make it awkward to select topmost
anonymous scope), and the upgrade flow encourages that, which should
reduce frustration later.
While the new `debug_items` method could still be broken in the future
as the C++ API permits, this seems unlikely since the debug information
can now capture all common netlist aspects and includes several
extension points (via `debug_item`, `debug_scope` types).
Also, naming of scope paths was normalized to `path` or `top_path`,
as applicable.
Processes can contain `MemWriteAction` entries which are invisible to
most passes operating on memories but which will be lowered to write
ports later on by `proc_memwr`. For that reason we can get corrupted
RTLIL if we sequence the memory passes before `proc`. Address that by
making the affected memory passes ignore modules with processes.
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.