[libre-riscv-dev] CAM multiple match policy

Luke Kenneth Casson Leighton lkcl at lkcl.net
Thu Mar 7 06:25:52 GMT 2019

On Thursday, March 7, 2019, Daniel Benusovich <flyingmonkeys1996 at gmail.com>

> Forgive me but I do not have this thread

Dont worry about that

> so Im sending it here just to
> give an update on the yosys graph. If you want to throw this in the
> list please do.


> > hmmm... also...i'm woonderiiiing.... if the code (hardware) inside the
> > loop would be better placed in [yet another] module.  the for-loop is
> > auto-generating duplicated code (which is exactly what it's supposed
> > to do), however it's making it really unclear to be able to follow
> > what's going on.
> Made the graph and yes I see the section you are talking about. The
> giant loop-de-doo of death after the matching nodes correct and the
> PROC? Most of the diagram makes sense except for these last bits.
> By the way what are PROCs?
Clueless! :)

> Also, if I am reading the nodes corretly something labeled (3:3 - 0:0)
> Mean a slice of size on from position 3 -3 is going to position 0 - 0?

Bits indexed 3 down to 3 as input, renumbered to bits 0 down to 0 as output.

> So this 4 bit array [0,1,0,0] would become [1]. Right?

If the... no, output would be [0].

Array[3] would need to be 1 to get an output of [1]

> The cam is almost there. Just need to add the read warning fault. Do
> we want the ternary operations or should I just leave the port?

Sorry I dont know what you mean. Ternary operator is "Mux" in nmigen.


crowd-funded eco-conscious hardware: https://www.crowdsupply.com/eoma68

More information about the libre-riscv-dev mailing list