[libre-riscv-dev] Minerva L1 Cache
Luke Kenneth Casson Leighton
lkcl at lkcl.net
Mon Jun 15 21:10:53 BST 2020
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
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
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*
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.
More information about the libre-riscv-dev