[libre-riscv-dev] TLB

Luke Kenneth Casson Leighton lkcl at lkcl.net
Mon Apr 22 02:22:11 BST 2019


On Mon, Apr 22, 2019 at 1:53 AM Daniel Benusovich
<flyingmonkeys1996 at gmail.com> wrote:

> When I was in school I worked a bit with AXI4 for FPGA interconnects.

 that would help.  when you have time have a look at cocotb, it
compiles verilog in a way that makes it possible to connect a unix
pipe to it from python, and interact with it as if it was a nmigen
simulation.

 utterly awesome.

 the examples have some axi4 client applications, so there is a route
for doing unit tests that way.

> I will look at the git page this week as I am trying to finish the
> assoc cache by the end of the day.

 that would be great.

> > The only thing with this code, the search algorithm for the L2 TLB is quite
> > poor, it is linear, and a FSM.
> >
> > I start to see why you asked about the PLRU, it would be possible to use
> > the same PLRU module from ariane ptw in the L2 Cache.
>
> The PLRU change is almost there. It is implemented into the
> AssocCache.

 nice.  i saw the commits, will take a look

> The only issue is the PLRU module does not give an update
> on the new PLRU tree after writing which I need for the cache (at
> least from what I see).

 erm... ermermerm.... hmmm... ok so there's *multiple* plru tree
sets... routed through the one single PLRU.

 would that instead be better as an array of PLRUs?

 one reason why, plru_tree in PLRU is updated using sync.  the
multiplexing "plru_entry = self.plru_array[self.cset]" is done
combinatorially... that doesn't feel right.

i have a sort-of sneaking suspicion that keeping an array of PLRUs
would be better, then using cset in access_plru to select which one in
that array:

            self.plru[self.cset].lu_hit.eq(self.encoder.o),
            # Set that the cache was accessed
            self.plru[self.cset].lu_access_i.eq(1)

and setting the ones *not* being accessed to zero...

then, the sync-based plru_tree stays "safe" in each of the array of
PLRUs, on a per-cset basis.

> At least the assoc cache is almost there now!

 o yeh :)

l.



More information about the libre-riscv-dev mailing list