[libre-riscv-dev] Scoreboards

[Samuel Falvo II]

I think I see the confusion.  If I'm right, you think I'm questioning the
need for the scoreboard as a whole.  I was asking specifically about the
Q-matrix and FU-FU bitmap, as it seems to me that the global write and read
reservation vectors seemed to do the same job.

I'm mid-con and writing this on mobile, so can't write further.  Will write
more later.

On Fri, May 17, 2019, 4:04 AM Luke Kenneth Casson Leighton <lkcl at lkcl.net>
wrote:

> 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.
>
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>