[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