esired design functionality, without anything superfluous. This stream- lined software architecture is comprised of the following: An open applications programming interface (API) with custom-written application-specific code or other third-party software packages Transparent access to other coprocessors available from other vendors, such as search engines, encryption acceleration chips, and SO on Traffic management engine interactions and switch fabric configuration and management A library of common networking functions A modular interface for customer-developed NPU software Customers write their application software, without loss of efficiency, as if it was intended to run on one single CPU. The system will automatically repartition it over the available nPcores. From the beginning of its development efforts, AMCC was extremely sensitive to the fact that embedded soft- ware written for a high-speed switching system must be fine-tuned for true wire speed SO that hard- ware-computing resources would not remain idle even for small amounts of time. A typical situation where this occurs is with the phenomenon of a pipeline bubble. In a pipeline bubble, inactivity at some point in time propagates down the pipeline stages, further promulgating the effect of temporary idle- ness and multiplying the effect of efficiency loss. Supercomputer designers have found out the hard way that scheduling multiprocessor-based com- puting tasks for the time-sensitive execution of software is a difficult task. The unpredictable nature of network traffic, coupled with the extreme high speeds involved in today's links, can cause interde- pendency situations and force undesirable wait states on some processors. As a result, partial idleness can be incurred pending the completion of an intermediate and necessary task that runs on another System CPU Application software nPSS API Software Services Common Services nPX Switch Fabric nPC from AMCC Application software nPTM family 3rd party Network Processor coprocessor FIGURE 6.3 AMCC's nPsof