Ask the Experts: Krisztián Flautner VP of R&D, ARM

62 Comments

View All Comments

• KFlautner - Wednesday, June 4, 2014 - link

  I’m pretty sure for the fans it never actually left the top spot ...

• nemi2 - Tuesday, June 3, 2014 - link

  Will clock-less ARM cores like the "Amulet" and "ARM996HS" become mainstream? will we hear more about them? do they have a significant power savings advantage for mobile and other low power applications?

• KFlautner - Wednesday, June 4, 2014 - link

  No. We’ve been involved in many asynchronous implementation projects but none of the potential benefits ultimately panned out. This is not necessarily the fault the people involved. The ideas were interesting but as they weren’t mainstream, there wasn’t an ecosystem there to support them. The implementers usually had to make do with poorer quality tools and cores that were originally designed for synchronous operation. So it’s one of these things: the ideas may have been sound in theory but it takes much more than that to build a successful product that delivers on the promises.

• JCP2014 - Tuesday, June 3, 2014 - link

  My questions are about big.LITTLE that ARM has been championing for the last few years:
  
  First, Given the early issues with big.LITTLE designs (infamously Exynos 5410), what will ARM do to prevent problems like this in the future? Now that A15/A7 issues seem to have been ironed out, might similar issues arise with A57/A53 in the future?
  
  Second, how much optimization does big.LITTLE require on the kernel/OS side to get best efficiency/performance results? Do you currently work with Google, Microsoft, etc to integrate this capability into their stock kernel?

• KFlautner - Wednesday, June 4, 2014 - link

  Regarding your first question, we can't comment on specific partner SoCs or their implementations, so any questions on Exynos 5410 should be directed to Samsung.
  
  What we can say is that big.LITTLE and coherency are fully supported in the ARM CPU and system IP. In fact, there are now several shipping examples of big.LITTLE MP (global task scheduling) in the market, and expect big.LITTLE SoCs to be predominantly big.LITTLE MP enabled from this point forward.
  
  There are specific enhancements in the latest ARM CPUs that improve CPU performance, introduce 64-bit support, and will additionally improve big.LITTLE performance in the following ways:
  + Even faster coherency transactions
  + A higher performance LITTLE core (Cortex-A53) means the big cores (Cortex-A57) can remain asleep for a larger percentage of workloads
  
  big.LITTLE software continues to evolve as well, in the optimizations and tuning of big.LITTLE SOCs, and in coordination with other power management frameworks and other system components.
  Expect more advances in the software to come as big.LITTLE continues to improve over time.
  
  Regarding your second question, perhaps the best way to answer is to point you to a blog that my colleague Brian Jeff, posted last year entitled “Ten things to know about big.LITTLE” http://community.arm.com/groups/processors/blog/20...
  In this blog, Brian talks about how big.LITTLE software effectively operates underneath Android in the kernel and you don't have to directly change Android middleware. The Linux kernel is patched with code that handles the big.LITTLE thread scheduling.
  ARM keeps its ecosystem partners updated on big.LITTLE software techniques and approaches, but for comments on a specific OS, you'll need to ask the OS vendor directly.

• TylerGrunter - Tuesday, June 3, 2014 - link

  The first time I heard about A15 cores they were designed for microservers, the first time I heared about about A57 cores they were targeting microservers (with what looks like better luck this time).
  Both ended or will end up in mobile devices. Two questions arise regarding this:
  Does ARM have a plan to develop some bigger core with higher IPC that can compete with Intel cores? (Apple Cyclone comes to mind)
  In case it´s a yes: Will you ensure those cores can be used later on mobile devices? Can you give us some insight of how? I guess it´s quite challenging to design both for ultra performance and low power consumption at the same time.
  What´s your view in wereables? I see them as a huge promise, but created of lot of niches, which makes it difficult to monetarize. Are you planning anything ultra low power for them?
  One last question. I have the feeling Moores law is coming to an end, seeing that the 20nm node is presenting serious challenges and cost per transistor is rising. What´s the next step one the big up slope of reducing nodes is reached? What technology do you think will substitute sylicon? Is there anything on the pipe already?

• Krysto - Friday, June 6, 2014 - link

  They could do what Apple did, and build some cores that will only go in 2-core set-up in mobile, and at 1-1.2 Ghz speeds. Then take those cores and put them at 2-2.5 Ghz in PCs. However, I don't think this is ARM's plan. As we've seen with Apple's Cyclone, it's not among the most efficient. It will be interesting to see Nvidia's Denver cores which aren't just huge, but also clocked at 2.5-3 Ghz.
  
  But as I mentioned in another comment at the end of the comments page, ARM doesn't need to do this. They can just wait it out, and will eventually reach parity with Intel in performance anyway (since Intel doesn't care about improving performance as much with the latest generations).

• Wreckage - Tuesday, June 3, 2014 - link

  Is there a future for a desktop ARM chip (non-SOC)? There had been a rumor of Apple moving iOS to the desktop and I could see Android making a similar move. It sounds like Project Denver and the move towards 64-bit are in line with this kind of transition.
  
  Is this something that ARM is working on?

• ImSpartacus - Tuesday, June 3, 2014 - link

  Are you talking about something socketed?

• BMNify - Thursday, June 5, 2014 - link

  yes i think he is, but my thinking has aways been longer term, given that cortex is destined for hyperscale eventually the efforts so far are odd in their choices to advance ARM everywhere.
  
  while the Cavium ThunderX Server SoC Features up to 48 ARM 64-bit Cores
  
  http://www.cnx-software.com/2014/06/04/cavium-thun...
  http://www.cnx-software.com/wp-content/uploads/201...
  seems a nice step up, i dont know the size of the SOC (you do probably) it seems to me that the way they all pack the ARM cores into a generic sled seems very wasteful to date plus masses of redundant steel doesn't help ether , could that ThunderX fit on a generic SoDIMM module ?.
  
  if so id really like ARM to get behind one of the existing SoDIMM module formats, or better yet, use your long tail information to create a brand new free generic ARM(64) SoDIMM module SoM industry standard with the base carrier/daughter board (multi 4+) SoM enabled, something far better than the existing limited scope barely good enough standards today see http://www.cnx-software.com/2014/05/24/aaeon-annou... for the state (it is) of the art yack :) and do far better with an eye to create 100+ ARM SoM on a generic sled and perfectly happy to take one of those server SoM and put it in a small ARM STB box if you like, cross compatibility at the core no real sub dividing in to pro segments as such, dont throw it away recycle it if you will....