ce of these types of statements in the source code, and auto- matically reserves and schedules the use of the hardware-based MPBX unit. All packet buffering for the iPP is embedded on chip. Likewise, on-chip SRAM eliminates the need for external tables for pro- tocol data and data-path state information. The iPP can contain up to 4K instructions. The company's own reference-design code is reported to only take up about half of this space, SO plenty of room is available for custom coding. In addition to the advantages the on-chip TCAM offers, it can be accessed up to six times per packet. The iPP has two transmit (Tx) and two receive (Rx) System Packet Interface, 4.2 (SPI-4.2) inter- faces. These are capable of 12.6 Gbps on each interface. The host interface is ensured over a standard 32-bit 33/66 MHz Peripheral Computer Interconnect (PCI) 2.2 bus. It also contains proprietary HCCs based on low-voltage differential signaling (LVDS), which are used to connect the iAC, iAP, and iCL chips with the iPP. Clocked at 400 MHz double data rate (DDR), an 8-bit HCC provides 6.4 Gbps of bandwidth for each direction. The iPP is available in a 1,170-pin HPBGA package and consumes about 12 watts. As of this writing, the company has not yet disclosed details about the chipset's iTM. Con- sequently, current users are obliged to use the other members of the iFlow chipset in conjunction with a special application-specific integrated circuit (ASIC) that the customer must design to handle traf- fic management issues. The company has only alluded to the connectivity between the iTM and the switch fabric as being either SPI-4.2 or CSIX-L1. However, it seems that bandwidth throughput issues will occur with the CSIX-L1 if a fabric throughput of 25 Gbps is required (although this is not the case with the dual SPI-4.2 approach). The iAC is a powerful platform that can handle up to 550 million operations per second. Its role is to assist the iPP by taking care of traffic policing and statistics gathering. It can match header val- ues against