Some cells (e.g. $macc_v2) are marked evaluable, but will raise an abort if called with `CellTypes::eval()`.
Instead of falling through to the abort, we can pass a pointer to a boolean to check for errors.
Use said check to catch `CellTypes::eval()` errors and treat them as unevaluable but otherwise continue.
Reflows the series of if checks into `if ... else if ... else` so that we can check for errors and set state in one place.
Fixes these build errors I'm getting locally with `tcl-devel-9.0.0-7.fc42.x86_64`.
I guess Tcl 9 broke this.
```
passes/cmds/sdc/sdc.cc:438:6: error: no matching function for call to 'Tcl_ListObjLength'
438 | if (Tcl_ListObjLength(interp, listObj, &listLength) == TCL_OK) {
| ^~~~~~~~~~~~~~~~~
/usr/include/tclDecls.h:1788:13: note: candidate function not viable: no known conversion from 'int *' to 'Tcl_Size *' (aka 'long *') for 3rd argument
1788 | EXTERN int Tcl_ListObjLength(Tcl_Interp *interp,
| ^
1789 | Tcl_Obj *listPtr, Tcl_Size *lengthPtr);
| ~~~~~~~~~~~~~~~~~~~
passes/cmds/sdc/sdc.cc:446:8: error: no matching function for call to 'Tcl_ListObjLength'
446 | if (Tcl_ListObjLength(interp, subListObj, &subListLength) == TCL_OK) {
| ^~~~~~~~~~~~~~~~~
/usr/include/tclDecls.h:1788:13: note: candidate function not viable: no known conversion from 'int *' to 'Tcl_Size *' (aka 'long *') for 3rd argument
1788 | EXTERN int Tcl_ListObjLength(Tcl_Interp *interp,
| ^
1789 | Tcl_Obj *listPtr, Tcl_Size *lengthPtr);
| ~~~~~~~~~~~~~~~~~~~
```
This uses the environment variable `YOSYS_PLUGIN_PATH` to provide multiple colon-delimited search paths for native plugins in a similar manner to `PATH` for executables and `PYTHONPATH` for Python modules.
This addresses https://github.com/YosysHQ/yosys/issues/2545, allowing Yosys to be better packaged in non-FHS environments such as Nix.
We were performing the helper passes `abc9_ops -replace_zbufs` and
`abc9_ops -restore_zbufs` for every module, but those passes act on the
full design (and can't be applied entirely selectively due to entering
and leaving bufnorm).
This lead to an explosive creation of a lot of redundant bufnorm helper
cells that would have been cleaned up by `clean` but that never ran.
Instead we now run each helper pass once, one before and one after
iterating over the selected modules. This limits the number of bufnorm
helper cells.
For consistency.
Also trying a new thing: only rebuilding objects that use the pybind11 library. The idea is these are the only objects that include the Python/pybind headers and thus the only ones that depend on the Python ABI in any capacity, so other objects can be reused across wheel builds. This has the potential to cut down build times.
- Rewrite all Python features to use the pybind11 library instead of boost::python.
Unlike boost::python, pybind11 is a header-only library that is just included by Pyosys code, saving a lot of compile time on wheels.
- Factor out as much "translation" code from the generator into proper C++ files
- Fix running the embedded interpreter not supporting "from pyosys import libyosys as ys" like wheels
- Move Python-related elements to `pyosys` directory at the root of the repo
- Slight shift in bridging semantics:
- Containers are declared as "opaque types" and are passed by reference to Python - many methods have been implemented to make them feel right at home without the overhead/ambiguity of copying to Python and then copying back after mutation
- Monitor/Pass use "trampoline" pattern to support virual methods overridable in Python: virtual methods no longer require `py_` prefix
- Create really short test set for pyosys that just exercises basic functionality
The `portarcs` pass was already ignoring `$buf` cells when loading
timing data, but now bufnorm will also emit `$input_port` and `$connect`
helper cells, which need to be ignored as well.
Was previously the number of proposed renames, but since renames can be skipped this causes the final count to differ from the number of actually renamed objects.
Check counts in `tests/various/autoname.ys`.
This option allows you to process a design that includes unsupported
SVA. Unsupported SVA gets imported as formal cells using 'x inputs and
with the `unsupported_sva` attribute set. This allows you to get a
complete list of defined properties or to check only a supported subset
of properties. To ensure no properties are unintentionally skipped for
actual verification, even in cases where `-sva-continue-on-error` is
used by default to read and inspect a design, `hierarchy -simcheck` and
`hierarchy -smtcheck` (run by SBY) now ensure that no `unsupported_sva`
property cells remain in the design.
This code is quite confusing because there are two "is the cell known" filters
applied, one while building the cell vector and one after building the cell
vector, and they're subtly different. I'm preserving the actual behaviour here
but it looks like there is, or was, a bug here.
Currently the order of extraction can vary based on which ABC runs finish first. That's
nondeterministic, therefore bad. Instead, force the processing to happen in the same order
as `assigned_cells`, i.e. the same order we use when not using parallelism. This should
make everything deterministic.
Note that we still allow ABC runs to complete out of order. Out-of-order results are
just not extracted until all the previous runs have completed and their results
extracted.
1) Change token from ABC_DONE to YOSYS_ABC_DONE to be a bit more robust against false matches.
2) Emit the token from the sourced script so that we don't have to worry about it showing up in the echoing
of the command as it executes. It will only appear in ABC stdout when it executes, i.e. when
our script has completed.
3) `set abcout` doesn't actually switch ABC to line buffering on stdout, since HAVE_SETVBUF is not actually
set in ABC builds in general. So stop using that. ABC does the necessary flushing when
`source` has finished.
With the updated bufnorm code, buffered 'z drivers are used as anchor
points for undirected connections. These are currently not supported by
read/write_xaiger2, so we temporarily replace those by roughly
equivalent $tribuf cells which will be handled as blackboxes that
properly roundtrip through the xaiger2 front and backend.
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.
Doing ABC runs in parallel can actually make things slower when every ABC run requires
spawning an ABC subprocess --- especially when using popen(), which on glibc does not
use vfork(). What seems to happen is that constant fork()ing keeps making the main
process data pages copy-on-write, so the main process code that is setting up each ABC
call takes a lot of minor page-faults, slowing it down.
The solution is pretty straightforward although a little tricky to implement.
We just reuse ABC subprocesses. Instead of passing the ABC script name on the command
line, we spawn an ABC REPL and pipe a command into it to source the script. When that's
done we echo an `ABC_DONE` token instead of exiting. Yosys then puts the ABC process
onto a stack which we can pull from the next time we do an ABC run.
For one of our large designs, this is an additional 5x speedup of the primary AbcPass.
It does 5155 ABC runs, all very small; runtime of the AbcPass goes from 760s to 149s
(not very scientific benchmarking but the effect size is large).
Large circuits can run hundreds or thousands of ABCs in a single AbcPass.
For some circuits, some of those ABC runs can run for hundreds of seconds.
Running ABCs in parallel with each other and in parallel with main-thread
processing (reading and writing BLIF files, copying ABC BLIF output into
the design) can give large speedups.