[libre-riscv-dev] Scoreboards

[Luke Kenneth Casson Leighton]

http://lists.libre-riscv.org/pipermail/libre-riscv-dev/2019-May/001461.html

hi samuel,

so i went through the archives looking for the answer that i'd already
given, to the question that you asked, and it's above

"thirdly: as i mentioned before, no matter what you do in a standard
single-issue pipeline design, you still have these hard choices to make
where you are forced to add in pipeline stalling (to deal with cases where
a register is being written to and the next instruction needs that answer),
you're forced to mask interrupts or cause pipeline stalls during LD/ST
operations, and all sorts of other awful "messes", *all of which go away
and are dealt with in one place* in a 6600-like design."

when you asked - again - the question, "but why is the scoreboard even
necessary, it doesn't seem like does anything at all, why should i
bother with it", can you see that the question is ignoring what i
wrote above?

if that's not clear, can you explain what strategy you intend to
deploy (without a scoreboard) for dealing with the following.  (note:
it should be clear that any processor has to deal with these issues)

* RaW hazards
* WaR hazards
* WaW hazards
* LD hazards wrt registers
* ST hazards wrt registers
* LD hazards wrt STs
* ST hazards wrt LDs
* Atomic versions of the 4 above (AMO)
* Interrupts
* Exceptions
* branch-points
* FSM-based ALUs combined with pipelined ALUs

you covered already how you intend to deal with a couple of those
(pipeline stalls on RaW and WaR hazards), and you mentioned already
that you *have* logic *that* detects those (detects RaW and detects
WaR).

if you can describe - in one sentence - exactly how you intend to deal
with all of the above - we can go through each of them, first in the
context of a single-issue pipelined design, and second in the context
of a scoreboard.

note that if this is not done, *the question cannot be answered*.

l.