Hybrid programming best for CPE net processor designs

Developers of broadband customer premises equipment (CPE) applications face the challenge of balancing a set of conflicting requirements: performance, value-added features, product cost, time to market and processor headroom for future growth. To resolve this conflict and satisfy each requirement, developers are moving from traditional single-purpose ASICs to programmable network processors. This approach presents another dilemma: how to choose a flexible software development model.

In a hybrid architecture, such as the IXP425, which was developed for CPE applications at the network edge , the best approach is to use a software development model that provides a set of strongly typed C-language application program interfaces (APIs) that allow developers to easily access and use network protocol hardware accelerators, which include performance optimizations. Using this model, the developer can now concentrate on developing value-added features by leveraging both the existing hard-wired functionality and the RISC processor.

Moving from ASIC processors to flexible network processors requires a balance between hardware and software functionality. In the CPE environment, this is no different and often requires a network processor architecture that incorporates a hybrid design with a combination of hard-wired accelerators and a standard RISC core.

The major I/O interfaces are connected directly to several network processing engines (NPEs) that perform commonly used, computation-intensive networking protocols using various hard-wired accelerators. Each NPE includes several accelerators that group related functionalities. For example, one NPE includes Utopia 2 and ATM Adaptation Layer segmentation and reassembly (SAR) accelerators.

In such an architecture, the general-purpose programmable core handles higher-layer and developer's value-added networking features. When properly balanced, a hybrid processor solution solves the hardware paradox by providing both performance and flexibility. This silicon architecture works together with the software development model to meet the requirements for broadband applications. But this requires a software development model that provides a mechanism that supports the NPE interfacing and must be capable of managing the development of applications that use both hard-wired accelerators and a flexible core processor.

The firmware running in each NPE coordinates the operations of accelerators to provide coherent I/O and protocol handling services to upper layers. The software development platform provides a set of APIs for upper-layer stacks and applications to access these services. This strongly typed C-language API set has a number of important advantages for the software developer. The strongly typed interface provides compile-time, rather than run-time, indicators of incorrect parameters passed to the NPEs. This makes the development cycle more efficient. Also, the API set insulates the developer from underlying silicon changes including future enhanced variants of the processor family.

Task distribution

CPE applications, such as a residential gateway, can leverage this software development model to enable the distribution of tasks among NPEs and the core processor. This software development model combined with the silicon NPEs enables a developer of a residential gateway to create wire-speed — no bottleneck for 64-byte packets — applications by offloading tasks onto hard-wired integrated accelerators to avoid taxing the core processor. This allows for plenty of core "headroom" to handle the higher-layer and developer's value-added networking features and provides for future upgrades.

Using this software development model, let's step through the creation of a residential gateway, highlighting a few key points:

• Select a network processor with a supporting software development model. A "hybrid" network processor will enable a software developer to concentrate on the application stack development and reuse the factory-programmed NPEs to perform commonly used, computation-intensive networking protocols, such as cyclic redundancy check, ATM SAR, High-level Data Link Control, encryption, and address learning and searching
• Create the board support package, including drivers. A residential gateway hardware platform that includes a network processor, a board support package and driver set can be built using preprogrammed NPEs. C-language APIs provide the access to the NPEs. This API layer is used to tie and offload functionality onto the accelerators within the NPEs.
• Use reference platforms and create the application stack. Reference platforms can be used as templates for both hardware and software. For example, reference platforms are available for multiple operating systems, each containing a software package that includes an NPE enabled driver set, a board-support package, and an integrated optimized tool chain. Hardware reference platforms also provide an instant development environment. To get a jumpstart, developers can use a reference platform to port, test, optimize and debug specific software stacks of a product in parallel with their manufacturing process.
• Transfer silicon functionality into the core to reduce BOM cost. Use the core processor to perform voice digital signal processor functionality, thereby reducing the overall BOM. For example, the residential gateway may require support for two voice-over-IP channels which means it can take advantage of DSP software-based voice CODECS to eliminate the need for a DSP, offloading the calculations onto the core.
• Increase performance by offloading CPU intensive features, such as VPN encryption. By leveraging the software development model NPE API set, the developer can offload computational tasks for VPN encryption and authentication to the embedded hard-wired accelerators. For instance, the software developer can use the API set to offload 3DES encryption and MD5 authentication to the NPE, thereby not taxing the core processor.

See related chart