x
Comms chips

Intel Isn't Through With NPUs

has been all but invisible in the high-end network processor market lately, but that doesn't mean the company has dropped out.

Rumors began to spread after Intel's January reorganization under new CEO Paul Otellini. The communications product lines ended up inside the Digital Enterprise Group, a move that gave them less prominence to outside viewers. Many took it as a sign that Intel was giving up on network processors or at least dropping development of the high-end parts, particularly the IXP2800.

That device isn't dead; it's just that the chip's OC192 target market moves slowly, Intel says.

"The gestation period for these designs has been longer than we expected, but they're starting to move into production," says Doug Davis, an Intel vice president and the general manager of its Communication Infrastructure Group.

In the meantime, most of the OC192 network processor buzz is going to startups EZchip Technologies and Xelerated Inc., each of which picked up additional funding this year (see EZchip Nets $10M Extension and Net Processors Bloom at 10-Gig).

Most of the activity in network processors, also called network processing units (NPUs), has come from access equipment -- the sole market for startup Wintegra Inc. and a renewed center of focus for established companies like Agere Systems Inc. (NYSE: AGR.A) and Applied Micro Circuits Corp. (AMCC) (Nasdaq: AMCC). Intel, too, seems to have focused most of its energy on access products, as opposed to the core routers that network processors originally targeted.

"Intel and AMCC are studiously ignoring that high-end market and letting EZchip run away with it," says Linley Gwennap, principal analyst with The Linley Group. "If Intel comes out with an incredible product, EZchip would clearly be the big loser. The interesting question is how big the high end is."

So far, it's a small fraction of a small market. Linley Group forecasts from December put the network processor market at a likely $150 million in 2005. Weak prospects and expensive product development prompted big players such as Freescale Semiconductor Inc. (NYSE: FSL) and Vitesse Semiconductor Corp. (Nasdaq: VTSS) to back out of high-end network processors (see Cingular Trials Lucent UMTS).

Intel says it has no particular fear of the network processor startups, claiming the IXP line is far more programmable than the other OC192 network processors available. Rivals have countered by noting the IXPs are difficult to program, particularly when it comes to dividing tasks among the multiple mini-processors inside each chip.

Intel hasn't stopped design work on its high-end network processors, Davis says, although most of the work is on incremental changes. A low-power version of the IXP2800 is nearly ready for production qualification, for example. But the next dramatic step, to 40-Gbit/s devices, won't be happening for a while.

Customers say they want 40-Gbit/s network processors, but the volumes aren't enough to justify building such things. "We ask: So, you need, what, 100,000? They say: somewhere between tens and hundreds a year," Davis says.

Intel combines its network processor revenues with those of other processors, so it's difficult to tell how well the product line is doing. While hinting that network processors continue to lose money, Davis insists Intel isn't content to let them stay that way. "We're not going to stay in any business that's not profitable."

— Craig Matsumoto, Senior Editor, Light Reading

Page 1 / 2   >   >>
edgecore 12/5/2012 | 3:03:46 AM
re: Intel Isn't Through With NPUs
Good read, a little disappointed that the article does not dive into the issue of writting the actual programmable code that will run on the micro engines on these NPU's.

I am not talking about what OS'es will Intel support onm the control plane 32 bit processor, we can guess that they will suport Generic Linux, PNE-LE and VxWorks.

What is a killer for the OEM's are the micro apps that run on all these micro engines (that are supposed to be the root of thevalue proposition of NPU's). Does Intel write these all themselves and charge NRE for them? Do we know if there a productive toolkit that OEM's can use..even better, is there an ecosystem of micro apps companies building to complement the Tejas and Radisys of the Intel world.

Can anyone help shed some light?

Thanks

EC
Pete Baldwin 12/5/2012 | 3:03:46 AM
re: Intel Isn't Through With NPUs The question around Intel's network processors hasn't changed in years: Will they make any money here?

They obviously think so, but there's been a lot of cash pumped into these puppies, particularly when you add the programming support they've offered customers ...

Interesting how the business has become access-heavy, versus high-end core devices. I'd guess access NPUs could become profitable on their own, but it's going to take a while to recoup what they put into the high-end parts.
sigint 12/5/2012 | 3:03:45 AM
re: Intel Isn't Through With NPUs What is a killer for the OEM's are the micro apps that run on all these micro engines (that are supposed to be the root of thevalue proposition of NPU's). Does Intel write these all themselves and charge NRE for them? Do we know if there a productive toolkit that OEM's can use..even better, is there an ecosystem of micro apps companies building to complement the Tejas and Radisys of the Intel world.
________________________________________________

The basic code is handed out gratis to customers. Productivity tools come from another company - Teja Networks (not to be confused with "Tejas Networks"), which have to be purchased. I think Intel had propper up Tejas through their VC arm, Intel Capital.
pkallur 12/5/2012 | 3:03:45 AM
re: Intel Isn't Through With NPUs As I know of, Intel only provides some sample code designs for basic functionality. It also has services capabilities for major TIER 1 OEM's. In addition, there are a few companies out there who do this as a business and offer dev. environments as well as microcode solutions for apps. Can provide specific info. offline.

What is a killer for the OEM's are the micro apps that run on all these micro engines (that are supposed to be the root of thevalue proposition of NPU's). Does Intel write these all themselves and charge NRE for them? Do we know if there a productive toolkit that OEM's can use..even better, is there an ecosystem of micro apps companies building to complement the Tejas and Radisys of the Intel world.

Can anyone help shed some light?
turing 12/5/2012 | 3:03:44 AM
re: Intel Isn't Through With NPUs As the other guys said Intel doesn't offer much in terms of actual usable functional code to really do anything interesting, and what they do isn't performance optimal from what i hear. So you need to rewrite it to be efficient on the IXP. Same thing's prob true of most NP vendors. But there are 3rd party companies to help for most of them.

The funny thing is that writing the NP code essentially becomes an investment and locks you into their NP (or any vendor you choose). So maybe Intel sees that and thinks fighting for the market now at a loss will pay off in the long run.
turing 12/5/2012 | 3:03:44 AM
re: Intel Isn't Through With NPUs Moving to the access or lower-end makes a lot of sense. Lets face it, the core router world is dominated by 2 companies, and they use mostly home-grown ASICs for that. There may be some technical reasons for that, but really i think it was more a matter of timing (they had 192c ASICs before NPs, so why reinvent the wheel), and also when you're selling a core router the last thing you want the customer to think is "commodity item".


But for smaller boxes that need more than CPU-based performance and more intelligence than L2/L3 off-shelf chips, an NP is very attractive. Possibly higher volume pricing, but also a lot less NRE and risk than ASICs.
Pete Baldwin 12/5/2012 | 3:03:42 AM
re: Intel Isn't Through With NPUs The funny thing is that writing the NP code essentially becomes an investment and locks you into their NP (or any vendor you choose). So maybe Intel sees that and thinks fighting for the market now at a loss will pay off in the long run.

Thanks turing, excellent points. I wonder if that "lock-in" factor contributes to the long development cycle behind NPUs -- do OEMs have the manpower to try programming more than one, to see which one works out best?

Chip vendors are definitely trying to use ease of programming (or configuring) as a selling point. Everybody tells you they've got a simpler model than Intel -- Agere in particular will talk your ear off about it.

As mentioned before, you've got third-party vendors offering Intel code, either pre-packaged or custom; Intel is counting on the buildup of that "ecosystem" to solidify its NPU audience.
spelurker 12/5/2012 | 3:03:42 AM
re: Intel Isn't Through With NPUs > Intel doesn't offer much in terms of actual usable functional
> code to really do anything interesting, and what they do isn't
> performance optimal from what i hear. So you need to rewrite it
> to be efficient on the IXP. Same thing's prob true of most NP
> vendors.

The Intel NPs are among the worst as far as performance because they rely so much on microcode. The upside of this is flexibility for complex feature enhancements, making it most appropriate for access boxes.

> writing the NP code essentially becomes an investment and
> locks you into their NP (or any vendor you choose).
This is true, since it is both a skill-set which must be developed within your development organization and a base of software which is easier to augment than to replace.

There is another reason why the high-performance applications do not use NPs -- performance limits. A 10Gb/s forwarder is less useful when you want to create a board with 8 OC192/10GbE ports - plunking down 8 NPs complete with independent bosses and memory systems is costly and takes up lots of room. A home grown system can share more components, alleviating both/either issue. NPs have always been a generation behind the raw performance needs of the high end.
simpleton 12/5/2012 | 3:03:41 AM
re: Intel Isn't Through With NPUs I think the Intel IXPs are pretty good with a great development suite - simulator, compiler, debugger, performance analysis tool. The C-Compiler for ME is pretty good. The best part is that all this is free.

Quite frankly I don't see the market for IXP2800s in packet pushers (core routers etc.). Like the other poster, I see its advantage in packet analyzers and modifiers as in the edge with lots of features that can be cranked out quickly. I think the key issue here is cost. The IXP2800 is expensive for the cheap, and unfortunately, w/o the volume, Intel can't make it cheap.

I like the multiple MEs with multi-threaded code. What is sort screwy is the XScale processor w/o protected memory capabilty due to it sharing the same dram & sram bus with the MEs (cache coherency problem). Because of this short coming, the XScale can't be used seriously as a Control Processor w/o undermining the ME performance. They really ought to give the XScale its own high performance memory bus and add in the memory protection bits in their otherwise complete VM Controller.

As far as getting locked into the NP programming model, I see a parity with DSPs - only two left standing (TI & Analog Devices). Like the DSP programmers, I welcome that. I can make some money consulting ;-)

Regards,

Simple
Sisyphus 12/5/2012 | 3:03:34 AM
re: Intel Isn't Through With NPUs > Interesting how the business has become access-
> heavy, versus high-end core devices

Well, 10G is not just required in the core. The simple traditional perception of access = slow, core = fast is not quite as accurate anymore, networks are getting flatter in that respect. 1GE is everywhere in the Enterprise and Campus. And 10GE, while present mostly just in the high end datacenter these days, could become quite widespread in a variety of applications, even when it's via 1GE aggregation alone. Provided performance and cost-per-port meet market needs...
Page 1 / 2   >   >>
HOME
Sign In
SEARCH
CLOSE
MORE
CLOSE