[Libre-soc-dev] NGI POINTER gigabit ethernet router ASIC roadmap

[lkcl]

On November 3, 2021 2:51:09 PM UTC, lkcl <luke.leighton at gmail.com> wrote:

>* Reservation Stations need to be latched as actually reserved
>   until such time as the same MUX id is seen at the output
>   (final stage of the single pipeline).

i am slowly working out what is needed:

* no ready/valid pipeline stage will proceed (ever) unless its incoming ready (n.i_ready) is HI

* there is only one ALU pipe input with a p.o_ready to connect to those multiple ReservationStations.

* therefore either NONE of the RS n.i_ready signals may be HI or ALL may be HI.

* if none, no progress is made (all RSes blocked from receiving new data) and we're screwed

* if all, ALL RSes will receive ready indicators, therefore ALL RSes could attempt to deliver to the (one) pipeline, and we're just as screwed.

* having a round-robin selector is hopeless because performance will be 1/(number_of_RSes)

* therefore the only solution is to have, in every single RS input, a one-entry FIFO aka a BufferedHandshake Control Base.

* there is however a scenario where if multiple RS buffers are filled simultaneously, and the ALU p.o_ready is HI, then *one* of those RSes can be selected *immediately* whilst all others are left to go directly into their FIFOs.

* this tells us that a combinatorial bypass (simultaneous read/write, or passthru) is needed on the FIFO.  funnily enough this is one of its options in the FIFO Control Base, but i may just copy BufferedHandshake instead.

similar logic applies to the output, and there needs to be back-communication from the output phase of the RS to prohibit a given RS input FIFO from accepting more incoming data until the *output* has been passed on, *even if the ALU pipeline has performed the work*.

otherwise, blocked delivery at the RS will ripple up the ready/valid signalling and a block at the output will cause a block at the input.

it is really quite ridiculously complicated for something that appears to be straightforward, "just have some Reservation Stations".

estimated about another 3 days on this including unit tests.

which is 2.5% of the 150 days available to meet the NGI POINTER first milestone deadline, which i don't mind saying again i'm freaked out about.

however, Cesar: as i mentioned already, you do not need this to make the InOrderIssuer, you can use the Single CompUnits for now.

i will make RS CompUnits exactly compatible with the same API, drop-in.

l.