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

158 Comments

View All Comments

• tygrus - Thursday, December 12, 2013 - link

  Memory bandwidth to RAM is more important than huge on chip caches. The on chip cache is more like a buffer for prefetching and write-back. 10% more RAM bandwidth is better than 50% more cache. Even caching of instructions is getting harder (keeping enough in cache) because the size of RAM used has increased far more than cache with the number of active programs and their complexity has increased. Mid 90's Pentium offchip 256KB L2 cache with 64MB RAM, P3 onchip 256KB L2 with 1024MB RAM, Sandy Bay Xeon with about 2.5MB L3 per core (upto 20MB) and 16GB RAM per core (128GB) or more.

• vvid - Thursday, December 12, 2013 - link

  Hi Peter!
  Can 32bit performance degrade in future ARMv8 processor designs? ARMv7 requires some features omitted in ARMv8 - I mean arbitrary shifts, direct access to R15, conditional execution. I guess this extra hardware is not free, especially the latter.

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

  Hi vvid,
  
  Fortunately, while the ARM instruction set has evolved over the years, ARMv8 AArch32 (which is effectively ARMv7) isn't that far away from ARMv8 AArch64. A couple of big differences in ARMv8 AArch64 are constant length instructions (32-bit) rather than variable (16-bit or 32-bit) and essentially no conditional execution, but most of the main instructions in AArch32 have an AArch64 equivalent. As a micro-architect, one of the aspects I like the most about the AArch64 instruction set is the regularity of the instruction decoding as it makes decoding them faster.
  
  As such the hardware cost of continuing to support AArch32 is not that significant and it is more important to be able to support the thousands of software applications that have been compiled for ARMv7 which are fully compatible and run just fine on the generation of 64-bit ARM processors that are now arriving.

• ARMtech - Friday, December 13, 2013 - link

  Thanks for the time.
  I have few questions
  
  How is ARM A57 matching up with performance related to Intel Haswell? Though very good at power, the ARM cores are traditionally weak in performance compared to Intel. The Haswell arch seems to be beating ARM A15 very easily in Chromebook. Is this due to memory b/w issue? Can ARM arch with big.Little including CCI support higher BW?
  Also why doesn't ARM go to Qualcomm arch like asynchronous Freq scaling? Why does freq tied to cluster instead of cores?

• elabdump - Friday, December 13, 2013 - link

  Very nice,
  
  Here are some Questions:
  
  - Does ARM works on GCC Development?
  - Are there special instructions for Cryptostuff defined in the 64-Bit ISA?
  - If yes, are there patches for the upstream linux kernel available?
  - Are there Instructions for SHA-3 available?
  - Would ARM change their mind about free Mali drivers?
  - Would ARM support device-trees?

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

  Hi Elabdump,
  
  Yes, ARM works on GCC development and, yes, there are special Crypto instructions defined in the v8 Architecture (for AES and SHA).
  
  As for patches, Mali drivers and device trees, these are handled by other teams in ARM. If you're interested in these wider questions about ARM technology, forums such as http://community.arm.com can help you.

• Krysto - Monday, December 16, 2013 - link

  I hope you guys intend to add ChaCha20 to your next-generation chips or architecture. I'm pretty sure it's the next big cipher to be adopted by software makers. Google's security chief, Adam Langley, has already shown his support for it, but there are others who are looking to adopt it as an alternative to AES. So I hope you too can adopt it as soon as possible.
  
  http://googleonlinesecurity.blogspot.com/2013/11/a...
  
  As for SHA-3, the jury is still out on that one, since nobody trusts NIST anymore, and there has been even some recent controversy about them wanting to lower the security of the final SHA-3 standard, so you might want to hold off on that one. You should support SHA-512 in the meantime, though, which is oddly missing from ARMv8.
  
  Also, you guys should move to 4-wide and at least 256-bit NEON for Cortex A57's successor (I know, not your job, but still). And as others have said, try to match the low-end, mid-end and high-end release of the cores next time. One more thing - try to support OpenCL 2.0 as soon as you can.

• JDub8 - Friday, December 13, 2013 - link

  My question is about processor architecture design in general - there cant be very many positions in the world for "lead processor/architecture designer" - so how does one become one? Obviously promotion from within but how to you get the opportunity to show your company you have what it takes to make the tough calls? There cant be very many textbooks on the subject since you guys are constantly evolving the direction these things go.
  
  How many people does it take to design a bleeding edge ARM processor? How are they split up? Can you give a brief overview of the duties assigned to the various teams that work on these projects?
  
  Thanks.

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

  Hi JDub8,
  
  I'd imagine that ARM is not so different from any other processor company in that it is the strength of the engineering team that is key to producing great products.
  
  Perhaps where ARM differs from more traditional companies is the level of discussion with the ARM partners. Even before an ARM product has been licensed by an ARM partner they get input in to the product and there will be discussions with partners at all levels from junior engineers a few years out of college, through to multi-project veterans, lead architects, product marketing, segment marketing, sales, compiler teams, internal & external software developers, etc etc.
  
  As a result, there are rarely 'tough calls' to be made as there's enough input from all perspectives to make a good decision.
  
  In answer to your question about processor teams, these are typically made up of unit design engineers responsible for specific portions of the processor (e.g. Load-Store Unit) working alongside unit verification engineers. In addition to this there will be top-level verification teams responsible for making sure the processor works as a whole (using a variety of different verification techniques), implementation engineers building the design and providing feedback about speed-paths/power, performance teams evaluating the IPC on important benchmarks/micro-benchmarks.
  
  And this is just the main design team! The wider team in ARM will include physical library teams creating advanced standard cells and RAMs (our POP technology), IT managing our compute cluster, marketing/sales working with partners, software teams understanding instruction performance, system teams understanding wider system performance/integration and test-chip teams creating a test device.
  
  All in all it takes a lot of people and a lot of expertise!

• twotwotwo - Saturday, December 14, 2013 - link

  I. Core count inflation. Everyone but Apple lately has equated high-end with quad-core, which is unfortunate. I have a four-core phone, but would rather have a dual-core one that used those two cores' worth of die area for a higher-IPC dual-core design, or low-power cores for a big.LITTLE setup, or more L2, or most anything other than a couple of cores that are essentially always idle. Is there anything ARM could do (e.g., in its own branding and marketing or anything else) to try to push licensees away from this arms race that sort of reminds me of the megapixel/GHz wars and towards more balanced designs?
  
  II. Secure containers. There has been a lot of effort put in to light-weight software sandboxes lately: Linux containers are newly popular (see Docker, LXC, etc.); Google's released Native Client; process-level sandboxing is used heavily now. Some of those (notably NaCl) seem be clever hacks implemented in spite of the processor architecture, not with its help. Virtualization progressed from being that sort of hack to getting ISA support in new chips. Do you see ARM having a role in helping software implementers build secure sandboxes, somewhat like its role in supporting virtualization?
  
  III. Intel. How does it feel to work for the first company in a long while to make Intel nervously scramble to imitate your strategy? Not expecting an answer to that in a thousand years but had to ask.