[libre-riscv-dev] TLB Initial Proposal

[Daniel Benusovich]

>
> We were specifically looking for ways to not need large CAMs since they are
> power-hungry when designing the instruction scheduling logic, so it may be
> a good idea to have a smaller L1 TLB and a larger, slower, more
> power-efficient, L2 TLB. I would have the L1 be 4-32 entries and the L2 can
> be 32-128 as long as the L2 cam isn't being activated every clock cycle. We
> can also share the L2 between the instruction and data caches
>
> Sounds great. Would the two levels of caching be separate types of memory
entirely? For example, the first level is a CAM and the second level is a
SRAM? What would determine the size of the caches? Would the cache size
value be created through testing to see what gives the minimum number of
misses vs power used?

The spec supports up to 56 bits, I would like to implement at least 40 for
> the off-chip tilelink-over-ethernet. The rest of the internals probably
> only need about 35.
>
>
Neat. So we would need to hold at least 56 bits per entry? Or is it 56 +
40 + 35 bits per entry? What is the spec? Is that relating to SimpleV or
RISCV specifications? Also what is referenced by internals? Is it possibly
the actual Physical Page Numbers (PPN) stored in the table entries? I see
in the RISCV manual that for Sv48 implementation a 64 bit table entry is
used for a 56 bit physical and virtual address. (Section 4.5.1 Figure 4.21
pg. 64 V1.10)

So it seems that having a software controlled TLB with 2 levels of caching
is the current course. Since misses will be handled in software what does
need to be done in hardware? For instance, will fetching the translations
and placing them into the TLB be a hardware or software task? If it is a
software task then the TLB must accept certain instructions to do what it
needs to or how does it work?

i've seen hardware implementations: whilst they look simple (not many
> lines of code), i just cannot understand them
>
>
Me too! :)

Thanks for the input it is very helpful.

Daniel B.