 designer must ensure that very few computing cycles are wasted. Some software pertains to deciding what operations need to be performed on traf- fic packets, whereas other software deals with actually performing specific operations on the traffic packets. If the programmer is required to have an intimate knowledge of the underlying NPU hardware architecture in order to set the functional module allocation and the performance optimization of the engines, then both of the following statements are true: This is very tedious work that few people can properly perform and that cannot be done on some platforms. This task makes the developed software completely dependent on the underlying architecture. Perfectly and deterministically mapping the actual software on the available computing resources is not easy. In fact, it is only on rare occasions that it is possible. Therefore, it is not a discipline that we can expect to apply across the board. Most network processors are based on a single-image pro- gramming model, which completely shields the programmer from hardware intricacies and details. This convenience results in immediate inefficiency as instruction cycles will be wasted at some point sooner or later. Typically, this implies that all processing engines within network processors execute the same code on various packets. Some pipelined designs offer several packet engines at each stage. A designer can have the convenience of different pieces of code running on different packets at the same time. This might bring up the subject of packet allocation to various computing resources. It is generally not desirable to extend this granularity of program allocation to the average software engi- neer for many reasons. Some applications might negate efficiency choices imposed by other programs. At the same time, some code must change as applications and protocols are upgraded. Reallocating the executable software modules usually becomes a continuous nightmare and a moving target. The problem is even further compounded whe