Field Notes from DAC 2008: Multi-Processor SOCs—The Next Generation

Former EDN editor Markus Levy (and president of EEMBC and the Multicore Association) ran a DAC Pavilion panel on multiprocessor SOCs this week at DAC in Anaheim. On the panel were Sreenivasa Rao (Analog Devices), Max Domeika (Intel Corp), and Grant Martin (Tensilica). This panel very much reminded me of the fable of the blind men and the elephant for the varied panelist views of what this topic actually meant. Levy telegraphed the broad scope of the topic by saying “In the next 45 minutes, we’re going to tell you everything you need to know about multicore.” NOT!

Rao started by saying that, from his perspective, the biggest challenge was designing the multicore architecture itself. Usually, he said, it’s a bus system with a memory hierarchy. Now I take great exception to this statement, not because it’s wrong but because it should be wrong. I agree that most of today’s system architects gravitate to putting multiple processors on a bus, communicating through a memory hierarchy. This is a really inefficient way to harness microprocessors although it might work just great for horse teams pulling stagecoaches. A bus is naturally a limited resource with a relatively narrow width, a finite bandwidth, and a large acquisition overhead in a multiprocessor environment. It may well be the best way to hook up a bunch of processors, but no system designer should ever assume that it’s the best way without some thought and careful analysis.

Next up was Domeika, speaking from the perspective of a company that makes dual- and quad-core SMPs (symmetric multiprocessors). “The major challenge is how to program these devices,” he said. “We can build a lot of processors on chip. The problem is how to harness them.” Again, this is from the SMP perspective where you have a relatively few big, fast, general-purpose processors on which you are going to run all your tasks regardless of how well those tasks fit on the processors. Naturally, programming is a challenge using this approach.

Martin said, “The biggest challenge our customers face is mapping tasks to processors in multicore systems.” Now Grant Martin and I work at the same company and we co-author a lot of articles and papers, so you shouldn’t be surprised to find me in violent agreement with him. But I’d do so without the corporate brotherhood, given my systems-design background. If you tell a system architect that the next system his or her team designs will incorporate 100 processors, you’ll likely see furrows of concern appear on their forehead. However, if you instead say that the system will consist of 100 hardware blocks, don’t expect to see a ripple.

Incredible! What…is…the…difference??? A processor is nothing more than a chunk of hardware controlled by firmware. Draw a black box around the thing and you literally cannot tell whether the circuitry in the box is random state-machine-plus-datapath RTL or processor RTL. Its shouldn’t make a difference, but somehow it does.

Further, it makes a difference in the way the boxes get interconnected. Again, say it’s 100 boxes of hardware and you’ll tend to get point-to-point system connections. No one connects hardware blocks with buses automatically. There has to be a good reason. However, say it’s 100 processors and you’ll get buses, bus hierarchies, and networks on chips. All of these approaches incur a lot of overhead. Hence they may all be the wrong sort of interconnect. At the very least, they should not be the default choice of an unthinking architect.