[libre-riscv-dev] KCP53000B micro-architecture thoughts

[Samuel Falvo II]

On Wed, May 29, 2019 at 7:41 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:
>  took me about 5-6 months of study, 2 of which were near-full-time
> communication with mitch.

Oh, good.  I don't feel so bad about myself now!  ;-)

>  from what you've written you demonstrated a pretty clear understanding.

Thanks!

>  unless they are also prevented from writing results, this is a
> dangerous design.  if however they are "shadowed" (prevented from

Correct; ABORT (whose name is taken from the ABORTB pin on the 65816
processor and with identical execution semantics) causes /total/ and
unequivocal termination of the currently executing instruction.  That
includes terminating register write-back.  If the results of a
computation reaches the commit stage AND the FU has not yet
successfully arbitrated access to the CDB, then write-back still does
not happen; the FU is compelled to rescind its request on the CDB.  If
the FU DOES successfully arbitrate access to the CDB, then because
it's guaranteed to be the only FU doing so, we also know that it is
also the FU that is causing ABORT to be asserted as well.

(In a subsequent response, you mention go_die as being the same as
ABORT; I'll need to re-read Alsup's texts in more detail later with
this in mind.  His naming conventions frequently confuse me, and his
lack of timing diagrams to illustrate chronological relationships
between signals frequently leaves my head spinning.  You may recall I
frequently have confusion around the timing of GO_READ and GO_WRITE,
etc.)

>  that's just a change of some flag that changes the behaviour of
> instructions.  as long as that flag is carried along with the
> instructions, to the FUs that need to respect that flag, what is the
> problem?

That's not the problem I was considering.  The problem I was thinking
about was where to put the logic which /alters/ those flags.  A
dedicated "interrupt unit" is one possibility.  Keeping it in the
instruction dispatcher is another.  I was just speculating on
different design approaches.

>  hypothetically, though, several CSR writes could be grouped together
> (into a single instruction)  however... mmm....  i suspect that going
> down that route would hugely complicate the design, particularly the
> transfer of instruction data.

Things to consider for the future perhaps; I'm just trying to build up
an understanding and an implementation to test my understanding.  I'm
seriously considering abandoning the 6502-style "one giant PLA to rule
them all" decoder in favor of a *small* out-of-order approach, just to
play with the ideas and confirm my understanding (one CSR-FU, one
load/store unit which also does addition/subtraction, one logical unit
to do XOR, AND, etc., and one branch unit to deal with JAL, JALR, and
the conditional branches).  Then, after that, I was thinking of going
back to re-read Thornton and Mitch Alsup's chapters with my design
experience helping to inform my understanding and learn some of the
finer details.

>  unfortunately, i've not thought through the CSRs enough to be able to
> comment.  off the top of my head, though, if a CSR may be affected by
> any given instruction, then to my mind it makes sense to simply treat
> it as... just another destination "register" as part of the Dependency
> Matrices (this time it would be the "CSR Register Dep Matrix", being
> the 3rd Reg-Matrix, next to FP Reg Matrix and INT Reg Matrix)

This makes complete sense to me; I'm implicitly trying to make my
design small and compact enough for an iCE40HX8K FPGA.  Considering
the number of CSRs, each row of the matrix I think will end up using
more DFFs in an FPGA than I can support in such a small package.

(It probably still won't fit; but, I'd like to try anyway.  :) )

-- 
Samuel A. Falvo II