[libre-riscv-dev] Minerva L1 Cache

[Luke Kenneth Casson Leighton]

On Mon, Jun 15, 2020 at 8:54 PM Yehowshua <yimmanuel3 at gatech.edu> wrote:
>
> >
> > 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.
>
> OK. So right now, it sounds like instructions execute in order with
> scoreboard?

no scoreboard at all.  no dependency checking at all.


> Are we simply stalling with instructional dependencies?

correct.  it's why it's nicknamed the brain-dead core

https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simple/core.py;hb=HEAD
https://git.libre-soc.org/?p=soc.git;a=blob;f=src/soc/simple/test/test_core.py;hb=HEAD

at the moment it has three major top-level components:
* Function Unit block
* Register Files
* TSTL0CacheBuffer which contains a single memory port to a single
nmigen Memory with 64 8-words.

the unit test feeds instructions directly into one (and only one) of
the pipelines, and waits for the busy flag to go LOW.

> I’m assuming that right now there is no multi-issue or anything of that
> nature at the moment?

correct.  incremental development.  each step - each new piece of
functionality - confirmed by a unit test.

* when the core's executing instructions, we can start writing more
comprehensive unit tests.
* when the scoreboard is added, we re-run those unit tests.  if they
work, chances are scoreboard is functional.
* when that's added, we add multi-issue.  exactly the same same thing
again: run the unit tests.

i am absolutely shocked to find that there is not a single other
"open" processor that takes this approach.  they all - all of them -
rely heavily on "high level" integration tests.  test suites written
by other people.  or just a series of binaries which test the *whole*
system.

one error and the only way to find it is to compile up one massive
core.  if that takes several minutes to do (minerva takes a *minute*
to compile to verilog), tough luck.

we can run the *local* unit tests for the *local* module that is
believed to be the problem and rapidly track the problem down.


btw my brother dan pointed out that this type of approach - which is
not carried out *AT ALL* by *ANY* commercial team (especially Intel
right now) let alone an "open source" one, is a critically important
"Unique Selling Point" to investors.

by having a combination of low-level unit tests (and formal
correctness proofs) that test components individually prior to use in
a higher level that then *ALSO* has a unit test, this type of approach
is *EXACTLY* the kind of thing that will give investors a high degree
of confidence that we will be a safe bet.

l.