It adds `DriveBit`, `DriveChunk` and `DriveSpec` types which are similar
to `SigBit`, `SigChunk` and `SigSpec` but can also directly represent
cell ports, undriven bits and multiple drivers. For indexing an RTLIL
module and for querying signal drivers it comes with a `DriverMap` type
which is somewhat similar to a `SigMap` but is guaranteed to produce
signal drivers as returned representatives.
A `DriverMap` can also optionally preserve connections via intermediate
wires (e.g. querying the driver of a cell input port will return a
connected intermediate wire, querying the driver of that wire will
return the cell output port that's driving the wire).
This is already supported by `SigSpec` and since both `SigChunk` and
`SigSpec` implement `extract` which is the multi-bit variant of this,
there is no good reason for `SigChunk` to not support
`SigBit operator[](int offset)`.
When implementing custom log_... functions or custom overloads for the
core log functions like log_signal it is necessary to return `char *`
that are valid long enough.
The log_... functions implemented in log.cc use either `log_id_cache` or
`string_buf` which both are cleared on log_pop.
This commit adds a public `log_str` function which stores its argument
in the `log_id_cache` and returns the stored copy, such that custom
log functions outside of log.cc can also create strings that remain
valid until the next `log_pop`.
This adds a generic non-recursive implementation of Tarjan's linear time
SCC algorithm that produces components in topological order. It can be
instantiated to work directly on any graph representation for which the
enumerate_nodes and enumerate_successors interface can be implemented.
Only the `B` input (the shift amount) can be marked as signed on a
`$shiftx` cell. Adapt the helper accordingly and prevent it from
creating invalid RTLIL when called with `is_signed` set. Previously
it would mark both `A` and `B` as signed.
Previously `extract` on a `SigSpec` would always unpack it. Since a
significant amount of `SigSpec`s have one or few chunks, it's worth
having a dedicated implementation.
This is especially true, since the RTLIL frontend calls into this for
every `wire [lhs:rhs]` slice, making this `extract` take up 40% when
profiling `read_rtlil` with one of the largest coarse grained RTLIL
designs I had on hand.
With this change the `read_rtlil` profile looks like I would expect it
to look like, but I noticed that a lot of the other core RTLIL methods
also are a bit too eager with unpacking or implementing
`SigChunk`/`Const` overloads that just convert to a single chunk
`SigSpec` and forward to the implementation for that, when a direct
implementation would avoid temporary std::vector allocations. While not
relevant for `read_rtlil`, to me it looks like there might be a few easy
overall performance gains to be had by addressing this more generally.
Emily Schmidt
Roland Coeurjoly
Jannis Harder
Emil J
Emil J. Tywoniak
Alexander von Gluck
George Rennie
Martin Povišer
Miodrag Milanovic
KrystalDelusion