The YosysHQ Verific Extensions are compiled separately using their own
stripped-down version of the Yosys headers. To maintain ABI
compatibility with older extension builds post C++-ification of Yosys's
logging APIs, which are backwards compatible on the API but not ABI
level, this commit adds ABI compatible versions of a subset of the old
logging API used by the extensions.
The ID(OVERFLOW) IdString isn't used widely enough that we require a
statically allocated IdString, but I think it's good to have an example
workaround in place in case more collisions come up.
I've used this shell command to obtain the list:
rg -I -t cpp -t yacc -o \
'ID\((\$?[a-zA-Z0-9_]+)\)|ID::($?[a-zA-Z0-9_]+)' -r 'X($1$2)' \
| LC_ALL=C sort -u
This removed the entries X(_TECHMAP_FAIL_) and X(nomem2init).
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.
Provides very simple ConcurrentQueue and ThreadPool classes that build even when threading is disabled.
Also provides a `DeferredLogs` class that captures log output to be replayed on the main thread
later.
The simple XOR `commutative_eat()` implementation produces a lot of collisions.
https://www.preprints.org/manuscript/201710.0192/v1/download is a useful reference on this topic.
Running the included `hashTest.cc` without the hashlib changes, I get 49,580,349 collisions.
The 49,995,000 (i,j) pairs (0 <= i < 10000, i < j < 10000) hash into only 414,651 unique hash values.
We get simple collisions like (0,1) colliding with (2,3).
With the hashlib changes, we get only 707,099 collisions and 49,287,901 unique hash values.
Much better! The `commutative_hash` implementation corresponds to `Sum(4)` in the paper
mentioned above.
`CellTypes::eval()` is more generic but also more limited. `ConstEval::eval()` requires more setup (both in code and at runtime) but has more complete support.
Still unsupported:
- wide muxes (`$_MUX16_` and friends)
Partially supported types have comments in `test_cell.cc`.
Fix `CellTypes::eval() for `$_NMUX_`.
Fix `RTLIL::Cell::fixup_parameters()` for $concat, $bwmux and $bweqx.
