[libre-riscv-dev] CAM multiple match policy

[Luke Kenneth Casson Leighton]

On Mon, Mar 4, 2019 at 6:23 AM Daniel Benusovich
<flyingmonkeys1996 at gmail.com> wrote:
>
> 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.

 yes, i ran and confirmed they work great.

 i made some further whitespace changes.

> 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.

 that's what it's for :)

> 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.

 a possible reason that i can think of, is that to make them
general-purpose.  also, once you have the line address (the row /
index), it becomes possible to reference that entry in the future
*without* requiring further unnecessary power consumption.

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

 hurrah! :)  then that would be a usage bug.  as in, if a L1 or L2 or
TLB has multiple matching entries, that's a really, really serious and
critical fault that would require the processor to halt with extreme
prejudice.

> 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.

 that's a good idea.

> 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.

 like a nmigen PriorityEncoder

> 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).

 for a L1, L2 or TLB, multiple entries is a real serious and
absolutely critical hard fault.  there should *never*, under *any*
circumstances, be a situation where two L1 cache lines match for a
given address.  EVER.

 think about it: what on earth would you do if that occurred?  which
of the 2 (or more!) cache lines would you read (or write) the data to?

> 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.

 one cycle goooood.

> What do you guys think? Pretty much just follow the interface or
> add some extra goodness?

 path of least resistance goooood.

> 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.

 demand... respectfully: make the technical case and the need
absolutely clear, however do not be surprised if there is no response
to any needs for something that has not been specifically designed by
"RISC-V Foundation Members".

 please, do leave it to me to deal with the Trademark issues....

l.