At the core of the Internet and World Wide Web, down at the packet-passing level in the routers and switches and myriad edge devices that link the end clients to the internetwork cloud, a knock-down, no-holds-barred battle is under way. This revolution is as profound, tumultuous and confusing as the transition from hardwired logic to microprocessors, or the RISC vs. CISC wars that followed it.
Still up for grabs is who will win the fight for market and mind share, traditional RISC designs or new, highly parallelized data flow engines.
As with previous architectural transitions, this one raises the issue of development tools, languages and OSes: How quickly should the transition be made to a higher-level language methodology? And what language should it be? Should we stick with traditional sequential programming or shift to parallel languages and tools? What about operating systems: Should they be eliminated, enhanced, changed?
It takes a modular approach to address the problem of fast, efficient C-language programming typical of general-purpose CPUs without giving up the targeted performance achievable with microcode written in the machine language of the processor, Larry Huston, principal architect at Intel Corp.'s Network Processor Division, said. In his article in this week's Focus section, Huston describes the modular programming methodology that Intel has developed, called ACE.
“One problem all designers face in multiprocessor networking designs is how to partition the application across the multiple processors,” Huston said. “This [ACE] approach provides a low-overhead framework within which to partition the design, as well as a number of predefined building blocks to reduce design time.”
In the view of Brian Ramsey, director of product management and strategy for Teja Technologies Inc., the advent of the kind of high-level development tool environments now familiar in the the embedded market generally occurs only when standards and dominant architectures begin to emerge. “The network processor environment is very much like the early microprocessor market in which there were no clear leaders, no agreement on design tools, no common language environment-indeed no agreement on the general architectural approach to take to the problem set that was emerging,” he said. The graphical state machine methodology that Ramsey describes in his report here is an attempt to provide a top-down, system-level unifying mechanism to speed up program development in such a diverse processor environment.
Just as important in network processor design as it is in traditional embedded designs is the choice of operating system, said Curtis A. Schwaderer, director of network technologies at Microware Systems Corp. Developers will face a choice between OS kernels built around traditional task-oriented, threads-based paradigms and shifting to one more appropriate to the needs of the network market, based on an event-driven process model.
“But on the software side we have nothing that is worth writing home about,” Schwaderer said. “Software development cycles are not being accelerated.” Indeed, he said, over the past 10 years traditional threads-based kernels “have not evolved to accommodate these rapid silicon changes.”
As a result, “Many popular RTOSes are fundamentally flawed for communications applications,” he said. “Communications software frameworks are absolutely vital in order to take advantage of network processors, yet few vendors provide this kind of software integration.”
Companies that attempt to apply current software solutions to network processor technology, said Schwaderer, are destined to fail.