[libre-riscv-dev] TLB key for CAM

[Daniel Benusovich]

>  sounds initially like a plan to get going... ahh is that the 2-level
> TLB idea that you were thinking of removing? i really liked the 2
> levels (and it turns out it's something that intel does for high
> performance).
>
>  would it be possible to remove the 2nd cache, write a unit test to
> prove one cache, then add it back in and modify the unit test to do 2
> again?

I can keep it at two. I was not sure how the second level would be
implemented yet.

> > After that is done I am not really to sure as the TLB will be
> > fundamentally done.
>
>  great!  would that mean it would be at the point where it could do
> page-walking in hardware?  or are we sticking to software?

I believe the consensus was software. Though there is an option in the
RISCV mode selection (if I am remembering correctly) to use hardware
walking as opposed to software when a miss occurs.
I would have to look back again though writing a page walker would not
be the end of the world.

> > Do you have any ideas? I have seen the phrase
> > formal verification being thrown about (I have no
> > idea what that is yet I have not googled it haha) so maybe that? Or
> > start the next component perhaps?
>
>  next component... and/or discuss/review the levels of TLB idea, i
> really liked that concept, to have a 2-level TLB with reduced CAM
> sizes for the 1st level.   being able to check the peformance of that,
> via a unit test that emulates workloads would be really useful.
>
>  honestly there's quite a bit i am not familiar with on this, so the
> more everyone can help out the better.

I agree it is a cool idea and efficient idea. I was not confident in
implementing the second cache as a CAM as it would be a bit much size
and power wise.
However, once we go into a more common version of caching it will no
longer be a one cycle search.
Pretty much it would delay getting a miss while we search the second
level cache. If that is alright I could move forward, maybe with a set
associative cache with a generic size?
If so more modules to write! Hooray!

>  oh!  btw, VectorAssembler.py can be replaced with this:
>
>  vector = []
>  for index in range(len(something):
>       ematch = entry_array[index].match
>       vector.append(ematch)
>
> encoder.i.eq(Cat(*vector))
>
> basically, VectorAssembler is identical to the nmigen "Cat" class.
>
> the Cat class takes a variable number of non-keyword arguments.  to
> pass in a list *as if* it was a series of arguments, you do
> Cat(*arguments).
>
> so, these are identical:
>
> arg1 = "hello"
> arg2 = "fred"
> Cat(arg1, arg2)
>
> this is identical to the above:
>
> arguments_list = [arg1, arg2]
> Cat(*arguments_list)
>
> the star ("*") is what tells python to apply the list (or tuple) as
> arguments *to* the Cat object.

Absolutely gorgeous. I was thinking that Cat should be able to do this
but didn't get around to making it work thank you!
I will put that in post haste (as long as those dreaded loops don't come back).

Cheers,

Daniel B.