Cortex A76 µarch - Frontend

Starting off with a rough overview of the Cortex A76 microarchitectural diagram we see the larger functional blocks. The A76 doesn’t look too different than other Arm processors in this regard and the differences come only with details that Arm is willing to divulge. To overly simplify it, this is a superscalar out-of-order core with a 4-wide decode front-end with 8 execution ports in the backend with a total implementation pipeline depth of 13 stages with the execution latencies of a 11 stage core.

In the front-end, Arm has created a new predict/fetch unit that it calls a “predict-directed fetch”, meaning the branch prediction unit feeds into the instruction fetch unit. This is a divergence from past Arm µarches and it allows for both higher performance and lower power consumption.

The branch prediction unit is what Arm calls a first in the industry in adopting a hybrid indirect predictor. The predictor is decoupled from the fetch unit and its supporting large structures operate separate from the rest of the machine – likely what this means is that it will be easier to clock-gate during operation to save on power. The branch predictor is supported by 3-level branch target caches; a 16-entry nanoBTB, a 64-entry microBTB and a 6000 entry main BTB. Arm claimed back in the A73 and A75 generations of branch predictors were able to nearly predict all taken branches so this new unit in the A76 seems to be one level above that in capability.

The branch unit operates at double the bandwidth of the fetch unit – it operates on 32B/cycle meaning up to 8 32b instructions per cycle. This feeds a fetch queue in front of the instruction fetch consisting of 12 “blocks”. The fetch unit operates at 16B/cycle meaning 4 32b instructions. The branch unit operating at double the throughput makes it possible to get ahead of the fetch unit. What this serves is that in the case of a mispredict it can hide branch bubbles in the pipeline and avoid stalling the fetch unit and the rest of the core. The core is said to able to cope with up to 8 misses on the I-side.

I mentioned at the beginning that the A76 is a 13-stage implementation with the latency of an 11-stage core. What happens is that in latency-critical paths the stages can be overlapped. One such cycle happens between the second cycle of the branch predict path and the first cycle of the fetch path. So effectively while there’s 4 (2+2) pipeline stages on the branch and fetch, the core has latencies of down to 3 cycles.

On the decode and rename stages we see a throughput of 4 instructions per cycle. The A73 and A75 were respectively 2 and 3-wide in their decode stages so the A76 is 33% wider than the last generation in this aspect. It was curious to see the A73 go down in decode width from the 3-wide A72, but this was done to optimise for power efficiency and “leanness” of the pipeline with goals of improving the utilisation of the front-end units. With the A76 going 4-wide, this is also Arms to date widest microarchitecture – although it’s still extremely lean when putting it into juxtaposition with competing µarches from Samsung or Apple.

The fetch unit feeds a decode queue of up to 16 32b instructions. The pipeline stages here consist of 2 cycles of instruction align and decode. It looks here Arm decided to go back to a 2-cycle decode as opposed to the 1-cycle unit found on the A73 and A75. As a reminder the Sophia cores still required a secondary cycle on the decode stage when handling instructions utilising the ASIMD/FP pipelines so Arm may have found other optimisation methods with the A76 µarch that warranted this design decision.

The decode stage takes in 4 instructions per cycle and outputs macro-ops at an average ratio of 1.06Mops per instruction. Entering the register rename stage we see heavy power optimisation as the rename units are separated and clock gated for integer/ASIMD/flag operations. The rename and dispatch are a 1 cycle stage which is a reduction from the 2-cycle rename/dispatch from the A73 and A75. Macro-ops are expanded into micro-ops at a ratio of 1.2µop per instruction and we see up to 8µops dispatched per cycle, which is an increase from the advertised 6µops/cycle on the A75 and 4µops/cycle on the A73.

The out-of-order window commit size of the A76 is 128 and the buffer is separated into two structures responsible for instruction management and register reclaim, called a hybrid commit system.  Arm here made it clear that it wasn’t focusing on increasing this aspect of the design as it found it as a terrible return on investment when it comes to performance. It is said that the performance scaling is 1/7th – meaning a 7% increase of the reorder buffer only results in a 1% increase in performance.  This comes at great juxtaposition compared to for example Samsung's M3 cores with a very large 224 ROB.

As a last note on the front-end, Arm said to have tried to optimised the front-end for lowest possible latency for hypervisor activity and system calls, but didn’t go into more details.

The Arm Cortex A76 - Introduction Cortex A76 µarch - Backend
Comments Locked


View All Comments

  • lmcd - Friday, June 1, 2018 - link

    They're at the mercy of chipmakers. The only companies that would buy such a core have already left reference designs behind. Everyone else wants small, cheap chips, so much so that we've had A53-only designs in the entire middle-and-lower range. Will anyone even use the A76? I don't know if that's guaranteed.
  • vladx - Friday, June 1, 2018 - link

    Read the last part of the article, it's almost guaranteed next Kirin is skipping the A75.and going directly to A76. I think Huawei is done playing catch-up.
  • darkich - Friday, June 1, 2018 - link

    It's so frustrating how even you people who are into SoC's already forget that Apple was basically cheating the customers with secret huge compromises, just to be able to put unbalanced and owerpowered cores in the iPhones.
  • Zoolookuk - Friday, June 1, 2018 - link

    Wow, I've seen some seriously bad anti-Apple comments over the last 30 years, but this is probably the best one yet. A10 and A11 are not unbalanced and not 'cheating' customers. Anyone with half a brain can the history of this advantage Apple has started with A7, which was the first 64-bit ARM-based SoC in phones. Ever since they, they've been consistently 2 generations ahead of the competition, and that gap shows no sign of closing.

    The comments below this that 'at 3ghz' the (still unreleased) A76 would 'only need a 20% boost' to match last year's A11 is pretty funny. So a chip already at its thermal and power limit "only" needs to be overclocked by 20% to match a chip designed two years ago running 40% slower.
  • techconc - Tuesday, June 5, 2018 - link

    Actual device performance easily disproves your claim. Your comment isn't helpful and you would have more credibility if you at least attempted to justify the claim you made.
  • jjj - Friday, June 1, 2018 - link

    In reality Apple is the one behind but won't bother to explain, just remember the core count for Apple's solutions.

    Anyway, A76 at 3GHz and 750mW per core would require less than a 20% boost in clocks to match Apple's A11 in Geekbench.
    Apple has only 2 large cores and when including the 4 small ones, the SoC throttles hard under 100% load
    If that is what you want, A76 should be able to deliver something close enough when configured as dual core with stupid high clocks. A SoC vendor could push A76 to 2W-3W per core instead of 0.75W and get clocks as high as possible.
    But maybe it's better to have more than enough perf, 4 cores and sane efficiency.
  • Lolimaster - Friday, June 1, 2018 - link

    Please stop using geekbench as a comparison tool specially between 2 different ARM ecosystems.
  • jjj - Friday, June 1, 2018 - link

    You have results for Apple on anything else?
  • Elstar - Friday, June 1, 2018 - link

    Because, crazy as it sounds, most ARM's customers don't want fast off the shelf designs, at least at first. ARM's whole business model is rather simple: they sell simple, affordable, efficient, and feature rich reference designs as a "gateway drug". Once you get hooked on their ecosystem, then they charge a lot for nontrivial customization.
  • name99 - Friday, June 1, 2018 - link

    This is like asking "why doesn't Apple come out with a 5GHz A12?" It's not so much that they can't as that this does not make sense for their business model.

    You can SAY that you want (and would be willing to pay for) Apple level's of performance, but is that really true? God knows Android people complain all the time about how expensive Apple products are, and they MOSTLY buy the midrange phones, not the high end phones. Essential just went bust assuming that more people want to pay for high end Android phones than actually exist.

Log in

Don't have an account? Sign up now