ot just a MIPS problem. It is a general RISC and complex instruction set computer (CISC) problem. As a result, it plagues other IP core vendors such as Tensilica and ARC. Recently, in order to play a more important role in the network-processing realm, MIPS has re- worked its fundamental instruction set to create some extensions that allow a satisfactory addressing of the first one of these two problems. Although the company's RISC cores have not suddenly become specialized network-processor cores with the introduction of the extended MIPS instruction set, it offers an improvement in programming network-processing applications. Nevertheless, MIPS IP cores still cannot compete with any network-processor chip that we have discussed SO far. NPUs have been designed to excel in data plane applications; therefore, MIPS technology remains largely a candidate for the embedded implementation of control plane processing. MIPS was unprepared when it was confronted with the sudden arrival and the ringing market endorsement of configurable architectures and methodologies within the last three years such as the one Tensilica has evangelized. Many people who are not familiar with internals of computer archi- tecture may be wondering what is SO different between the two schools. For example, with the Tensilica approach, a quick comparison will show that in the MIPS extensibility and configurability scenario (at least as depicted in the MIPS presentation at the Embedded Processor Forum in 2002), person must hack into the processor's pipeline by coding in Register Transfer Language (RTL) in order to make a new instruction work. That requirement alone lies well outside the skills territory of most experienced design engineers. Handling all issues pertaining to synchronization with the proces- sor's pipeline is the customer's responsibility. As the customer must handle the new instruction decod- ing, this is scary for most people. As if this is not enough of a worry for those who may be contemplating the customization of a MIPS core