This post is a response to Greg Ferro’s recent Basics posts on (Content Addressable Memory) CAM tables. As this is a response post, you can assume that I don’t agree entirely with all of his definitions. Alternatively, perhaps I am totally wrong and I need to go back and relearn how CAM works. Either way, Greg loves a good spar, so maybe together with our readers we can determine the truth in an understandable format for the betterment of everybody who isn’t a hardcore digital electronics engineer.

Greg’s Posts

Before continuing, I’d recommend should go reading these posts as context, since they are the basis for this post:

Basics: What is Content Addressable Memory (CAM) ?
Basics: What is Binary CAM (BCAM) ?
Basics: What is Ternary Content Address Memory (TCAM) ?

I’ll now address my concerns post by post below.

What is CAM

A CAM cell in the chip actually consists of two SRAM cells. SRAM requires requires extensive silicon gates to implement that require a lot of power per gate for fast switching. In a chip, power consumption generates heat and leads to limits on thermal dissipation by the limited footprint of a chip. This is a key factor on the physical limitation on TCAM size today.

Nothing wrong with this as such, but I would also note that SRAM is only one component contributing to the heat problems. We want to be able to query multiple bits in parallel and get a result in a single clock cycle, which means taking the two SRAM cells and adding a Search Line (SL) and a Match Line (ML). As the names suggest, the SL is where the bit to be matched is presented, and the ML is where the result goes.

Typically the Match Line works by activating the Match Line (i.e. setting it to the voltage representing a 1), and letting a mismatch ground the line (deactivate it), thus reducing the voltage on the match line to zero (which is read as 0). That’s quite an expensive use of power, and means that even while SRAM technology may improve its power consumption, that’s independent from its use in CAMs and the ML in the CAM remains the bigger power issue and has a different set of problems to solve. In fact, a recently published paper Content Addressable Memory performance Analysis using NAND Structure FinFET tries to address this problem, and per the paper’s summary: This paper proposes an effective design for the Content Addressable Memory (CAM) with NAND and NOR cell structure using the FinFET Technology, thereby largely reducing the issue of increased power consumption. Well now, wouldn’t that just be lovely? It might seem like this response is nit-picking, but it’s an important distinction: if you read an article saying that SRAM has just halved its power utilization, that’s great, but it won’t mean that a CAM will now have halved power utilization because it uses that new SRAM.

What is Binary CAM

Binary CAM performs a binary lookup ands returns either a 1 or 0. (sic)

Ok, this is potentially ambiguously phrased (to whom does the binary CAM return those values?), so for clarity: The Match Line result is a 1 or 0 (match or mismatch respectively), but what’s returned to the caller (i.e. the entity requesting a CAM lookup) is either a memory location (e.g. a pointer) or – in a more complete CAM system – the value of what’s in the referenced memory location. After all, the CAM is supposed to be kind of like a hash lookup by value, and should return the key. Ok, this one is a little picky I grant you.

The MAC addresses in the diagram on that post all have a bonus nybble (e.g. 0000.0000.00007). Yes, that’s tremendously picky.

The search look ups the BCAM table of MAC Address and either finds the a complete match for the MAC address or doesn’t – a binary condition. (sic)

This is true, it’s a binary condition, but that’s not why it’s called a Binary TCAM, which seems to be the implication. It’s a binary TCAM because the bit values that can be stored in each CAM cell (against which lookups can be performed) are binary: 1 or 0, as opposed to the Ternary TCAM which stores three values (actually since it uses two bits to store each value, it can theoretically store four values, but typically TCAM does not use 0x00). And to pick at myself, it’s not really 0x00, but that’s a handy way to represent the bit values as they are stored in each of the two respective SRAM cells.

What is Ternary CAM (TCAM)

That TCAM memory has the ability to match (0), not match(1) (the binary is counterintuitive there) or not care (wildcard).

Behold, I have now reached peak pickiness! First of all, “TCAM memory” expands to “Ternary Content Addressable Memory memory”. Back to technical stuff though, a lookup in TCAM still returns a binary value – either match or mismatch; there isn’t a don’t care return value because the Match Line itself is either high or low; it’s a binary value. The TCAM has the ability to store three values as I mentioned above, and a typical mapping of the values stored in those two SRAM cells would be like this:

Stored Bits	Represents
0 0	UNUSED
0 1	0x0
1 0	0x1
1 1	X (wildcard)

(See Pagiamtzis Table II for more information).

That said, my understanding is that a Match Line will return 1 for a match (success) and 0 for a mismatch (failure), not the other way around. The presence of a mismatch is what grounds each CAM cell, thus deactivating the Match Line given that it starts off as activated. Of course, there’s more than one way to skin a cat, and there have been various methods developed to try and run a Match Line using other mechanisms, so perhaps Greg is referring to one of those.

 

I will now go bury my head somewhere dark and moist and await the inevitable correction of my corrections. Whether I’m being picky or not, Greg has chosen a subject that is not well understood by many (it falls within the magic hand-waving of most vendors) and I appreciate him putting a much needed well-written set of explanations out there for me to gnaw on.