[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