Maximum Frequencies
The Binary CAM Search IP is designed to run at up to 600 MHz in UltraScale+™ -2 speed grade devices.
Latency
The BCAM lookup latency depends on the size of the BCAM the RAM_FREQ / LOOKUP_RATE ratio and the memory type. The lookup latency is constant and some examples are shown in the following table.
Entries | RAM Clock 1x | RAM Clock 4x | RAM Clock 16x | RAM Clock 32x |
---|---|---|---|---|
256 | 16/17 | 13/14 | 9/9 | 8/8 |
1K | 16/17 | 14/14 | 9/9 | 8/8 |
4K | 18/17 | 14/14 | 9/9 | 8/8 |
16K | 21/18 | 14/14 | 9/9 | 8/8 |
Throughput
The lookup throughput corresponds to the LOOKUP_RATE parameter. The highest possible lookup throughput is accomplished when LOOKUP_RATE equals the RAM _FREQ parameter. One Lookup Request can then be issued per RAM clock cycle. The Management Request has strictly lower priority than the Lookup Request, consequently the Management Request throughput becomes:
The ECC scrubbing process has the lowest priority. A memory read followed by a potential corrective write is only executed if both the Lookup Request and Management Request FIFOs are empty. Neither the lookup throughput nor the Management Request throughputs are affected. ECC scrubbing of a new address is only initiated if both FIFOs are empty and a potential pending corrective write has been executed.
All read and write Management Requests are 32 bits wide. The only exception is for write Management Request of entry data. These Management Requests might be wider as described in the section below. The Management Request width for entry data is essential for correct dimensioning of the lookup rate and RAM frequency in order to have throughput headroom for Management Requests.
In order to perform management updates while maintaining correct state for lookups, the management operations need to be atomic. This means that a complete entry must be written to the CAM Database before the entry is made active (valid). To accomplish wide writes, an entry is written using multiple Management Requests where the last Management Request sets the valid bit. When an already existing entry is being updated, the valid bit is already set. This means that the response data needs to be written using only a single Management Request. For this reason a Management Request writes at least (response + valid) width bits of data. The total width is rounded upwards to the next 64-bit boundary. For a 160-bit key with 72 bits of response + valid, assume that the following is written:
- Key, 160 bits
- Response + Valid, 72 bits
In total, 232 bits are written. The width of response + valid is 72 bits, this will be rounded to 128 bits. Each Management request writes 128 bits. With rounding up, 232/128 = 2 write Management Requests are sent.
The AXI4-Lite bus uses 13 bits of address and 32 bits of data, so for every Management Request multiple AXI4-Lite writes are issued from the API software. The AXI4-Lite writes are assembled by the AXI4-Slave to a single Management Request. The AXI4-Lite interface is a standard type. Refer to AXI4-Lite IPIF LogiCORE IP Product Guide (PG155).
- All outstanding write responses must have been received before issuing a read.
- All outstanding read responses must have been received before issuing a write.
The following table shows an example calculation for 100 Gb ethernet rate. Keep in mind the calculated update rate only refers to the hardware resources, the final update rate is most likely limited by the table management software.
Management Request Size [bits] | AXI Lite Write Operations [min / max] | Management Update rate [M updates/s] |
---|---|---|
64 | 1 / 3 | 4.8 |
128 | 2 / 5 | 2.4 |
256 | 4 / 9 | 1.2 |
512 | 8 / 17 | 0.6 |
1024 | 16 / 33 | 0.3 |