[libre-riscv-dev] TLB Initial Proposal

[Luke Kenneth Casson Leighton]

On Mon, Jan 21, 2019 at 11:13 AM Jacob Lifshay <programmerjake at gmail.com> wrote:
>
> On Sun, Jan 20, 2019, 22:20 Daniel Benusovich <flyingmonkeys1996 at gmail.com
> wrote:
>
> > 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.
> >
> 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.

 oo that's a really good idea.

> > This logic would have to be implemented in software not hardware correct?

> You can do it either way. The state machine needed for walking page tables
> is quite simple and (hopefully) rarely activated.

i've seen hardware implementations: whilst they look simple (not many
lines of code), i just cannot understand them.  plus, they have
permissions hard-coded into the HDL.  that makes me nervous.  so if we
can do a minimal hardware plus software version, and performance isn't
terrible, GREAT.

> >
> > A few questions appear from this:
> >
> > 1. What page size we will be supporting?
>
> 4KiB
>
> > 2. What is the maximum physical memory we will be supporting?
> >
> 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.

 oh, yes, i'd forgotten about memory-mapped IO.  so yes, more is
better... but not too much.

> If it's not too much work, I'd like to support Sv48 as well, since that
> will be useful for mapping very large files and connecting via shared
> memory to bigger servers. If we are having sw handle TLB misses, all we
> have to do is make the virtual address bus bigger.

 sounds good to me.