Porting Legacy Code to Net Processor Designs

Porting Legacy Code to Net Processor Designs
By Brian Ramsey, CommsDesign.com
March 12, 2002 (6:46 p.m. EST)
URL: http://www.eetimes.com/story/OEG20020307S0046

The new generation of network processors (NPU) present a wealth of advanced functionality to be employed in switch, router, and other networking designs. But still, as in every embedded design, minimizing time-to-market is of paramount importance. To address this need, software design frameworks have been built and commercialized to assist OEMs in developing NPU-based applications.

But the issue facing developers is not limited to generating new code. They must also find a way to reuse code from previous designs. For years, OEMs have built up libraries of code in their ASIC architectures. Now, they want to port this code to new network processing architectures, and this need must be addressed in the time-to-market solutions.

One solution to this problem is to manually integrate legacy code into the distributed network processing architecture. This approach, however, involves time-consuming hand tweaks to the legacy code, which is not an attract ive option under today's time-to-market conditions.

Another option is to turn to third-party software design tools and evaluate their ability to import legacy code into the new applications. Evaluating these tools, however, can be challenging. Each tool is equipped with its own feature sets, thus choosing the right product can be a daunting task. Here's a guide that will help in that selection process.

What to Look Out For
When beginning the design of complex, high performance network equipment, the integration of several of the following types of pre-existing legacy applications may be necessary:

Protocol stacks

Routing packages from an ISV, or the open-source community

Libraries of frequently used functions

User-defined, "standard" functions
System provided libraries (language and OS specific)

Management agents

Applications

Co-processors

Here are 4 tips on how to avoid the pitf alls of integration.

1. Reuse what you know
Integrating the OS or third-party protocol and routing stack immediately benefits the development schedule and system reliability. These stacks are usually "tried and tested" over years of multivendor network equipment designs. Every effort should be made to reuse existing stacks and routing protocol packages to ensure interoperability and reduce the magnitude of overall design effort.

Functionally, these high-performance routing suites (including OSPF, BGP and RIP protocols) integrate with the control plane for management of connections, interfaces, route updates, exceptions and statistics.

2. Go to your library for resources
In the context of reusing existing software, the term "library" is used to describe a collection of defined API functions, a collection of programming language macros, or specific OS service calls. In general, library functions and macros can be used to define the behavior of any component by entering the app ropriate calls as user-defined actions.

Macro libraries are reusable software functions optimized for a specific platform (language and processor) that simplify programming, promote reuse, and as a result eliminate a number of those "nagging" typographical coding errors. Macro and structured actions for the forwarding plane are further optimized for both 'control store' instruction size and for performance.

When microcode for each thread of the processing elements (PE) is written as structured code (including the macro calls) it is easier to use and maintain, looking much like a higher level language such as 'C'--without performance penalties. A macro call, for instance a CRC32 computation or a packet I/O operation, may execute as a set of software instructions on one generation of a net processors, and employ a built-in hardware function on another generation.

Macros and structured actions facilitate:

Portable and reusable software
Faster and more compact code developmen t
Programs that are easy to read and understand
High performance, optimized standard functions
Support across generations of the same functionality

Network equipment manufacturers may already have predefined libraries of common network, operational, or administrative functions that are "standard" across products, or families of products. The ability to reuse these function libraries shortens development time, improves interoperability and simplifies software quality assurance (SQA) and test.

The programming languages appropriate for each of the planes may have their own macro libraries. A developer's own legacy control applications may also make use of compatible control plane libraries. Such software can support both data and control plane reuse of library functions.

3. Don't forget third-party tool integration
A critical productivity requirement is seamless integration of development tools with the diverse multi-vendor tools often required in pr oduct development. Any software platform used for integration or development should integrate with RTOS/Windows/Linux integrated development environments (IDEs), languages, compilers, and all other popular tools.

Beyond the integration of these code development and debug tools, tool integration includes the network processor simulator, microcode libraries, and software and hardware debugging aids. Simulation, testing and debugging tools allow the verification of application logic and improve the performance and quality of a system by running the application interactively. Test cases can be built and run, and execution can be controlled through logic-level breakpoints and step-by-step debugging and state inspection. These tools may include the ability to 'integrate' Verilog software models of fabric, media or coprocessor devices.

4. Develop a message wrapper
Problems may occur if a legacy application's interface is not well defined or robust enough to integrate with a communications "wra pper."

The first function of a wrapper is to support the receipt and return of messages through any communications mechanism (communication layer). The second function of this wrapper is to interpret the message requests, invoking the appropriate operations upon the legacy application, and conversely formatting outgoing requests and responses as messages (service layer). A good wrapper implementation creates a communications adapter that provides a consistent message interface to the application and facilitates its integration and reuse.

Good, solid communications wrappers are quickly produced within such a software platform specifically to avoid messaging meltdowns in network processors.

Application Development--The Basics
There are several factors to consider in the initial stages of network processor application development. An application must make full use of the multiple processors and split processing planes of the network processor. Processing should be segmented between the co ntrol plane and the forwarding plane. Additionally, in the forwarding plane, the code needs to be further segmented and loaded across the multiple processing elements (PEs), which are typically provided in the net processor design.

The application must also allow the multiple distributed processors to share data and work together as a cohesive system. This requires an application development framework that can seamlessly integrate legacy applications while easily facilitating the development of the new application logic required by the system design. Reuse, of course, will be mandatory during the application development process.

Choosing Your Tool
Quite a few design tools have popped up recently for building applications for net processor designs. Basically, what some third-party developers have been promoting is a development platform that allows new logic to share data with existing applications and libraries. These proposed platforms integrate diverse network applications with full lan guage, net processor platform, and control plane independence.

When choosing an application development platform, designers should look for tools that provide easy-to-understand mechanisms for integrating legacy applications and software, and well-structured applications often require no, or minimal, code changes to interact with newly developed system logic.

In order to integrate legacy code, legacy applications must be prepped for integration. Specifically:

The application must be made capable of supporting a consistent "messaging interface" through one or more "communications mechanisms."
For performance and concurrency, legacy applications may not block on asynchronous message and memory accesses. As a result, it will sometimes be necessary to insert a middle-layer program that converts the blocking legacy calls to non-blocking calls. This is a simple process, usually requiring only a couple dozen lines of code.

The term "messaging interface" describes consi stent, structured messages that software components (legacy or new) may send or receive, regardless of the communications used and the location of the sender or receiver. The term "communications mechanisms" refers to the inter-application level protocols (events, alerts, queues, and mutual exclusion primitives), hardware-specific interfaces (shared memory, data-link drivers, PCI bus, queues or mailboxes), and networking protocols (TCP/IP and UDP).

When choosing a net processing development platform, designers should look for development environments that integrate and automate these mechanisms. By integrating/automating these functions, the tools can develop apps that are extensible to new applications and protected from obsolescence. Additionally, the tool will allow the application's system logic to be immediately reusable while new functional requirements can be defined and implemented with minimal effort.

Leveraging the Platform In order to leverage processor resources, designers need a platform that is designed for the intricacies of forwarding path, control path, and management path processing on network processors and other CPUs in network equipment. To do this, the applications development platform should provide a parallel and distributed software execution environment that includes a multiprocessor runtime environment that ensures correct and consistent execution of other state machine components and "legacy" components that are distributed on various processing resources and accessing data structures placed in shared and distributed memory banks.

The development environment should also facilitate the development of appropriately granular network logic. This enables design engineers to develop network processor software with:

Logical components are described as "state machine defined behavior."
The data structure of the components is efficient, extensible, and portable.
Logic segmentation and loading changes for optimization and performance tuning ar e easily accomplished and self-documented.
The generated application automatically includes multiprocessor scheduling of the state machine contexts through a structured messaging interface.

In addition, the software platform must also deliver all of the tools and capabilities needed for advanced application development. These include:

System architecture tools that define the hardware characteristics and communication interfaces.
Application logic development facilities define the system logic and logic dependencies.
Facilities using the method of "dragging and dropping" load the application logic on the individual processing resources defined by the system architecture. The mapping of logic and hardware design only intersects at this phase of application development, and can be modified to optimize and test other combinations of software distribution and loading.
Mapping and code-generation tools that enable engineers to map application logic t o the logical system architecture, and then to map this logical design to the physical platform. Based upon this mapping, the code generator produces optimized code for the entire application (C/C++ and microcode) to target the application programming interfaces supported on the physical platform. The explicit behavior defined by the state machines is used by the code generator to produce efficient code for distributed applications. This generated code is integrated with the runtime that would be highly optimized for the target processor, or processing element.
Simulation, testing and debugging tools that allow the verification of application logic and improve the performance and quality of a system by running the application interactively. Test cases can be built and run, and execution can be controlled through logic-level breakpoints and step-by-step debugging and state inspection. These tools are directly integrated with the network processor simulator, microcode libraries and hardware debugging aids, which are provided by the network processor vendor.

The platform should also include a framework of extensible system and network building blocks for hardware management, data manipulation, forwarding and lookup that can be reused, extended and combined in different ways. With these capabilities, the platform would allow the development of network processor applications that deliver flexible network services at wire speeds and optimize the high performance multiprocessor architecture of today's network processors.

A Good GUI Saves Time
While much of our attention focused on the technologies an application development should provide, usability should also not be forgotten. Even if a design tool provides the optimal performance capabilities, it is useless unless a strong user interface is provided.

In terms of network processing, the software platform should include a thin runtime element that integrates the control and data plane with some kind of graphical design envir onment. By doing this, the tool can deliver an integrated distributed processing capability that substantially reduces the development schedule of a new project. Specifically, the GUI can simplify segmenting and distributing of logic between the control plane and the multiple processing elements in the forwarding plane, ensuring maximum system performance while reducing the risk of development delays.

Brian Ramsey is director of product management at Teja Technologies Inc. Prior to joining Teja, he worked for a variety of network processor, real-time and networking firms, including XaQti (now Vitesse), LynuxWorks, ISI (now WindRiver), Stratacom (Cisco), and Novell. Brian can be reached at bramsey@teja.com.