[libre-riscv-dev] [hw-dev] Re: 6600-style out-of-order scoreboard designs (ariane)

[Luke Kenneth Casson Leighton]

On Thursday, May 23, 2019, Samuel Falvo II <sam.falvo at gmail.com> wrote:

> I'm terribly sorry for digging far back into the history;


Not at all. Quite recent


>
>
>
I've been trying
> to bring myself up to speed on scoreboards and such, and I'm lagging far
> behind, in part because I never understood them to begin with and am new to
> the technique, but also because I've just returned from a week of vacation.
>
> (Which I already need another one, but I digress.)
>
>
Trick I heard, pack overnight bag each person. Hand carry it. If main
luggage lost, not end of world. Plus, LEAVE the big bag to unpack the day
AFTER arriving. and rested.


> On Thu, May 16, 2019 at 10:58 PM Luke Kenneth Casson Leighton <
> lkcl at lkcl.net>
> wrote:
>
> > the FU-FU dependency matrix effectively has a *per FU* variant of the
> > [global] read-pend and write-pend vectors which, due to them having
> > their own latches, take a snapshot of the read/write-pending state *at
> > that specific time*, for *that specific FU*.
> >
>
> This is an interesting interpretation which I'll need to meditate on to
> fully understand; however, this is the first time I've come to have any
> insight on why the FU-FU matrix is necessary.


The latches are triggered by ISSUE just like the FU-Regs one. Thats how
they snapshot the state.



>
>  This has been a huge
> stumbling block for me, as up until the example with ADD r7, r7, ... was
> given,


>
(Mitch it was the same ADD R4 R4 R7, ADD R7 R7 R4 example we found the
dependency loop on, for the Function Unit only design)

I'd not understood why it was needed in the first place.  Thank you
> for framing it in these terms.


No problem


>
> Let me see if I understand correctly:
>
> * the value proposition of the FU-FU matrix is *not* for the benefit of the
> issue logic, but for the individual FUs themselves.


Yes. The FU FU Matrix doesnt care about what the regs are, it cares only
about RESULTs.

As in, it expresses that this FU is creating a RESULT that another FU needs
(or the other way round).

The Q Table says where those results go or come from.

Each has a very different purpose and you cant do without both of them.


>  If the global vectors
> all show R7 to be clear, then ADD R7,R7,R4 will happily issue; once issued,
> however, now there's a self-inflicted deadlock on R7, preventing the state
> machine from issuing GO_READ since it's waiting for something (anything!)
> to write to R7.  But since there's a write reservation on R7, the issue
> logic will never permit a writer to R7 to be issued.


Yyup.


>
> With the FU-FU
> matrices, the FU's GO_READ logic only concerns itself with its own cached
> write reservation vector, which in this case will *not* have R7 set (since
> it's a copy of what existed *before* issue).


I believe so.  The clue here was *at issue time*.

Btw the GORD comes in to the FUFU matrix from the LEFT (connected
horizontally) and ISSUE comes in from the TOP (connected down vertically).



>
> * the global reservation vectors are *column-wise summations* of the
> individual read/write FU-FU matrices,


Confusion

The global reservation vectors, called read pending and write pending, are
per REGISTER, and are the column wise summations of the FU REGs matrix.

Not FUFU.

These global reg-bit pending vectors are, yes, only useful in the FU REGs
Matrix.

However as we found earlier, with the loop example, the global pending reg
bitvector can fire in BOTH rd deps AND wr deps, it has no concept of "time"
basically.

The *FUFU* matrix is what stores the concept of time.


Or..

You may be referring to READABLE and WRITABLE which are, yes, column wise
sums of the FU FU Matrix rd and write latches respectively.

These sums basically say, for each FU, that it is safe to READ or safe to
WRITE the regfile.

However given that there could be several of those, you have to use a
priority picker to pick only one to read and one to write.



>  giving the issue logic the summary of
> what's happening as of instruction issue time.  Because of this, they are
> good enough to determine when to and not to issue to another FU.  As it
> happens, this is about the only thing they're really good for.  All other
> timing generation really depends on the FU-FU matrix.
>
> * the individual FUs are only concerned with *their own row of the FU-FU
> matrix* and are oblivious to all other rows,


Yes except that the issue signal comes in from the top.

This is really important to appreciate.


>
> controlling timing and
> arbitration to the common register file bus(es)


>
Yes... except it has no idea what the regnums are (and doesnt need to
because those are in the other Matrix)

Hence why they work together

based on that stored value
> (a copy of the global vectors *as of when the instruction was issued*).


 Yes.


> * Issue logic preventing issue when a (global!) write-after-write situation
> is detected ensures the FU-FU matrix effectively represents a DAG,


Right, ok, as-is, the 6600 matrices can't cope with WaW, only RaW and WaR.

So, what you do is, you recall that the FU REGS matrix generates a global
per reg bit vector called Global Write Pending?

What you have to do is, BEFORE issuing an instruction, AND that vector
against the unary version of the Dest reg, and if it matches, it is a WaW
hazard and you have to stall that instruction.

I do have a plan for adding WaW to the design I am working on, it needs the
precise exceptions system first, plus QTable history, as WaW hooks into
that and allows rollback.

It is complicated and honestly best left.  Note that WaW on a ST can be
IGNORED. See Mitch book Issue Unit diagrams, chap11 is clearer, chap10
version is based on 6600.


> preventing deadlock of the whole mechanism.


Yes.


>
> Put another way, it ensures
> that for any bit in the FU-FU write reservation bits, one and only one row
> with that bit set exists.
>
> Is this a correct understanding?


Pretty much yeah


>
> Thanks for your patience.
>
> --
> Samuel A. Falvo II
> _______________________________________________
> libre-riscv-dev mailing list
> libre-riscv-dev at lists.libre-riscv.org
> http://lists.libre-riscv.org/mailman/listinfo/libre-riscv-dev
>


-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68