[libre-riscv-dev] TLB

[Daniel Benusovich]

>  honestly, i was thinking of following ariane, converting mmu.sv next,
> so modifying the ariane ptw.py or tlb.py too much would lead to
> clashes

So we are leaving it as is? I would be a little hesitant as we were
planning on using Sv48 rather than Sv39.

Also is the PLRU implemented into the TLB or is that still a todo?

We might as well throw out most of what I have so far. Ariane have
their own versions of pretty much class albeit stuffed into one mega
file.
We can probably keep the PermissionValidator but across from that
almost everything seems to be already contained. Unless we are
planning on stuffing the CAM into the ariane TLB.

I am also having a hard time looking at the code without any comments
in regards to input and outputs.

>  (btw, mmu.sv is dead simple: it instantiates a couple of tlbs, and a
> couple of ptws, and... er.... links them together).
>
>
>  however... hmmm, ariane doesn't appear to have any evidence in the
> code of *having* an L2 cache!
>
>  so i am not sure what to suggest.... although... logically... i
> *think*... if we have like... a Wishbone Bus, where the memory access
> go through that before getting to the actual physical memory, then L2
> is like, completely separate.

Sure. I will look at that when I can. I am not sure whether to focus
on the TLB or the bus now.

>  so can we focus on AssocCache, TLB and PTW initially?

Why do we need the AssocCache at all? If we are not modifying the
tlb.py we should stay away from how it is storing data.

>  and, shall i do mmu.sv converted to nmigen?   do you want to take a
> look first, see what you think:
>  https://github.com/pulp-platform/ariane/blob/master/src/mmu.sv
>
>  it really does just (mostly) link instruction/data tlbs and ptws together.

I am not familiar with SystemVerilog so it is rather difficult for me
to have an opinion.
At a high level it is reasonable and makes sense with an instruction
and data TLB. We can probably use the PermissionValidator in there too
which could be handy.