[libre-riscv-dev] Scoreboards

[Samuel Falvo II]

I've been reading up on implementing scoreboards from various sources,
especially how things were done in the CDC 6600.  It has gotten me to
think of a few things, some plus some minus.

1) One of the big concerns with the KCP53000(B) is the size of the
finished design, and there seems to be two reasons for it: the CSRU,
which I can't do much of anything about, and the ALU, which I
originally built 6502/Z80-style, where you have one monolithic chunk
of logic that does everything.  It implements a barrel shifter and
whatever adder circuit the Verilog synthesis tool deems appropriate.
I'm wondering if there's value in removing the shifter and making it a
slower computational unit (narrower shifts per cycle, but using
multiple cycles to complete a full 63-bit shift).  Since the iCE40HX8K
uses ripple-carry for its adder logic, I'm wondering if there's value
in isolating _that_ as well (e.g., using a 16-bit adder circuit over
four cycles to accomplish a 64-bit add), and perhaps making some
future 530x0 design variant which is concurrent to support more rapid
clock speeds but still hiding enough latency to simultaneously allow
me a smaller design while giving the illusion of (almost?) consistent
and rapid throughputs (whatever that may be).  Basically, if I split
the single IXU into three or four FUs (you figure one for load/store
as well), will this reorganization of the logic combined with the
scoreboard needed to drive it result in a smaller overall design than
just having one monolithic IXU?  This is an open question that I don't
know the answer to.

2) I've read up on Q matrices at least five times now.  I'm still
*utterly* confused.  Continuous scoreboards make 1000% more sense to
me.

3) I'm surprised at how my independent design fairly closely matches
Thornton's FU design.  The "three cycles" of my design are, literally,
operand-fetch, execute, register-writeback, corresponding roughly to
issue, go-read, and go-write, in that order.  I can now understand why
Luke wanted to bring Thornton's work to my attention.  It doesn't see
like *that* big of a leap from my current plans to a superscalar
design.

-- 
Samuel A. Falvo II