I think the Handshake to FIRRTL conversion existed before a lot of the recent work to flesh out the RTL dialect. That conversion doesn’t appear to need a ton of high- or mid-level constructs in FIRRTL. I see it using
when ops and the
bundle type. We may not need the
when ops, but the
bundle type is used pervasively to represent a data signal and its valid and ready bits.
I don’t see why we can’t target RTL from Handshake. If we support a new type in the RTL dialect that can represent the data+valid+ready bundles, I think that conversion would work pretty much like it does today. As you mentioned, we would then need to flatten the higher-level type into something EmitVerilog understands, or update EmitVerilog to model this type (perhaps using SV interfaces).
If we didn’t have such a type, the lowering from Handshake would have to generate flat lists of signals for all the data+valid+ready bundles.
My current thinking is to keep targeting FIRRTL from Handshake, and in the short term support lowering the aggregate types within the FIRRTL dialect. This way, the FIRRTL produced by the existing lowering can be made compatible with the lower-level types expected by RTL, LLHD, and EmitVerilog. It also enables other clients of FIRRTL that may be using
This is really just a pragmatic choice to connect the dots with minimal changes (and changes that we want to do anyway). I’d also be interested in seeing more high-level types available in the RTL dialect long term, and in that case, lowering from Handshake directly to RTL make sense to me.