[libre-riscv-dev] store computation unit

[Luke Kenneth Casson Leighton]

On Thu, Jun 20, 2019 at 10:29 PM Mitchalsup <mitchalsup at aol.com> wrote:

Ah. Minor concern: if there are say 25 FUs, all of which are permitted to
> forward simultaneously to all 24 other FUs, the forwarding could result in
> a massive 64 bit 25-way multiplexer.
>
> Obviously too many wires. I suggest that each group be allowed one FW per
> cycle.
>

 using an SR-Latch with accompanying "fwd_req_rel" and "go_fwd"? both
req_rel *and* fwd_req_rel would be set (simultaneously).  req_rel
activation (go_write) would cancel (reset) the fwd_req_rel signal but *not*
the other way round.  fwd_req_rel would be reset when go_fwd was activated.


> But that one FW can be consumed by as many operands as need that value.
>

 a broadcast bus.  still needs a fwd priority picker to manage access to
each fwd-broadcast-bus.


> This way, one minimizes the number of reads to the RF and the number of
> cycles used to deliver operands. Later we will determine that Rk is being
> written multiple times, and elide all but the
> last write.
>
> The scenario that illustrates best is: say that an FU managed to forward
> its result to all other FUs waiting for that result. Those FUs complete and
> commit, and let us suppose that one of them is a WaW that OVERWRITES the
> very same register that the original FU was waiting to write to, but never
> did, because it used Forwarding, instead.
>
> The logic I am developing will take care of that case.
>

ahh goood.  look forward (haha) to seeing the result (haha).

btw if you recall, detecting the write-elision was easier when the Q-Table
entries were turned into a stack / array.  aka "Q-Table History".  the
WaWing becomes a matter of incrementing the index (pushing another Q value
onto the "stack" in each FU-Reg "column").

all entries below the top of the per-register Q-Table "stack" represent WaW
elision opportunities.

it's complicated.  i understood it well back in january :)  and, i think i
was thinking in terms of binary Q-Table entries, not unary

 Hmmm that just makes a single selection from a large group, it doesn't
allow for one forwarder to be picked *and* one readable to be picked (just
not the same as the forwarder).

>
> You are only picking one instruction to make forward progress per picker
> per cycle.
>

yes.  which means there needs to be a way to have each picker not pick the
exact same instruction.  still need to read the book chapter on this.

I believe it is a non-issue (trivial), as the pending read vector is global
> in nature.
>
> It is not like it is necessary to do a full N to N crossbar Forwarding
> system.
>
> Also note: the typical calculated result is used 1.2 times so an N×N
> crossbar will have the vast
> majority of routes idle the vast majority of the time.
>

iiinteresting.


>
> Hence why I was picturing Forwarding as being a kind of regfile port suite
> without the actual regfile, and thus having cascading priority pickers a la
> multi issue.
>
> About 1 FW per group per cycle should fit the bill.
> In addition to the 1 GoWrite per group per cycle.
>
>
so a multi-issue context would need N FW'ers per group per cycle.

l.