[comp.arch] CAM hits the market

mark@mips.COM (Mark G. Johnson) (12/13/88)

In article <23767@amdcad.AMD.COM>, phil@diablo.amd.com (Phil Ngai) writes

  $ The Am99C10 CAM is composed of 256 words, each consisting of a 48-bit
  $ register and a 48-bit maskable comparator. Data presented to the CAM
  $ is simultaneously compared to all 256 addresses in a single 100 ns
  $ cycle.

I congratulate the folks who brought this device to market; especially the
decision to go with a wide-word (48bit) match.  However, at 100 nsec it
does appear to be rather slow for a 1988/9 CMOS product.  {but then again
100 nsec is plenty good enough for Ethernet}

Just as a datapoint for comparison, several microprocessors use CAMs
in their virtual-to-physical address translation mechanism.  And these
CAMs go a lot faster; for example, the CAM on the die I'm familiar with
(R3000) is 64 words of 20 bits, and operates in 20 nsec.  Admittedly
that's on-chip, so to be fair we'd have to add, say, another 15 nsec for
the CMOS/TTL conversion at inputs and outputs.  Also, making the array 4X
deeper and 2X wider would, at worst, multiply the array access time by
1.5X, (e.g. compare access times of CMOS 64K and 4K SRAMs), adding another
10 nsec.....  a total of 45 nsec.

Note that the CAM's per-bit masking features add complexity, but not delay,
to the design.   The matcher's output priority encoder adds 4-6 gate delays
(about 4ns)..... a total of 50 nsec.

Don't get me wrong, I'm glad that system folks can now trade money for
CAMs, and I'm glad the "special application memory" market now contains
something more innovative than FIFOs and dual-ports.  But I sure wish the
99C10 was spec'd at 50ns instead of 100ns.
-- 
 -- Mark Johnson	
 	MIPS Computer Systems, 930 E. Arques, Sunnyvale, CA 94086
	...!decwrl!mips!mark	(408) 991-0208

rpw3@amdcad.AMD.COM (Rob Warnock) (12/16/88)

Based on the announced characteristics, I suspect the Am99C10 CAM is intended
for applications like MAC-level bridges (note the "selectable 16- or 48-bit").
For that application, 100ns is fine -- even for FDDI. Even with clever hashing,
or tree-structured direct-mapping, it'll take a fast node CPU several
microseconds to do the same thing.

But 256 words is marginal. For bridging apps, you basically need a big enough
CAM in each bridge to hold all the source addresses you may ever see on either
side of the bridge -- that is, the number of hosts on your net -- which is why
I said 256 is marginal. But you can cascade them to expand the size. (The chip
is said to include cascade controls.)

So the Am99C10 probably has a place in the world.

Rob Warnock
Systems Architecture Consultant

UUCP:	  {amdcad,fortune,sun}!redwood!rpw3
ATTmail:  !rpw3
DDD:	  (415)572-2607
USPS:	  627 26th Ave, San Mateo, CA  94403