Avici, Riverstone Pick Processors

COMMENTS

Newest First | Oldest First | Threaded View

<< < Page 3 / 6 > >>

RoutedWorld 12/4/2012 | 11:52:04 PM

re: Avici, Riverstone Pick Processors
OK, I love it when people bash NPUs (Programmable or otherwise) for lacking tool chains. I worked at a very large technology company that did many ASICs. All of them used tool chains from internal software groups that were extremely under staffed and under qualified. (BTW, I'm not bashing the tools groups, I'm bashing the company culture that doesn't understand the value of excellent tool chains). In this market I don't think much has changed with respect to these internal groups. When has Cisco or any other company bragged about the great tool chains supporting an ASIC? I can assure you that the developers I know don't think they have great tools.

In MMC's early NPU products they had very poor tool chains but even they have evolved.

I work with an NPU today that's easier to program and has better simulation and hardware debug support then the PowerPC controlling it. (It's NOT Intel based).

Perhaps you did not have the right level of software support involved as part of your NPU evaluation phase.

Reply | Post Message | MESSAGES LIST | START A BOARD

edgecore 12/4/2012 | 11:52:01 PM

re: Avici, Riverstone Pick Processors Drone, Capolite,

Remember that Seinfeld episode when Jerry tells George:

"Its not a lie, if you believe it..."

-------------------------------------------

Anyways, NPU's are a double edged sword, the more
programmable they get, the more features and functionality needs to be built into the SDK...which is provided to you by guess who...a silicon vendor....

Silicon vendors were not put on thid earth to become software companies..its really challenging fpr the Mot's and Intel's of the world to run these virtual sw companies inside their big silicon shops!

EC

Reply | Post Message | MESSAGES LIST | START A BOARD

Sisyphus 12/4/2012 | 11:51:58 PM

re: Avici, Riverstone Pick Processors
> .. Actually, it is the tyranny of wire speed
> that drives ASICs. ..

I agree, but that is quickly becoming past-tense as networking plateaus at 1 to 10G and Moorer's and Grosch's Law inexorably render the wire-speed argument obsolete.

Wire-speed used to be a core competency only a few ASIC teams could deliver on, but now it either has or definitely will become a lowest common denominator that provides no differentiation, and certainly doesn't justify burning tens of millions of $ of R&D on. Better spend that money where it'll truly count - on services and their support in support software.

Reply | Post Message | MESSAGES LIST | START A BOARD

Sisyphus 12/4/2012 | 11:51:58 PM

re: Avici, Riverstone Pick Processors > .. Silicon vendors were not put on thid earth
> to become software companies ..

You sell a processor, you better provide a good compiler. Just like good documentation, it is not a supporting product and part of the package.

It's like saying network system vendors were not meant to be support companies. Or heck, semiconductor companies with their ASIC practise.

Products are never just *one* thing - they're a package.

Reply | Post Message | MESSAGES LIST | START A BOARD

Ben Crosby 12/4/2012 | 11:51:54 PM

re: Avici, Riverstone Pick Processors Anyways, NPU's are a double edged sword, the more
programmable they get, the more features and functionality needs to be built into the SDK...which is provided to you by guess who...a silicon vendor....

--------

Very true. In my experience the NPU vendors like to upsell their tools, compatibility from one revision of the NPU family to the next, and various power issues in addition to the crown jewels of flexibility.

The reality is that even though the NPU vendors want to commoditize the datapath and have equipment vendors differentiate from each other in software - much as the PC market moved - it is going to take a long time for this to happen. The libraries and building blocks in the NPU tools are never good enough compared to an optimized solution, so much of the TTM advantage goes away.
Not only that, suppose that one did use the off-the-shelf forwarding code for example. Every router built upon VENDOR_1's NPU would have mostly the same forwarding characteristics, barring minor tweeks that the software team implemented....

I'm not convinced any NPU vendor has clearly demonstrated code portability between generations of their uP family... by this I mean compiled microcode running across multiple products. This is required to support - guess what - changing standards.

Power budgets for NPUs vs ASICs are interesting - I dont have a clear answer yet, though I will point out that most of the NPUs I have seen require more voltage rails than custom ASICs, meaning more power regulation, more heat, more components to fail.

As someone pointed out, the standards do evolve. This doesn't mean that you can't do everything in ASIC, it just means that your overall architecture needs to be able to cope with an alternative to the ASIC fast path - in fact something that nearly every vendor does today is offer a standard uP based slow-path for exception processing, and stuff they don't support in the ASIC. Perhaps the next step will be fast path ASIC, and slow path NPU ?

There are reasons for both devices. As with anything on this planet, there are pros and cons, which must be considered carefully....

Finally, please link me to one real NPU, available today capable of doing clear channel OC-192 at 40 byte packet size with classification, TM, large ACL processing, RPF etc... Now one that does 4 x OC-48 with all the above. Are they the same device ? At least our industry can do that in ASICs :)

What I find really interesting is that all these companies begin to talk about their silicon months after Cisco's analyst conference upsold the Cisco ASIC engineering team. Talk about reaction :)

Reply | Post Message | MESSAGES LIST | START A BOARD

multithreaded 12/4/2012 | 11:51:53 PM

re: Avici, Riverstone Pick Processors >I think the real issue with NPUs is that the >tools chain, libraries, and support for most >are awful. Most people doing the selection

Come on. NPU is not a toy CPU!! It consists of multiple cores, and each core normally supports multithreading. To program such a leading-edge system, the program entry barrier is definitelly much higher. There is no free meal in the world.

I have to say that programing NPU today is like programming a supercomputer. There is no easy way out since we have so limited understanding on a universal parallel programming model. Without such a good programming model it is very hard to develop a good compiler to parallelize the user code.

Reply | Post Message | MESSAGES LIST | START A BOARD

alchemy 12/4/2012 | 11:51:53 PM

re: Avici, Riverstone Pick Processors Finally, please link me to one real NPU, available today capable of doing clear channel OC-192 at 40 byte packet size with classification, TM, large ACL processing, RPF etc...

I saw a really spiffy PowerPoint presentation about that very part a couple of weeks ago. I can buy all I want in 2005. *grin*

Reply | Post Message | MESSAGES LIST | START A BOARD

edgecore 12/4/2012 | 11:51:53 PM

re: Avici, Riverstone Pick Processors
You sell a processor, you better provide a good compiler. Just like good documentation, it is not a supporting product and part of the package.
-----------------------

I agree with that statement...but only so far...a compiler developed by Intel or Mot may create leaner faster code...but these companies would prefer to not have to do that...they wish that the Green Hills, Diab (RIP) and Metaware's (RIP) of the world could do that and integarte it into the rest of their tool chain (debuggers, runtime performance tools, memory leak tools).

But compilers sold standalone are not in the same league as the tremendous complexities involved in developing dev tools, target OS specific tools and all the microcode to make these NPU's come close to what the Cisco, NT and the rest have come to expect.

Being fairly stupid, I see things this way...how is a company like Intel and Mot set up to do validation, QA and regression testing on multiple OS'es (Linux, Vx, QNX, OSE...)..all these OS'es have different tools chains and different architectures..so you need some serious sw talent!

The scariest thing wouold be for Motorola and Intel to both have 100 design wins each at Cisco, NT, Nokia, Alcatel, Ericsson...etc...etc...the NPU SDK's (called workbenchs) are free (once you pay 20K for the HW...plus youi need to support these new huge customers...are Intel and Motorola able to charge for this support...plus keep hiring the 500 people required to support it...then one customer wants to stay on Vx 5.3, the other on Linux 2.5a, the other on Vx 5.4c..blahblahblah...

The sw makes these puppies useful, but again, its a tremendous undertaking...that was my long and boring point!

Cheers

EC

Reply | Post Message | MESSAGES LIST | START A BOARD

multithreaded 12/4/2012 | 11:51:52 PM

re: Avici, Riverstone Pick Processors First, if one writes his code in micro-code (assembly), I don't think there is too much portablility between different generations.
I agree with you that NPU vendors did not do the good job here.

Second, edcucating users on how to program a NPU is really a challenging task and no NPU vendors are good at it. I guess almost none of NPU vendors have supercomputing background. This may be one of the reasons that NPU vendors don't know (at least are not well prerpared) to teach the end users on how to program a NPU efficiently.

Third, if the end user really understands the following NPU programming techniques:

-- Multi-processor based task partitioning
-- Multithreading based latency hiding
-- Concurrent threads synchronization

They can difference their products significantly from their competitors. For example, there are two-memory-access, three-memory-access, and four-memory-access based table lookup methods. Depending on the memory budget, the user can choose the one that best suits his own needs.

Fourth power consumption is a problem for NPU since any CPU based system cannot compete with ASIC in terms of power. That is why Intel/2800 needs about 30W :(

Fifth, if external TCAMs or CAMs are allowed I don't there is any problem to build a OC-192 routers using a NPU. Could you please give an example that ASIC based OC-192 routers that do't use TCAM for table lookup and classification?

Reply | Post Message | MESSAGES LIST | START A BOARD

multithreaded 12/4/2012 | 11:51:52 PM

re: Avici, Riverstone Pick Processors >You sell a processor, you better provide a good compiler. Just like good documentation, it is not a supporting product and part of the package.

I could not agree with you any more :-)

However the challenge is developing a NPU compiler is not as the same easy as porting a GNU C compiler. NPU requires a PARALLEL programming model and we don't have good one for the moment.

Reply | Post Message | MESSAGES LIST | START A BOARD

<< < Page 3 / 6 > >>