Recently, one of those very restrained press releases – in this case, Mentor Graphics and Imagination Technologiesextending their partnership for MIPS software support– crossed my desk with about 10% of the story. The 90% of this story I want to focus on is why Mentor is putting energy into this partnership
For background on where MIPS has been, you may want to check out my piece The Re-Imagination of MIPS written when the acquisition first surfaced. The results are just starting to show, and one is clear: Imagination has quietly tucked their Meta processor core under the rug, going all in on MIPS cores. At an analyst conference at Stanford University, Imagination CEO Hossein Yassaie proclaimed: “There should always be Pepsi wherever there is Coke.” MIPS may be more like Dr. Pepper, an alternative for a non-zero sum game.
I had the chance recently to sit down with Mark Mitchell, general manager for open source embedded solutions at Mentor Graphics, to explain the Mentor teaming with MIPS. What follows is connecting dots from his comments and more I see going on.
With due respect to my SemiWiki colleagues, Mentor is far from new at this embedded software game. The Mentor Graphics Sourcery Tools are widely respected across the industry for C/C++ software development, debug, and optimization. One of Mark’s advantages is Mentor, at least to date, doesn’t have a captive core architecture and the resulting IP conflicts. That makes partnering with the prominent core ecosystems – including ARM, ColdFire, Intel, MIPS, and Power – much cleaner for Mentor and its OEM cusotmers.
Mark opened with the thought that people still think that the world is all ARM or Intel. It’s kind of like that poster, where Cambridge and Santa Clara take up half the world map with a few other dots like Chandler. He sees a significant space for special purpose processors, designed for performance and power efficiency in certain roles.
For instance, network processing units with thousands of cores and funny caches and specialized interconnects and look up tables. Mentor customers like Broadcom and Cavium feature MIPS cores in these NPU platforms, which are about to take on an even larger role on the Internet of Things.
A potentially huge development is the Cisco nPower X1. My observation, no inside info from Mark or anyone else: Any bets as to the core inside? We’ll find out Tuesday when Cisco reveals details, but … they are a MIPS customer.
Speaking of the dot on the map in Chandler, it is one of the MIPS outposts: Microchip Technology has the PIC32 family with the MIPS M4K core inside. Renesas also has a MIPS MCU family. When I asked Mark about this, he said generally Mentor is after higher end, presumably multicore devices. The tools at the MCU end of the spectrum tend to be low-cost, even free, and Mark’s model is delivering both products and services to generate sustainable, profitable business.
I asked him for an example, and Mark cited the automotive market, where larger software organizations are emerging and facing a huge problem set – as he put it, “this car doesn’t work as nicely as my iPhone 5S”. The reality of consumer electronics cycles is just setting in on the auto guys, and they are ill equipped to compete all by themselves. Mentor offers an objective partnership and expertise for software development, and an attractive division of labor especially when it comes to understanding the depth of a processor core architecture. Those relationships with the processor vendors are extremely valuable, and not easy for OEMs to develop.
MIPS has been fairly successful in Asia for set-top boxes, and there are several MIPS-based mobile SoCs in China. They have also done some interesting things in speeding up the Dalvik implementation for Android in their architecture. So is that what Mentor is after, the consumer footprint of MIPS? Not exactly, although it is part of the equation.
Mark made an interesting observation from that line of questioning. He said that architectures shouldn’t be so sticky, but they are. We got into one of my favorite subjects: endianism. There is nothing worse than scrambled bytes on a network. All Intel implementations and the vast majority of ARM implementations are little endian. The vast majority of Power Architecture implementations are big endian. Mark says MIPS is split about half and half – network infrastructure implementations are usually big endian, consumer electronics implementations are usually little endian. The inference is: if you have a large pile of big endian networking infrastructure code, you’ll be looking at either MIPS or Power. (I’m looking right at you, Cisco.)
Our conversation concluded with a powerful observation from Mark: it is really hard to write that one piece of embedded code to sell again and again. He agreed with one of my favorite terms: “other people’s code” that may work just swell in one environment may cause another application to melt when added. The integration, debug, and optimization process is never ending.
Your mission, should you decide to accept it, is to get more code done, faster. And you may have some funky part, like a Cisco nPower X1, to do it on. Where Mentor fits in is the experience to develop better code, pretty much regardless of the target processor architecture, and sometimes deeply customized to a specialized combination of cores. MIPS is an important processor architecture that will likely experience a resurgence with the backing of Imagination, and Mentor will be there with development tools and services.
lang: en_US
Share this post via:
Comments
0 Replies to “What’s in your network processor?”
You must register or log in to view/post comments.