[libre-riscv-dev] TLB

[Daniel Benusovich]

>  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.

>  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. 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.

> 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.
We can change it back if you think it would be better. 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.

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.

> > At least the assoc cache is almost there now!
>
>  o yeh :)

As long the PLRU decides to cooperate.