[Libre-soc-bugs] [Bug 393] Hook up L2 Cache to Wishbone/LDST Wrappers

[bugzilla-daemon at libre-soc.org]

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

--- Comment #17 from Luke Kenneth Casson Leighton <lkcl at lkcl.net> ---
(In reply to Yehowshua from comment #12)
> Well - we don't have to do full wishbone...

it's the fact that it has to be done at all which places a chain of 4
completely unknown pieces of code in a line, before any of the 4 can
be tested that is the problem.

the strategy is to cut that back *first* to *only* 2... and *then*
add in the other 2.

we have two tasks, here:

1) convert L0CacheBuffer to talk the LoadStoreInterface
2) add wishbone.

what you are proposing is to do those *two things at the same time*.

can you see that this chain of unknowns provides us with no way to
know which two pieces *might* be a problem, if there is code that
"does not work"?

_yes_ we need to do both tasks.... however you are proposing to do
*both* of them *at the same time* and consequently this will be far
harder than it needs to be


> If we targeting Litex DRAM, sub, cycle, addr, re, and data
> really suffice I think.

... which is extra complexity that still does not help us because that
is step (2) *and we still need step (1)*.


> Basically, LiteX DRAM behaves kinda like Harry Ho's SRAM.
> 
> And now I'm confused.
> L0 Cache **isnt** the even odd cache things?

see line 322 of L0CacheBuffer:
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/l0_cache.py#l322

 322     Note that the final version will have *two* interfaces per
LDSTCompUnit,
 323     to cover mis-aligned requests, as well as *two* 128-bit L1 Cache
 324     interfaces: one for odd (addr[4] == 1) and one for even (addr[4] ==
1).

(i have been meaning to correct that to "even addr[4] == 0" for some time) ...
:)

it *becomes* the odd-even cache system

> At some point, we should have a call so I can better understand this.
> 
> For now, I can make a dead simple cache that looks like a memory.

as long as it conforms to the LoadStoreInterface it will be useful.


> I'm afraid I won't be much help on LDST as my conversation will generate
> more questions.

questions are great.


> I really wish thing were more simple.

they are.  it's just that you're suggesting to add extra complexity without
fully understanding that it is in fact extra complexity, not less.

the very simple approach - we need two things:

1) a class named TestMemoryLoadStoreUnit which conforms to LoadStoreInterface
   (as a slave)

2) modifications to L0CacheBuffer which gets it to conform to
LoadStoreInterface
   (as a master)

that's it.  that's all that's needed to get this:

    L0CacheBuffer <- LoadStoreInterface -> TestMemory

it cannot get less simple than that.

it's two unit tests.

one of those unit tests actually partly exists already (the existing unit
test for L0CacheBuffer).

wishbone is *not* needed.  at all, in that.

yet it provides us with the absolutely critical step of converting
L0CacheBuffer
to LoadStoreInterface.


what you are (might be) proposing is (requires the following steps):

1) a class that implements a Memory that conforms to Wishbone (we already have
   this, it is Harry's sram.py)

2) to bring in BareLoadStoreUnit and connect it to the Wishbone-enabled sram.py
   (BareLoadStoreUnit conforms slave-side to LoadStoreInterface)

3) to modify L0CacheBuffer to get it to conform to LoadStoreInterface
   (master-side)

connect (3) to (2) to (1)

that's four unit tests.

that's more work, more complexity, and more things to go wrong.


or, what you might be proposing - which is *even more* complex is:

1) to write a *completely new* from-scratch cache

2) to put an interface around it that conforms to Wishbone

3) to (create?) a completely new(?) class that conforms to LoadStoreInterface
   (slave-side)

4) to modify L0CacheBuffer to get it to conform to LoadStoreInterface.
   (master-compliant)

that's *FIVE* unit tests, and *THREE* completely unknown, completely new sets
of code.

that's *even more* complex!


again: *yes* we have to get to that point.  however if we do it *right now*,
straight away, we have a chain of completely unknown untested code.

i don't understand why it is that you don't understand that what you are
proposing
is far more complex.

what you are proposing *still and always requires that L0CacheBuffer be
converted
to LoadStoreInterface*.

therefore, it should be logically obvious that the first incremental step
should
be to get that done as the first top priority.

and it should also be logically obvious that, because we are doing incremental
unit tests, that the simplest possible way to demonstrate that L0CacheBuffer
"works" when converted to LoadStoreInterface is:

write a simple class that connects LoadStoreInterface (slave) to TestMemory.

what is not obvious and simple about that?

i don't understand why it's not obvious and simple.

perhaps if you write it in your own words, describing how to connect to
PortInterface, that would help?

PortInterface is our equivalent of minerva LoadStoreInterface.

can you describe - in your own words - what you would do, what code you would
write - that would connect to PortInterface, to provide LOAD/STORE capability?

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