[libre-riscv-dev] Virtual Memory Management system

[Luke Kenneth Casson Leighton]

On Tuesday, June 25, 2019, Tobias Platen <hacks2019 at platen-software.de>
wrote:

> This weekend I was reading both the "ScoreBoard Mechanics" PDFs and the
> source
> code of the soc. I saw that there is already a TLB, but no module that uses
> the TLB, therefore I will write one.


A proper unit test of the TLB would be good.

btw do bear in mind it may save a lot of effort to translate ariane verilog
into nmigen, this you can see is underway in the ariane src directory.

I started a basic test of the TLB code, there.


>
>  I think I should start working on the
> instruction fetch stage first, then getting load and store instructions
> working.


Those are each seriously big tasks (all three of them) and the fetch part
needs a *lot* of thought and design work.

If you have been following the SimpleV  VBLOCK modifications, instruction
fetch is now a 2 step process with a massive 2 to 3 i-cache line sized
buffer needed, that adds SV state context into the second stage.

The second stage is a *multi issue* stage which can also generate a THIRD
level of multi issue execution, from the SimpleV Vector Loops.

At this third point, we work out if the multi issued ops can be jammed into
SIMD ALUs or even if they need to be split across 2 32 bit ALUs that work
in tandem to do 64 bit ops.

It is nowhere near as "simple" as a standard in order design, or even an
out of order multi issue engine.

More about this is here and you can backtrack a few messages to the
original on which the bits about predication are augmentations

https://groups.google.com/d/msg/comp.arch/yIFmee-Cx-c/3y4jthHBAQAJ

Wr do however need to go in stages. Single issue, then RVC, then SVPrefix,
then multi issue, then VBLOCK is probably a sensible order.

LD/ST i do not have that up and running, yet, so there is not anything to
hook into.

The scoreboard implementation has hooks for an instruction queue, i am
manually throwing instructions in it at the moment.

However these are pseudo instructions, nowhere near RISCV.

There is a heck of a lot that needs planning and piecing together.

Currently I have only migen working, next I'll setup the spike simulator.
>
>
Cool. You should be able to set up the standard RISCV environment (not
involving the sv branches at all) using any tutorial, I followed the riscv
tools one, many people use the sifive ones instead.

That will get you a suitable bare metal riscv cross conpiler etc etc as the
debian riscv one of course is set up to add stdlibs etc and you do not want
those linked in for spike tests, you really need the -none- gcc riscv cross
compilers here.

Once done, the sv branches of the two repos (sim and tests) can be checked
out and compiled.

Watch out for the fact that spike does dynamic library loading so it can
pick up the .so's from the wrong place. I use LD_LIBRARY_PATH to grab it by
the short and curlies, get its attention and use the .so in the actual
build ditectory without needing to be silly, like do make install as root.

L.



-- 
---
crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68