ARM to extend Big.Little for GPUs and heat management
A multiprocessor test chip has led ARM to improve the energy-control strategy for its Big.Little architecture and to simplify the debug architecture for the company’s multicore processor IP.
Launched in the summer, the Juno device combines the Cortex-A57 and A53 processors in the conventional Big.Little configuration together with a Mali graphics processor unit (GPU). “Because it’s not intended to be a production chip, we could get it out quickly,” said Pete Hutton, president of the products group at ARM in his keynote at ARM TechCon in Santa Clara, California this week. “It allows us get this technology into the hands of developers and our partners. We have already shipped hundreds of these devices to users.
“We also use this technology internally to innovate,” Hutton added. “One of the innovations is what we’ve done to extend Big.Little. The [existing] way to provide thermal control in Big.Little was fairly crude. There were static limits set for processing on the CPUs. In certain cases, if you were thrashing the smartphone fairly hard, the device would heat up and the performance drop off.”
Image Block diagram of the ARM Juno development SoC
Hutton described an improved approach, dubbed Big.Little Intelligent Power Allocation (IPA): “This uses a closed-loop control system that takes advantage of sensors on the device, so we now have thermal as well as performance targets. We have also extended the Big.Little approach to the GPU, to cover more of the SoC’s [processor cores].
To allow tasks to migrate between the CPUs and the GPU, ARM has written OpenCL support for the Cortex-A cores. “By putting OpenCL onto the CPU, we can let tasks that are embarrassingly parallel run on the GPU or, in other cases, run on the CPU, or you have move them dynamically,” Hutton claimed.
Aiming to make use of the technology widespread, ARM has contributed the core code for the IPA thermal governor to the Linux Foundation. The release for the Juno device, with additions for GPU control, is available through Linaro’s code archive.
Experience with Juno revealed issues with the approach to multicore debug used by ARM. “With chips like Juno, we’ve had to eat our own dog food,” Hutton said. “We realised what a lot of partners have been feeding back: that the debug is very useful but, boy, is it hard to hook up.”
Hutton pointed to the recent acquisition of Duolog as leading ARM’s intention to streamline the generation of the debug topology for multicore SoCs. “With Duolog we can roll out the Socrates technology that does this in minutes. It’s a great example of how we can get the technology out quickly. Socrates will go further: we will take it across the entire SoC.”
Leave a Comment
You must be logged in to post a comment.