[libre-riscv-dev] TLB key for CAM
flyingmonkeys1996 at gmail.com
Wed Mar 27 04:39:23 GMT 2019
> 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
> 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
I can keep it at two. I was not sure how the second level would be
> > 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
> 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
> so, these are identical:
> arg1 = "hello"
> arg2 = "fred"
> Cat(arg1, arg2)
> this is identical to the above:
> arguments_list = [arg1, arg2]
> 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).
More information about the libre-riscv-dev