[libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 10:08 PM Yehowshua <yimmanuel3 at gatech.edu> wrote:
>
> >
> > there *is* a test_cache.py already in that directory.
> > (i'm currently making all imports explicit)
>
> Right this is the formal.
>
> The formal doesn’t make it clear how to actually
> use the thing.

sigh this is what Samuel Falvo pointed out: he advocates two unit
tests.  one formal, one standard.  the formal one does code-coverage,
the standard one acts more as a "tutorial and demo".

minerva is missing that.

> Another question: what is the interface you want to the cache?
> I think you said you wanted to go with Minerva’s loadstore frontend?

yes.  basically adapt this:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/l0_cache.py;hb=HEAD

so that it instead talks this:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/minerva/units/loadstore.py;hb=HEAD#l13

right now, L0CacheBuffer is talking *directly* to the nmigen Memory
rdport / wrport:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/l0_cache.py;hb=HEAD#l400

if those direct calls are replaced with calls that are compatible with
the Minerva LoadStoreUnitInterface, adapted to 64-bit-wide, then for a
1st version approximation we're "done".

the next task on from that

>
> Could be a bit tricky as the loadstore frontend uses stage specific
> bit masks.

LoadStoreUnitInterface.x_mask? that's perfect.  it's exactly what's
needed.  those are i assume byte-level write-enable lines, exactly as
needed.  now, it's only 4 bits because the data width is only 32 bit:
those need to be expanded to 64 bit.

LDSTSplitter - when it's time to add that - *might* take care of the
128 bit cache-line requirement, however might not.  we may simply have
to internally not be compliant with Wishbone for the paths between
L0CacheBuffer and LoadStoreUnitInterface.

this would mean LSUI.x_mask being 16 bit wide, x_store_data being 128
bit, m_load_data being 128 bit.  and the L1 cache likewise widened to
128 bit, and given a 16 bit byte-enable line.

*that* - on the other side of the L1 cache - where it talks to actual
Wishbone - would be where a split to 2x 64-bit outgoing Wishbone
interfaces would be needed.


> Might be easier to morph the L1 cache to your needs directly.
>
> From your video, it seems that there is no instruction cache vs. data cache.

the video covers the data cache only.  the instruction cache is
"normal" and we should - unit tests notwithstanding - be able to just
drop minerva I-Cache (units/fetch.py, adapting PCSelector) directly
into place.

the only reason i haven't done that already is because i don't feel
comfortable doing it without the proper unit tests confirming that
they're functional.


> Can you specify what interface you want to see from the cache’s perspective?
> I suspect the only change we need to make is set s1_stall to Const(0), and disable
> s2_addr in Minerva’s L1Cache.

i honestly don't know, i haven't investigated the code closely (only
just literally got to the point where it's needed) will try to go over
it.

*thinks*.... ah.  we *do* actually have an AGEN phase, if that's what s1 is for?

at line 112 this is addr which is of type Data record which includes
an "ok" signal not just "data".
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/l0_cache.py;hb=HEAD#l112

at line 114 a response is expected to come back indicating that the
address is "ok" or that there was an error [currently this is ignored,
because there's no exception code - Cole - TRAP pipeline....]

and there *will* be a potential delay between the s1 reservation phase
and the s2 (commit) phase.  the AGEN phase should say "yes you can, if
you acknowledge it, safely proceed.   i will reserve the cache line
until you tell me go or cancel".

equally (particularly right now) the acknowledgement may actually be
combinatorial and immediate, so both these scenarios (delay, no-delay)
need to be taken into consideration, between s1 and s2.


btw, for later (when the scoreboards are added): up until that
"proceed or cancel" point, the Shadow Matrices will "hold" the actual
commit (s2 stage).  ONLY when the s1 stage has said "yes if you really
want to do this it is absolutely safe to proceed, guaranteed 100%
success", *then* the shadow is dropped and the commit to memory
allowed to proceed.

if however that error comes back at the AGEN stage (s1), then the
Shadow Matrices are told "activate go-die, please - kill *EVERYTHING*
that is downstream of this instruction, *right* now".

so, ignoring scoreboards for now: it does indeed look like the Minerva
cache - and the LoadStoreUnitInterface - is precisely and exactly what
we need.

just modified to 64 bit wide data buses, and 48 bit address buses.
actually, parameteriseable with defaults to those values would be
better.

l.