Given the timing of yesterday's Cortex A53 based Snapdragon 410 announcement, our latest Ask the Experts installment couldn't be better. Peter Greenhalgh, lead architect of the Cortex A53, has agreed to spend some time with us and answer any burning questions you might have on your mind about ARM, directly.

Peter has worked in ARM's processor division for 13 years and worked on the Cortex R4, Cortex A8 and Cortex A5 (as well as the ARM1176JZF-S and ARM1136JF-S). He was lead architect of the Cortex A7 and ARM's big.LITTLE technology as well. 

Later this month I'll be doing a live discussion with Peter via Google Hangouts, but you guys get first crack at him. If you have any questions about Cortex A7, Cortex A53, big.LITTLE or pretty much anything else ARM related fire away in the comments below. Peter will be answering your questions personally in the next week.

Please help make Peter feel at home here on AnandTech by impressing him with your questions. Do a good job here and I might be able to even convince him to give away some ARM powered goodies...

Comments Locked

158 Comments

View All Comments

  • mrtanner70 - Tuesday, December 10, 2013 - link

    1. We don't seem to have quite seen the promised power savings for big.little yet (thinking of the Exynos 5420 in particular since it has hmp working, not sure if any devices have correct Linux kernel yet though). Are you still as bullish on this aspect of the big.little story?

    2. Are there particular synergies to using Mali with the CCI vs. other brand GPU's?

    3. What is your general response to the criticism of big.little that has come out of Intel and Qualcomm? Intel, in particular, tends to argue dynamic frequency scaling is a better approach.

    Cheers
  • Peter Greenhalgh - Wednesday, December 11, 2013 - link

    Hi MrTanner,

    In answer to (3), DVFS is complimentary to big.LITTLE not instead of.

    A partner building a big.LITTLE platform can use DVFS across the same voltage and frequency range as another vendor on the same process with a single processor. The difference is that once the voltage floor of the process is reached with the 'big' processor the thread can be rapidly switched to the 'LITTLE' processor further increasing energy efficiency.

    Mobile workloads have an extremely large working range from gaming and web browsing through to screen-off updates. The challenge with a single processor is that it must compromise between absolute performance at the high-end and energy efficiency at the low-end. However a big.LITTLE solution allows the big processor to be implemented for maximum performance since it will only be operating when needed. Conversely the LITTLE processor can be implemented for best energy efficiency.
  • Krysto - Tuesday, December 10, 2013 - link

    So far it doesn't look like any chip maker is in a hurry to go to 20nm next year, even with the jump to ARMv8. Can he share his opinion on why this is happening? Why aren't we seeing all ARMv8 chips arrive at 20nm, as it was supposed to happen (just like the previous generation, Krait/Cortex A15, jumped to 28nm)?

    As a follow-up question, since I assume he'll hint at a combination of failures from both fabs and chip OEM's to move to 20nm fast enough, will this situation be rectified at least in 2015, with an early push to 14/16nm FinFET? Can we expect chip makers to move to that in EARLY 2015? (Nvidia has kind of hinted at that, but who can trust Nvidia with keeping their own schedule?!)
  • name99 - Wednesday, December 11, 2013 - link

    "So far it doesn't look like any chip maker is in a hurry to go to 20nm next year, even with the jump to ARMv8."

    This is the kind of thing that NO-ONE is going to talk about until they have things working. Assuming otherwise is just silly.
    Take, for example, Apple. They are quite likely porting the A7 to TSMC's 20nm process as we speak, with the goal of both learning about the process and introducing a speed-bumped iPad lineup (maybe even also a speed bumped iPhone) in Q2 2014. (They did the same think with the die-shrunk A5, though in that case they did not publicize it as a speed bump, it's just that newer iPads had better battery life.)
    But they're not going to tell anyone about this. If the project slips, they'll look dumb. They may prevent a whole of people buying today, then those people get sick of waiting and buy Android (Osborne effect), etc. Meanwhile there is no upside to telling the world about this move.
  • Krysto - Tuesday, December 10, 2013 - link

    Oh, and one more question. FreeBSD developers have just said that they will stay away from using Intel and VIA's hardware encryption features, because they could be backdoored by the NSA.

    http://arstechnica.com/security/2013/12/we-cannot-...

    ARM is from UK - the home of GCHQ, which is just as bad, if not worse, than NSA - so is there a way to reassure us that ARMv8, which comes with hardware encryption, is free of such backdoors? Is he willing to go on the record with that?

    I'm sure he realizes, that if people stop trusting these features, and they (including Intel, AMD, VIA, etc) can't prove to us that their hardware isn't in fact backdoored, will just mean NO ONE will end up using those features, and will stick with a software solution instead, which means their hardware encryption will just waste space on the die, so I hope they take this issue very seriously, for their sake, too.
  • smoohta - Tuesday, December 10, 2013 - link

    Sorry for piggy backing on Krysto's post but I'd love it if Peter talks not only about hardware RNGs (that's what I assume Krysto meant by "hardware encryption") but also about general security features in ARM - specifically TrustZone (which is what Apple uses in the iPhone's Touch ID solution).

    Thanks!
  • syxbit - Tuesday, December 10, 2013 - link

    The Cortex-A15 has really struggled on mobile. Neither Tegra 4 nor Exynos 5 (nor OMAP 5 cough cough) have sold well at all compared to Snapdragon 600/800.
    Possibly related to their lack of success with A15, Nvidia and Samsung (and AMD) have already announced that they are going to be designing their own CPU (rather than an ARM design).
    Is this worrying to ARM? Doesn't it show that big.LITTLE was a mistake required to cover up A15 power hunger?
    Krait 400 proves that big.LITTLE is not needed to be both powerful and very power efficient.
    How will A57 succeed where A15 failed?
  • marblearch - Monday, December 30, 2013 - link

    Hit the nail on the head there. I bet they say A15 wasn't really meant for mobile but then there's a glaring hole after A9 until the only just announced A12, so I reckon A15 was supposed to be for mobile but they messed it up and dreamt up big.LITTLE to cover themselves. Not that big.LITTLE is a crazy idea, just so far it's a botch job. And A53 and A57 seem to be just incrementals of A7, A15 with ARMv8 chucked in so I wouldn't expect any improved success with these.
  • silenceisgolden - Tuesday, December 10, 2013 - link

    Since ARM released the big.LITTLE guidelines, is there a plan for ARM to also release guidelines for processor and co-processor implementations such as Motorola's 'X8' system and Apple's 'M7' co-processor?
  • jameskatt - Tuesday, December 10, 2013 - link

    How does the A53 compare in performance to Apple's custom A7 64-bit Dual-core Chip?

Log in

Don't have an account? Sign up now