[Libre-soc-bugs] [Bug 382] nmigen wishbone Memory (SRAM) object needed

[bugzilla-daemon at libre-soc.org]

https://bugs.libre-soc.org/show_bug.cgi?id=382

--- Comment #16 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Yehowshua from comment #10)
> You can't write to Minerva's cache.

correct.  you only write via CacheLoadStoreUnit - that's its job.
Minerva.L1Cache is just a subcomponent that is managed *through*
CacheLoadStoreUnit.

it's a bit of a pain / mind-bender.

i believe RocketChip, ariane, and so on have this type of design.
however microwatt i believe has the design you are "expecting":

there, i believe, we can see not just evidence of L1, we can see TLB
as well:

https://github.com/antonblanchard/microwatt/blob/master/dcache.vhdl

in other words their team has merged at least three separate and
distinct objects into one, and consequently it "looks" more like
what you might be expecting.

if we were to *separate* the code from lines 102 through 139 (and
possibly slightly beyond) into a *separate* file named l1cache.vhdl,
*now* we have the equivalent of Minerva.L1Cache and *now* you would,
i believe, become likewise confused :)


> I was to shy to say this before because it sounds silly and I thought maybe
> I didn't understand Minerva.

:)

> But after EXTENSIVE review, I'm certain this is the case.
> Minerva handles writes by going directly to memory.

it should write to *both*.  that's the definition of a write-through cache
[that's if i understand the code correctly in CacheLoadStoreUnit]

i.e. i believe CacheLoadStoreUnit *is* what you are thinking of as being a 
"write-through" cache.... *not* Minerva.L1Cache itself.

my guess is that you are thinking - please do let me know if this is
correct or not - in terms of an interface where there is a single
Wishbone interface to {InsertNameOfL1CacheToBeDesignedHere}

and that in {InsertNameHereL1Cache} *that* is where it takes care of
write-through to Main Memory (and so on).

if that is the case, then it is simply a terminology / naming confusion,
because CacheLoadStoreUnit *is* that {InsertNameHereL1Cache}.

this becomes clearer when we come to adding L2 (and L3?) because then there
will be *THREE* wishbone Buses in CacheLoadStoreUnit:

1) a WB Bus to the object known by the name "Minerva.L1Cache"
2) a WB Bus to the [future] object known by the name "L2 Cache"
3) a WB Bus to *MAIN MEMORY*.

ths [future] CacheLoadStoreUnit would:

a) make a read request first of (1), then if that failed 
b) make a request of 2) and if that failed
c) make a read request to 3) and if that failed
d) report an address error / exception.

for a write - if we were to respect "write-thru" rules, you would initiate
*all three* of these at once:

a) write request to (1)
b) write request to (2)
c) write request to (3)

now, if you wanted to do "evict" and MESI or MOESI blah blah you would do:

a) write request to (1), and if not room in L1 perform an "evict" which
b) writes the *EVICTED* data to (2), and if not room in L2 likewise "evict"
c) the *L2* evicted data gets written to (3)


what i *can't* tell is whether the Minerva CacheLoadStoreUnit is actually
a write-through or whether it implements the latter delayed/eviction algorithm.

and *sigh* with no documentation, we have no idea.  some unit tests which
deliberately fill up the cache would help us to tell.


> In fact, Minerva's Cache is really really simple - I don't think its what
> we're looking for.

i believe you may agree, after reflecting on the above, that it's just
a sub-component, and that through naming you *may* have been misdirected
in expectations that it does more than its name suggests.


> Luke, I HAVE to have a cache for my thesis, so I'm thinking of writing one.
> Maybe I can kill two birds with one stone - just tell me what the cache must
> be able to do.

i think the main thing we need - the one thing that minerva's cache cannot
do which we need at this point (there will be others) is to give a
"reservation" on a cache line which can be dropped.

basically a decoupling of the "address assertion" from "actually putting
data into it".

however with a little bit of thought, i *believe* that this may be
achieved in *CacheLoadStoreUnit*...

*WITHOUT* having to actually modify Minerva's L1 Cache code at all.

i.e. it is a *FSM* issue, not a "modification of Minerva.L1Cache" issue.

however... honestly... i would be inclined to recommend to you that you
simply go ahead and write one anyway, because it will give you a better
understanding than trying to examine Minerva's code.

because you were the person that wrote it.

and therefore (hint, hint) documented it.

however what i suggest is - if this is ok - please do stick to that
same LoadStoreUnitInterface.

the reason is because then everything becomes a drop-in replacement,
revolving around that common data structure.


> I can also formally verify it no problem.

ahh excellent.

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