When the map starts to change, turning our view of the world upside down might be exactly the right thing to do.
I’ve been thinking a lot about some of the things vendors of multicore[
] Systems-on-Chip (SoCs) have been telling me lately. Like the folks at Freescale saying that their VortiQa software is the best way to show off all the capabilities of their QorIQ quad-core processor. Like the folks at Imagination Technologies saying that while their graphics IP is at the heart of many devices, designers don’t typically understand all the capabilities they have. The folks at Cavium have quietly said something similar about their Octeon II network processors, as have the folks at Intel about their multicore machines, as well as the folks at Tensilica regarding their IP cores, and possibly a dozen more companies that I haven’t heard say the same thing out loud.
This situation can be compared to a movie you’ve probably seen – Jack the pirate captain and his faithful crew, seemingly lost on a ship at world’s end with nothing but an upside down map, finally realize that the world won’t turn back upright until the ship is flipped over. Well here we are, folks – our multicore map sure looks upside down to me.
“Multicore programming” is an incomplete statement to describe what’s happening here. It’s not like you can whip out your editor, write some code, run a compile, and be fantastically better all of a sudden. It’s also not like you can pull out a tool – say, CriticalBlue Prism – and instantly resolve all your problems. Those help, but the problems start at the SoC/OS level and have to be resolved there.
Partnerships such as the Digi-Key and Texas Instruments collaboration on BeagleBoard, the Cavium/MontaVista and Intel/Wind River acquisitions, the formation of Linaro, and Freescale’s work with Mentor Graphics, Enea, and Green Hills are extremely important. Silicon and software vendors will have to work together closely well in advance of a release to make multicore support ready enough to be understood, utilized, and fully captured. It’s not only going to require point support for a single device; it will encompass issues like portability up, down, and across architectures and much more complete support with optimized elements to make sure performance, power, and flexibility are available and truly design-ready.
Is this even enough? Cadence has a different angle. The company’s EDA360 view makes a single statement that says the world might be so different it’s not even possible to get to where we’re going using the old method. The premise: Smartphone apps are in control now, but instead of having the multicore processor and OS determine what the application gets, the application should go in and configure the SoC/OS according to what it needs. While this is the reverse view of virtualization[] we’re seeing now, it’s probably the right view, one that involves SoCs, FPGAs and programmable logic, and virtualization technology much more robustly than we see it today.
We are truly seeing an inflection point for multicore SoC designs, taking into account both silicon and software. The winners will be those who work to flip the ship, not those who try to keep it steady. I’d enjoy hearing from folks about their view of the multicore map – drop me a note.
@dondingee, @embedded_mag
ddingee@opensystemsmedia.com
Up next:
Embedded Systems Conference
Boston, MA
September 20-23
http://esc-boston.techinsightsevents.com
