[libre-riscv-dev] multi-in. multi-out pipeline

[Luke Kenneth Casson Leighton]

ok i'm beginning a *slow* incremental process of adding
multiple-input-routing and multiple-output-routing to the pipeline
API.

i propose the option of passing in multiplex-arbitration modules that
make the decisions as opposed to forcing an explicit decision-making
process onto the API.

i believe it would be a mistake for example to add explicit *styles*
of input and output decision-making to the pipeline API, however in
turn i believe it would be reasonable to create derived classes that
provide, say, round-robin or FIFO or PriorityEncoder decision logic.

i'm also leaning towards allowing the option for the
arbitrator-modules to get a chance to modify the input (or output),
for example, to insert the array index into the incoming (or outgoing)
data stream.  i was just going to add a magic "routing" constant (mid)
to the incoming data array.

the scenario that i need this for is as follows:

RS0 RS1 RS2 RS3
    |     |      |      |
    +---+----+----+
             |
          pipeline
             |
    +---+----+----+
    |     |      |      |
  O0   O1   O2   O3

so... how could RS0 be matched up with O0, and RS1 matched up with O1?
 answer: the data in RS0 includes a mid (multiplexer ID), which the
*OUTPUT* stage multiplexer-arbitration logic uses to make the decision
to route the data through.

now, *hypothetically* the mid could be left out of the RS0-3 incoming
data, to be set by the input-arbitrator.

so the arbitrators are not just dumb-routers, they have to actually
know about and interact with and potentially *change* the data.

in the current IEEE754 FPU code i have an existing module called
"InputGroup" that uses a PriorityEncoder: i'll make this the first of
the modules as a way to test/prove the proposed API.

l.