eed to be consulted at the same time. For example, say that a MAC table, an IP table, a rules table, and a flow-management table must all be consulted in parallel, as shown in Figure 12.5. These tables will need to be loaded and main- tained into four partitions of the same CAM, or four different CAMs (each with their own associated SRAM memory) will need to be searched in parallel. What are the corresponding implications of these two approaches? The first solution is usually unacceptable as some tables are gigantic and others are small. In this case, some partitions may end up being too small to fit the larger tables, whereas the smaller table(s) may end up occupying more partitions than they should. This approach wastes expensive partitions that could be used more efficiently. The second solution is not negatively affected when larger tables are used, as they will each have their own CAM. However, it does suffer when smaller tables are used, as they don't easily justify an entire CAM of their own. The overall cost also increases significantly, because in addition to extra SRAM, some CAMs cost more than the network processor itself! In Chapter 9, "Other NPU Architectures," we described an interesting approach that was taken by Silicon Access (with its integrated solution). With this approach, the associated SRAM is embedded inside its search engine chip. This definitely minimizes component count and power consumption. To and from To and from Traffic manager Packet processing environment Network processor Backplane or custom-designed ASIC FIGURE 12.5 A typical approach based on a multiple-CAM arrangement for next-generation multitable parallel searches. Downloaded from Digital Engineering Library @ McGraw-Hill (www.digitalengineeringlibrary.com) Copyright © 2004 The McGraw-Hill Companies. All rights reserved. Any use is subject to the Terms of Use as given at the website. SEARCH ENGINES SEARCH ENGINES Another area of interest is when search keys are 36 bits long. As most current CAMs are designed with 72-bit sear