[libre-riscv-dev] [hw-dev] Re: 6600-style out-of-order scoreboard designs (ariane)

[Luke Kenneth Casson Leighton]

hi mitch (and list),

mitch, many many thanks for all your help and guidance (and patience)
with the scoreboard system. i am finally getting somewhere and have a
working system which means (hopefully) from now on, incremental
progress should be very rapid.

i added in the shadow capability tonight (11.5.1, p55) after porting
it from the FU-version to a Dependency Matrix style, and used it to
create a 2D-bit-based "instruction order linked list" that is set on
every instruction against the previous instruction.

this has the effect of making every instruction write-dependent on the
previous one, which has the (desired) effect of guaranteeing
(preserving) instruction order, as far as *writing* is concerned.
i.e. the order in which instructions are issued will also be the order
in which they write.

this has the secondary side-effect of providing write-after-write
capability, without the stalling that the 6600 has to do.  it's also a
nice test of the shadow capability before moving on to more complex
things like branch speculation or precise exceptions.

also it should be possible, with a bit of work (and some fudging) to
do multi-issue, because if more than one bit per clock cycle can be
inserted into the 2D linked-list-like matrix of bits, that's basically
still preserving the instruction order.

detecting how *many* writes can be removed is a matter of having a
counter (per Function Unit), which is incremented (on every FU) when
new instructions are added, and decremented whenever instructions
(plural) retire.

when the counter (for any FU) is equal to or greater than the number
of permitted "writes", that's the signal to that FU that it is
permitted (in parallel with any other FUs that also have a counter <=
N(permitted_writes) ) to commit.

not particularly difficult or sophisticated, at all.

l.