- consistently use value semantics for objects passed along FFI boundary
(not ideal but matches previous behavior)
- add new overload of RTLIL::Module: addMemory that does not require a "donor" object
- the idea is `Module`, `Memory`, `Wire`, `Cell` and `Process` cannot be directly constructed in Python and can only be added to the existing memory hierarchy in `Design` using the `add` methods - `Memory` requiring a donor object was the odd one out here
- fix superclass member wrapping only looking at direct superclass for inheritance instead of recursively checking superclasses
- fix superclass member wrapping not using superclass's denylists
- fix Design's `__str__` function not returning a string
- fix the generator crashing if there's any `std::function` in a header
- misc: add a crude `__repr__` based on `__str__`
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.
This is a complete rewrite of the RTLIL-kernel-side bufnorm code. This
is done to support inout ports and undirected connections as well as to
allow removal of cells while in bufnorm mode.
This doesn't yet update the (experimental) `bufnorm` pass, so to
manually test the new kernel functionality, it is important to only use
`bufnorm -update` and `bufnorm -reset` which rely entirely on the kernel
functionality. Other modes of the `bufnorm` pass may still fail in the
presence of inout ports or undirected connections.
Now that we only call `bitvectorize()` in non-const methods, we can move the casting-away-const to only happen
in `bitvectorize()`, which is deprecated so only some plugins (maybe) are using it.
This means `const` `Const` methods don't change the underlying data, which means
they'll be safe to use from multiple threads if/when we want to do that.
The vast majority of ID(...) uses are in a context that is overloaded
for StaticIdString or will cause implicit conversion to an IdString
constant reference. For some sufficently overloaded contexts, implicit
conversion may fail, so it's useful to have a method to force obtaining
a `IdString const &` from an ID(...) use.
When turning all literal IdStrings of the codebase into StaticIdStrings
this was needed in exactly one place, for which this commit adds an
`id_string()` call.
dict is pretty slow when you don't ever need to iterate the container in
order. And the hashfunction for char* in dict hashes for every single
byte in the string, likely doing significantly more work than std::hash.
If you have a large design with a lot of modules and you use the Verilog
backend to emit modules one at a time to separate files, performance is
very low. The problem is that the Verilog backend calls `design->sort()`
every time, which sorts the contents of all modules, and this is slow
even when everything is already sorted.
We can easily fix this by only sorting the contents of modules that
we're actually going to emit.
Robert O'Callahan
Miodrag Milanović
Robert O'Callahan
Vaibhav Singh
Mohamed Gaber
Emil J
Akash Levy
Jannis Harder
Drew Lewis
George Rennie