Efficient handling of patterns emitted by sv2v

[povik]

Feature Description

The external tool sv2v rewrites member accesses, element selects and other operations into part-selects and a bit of arithmetic.

Take e.g. (source)

mem_q[trans_id_i[k]].sbe.rd

it gets rewritten into

mem_q[(trans_id_i[0+:2] * 467) + 376-:5]

Within the read_verilog frontend, this gets parsed as a shift cell with the shift amount driven by arithmetic cells. Notwithstanding peepopt transformations some of those shift cells survive to the techmap stage at which time they are expanded into a sea of mux gates. Due to the presence of constant bits most of those gates are redundant as evinced by subsequent opt_expr -mux_undef cleaning them up. This redundant mux effect can be so bad it accounts for >80 % of Yosys peak memory usage in a real world synthesis flow incorporating sv2v.

This can get addressed at different points:

• the frontend detecting these patterns and emitting a more efficient structure right away
• additional opt_expr rules which transform a shift cell with constant bits on some of its inputs
• efficiently lowering the cells within techmap provided second-order constant propagation isn't a significant factor

Cc @zachjs @phsauter

[phsauter]

Related (but no the same):

• part-selects ($shift, $shiftx) create huge MUX-trees #3833
• Suboptimal default synthesis of $bmux, $shiftx #3893
• Optimization of nowrshmsk #3875
• Added nordshift attribute #3877

[whitequark]

Amaranth lowers such constructs into cases assigning to/from an intermediate variable for the same reason. I am not sure why sv2v is using arithmetic; perhaps it should stop.

[povik]

yosys-slang uses $bmux for element selects (within a complex type also)

[phsauter]

Amaranth lowers such constructs into cases assigning to/from an intermediate variable for the same reason. I am not sure why sv2v is using arithmetic; perhaps it should stop.

Good to know because I would have informed Robert next week as well, so there is no need.
I do think the way sv2v does this transformation is probably not the best choice but I can see where it comes from.

In general I think this is worth solving because the alternative, ensuring no other tool produces similar constructs, does not seem feasible to me.
Also you can have shifts coming from other RTL constructs (or even just from people actually writing it like that).

[whitequark]

(Robert?)

[phsauter]

Sorry, Rob Taylor.

[zachjs]

I have no objection to the premise of handling these patterns more efficiently in general, but insofar as sv2v targets yosys, I really don't intend for its output to be pathological. Detecting this pattern doesn't seem hard. (Any time a variable is used to index into something multi-dimensional?) Then adding the appropriate read/write attribute to the declaration seems harmless, if we go that route. Adding a temporary would be a bit more complex but also doable.