[libre-riscv-dev] Scoreboards

Luke Kenneth Casson Leighton lkcl at lkcl.net
Sat May 18 05:16:30 BST 2019


On Fri, May 17, 2019 at 7:44 PM Samuel Falvo II <sam.falvo at gmail.com> wrote:
>
> 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,

 oh ok, haha, yep, i went over the messages yesterday, and now that i
think about it i can see how that happened.

> 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.

 ack.  answer below for when you've more time.

 i just discovered a couple of days ago why the separate FU-FU NxN
bitmap is needed: without it, the case where 2 instructions have
src-dest and dest-src gets confused.  i outlined it here:

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

 each row of FU-FU NxN bitmap stores only the dependencies that
*future* Function Units need to be concerned about.

 without that information the possibility exists for a Q-only-design
to get itself into an deadlock situation where it accidentally (by way
of a global broadcast) links *past* instruction hazards as well as
future instruction hazards.

 in such a (broken) design, the moment any group of instructions has a
loop of hazards, you have gridlock.

 basically the FU-FU NxN bitmap, which records read dependencies
separately from write dependencies, is the way to guarantee that the
read (and write) dependencies are a DAG (Directed Acyclic Graph).

l.



More information about the libre-riscv-dev mailing list