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

bugzilla-daemon at libre-soc.org bugzilla-daemon at libre-soc.org
Sat Jun 20 19:37:26 BST 2020


--- 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*

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:


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.

More information about the libre-soc-bugs mailing list