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

Luke Kenneth Casson Leighton lkcl at lkcl.net
Fri May 31 13:37:49 BST 2019


On Thu, May 30, 2019 at 12:10 PM Luke Kenneth Casson Leighton
<lkcl at lkcl.net> wrote:

> > That's not the problem I was considering.  The problem I was thinking
> > about was where to put the logic which /alters/ those flags.
>
>  according to the scoreboard-style design concept / ethos / strategy,
> that bizarrely doesn't actually matter as much as the protection *of*
> the flags through the Dep-Matrices expressing the dependencies of
> access *to* the logic that reads - and writes - the flag.

 so the insight that's confusing - and worth emphasising - is that by
using a FunctionUnit to perform the "alteration" of the flags (even if
those flags are major, serious "state" from CSRs), the Dependency
Matrix that "tracks" that FunctionUnit looks after the
setting/alteration

 such that, once set/altered, *copies* (read-only copies) of that
state (CSR) may safely be made in, for example, latches, that are used
in various other places.

 this is basically how the Computation Unit logic works, except it
only treats the contents of src1 and src2 this way (ok, it also stores
the result in another latch until the DepMatrix says "ready to write
(alter state)" ).

 i have to be honest, it is on first consideration an extremely weird
way to think about something as critical as e.g. the MSTATUS register,
because of the way that we've been trained / ingrained to think of
CSRs as "global state".

 where things _will_ go wrong with the above approach is if there are
units that do *NOT* - by design - respect the "local" nature of the
copy (latched version) of any given CSR.

 so for example if the LD/ST Unit has some sort of "global state"
which is affected by a CSR (the virtual memory section, involving
ASIDs for example), which it could well have if it has been designed
in a particular way, and you fail to take that into account in the L2
cache or something, then yes, things will go horribly wrong.

 the way to deal with that, if it is *absolutely* necessary to have
some sort of globally-affected state in one sub-system somewhere, is
to treat the CSR associated with that sub-system as "special", to have
a total shutdown of issuing of instructions, wait for the engine to
finish computing and storing results, and, once everything is no
longer busy, *only then* change the CSR.

l.



More information about the libre-riscv-dev mailing list