[libre-riscv-dev] [Bug 257] Implement demo Load/Store queueing algorithm

bugzilla-daemon at libre-riscv.org bugzilla-daemon at libre-riscv.org
Fri Mar 20 19:53:41 GMT 2020


--- Comment #7 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Jacob Lifshay from comment #6)
> Was assuming that the L1 cache has a single cache-line-sized R or W port,
> though having 2 ports makes it even better.

here's the code i'd like to drop-in-place (literally), i.e. just use it.


that's already set up for "masking" - bear in mind it's only 32-bit-wide
so the x_mask signal is only 4 bits: we need to expand that to 16-bits
and it will fit perfectly with the 16-bit "mask" from the PartialAddressBitmap

so the other end of the interface, jacob, is the LoadStoreUnitInterface.  a
test can be written which bypasses the cache, for now, to make life a bit

> Remember that we probably want another cache-line-sized port for
> communication with the L2 and the rest of the SoC.

one step at a time :)

wait... ahh... everything memory-wise goes through the L1 cache. the cores are
"slaves" of the wishbone bus (not masters).  all communication is done by way
of memory-addressing (all peripherals are memory-addressable).

even "management" of the L2 cache (and L1 "flush" commands) etc. should ideally
be done by way of memory-addressable "registers".

or, we have a special side-channel wishbone bus that communicates "messages". 
basically drops a pre-determined data structure (a nmigen Record) onto the
side-channel WB bus at a known "address", it gets routed to where is needed,
and the recipient decodes it as "commands".

but as far as communication with periherals is concerned, they're *all*
memory-addressable.  all of them.  any "setup" is done by way of "Registers"...
which are also simply memory-addressable... over the WB memory bus.

some of those, because they are I/O, cacheing is not permitted.  so we have to
be on the lookout for that.

You are receiving this mail because:
You are on the CC list for the bug.

More information about the libre-riscv-dev mailing list