[libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 5:47 PM Yehowshua <yimmanuel3 at gatech.edu> wrote:
>
> >
> > maybe.  we will have to evaluate it.  as i explained in the crossover
> > message there are other higher priority design requirements that are unique
> > and specially required for the design.
>
> I watched the video and read through the pages.
> I understood high level what is going on - the details are
> not entirely clear to me at this stage.

this is understandable: it's literally taken me 2 years to learn.

> At some point, I can imagine that you’ll want to connect
> up the memory systems.

yes.  *right now*!

i just got LD/ST CompUnit working in test_core.py and it is relying on
a hard-link to a Test Memory limited to 64 8-byte words.

i am holding off putting in Wishbone interfaces onto the
(prototype/test) L0CacheBuffer because it is yet another layer of
complexity and it needs unit tests of a wishbone link in isolation,
first, before becoming comfortable with it.

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/experiment/l0_cache.py;h=5213ee986da7524b41ba8fb6842a15dc2c861d49;hb=HEAD#l318

that in turn requires that we have an actual SRAM *behind* that
Wishbone interface in order to be able to actually *do* those tests.
this is what i've been able to find.  harry points out that he did not
write any unit tests (yet).

https://github.com/HarryMakes/nmigen-soc/blob/wishbone_interconnect/nmigen_soc/wishbone/sram.py


at that point it is a matter of connect-connect-connect and finally we
are in a position to flip out the test infrastructure at the Wishbone
level and drop in Litex instead.

if Minerva's Load/Store interface is used / adapted then there is no
need to write-code-from-scratch, and it also means that enabling L1
caches is a brain-dead runtime configuration switch.

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/minerva/units/loadstore.py;hb=HEAD#l75

however there are *zero* unit tests for this code and so that will be
important to write.


> How much labor do you think is needed for this?

if we have the right components and the right people, probably only
about 2-3 weeks.

> Assuming I’m free starting at the end of July,
> It would probably take me a couple weeks to catch up to speed
> on the intricacies of the scoreboard.

with the current resources the scoreboard is not an immediate
incremental priority: getting a functional core that executes
instructions is a top priority... *and then* the scoreboard can be
incrementally added to it if there is time to do so.

this all changes if the people from Marketnext are good quality
engineers, who can get up to speed rapidly.  subtasks can be allocated
to them and at that point yes there will be plenty of time to do do
heavy-duty sustained focus on complex tasks.

in the meantime i know you really want to get to understand the
precise-augmented scoreboard system.  the only thing i can suggest is:
read and re-read Mitch's book chapters again and again and again, run
the unit tests again and again, go over the Tomasulo "morph" page
again and again, and look at the graphviz diagrams and match them to
Mitch's diagrams.

it littteerrallly takes mmmooonnnths of sustained dedicated focus on
this and *nothing* else, for the design to properly sink in.  remember
it took me *four* months to find a bug in the later sections of
Mitch's second book chapter, which not even he had noticed.

l.