CAM for FPGA ...

Hi all,
I would like to get into a CAM design for FPGA.
Does any of you know about where can I find material on this subject? I
will appreciate stuff like tutorials and reference designs (examples in
any HDL)..

Thanks in advance, Moti.

try the xilinx web-site, they have lots of information on CAMs, they also
used to have reference designs

Hi Daryl,
I already knows the stuff from xilinx, i was actually aiming for stuff
like tutorials and HDL code examples.
Regards, Moti.

Moti Cohen wrote:

> I already knows the stuff from xilinx, i was actually aiming for stuff
> like tutorials and HDL code examples.

Start by reading some data sheets of real CAMs:
http://www.google.com/search?q=content+addressable+memory+data+sheet+CAM

There are not many HDL level code examples
because a CAM does not fit well in an FPGA.
The basic idea is to search through a
register array to match an input tag
in one clock cycle. The read code is just a
FOR loop. The problem is the large amount
of wiring and logic generated between all the
register outputs and the match bit.
What will fit in an FPGA is a very small
array at a very low Fmax compared to
an off-the-shelf CAM.


          -- Mike Treseler

In article <3cq8miF6qu5etU1@individual.net>,
Mike Treseler  <mike_treseler@comcast.net> wrote:
>Moti Cohen wrote:
>
>> I already knows the stuff from xilinx, i was actually aiming for stuff
>> like tutorials and HDL code examples.
>
>Start by reading some data sheets of real CAMs:
>http://www.google.com/search?q=content+addressable+memory+data+sheet+CAM
>
>There are not many HDL level code examples
>because a CAM does not fit well in an FPGA.
>The basic idea is to search through a
>register array to match an input tag
>in one clock cycle.

The clock cycles for commercial CAMs seem pretty long; I wonder
whether a solution that stored the data in the first part of each of a
large number of block RAMs, with a very simple counter for addresses
and a comparator, running at a much quicker internal clock, might get
better results.  This feels as if it could be made a bandwidth
problem, and FPGAs lack not in bandwidth.

I suppose block RAMs are seldom wide enough; this feels like a case
where Altera's 512-bit memory blocks might come into their own [OK,
you need four to store a 64-bit word; with 318MHz not-to-exceed speed,
you probably can't fit more than 16 words per set of four blocks if
you want clock rates competitive with the 20Mhz of MUSIC; but you
could fit sixteen sets of four blocks on even the smallest Stratix].

Though that's 256x64, whilst MUSIC offers 4096x64 in their larger
devices.

Tom

Note that Altera has or had CAM functionality for 16 or 32 words at a time
in their memories starting in the 20K family.  That size was never
interesting for my applications so I didn't pursue them.

If you use a BlockRAM with a counter, you're going to have a maximum delay
of the number of entries in the RAM before a match: much, much longer than
commercial CAMs.

Hash tables or dictionaries built from parts of the value and pointers to
other values in a search tree can reduce your search times but they aren't
simple.

1) If you want a 1kx64 CAM, I'd suggest the FPGA isn't the way to go.  2)
Look at Altera's CAM functionality.  3) If you want small CAMs or have lots
of FPGA space, let us know.  We can't devine your requirements from the CAM
"idea" you're asking about.

John_H wrote:
> Note that Altera has or had CAM functionality for 16 or 32 words at a time
> in their memories starting in the 20K family.  That size was never
> interesting for my applications so I didn't pursue them.

Nor did anyone else.
The function was dropped after the 20K.

> We can't devine your requirements from the CAM
> "idea" you're asking about.

Yes, "getting into a CAM design for FPGA" is a little unfocused.

       -- Mike Treseler

In article <bYU9e.32$jt6.335@news-west.eli.net>,
John_H <johnhandwork@mail.com> wrote:
>Note that Altera has or had CAM functionality for 16 or 32 words at a time
>in their memories starting in the 20K family.  That size was never
>interesting for my applications so I didn't pursue them.
>
>If you use a BlockRAM with a counter, you're going to have a maximum delay
>of the number of entries in the RAM before a match: much, much longer than
>commercial CAMs.

That's why I was proposing using lots of blockRAMs with a counter;
given that the cycle times for block RAM are so much shorter than the
ones I see for commercial CAMs, the trade-off might be less completely
hopeless than you'd fear; the catalogue in

http://www.music-ic.com/index.php?section1=products&section2=function

has a lot of CAMs with a compare time as long as 90ns, in which time
you can look up quite a lot of entries in quite a lot of block RAMs in
parallel..

Tom

"Moti Cohen" <Moti.cohen@alvarion.com> wrote in message news:<1114067899.464241.13230@f14g2000cwb.googlegroups.com>...
> Hi all,
> I would like to get into a CAM design for FPGA.
> Does any of you know about where can I find material on this subject? I
> will appreciate stuff like tutorials and reference designs (examples in
> any HDL)..
> 
> Thanks in advance, Moti.

Maybe there could be some possibility to build a CAM by using
the integrated RAM of a FPGA / CPLD ...

What are going to use ? Altera, Lattice, ... ?

Rgds
Andr&#4294967295;

Thomas Womack wrote:
> The clock cycles for commercial CAMs seem pretty long; I wonder
> whether a solution that stored the data in the first part of each of a
> large number of block RAMs, with a very simple counter for addresses
> and a comparator, running at a much quicker internal clock, might get
> better results.  This feels as if it could be made a bandwidth
> problem, and FPGAs lack not in bandwidth.

For the (one) cam part I've seen - the latency was a number of clock 
cycles.  I've wondered whether it could actually be doing something a 
little more complex like a binary tree type search.  Still have to deal 
with don't-care type masks though, I suppose.

Jeremy