[libre-riscv-dev] TLB Initial Proposal

[Daniel Benusovich]

I read over a paper discussing TLBs and believe we could have 2 64-entry
fully associative TLB caches (128 entries total) using CAMs (Content
Addressable Memory). One cache would be used as an "active" list and the
second as an "inactive"  list . Linux uses a "Two-List Strategy" (which is
where I am pulling this from) in evicting cache entries.

All translations when initially called would be placed into the active
list. Entries in the inactive list would be moved into the active list when
hit.

If the active table fills up or gets to large the head entry should be
popped off and added to the inactive list. If both (active and inactive)
lists are full then: pop the head entry from the inactive list into the
ether, pop the head entry from the active list into the inactive table, and
place the new translation into the active list.

When lulls in requests occur and the inactive list exceed a given
threshold, popping off should occur to ensure that both lists never fully
fill up.

The benefit to this is the need to only maintain a tail and head pointer
for both lists. This would use 7 bits per pointer and total 28 bits for the
4 pointers which is nice.

Alternatively, A single 128 or 64 entry fully associative TLB is also
possible using a more standard LRU.

This logic would have to be implemented in software not hardware correct?
Most of the design papers I read have the OS perform the logic for cache
misses and controlling what goes where. This is a RISC styling. Older
designs had all logic controlled in the hardware. Which is a CISC styling.
I am not sure if this changes for a mobile application, as all what I read
was quite general purpose.

A few questions appear from this:

1. What page size we will be supporting?
2. What is the maximum physical memory we will be supporting?
3. Will the operating system on the chip be reserving any part of the
virtual memory space as kernel memory space?

Any feedback and or guidance would be much appreciated!

Hope you are having a good one and possibly had a chuckle reading this,

Daniel B.