[libre-riscv-dev] TLB

[Luke Kenneth Casson Leighton]

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

> >  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?
>
> I was under the impression that would be a great deal of hardware that
> is in reality not needed.
> Unless we are planning on accessing with more than one read port and
> then it should be one PLRU logic module per read and write port.

 that's what i kinda was thinking was needed: if we don't, we don't.
save gates.

> >  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.
>
> Yes I saw that and did not really understand why. I made it
> combinational to fix this exact issue.

 input plru_tree, output plru_tree.  nice.

> The higher level module keeps
> track of the memory and then asks the PLRU which entry is the LRU
> based on the current Signal state. Then the upper module updates its
> current state based on the PLRU output. While it is not as compact as
> the original storing its own Signal, passing in the state each time
> and then outputting the new state greatly reduces the amount of
> hardware required as we do not need a PLRU module per set.

 okaaay, cool.

> > 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.
>
> I implemented this just storing the signals and passing them instead.

m.d.sync += self.plru_array[self.cset].eq(self.plru.plru_tree_o)

looks great.

> We can change it back if you think it would be better.

 naah.

> Again my only
> concern was the amount of hardware per set would be a little larger
> than if it was just a Signal per set.

 got it.

> It is easy enough to go back and add back the synchronous and have a
> PLRU per line. It would actually be easier to use then the current
> setup but more expensive hardware wise.

 we don't like expensive in hardware terms

> > > At least the assoc cache is almost there now!
> >
> >  o yeh :)
>
> As long the PLRU decides to cooperate.

 :)