SAN MATEO, Calif. It promises to be a longstanding debate among network processor vendors: How much programming do customers want to do?
The question is particularly urgent for Intel Corp., which chose a "fully programmable" architecture with plenty of space for users to add their own software but one that turned out to be difficult to program. To validate its choice, Intel was going to need help.
That will arrive in September, when startups Teja Technologies Inc. and Consystant Design Technology Inc. unveil software tools targeted solely at Intel's upcoming IXP2800 and IXP2400 network processors. The software launches give Intel a chance to wave the flag for its chips, but also serve as a reminder that Intel needs this kind of support to begin with.
The upcoming software tools are "indicative of the complexity of programming the Intel part," said Bob Wheeler, senior analyst with research firm The Linley Group (Mountain View, Calif.). "It's a trade-off. Intel's parts can be used across a wide range of applications. Parts that are more hardwired, like AMCC's, are focused on a more-narrow range."
Whether the IXPs' flexibility triumphs will depend on whether Intel can recruit enough help using tactics such as venture funding supplied to both Teja and Consystant as well as the unpredictable tastes of future network processor consumers.
The still-unreleased IXP2800 and IXP2400 follow in the footsteps of Intel's IXP1200 by relying on a bevy of RISC-based microengines to handle packet processing. These microengines are blank slates, waiting for chalk marks in the form of microcode.
But programming them becomes a monster of a multiprocessing problem. "In the IXP1200, people spent months just trying to move packets back and forth, let alone do their application," said David Stepner, chief executive officer of Teja Technologies (San Jose, Calif.).
Determined to avoid similar hang-ups with the IXP2800 and IXP2400, Intel created its Portability Framework, which includes libraries of code for certain basic functions. The code isn't perfected or battle-hardened that's where Teja and Consystant come in, providing Intel's customers with tools to help hammer the code into something customized and robust.
Programmability is at the heart of Intel's goal for net processors: to provide a single part usable across a range of systems, giving OEMs space to adapt to new standards or to change a system's size to fit the market's whims. Not surprisingly, the strategy smacks of the company's regular microprocessor business, where a particular CPU can fit a variety of boxes. Likewise, Intel's recruitment of third-party tools vendors reflects what it's done before. "You see that happening around very successful processor architectures," said Johnathan Corgan, product-marketing manager for software at Intel Corp. "Network processors are no different."
Corgan said Intel's architecture choice stems from a belief that OEMs will prefer the malleability of software to the rigidity of hardware, given the complexity of higher-end systems today.
"Based on our analysis, having a software approach is the only way to scale to the next generation," he said. "If you have to approach each fourfold increase in speed from OC-48 [2.5 Gbits/second] to OC-192 [10 Gbits/s], say with a new architecture, it's not cost-effective."
Regardless of the type of system being built, some customers already appear hooked on the programmability of the IXP chips, said Mark Stair, application architect for Consystant Design (Kirkland, Wash.).
"I've talked to some tier-one customers that really believe Intel's model is the right one," Stair said. "Really, the whole reason you're selecting a network processor is to give you the flexibility to program it the way you want. Every time you hard-code something, you're taking away more of the flexibility."
But for many customers, usability is more important than flexibility, according to vendors such as Applied Micro Circuits Corp. (AMCC) that tout their chips as more hardwired and easier to program than Intel's. Even Motorola Inc.'s C-Port unit claims easier programmability than Intel's parts, even though both use the approach of fortifying the network processor with multiple RISC microengines.
"We started the architecture with this idea of building a machine that implements a C-based programming model supported by a set of APIs [application programming interfaces] that perform common networking tasks," said Bob Gohn, vice president of marketing for C-Port (North Andover, Mass.). Entire functions such as buffer management are handled through a simple call to the proper API. "By virtue of that implementation, the tools you need are simpler," Gohn said.
Less need for support
It's also meant that vendors such as Motorola haven't needed the kind of outside support that Intel has. Teja came calling, but Motorola couldn't find a need for its tools, Gohn said. "Other than a user-interface difference, there wasn't any advantage."
Likewise, AMCC director of marketing Robin Melnick has turned away potential software partners, finding in-house tools to be sufficient. One software vendor, which Melnick wouldn't name, had scored an alliance with Intel and was looking to do the same with AMCC, but found there was no work to be done. "The problem they had set out to solve was one we didn't have," Melnick said.
That could be a crucial point, because the futures of Consystant, Teja and other software vendors could ride not on their support for Intel, but on their ability to find other network processor allies. And "if such tools are truly necessary, the silicon vendor has to bring them in-house," Melnick said. "You've seen it in the DSP community. When there were deficiencies, up would sprout somebody to fill in the hole. Eventually, the vendor would buy it, or it would go away. In the network processor market it's the same thing there are holes to fill."
Would Intel consider hardwiring a few functions? The answer is yes, Corgan said. Time will point out certain functions required of every net processor in almost every system and those will be obvious targets for hardwiring, he said. Where Intel differs from Motorola, though, is in the level of function that gets hardwired. "On those [C-Port] devices, I see larger functional units hard-coded than what I'm talking about," Corgan said.