[libre-riscv-dev] CAM multiple match policy

Daniel Benusovich flyingmonkeys1996 at gmail.com
Mon Mar 4 06:23:24 GMT 2019

Evening gentlemen,

In terms of the CAM it is certainly getting there. I have the cam entry
have only store the data as opposed to a key and data pairing. The data is
the key itself and the output from the CAM is the address that was matched.
A couple unit tests and it all seems to be going well. If we want to keep
the keys it shouldn't be much work to revert the changes the data as I had
previously done it with a key/value pair and it is in the git history. I
was looking at various combinations of CAMs and saw that none had key,
rather the data was compared and match line address the output. Either or
is fine. To me personally it makes sense to store the data in the same
entry as the key but that's not what the interface wants.

However, I have run into the issue of CAM multiple matching policy!

I am currently looking at implementing an interface similar to that if
Xilinx's Parameterizable Content-Addressable Memory so that
simulation/replacement on an FPGA will be much easier. For multiple matches
it seems that

When there are multiple matches in the core, single-match unencoded and
> binary encoded
returns the match of the highest priority location,
> which can be selected as the lowest or highest address.

This leads me to think that it will only ever give you *one* of the matches
(that being the lowest or highest one). Meaning you have to clear the
higher priority entry to get the lower one. This is okay but leaves the
lower priority entry stranded until the higher priority entry is cleared
(from what I understood).

I could add an encoder that would hand out all the matches one cycle after
each other or keep the interface as is to match Xilinx. I think the auto
spewer of addresses is cool and bit is done already but it adds +2 cycles.
Whereas I currently have a one cycle response time by following the Xilinx
interface. What do you guys think? Pretty much just follow the interface or
add some extra goodness?

If you guys have any concerns about the implementation let me know. I am
hesitant about the removal of the key from the CAM entry module so I am not
pushing yet. Let me know what you think about think about the removal of
the key AND the multiple match interface decision. Id like to finish the
CAM this week and finally start on the actual TLB and go demand answers
from the gentlemen ont he hw-dev page haha.

Have a good one,

Daniel B.

More information about the libre-riscv-dev mailing list