Regular CAM asks "which row equals this key?" in one cycle. That's great for exact-match tables like MAC address lookups, but useless for routing, where the rule isn't match 10.1.2.3 exactly — it's match anything that starts with 10.1/16. Ternary CAM adds a third state per bit — X (don't care) — and matches an entire prefix or wildcard rule in one cycle. It's how every serious router and switch does line-rate lookups.

Each TCAM cell stores two bits, encoding three states:

• 01 = stored 0 — matches only when the search bit is 0
• 10 = stored 1 — matches only when the search bit is 1
• 11 = X (don't care) — matches any search bit
• 00 = always-miss (used to invalidate an entry)

Physically, a TCAM cell is two SRAM cells feeding a pull-down network on a shared match line. Before search, every match line is precharged high. On search, each cell tries to pull the line low if its stored bit disagrees with the search bit — X cells never pull down. A row whose match line stays high after evaluation is a hit. Every row evaluates in parallel; a priority encoder picks the first (lowest-index) hit, since multiple prefix rules can match the same address.

Real example — Internet route lookup. The BGP table now sits around 950,000 IPv4 prefixes. A software longest-prefix-match on a trie takes ~10 memory references per lookup. A datacenter switch pushes 12.8 Tb/s and needs one lookup per 64-byte packet — 25 billion per second. TCAM does that lookup in one cycle by storing each prefix as bits + Xs (10.1.0.0/16 → 16 exact bits, 16 Xs) and letting the priority encoder pick the longest match, which is placed at the lowest address by the control plane.

The cost is brutal. A TCAM cell is 16 transistors vs 6 for SRAM — nearly 3× the area — and every match line switches on every lookup, so power scales with entries × search-rate. A modern switch TCAM at 100,000 entries and 1 Gsearch/s dissipates 15–20 W just for the lookup. That's why TCAM sizes are advertised as a scarce resource ("128K IPv4 rules") and why routing engineers care whether an ACL can be compressed.

Rule of thumb: TCAM power ≈ (entries) × (width in bits) × (search rate) × ~0.5 fJ/bit-search. Multiply out a 40K × 144-bit TCAM at 500 MHz — you land at ~1.5 W, and that's just one stage of a multi-stage pipeline.