Drop the parts that are being dropped.
Move the things that are being moved.
Also move the verilog stuff out of README and into the docs.
GettingStarted is less cut and dry, so hold off on that one.
`Const::size()` returns int, so change iterators that use it to `auto` instead of `size_t`.
For cases where size is being explicitly cast to `int`, use the wrapper that we already have instead: `Yosys::GetSize()`.
There's a mismatch between what `kernel/mem.cc` emits for memories
with no read ports and what the internal RTLIL check expects.
The point of dispute it whether some of the parameters relating to read
ports have a zero-width value in this case. The `mem.cc` code says no,
the internal checker says yes.
Surveying the other `$mem_v2` parameters, and internal cell parameters
in general, I am inclined to side with the `mem.cc` code.
This breaks RTLIL compatibility but for an obscure edge case.
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)`.
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.
This PR speeds up by roughly 17% across a wide spectrum of designs
tested at Google. Particularly for the mux generation pass.
Co-authored-by: Rasmus Larsen <rmlarsen@google.com>
Signed-off-by: Ethan Mahintorabi <ethanmoon@google.com>
This does not correctly handle an `$overwrite_tag` on a module output,
but since we currently require the user to flatten the design for
cross-module dft, this cannot be observed from within the design, only
by manually inspecting the signals in the design.
