[libre-riscv-dev] TLB key for CAM

[Luke Kenneth Casson Leighton]

On Wed, Apr 10, 2019 at 8:24 AM Daniel Benusovich
<flyingmonkeys1996 at gmail.com> wrote:

> Greetings comrade.

 greetings.  ah, i ascertain you _really are_ from the soviet union?
if so that would make us... *five* timezones.  dang :)

> Yes there are a few sorry. I will fix those as soon as I can.

 no problem.  btw i will place "TLB/VM/L1/L2" onto the list of
milestones for NLnet, if you'd like to receive some small financial
contribution (aside from a slicing-pie share?  we really do have to
discuss that as a group).

> > also, could you check: i believe nmigen will set a signal to the
> > "default (reset)" value if it is not explicitly set, and that the
> > default is "0" (zero).
>
> It does indeed! For combinational logic the data will reset to 0 as nothing
> is driving it. For synchronous logic it will hold its value.

 ok cool.

> > so... what that would mean, in turn, is, that *all* of the code which
> > explicitly sets signals to zero is not necessary (see below).
> >
> > of course, that *assumes* that, for example, that "cam_L1.enable" does
> > actually default to zero!
> >
> > what do you think, better to leave the resets in explicitly, so that
> > it's clearer what's going on?
>
> It would be nice to remove those statements but I personally think that is
> a bad idea considering for synchronous logic we must reset the signals
> manually. Sounds like a really strong gotcha moment. Which I have a
> vendetta against haha.

 :)

> I will endeavor to break the logic apart more.

 don't overdo it - i did that for the FPU, and as we found out, it
becomes almost impossible to read the code.  big case statements
however are a good candidate, you can see that the
"names-of-the-functions" help describe what each case does.

> It is cool that you can pass
> the module and reset signals within methods.

 yes.

> Though I see a little bit of
> confusion stemming from modifying outside structures.

 well, that could be documented in the docstring of the function?

> Would you know how
> nmigen handles return values from functions or is that unusable in the
> generated code?

 it's fine: the thing to remember, though, is that it is *not* a
function that is going to be "called" by the hardware, it's a hardware
FRAGMENT that's being returned by the function.

 consequently, if you call the function 100 times, guess what?  you
end up with a HUNDRED copies of the hardware-fragment being inserted
into the design.

> For the set associative cache I am leaning towards saving a few bits in
> each way that records the place of the entry in a LRU "list".

 i am very slow at algorithms, it take me days or weeks to
understand.... i'll follow along the discussion between you and jacob,
here?

 one thing though, to say: i did some research into this about 6-8
months ago, i assume we're talking SMP cache protocols here?

 i found a really really good paper that explained that switching
cache coherency protocols *dynamically* based on workloads results in
signiiiificant performance increases.

 the protocol basically had a counter that told it when there were
failures on reads or writes (or something).  it was only like a 2 or 3
bit counter, nothing big.  and when that number went above a certain
quantity, it switched the Set-Associative Cache to Dragon protocol,
and below a certain quantity switched to Firefly protocol, something
like that.
https://en.wikipedia.org/wiki/Dragon_protocol
https://en.wikipedia.org/wiki/Firefly_(cache_coherence_protocol)

that way, you get the best of both worlds, and because the counter is
small, it changes very very quickly.

is that relevant at all or is it completely useless information at this point?

l.