Currently, the backend is in-charge of collecting all assignments to a port and generating an equivalent state in Verilog.
For example:

a.in = g1 ? b;
a.in = g2 ? c;
a.in = g3 ? d;

Gets converted into a mux:

a.in = g1 ? b : g2 ? c : g3 ? d : '0;

The goal of this proposal is to represent this process within Calyx itself using a new multi-ported std_mux primitive. The simplest benefit of doing this would be reducing the surface area of the backend even more and enabling us to experiment with different mux implementations, specifically, ones that do not implement priority logic like the one above.

Implementation

The std_mux primitive takes as its inputs:

• n data inputs
• An n-bit select signal
• A default value (this will enable supporting Annotations for Data Path Components #1169 in the future)

It produces a single output.

Since the primitive is multi-ported, i.e., the number of input ports depends on a parameter, this primitive cannot directly be represented in Calyx. We'd need to use some code generation to produce wrappers for muxes actually generated during compilation. The dumb solution is just writing down muxes with upto to 22 inputs or something

Lowering Pass

A final lowering pass would convert all the assignments in a program into direct assignments into std_mux. We'd change the verilog backend to no longer generate any muxes.