[Libre-soc-dev] avoiding huge combinatorial mux-messes

[Luke Kenneth Casson Leighton]

paul, hi,

following on from the question you asked about the design and
allocation of operands as separate and distinct from register ports,
you mentioned that it wasn't clear how muxes get saved by moving RS.

microwatt's main GPR regfile itself contains MUXes:

https://github.com/antonblanchard/microwatt/blob/e40e752b9ab602f5ce1eb79be1fe96932558830d/register_file.vhdl#L82

there are 3 on read port 1.

additional MUXes exist on storage of "Fast SPRs" (SRR1/0/TAR/LR/CTR).

all of these are gone in LibreSOC in two ways:

1) there are separate regfiles.  FP, FastSPR, SlowSPR, INT, CR, even
SO/OV/CA are in a separate (very small!) regfile.

2) regfile ports are connected directly to their operands.

by (2) i mean that... ok let's look at execute1.vhdl

ah, here's another set of MUXes:

https://github.com/antonblanchard/microwatt/blob/e40e752b9ab602f5ce1eb79be1fe96932558830d/execute1.vhdl#L271

what i mean is:

https://github.com/antonblanchard/microwatt/blob/e40e752b9ab602f5ce1eb79be1fe96932558830d/execute1.vhdl#L767

every one of those will create a MUX on the result.

the DIV unit, FP unit (which then, bear in mind, MUXes in/out in the
regfile itself), MUL unit, and the case statements generating the
OP_ADD result: all of them combine to create something like a 20-way
MUX onto the result.

[which reminds me to do something about that in LibreSOC..]

having separate INT, SPR and FP regfiles which are connected only to
the pipelines dedicated to processing that data makes for a
significant reduction in MUXes.

it's not the number of stages *in* those pipelines (or FSMs) that is
significant: it's their isolation and separation.

l.