 enter tables and maintain them properly while maximizing the usability of the CAM. We will look at some clever ways of man- aging the available space SO that as much information as possible can be squeezed into the CAM real estate. As tables are periodically updated, we will also look at some issues resulting from relocating either entire tables or simple entries inside the CAM array. As discussed previously, a system designer can maximize the occupancy of the array of useful entries by partitioning a CAM into segments. We will illustrate this point with an example from NetLogic.4 More details on this approach and similar ideas can be found in product literature and application notes. Imagine storing data into four tables that are IP addresses and are therefore 32 bits wide. If the CAM is 128 bits wide, unless the CAM array is partitioned into four tables, the storage capacity will be poorly used, as each entry will only store 32 bits. As a result, the rest of the bit positions that the CAM has available in each slot are wasted (128 available minus 32 used equals 96 wasted bits per slot). In this example, however, the four 32-bit-wide tables can be arranged next to each other. Every 128-bit slot is first split into four slices of 32 bits. These are numbered 3rd, 2nd, 1st, and 0th going from left to right. Each one of the four individual tables then occupies one of the four 32-bit slices of each 128-bit slot and runs the entire length of the CAM. If the CAM is, for example, a 1Mb array that was originally arranged as KX128 tables, it can easily be structured as four 8K 32 tables. Figure 12.3 shows how to work with the global mask registers to access only one among these four tables in order to perform a search. Bits set to zero in the global mask register guide the search to the corresponding table. For the four tables (partitions), the global masks corresponding to the individual partitions would look like the following (in hexadecimal): Mask 3: 00000000 FFFFFFFF FFFFFFFF FFFFFFFF Mask 2: FFFFFFFF 00000000 FFFFF