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

lkcl luke.leighton at gmail.com
Tue Nov 2 14:16:15 GMT 2021


On Mon, Nov 1, 2021 at 11:11 AM lkcl <luke.leighton at gmail.com> wrote:

> * there is not enough time to do out-of-order (it was 5 months just
> doing the 6600 experiment), a FSM is too slow therefore we do an
> in-order core making sure to plan ahead for OoO (use ReservationStations,
> use MultiCompUnits)

deep breath: i tested the use of the ReservationStations class
(developed over 2 years ago), and it is the first time it is "hit"
by full-on ready/valid Signalling: it didn't work.

i did however make a start on FunctionUnitBaseMulti:
https://git.libre-soc.org/?p=soc.git;a=commitdiff;h=2f264614f87c8d5f91fc077beaa956ceb95a566b

Cesar: you *should* be able to use AllFunctionUnits as-is,
and if there are say 1 ADD instruction followed immediately
by 1 MUL instruction followed by 1 SHIFT instruction, there
should be no stalling because those are all separate pipelines.
(i will put this in https://bugs.libre-soc.org/show_bug.cgi?id=737)

however once ReservationsStations is fixed, the way that
the FunctionUnitBaseMulti works is: it presents multiple
CompUnitMulti(s), looking exactly like FunctionUnitBaseSingle,
so there should not need to be any changes to Core, it just
looks like there are a lot more ALUs / CompUnits (when in fact,
they are multiple entry-points to the *same* ALU)

i am slightly freaked out because of the time pressure, i thought
ReservationStations was already working perfectly, it was however
just not properly tested with the same scenarios that we hit
ready/valid with in TestIssuer, and this is the first time it's ever
really been used outside of (smaller, less rigorous) unit tests.

l.



More information about the Libre-soc-dev mailing list