Qualcomm Not Big on Big.little

Don't expect Qualcomm to use ARM's big.little or off-the-shelf cores - it aims to lead at the risk of tripping on not-invented-here syndrome.

SAN DIEGO, Calif. — Murthy Renduchintala jokes about how hard it is to pronounce his surname, but there's no mistaking the message of the executive vice president of Qualcomm Technologies Inc.

Like six-foot-something Renduchintala, Qualcomm sees itself as a tall, capable presence that goes its own way in mobile technology. It expects to continue developing custom CPU, graphics, DSP, and other cores and combining them in unique ways in its SoCs.

"I don't care who copies Qualcomm, but Qualcomm will never copy anyone," Renduchintala said in a press Q&A at the Uplinq event here. "The ARM A15 core is good, but it's not good enough for Qualcomm, so we have to enhance it."

Murthy Renduchintala spoke with press after his Uplinq keynote.

Both Samsung and Mediatek claim their latest eight-core SoCs beat Qualcomm's quad-core Snapdragon in benchmarks. The two rivals both use ARM's off-the-shelf A15 and A7 cores combined using ARM's Big.little multicore architecture.

"What's important is the aggregate user experience rather than superficially the number of CPUs," said Renduchintala. "You can use benchmarks to show whatever you want, but if you take a broad panorama of benchmarks, Snapdragon is still the best technology out there."

But Snapdragon is getting a bit long in the tooth in the fast-paced silicon world. Its latest members were announced late last year, demonstrated at CES in January, and are now emerging in smartphones and tablets. Qualcomm will probably announce follow-ons before the end of the year.

Meanwhile Renduchintala downplays CPU core count as a metric for the quality of a mobile SoC.

"We could integrate 12 or 24 cores by tiling identical CPUs together. The complexity is not in laying down the silicon but in the software to make use of that many cores -- real-time software processing with 8 to 10 parallel tasks is pretty complicated and more trouble than it's worth."

Qualcomm claims it gains advantage by combining "the right number" of best-of-breed CPU, GPU, DSP, imaging processing, cellular, and other cores optimized for performance per watt. Renduchintala, raised in England, compares it to an 11-man soccer team with the right mix of players.

He dismisses ARM's Big.little approach of ganging performance and power optimized cores into an SoC. "It's one way of addressing the challenge, but we have a different idea" he said, adding that the ARM approach of multitasking between big and little cores implies that neither is well optimized for the task at hand.

I'd not dismiss the big.LITTLE approach, though the challenges in supporting this scheme in software and OS level are far from trivial as pointed out. Using the ever-increasing (but hard-to-power) number of transistors to add more specialized processing cores is also a great approach and easier to support in software/developer level.

There's a great paper called "Is dark silicon useful?: harnessing the four horsemen of the coming dark silicon apocalypse" by Michael B Taylor of UCSD, where two of the "horsemen" (the "dim horseman" and the "specialized horseman") correspond to two of the approaches here. Recommended reading for getting a better feel of what may lie ahead for the processor world.

The NIH syndrome not withstanding, there is validity to Mr. Renduchintala's point about core optimization, that too application-specific core optimization where Q certainly knows its turf better than ARM.

@Rick: I too suspect there's debate inside Qualcomm about licensing its cores, it is not just the revenue but proliferation of its technology.

I see the real message here being choice, the choice to have a big.LITTLE system, a 4PLUS1 system, an aSMP system, or even a good old fashioned basic DVFS/Sleep system.

It wasn't that long ago postings were whether more than 1 CPU could be used... today I have seen 8 cores being used in andriod, agreed these are not all 'big' tasks so whether you provide them a LITTLE cpu, or a cpu running more slowly with aSMP - the software complexity is pretty much the same.

Lets all just be thankfull we don't all need to eat a single DVFS based solution!