[libre-riscv-dev] Scoreboards
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Wed May 15 17:03:22 BST 2019
On Wed, May 15, 2019 at 4:42 PM Samuel Falvo II <sam.falvo at gmail.com> wrote:
> So, to clarify my understanding, a set of global read reservation and write
> reservation masks are alone insufficient to count as a scoreboard?
mmm... that's almost certainly the case. the reason why individual
function units have to have (generate) their own read and write
reservations is:
if the unit contributes to the global masks in the *same cycle*, it
will prevent *ITSELF* from obtaining the very read and write
reservations on the registers that it seeks to reserve!
btw i worked out how to answer your puzzlement about "commits
appearing to already have happened", it's because the Function Units
(because of the above trick) are made to run one cycle *AHEAD* of the
ALUs (Computation Units) that they look after.
so it *appears*, if you look at what the CUs are doing and compare it
to the FU, it can appear to one that the work's already been done: it
hasn't. they're very very deliberately one clock-cycle apart.
> "silly-tricks-that-have-to-be-done" on a single-issue design, it will
> > become clear.
> >
>
> Perhaps my questions are asking the wrong question.
not at all! questions are what indicates that interest lies in
working out an answer.
> I'll just need to play
> with the ideas until my Montessori[1]-mind finally figures it out.
>
> so that's "two stupid tricks" - note in particular that you had to
> > *have* the WAW and WAR detection, this is very very important to keep
> > in mind in order to answer your question.
> >
>
> Sure, I'm not arguing against having the infrastructure. I'm just saying I
> don't see the use-case for, e.g., Q-matrices or the bit-vector linked list
> of FUs. That I don't see the use-case doesn't mean the use-case doesn't
> exist! :)
i know. the reason that i'm not answering the question directly is
because i *already answered it*. the answer to the very question that
you asked today (and yesterday) was exactly the answer that i gave in
a post a few days ago.
> I was just wondering what sequence of instructions, for
> example, would necessitate their existence.
and that's precisely why i said it would be necessary to *outline*
the use-cases, one by one. given that i did so already, last week
(and you missed it, and are still asking the question that i already
answered), i am inviting you to outline them yourself.
> In my thought experiments, I derived my sequencing logic exclusively from
> global read and write reservation vectors and individual FU busy flags. I
> don't *think* I had a need for anything more sophisticated than that.
i would concur with this, pretty much. where it gets a leeetle more
sophisticated is LD/ST, and for precise exceptions and branch shadows.
LD/ST you need some special (tiny) modifcations plus a (separate,
simple) sparse matrix that expresses the rules which stop LDs from
operating at the same time as STs.
precise exceptions (interrupts) and branch shadows use the exact same
concept, the diagram's on page 56 section 11.5.1.1
you have to "hold" any given instruction in a "schroedinger" state,
preventing it from "committing" (stopping its Go_Write) until you
*know* that the branch (or exception / interrupt) will NEVER occur.
> nice. btw you do know that the 6502 is a super-scalar out-of-order
> > design, right? :)
> >
>
> I don't see how it's superscalar or out-of-order; can you elaborate on
> this? I'd like to know more.
it's just something that i heard, from people who looked closely at
the reverse-engineered acid-etched ASIC. i don't know the details.
> ________
> 1. I frequently lament that I'd've been more successful in life had I gone
> to a Montessori qualified school instead of the run-of-the-mill public
> school. My brain just seems to be wired in a fundamentally different way
> than most people I run across, and it has severely hindered me throughout
> life.
no - it means that you think of solutions that other people don't. or can't.
l.
More information about the libre-riscv-dev
mailing list