Ask the Experts: ARM's Cortex A53 Lead Architect, Peter Greenhalgh

158 Comments

View All Comments

• Peter Greenhalgh - Sunday, December 15, 2013 - link

  Hi twotwotwo,
  
  Core counts are certainly a popular subject at the moment!
  
  From our perspective we've consistently supported a Quad-Core capability on every one of our multi-core processors all the way back to ARM11 MPCore which was released in the mid-2000's. And while there's a lot of focus from the tech industry and websites like Anandtech on high-end mobile, our multi-core processors go everywhere from Set-Top-Box to TVs, in-car entertainment, home networking, etc, etc some of which can easily and consistently use 4-cores (and more, which is why we've built coherent interconnects to allow multiple cluster to be connected together).
  
  The processor's are designed to allow an ARM partner to chose between 1,2,3 or 4-cores and the typical approach is to implement a single core then instance it 4-times to make a Quad-Core with the coherency+L2 cache layer connecting the cores together and power switching to turn un-used Cores off. The nice thing about this approach is that it is technically feasible to design a coherency+L2 cache solution that scales in frequency, energy-efficiency and IPC terms from 1-4 cores rather than compromising in any one area.
  
  The result of this is that a Dual-Core implementation will be very similar in overall performance terms as a Quad-Core implementation. So while it may be that for thermal reasons running all 4-Cores at maximum frequency for a sustained period of time is not possible, if two Cores are powered off on a Quad-Core implementation it isn't any different from only having a Dual-Core implementation to start with. Indeed, for brief periods of time 4-Cores can be turned-on as a Turbo mode for responsiveness in applications that only want a burst of performance (e.g. web browsing). Overall there are few downsides to multiple Core implementations outside of silicon area and therefore yield.
  
  From a product perspective we've been consistent for almost a decade on the core counts provided by our processors and allow the ARM partners to choose how they want to configure their platforms with our technology.

• Krysto - Monday, December 16, 2013 - link

  I think many chips companies will be moving to 8-core solutions soon. What would the purpose of that be (other than marketing)?

• Krysto - Monday, December 16, 2013 - link

  To clarify, I'm referring to 8-same-core solutions, not big.Little.

• twotwotwo - Monday, December 16, 2013 - link

  First, wow--had no idea you were going to go through all these comments and answer them; good work.
  
  FWIW, your answer dismisses a problem slightly different from the one I asked about. Yes, 4xA15/2MB L2 performs no worse than 2xA15/2MB L2; you just spend more because of higher die area. But if the SoC design had stuck to two cores, I imagine they could use extra die area for more useful things--enlarging the L2, adding A7s in a big.LITTLE config, using a higher-IPC but larger core design if one were available, upgrading other SoC components like the GPU, etc. My understanding, mostly from AnandTech, is that Apple's A7 (where'd they get that name from?) SoC basically does this--it's largish, but that's from Apple doing basically everything *but* going quad-core.
  
  Still, indirectly, you have answered my bottom-line question--ARM doesn't really see the proliferation of quad-core SoCs as a problem, and maybe doesn't see it as their job to push licensees towards one config or another in general.

• darkich - Sunday, December 15, 2013 - link

  Can we expect the fully flexible A53+A57 octa core successor of the current big.LITTLE implementation?
  Can you estimate the improvements it could bring regarding performance /efficiency, on the 20nm?

• Kevin G - Monday, December 16, 2013 - link

  Will Aarch64 add coprocessor instructions? The CP15 interface exists in the 32 bit ARMv7 but are missing in ARMv8. Will this be added later so that 3rd parties may add their custom coprocessors to an ARM design? If not, is this to prevent Aarch64 from becoming diversified with proprietary extensions?
  
  The 64 bit ARM ISA is unique in that it allows legacy 32 bit support to be omitted from a design. How much additional power consumption is needed to support the 32 bit legacy modes? Also if 32 bit legacy support was removed and the core optimized for 64 bit only mode, what would the performance gains be, all other things being equal?
  
  big.LITTLE is an interesting concept that launched with the Cortex A7 and A15. Several years later the A12 arrives and can be used in big.LITTLE as well. Can big.LITTLE scale to span three architectures (A7, A12, A15) for fine grained performance/watt stepping as load increases?
  Similarly, there is a gap between the Cortex A53 and Cortex A57. Presumably there is room for a hypothetical Cortex A55 but that’d arrive several years later. Is there plans to synchronize the release schedule for the low, middle and high end designs?

• Zisch - Monday, December 16, 2013 - link

  How would you liken ARM to MIPS? Where do you see MIPS going?

• barbare64 - Tuesday, December 17, 2013 - link

  Is ARM planning to create high TDP CPU for servers ?
  
  Is there some work towards APU ?