MIPS loves Tensilica. What?

OK, what is going on in that royal family of silicon intellectual property, the CPU cores? For years industry giant ARM has been accumulating IP products: everything from graphics and DSP engines to bus interfaces and cell libraries. Then in August, expanding IP vendor Virage Logic formed a smaller mirror image of ARM by acquiring CPU IP vendor ARC International. But this week brought the last straw: bitter competitors MIPS and Tensilica sent out a joint press release. And no, neither company is either acquiring or suing the other. They are working together.

More specifically, the two companies announced a demo—a suggested approach to an Android phone design—that they will show at CES. In this demo design, a MIPS core hosts the Android software and a Tensilica HiFi2 core does audio processing.

Needless to say this is an enormous departure from the days when each CPU core vendor would contest every processor in a prospective customer’s SoC block diagram with tooth and nail. It is, in fact, an indication of how profoundly the role of processor IP has changed in SoC design.

Not that long ago, the CPU win was the goal supreme in any SoC project. There likely would be only one 32-bit CPU core in the chip, and the vendor of that one core had an inside track on the other major cores in the design. Hence the tendency of ARM to accumulate supporting IP. But in today’s world of multicore architectures, there is often not one identifiable central processor. Instead, a pool of processing elements cooperatively supports the task load, and no one of them has much greater leverage than any of the others. In some cases the control processor, far from being at the center of the architecture, has been reduced to such low-bandwidth tasks that it need not even be a particularly powerful unit. All the processor cores are becoming less important as individual architectural elements and more important as delivery vehicles for specific blocks of software IP.

That’s a big difference in strategy. SoC architects can assemble the software architecture first: partitioning the functions, selecting software vendors, and defining interfaces between the software packages. This process in turn creates the specifications for the processing cores, their memory subsystems, and their hardware interconnect architecture. In this methodology the choice of operating system, not of CPU, is the watershed from which other decisions flow.

And in this world processor cores are not defining IP, or even, really, star IP. They are merely the physical foundations on which rest the platform software, virtualization system, middleware, and applications. It makes perfect sense for competing processor IP vendors to work together if that helps them to host all the software the design team needs. Especially vendors who trail ARM and Virage in assembling extensive IP portfolios and software ports may find cooperation their best defense.

The methodology also puts a premium on a currently under-explored category of IP: interconnect. Architecting the software first places stringent and complex constraints on the SoC interconnect segments between hardware blocks in terms of bandwidth, latency, and protocol. And the approach is intolerant of any IP block—star or otherwise—that attempts to overconstrain the architecture with a proprietary interface. Even ARM, whose AMBA system has ruled the SoC world since the uniporcessor days, had better watch out for that one.