ARM Processor Cores

Almost every ASIC you will ever work on has an ARM core in it somewhere — running firmware, handling the boot chain, managing the control plane. This page covers the core families, what they actually cost you in silicon, and what you have to integrate around them.

!!! abstract "The gate-count question, answered properly"

ARM **does not publish gate counts.** Its datasheets publish **area in mm², at a named library, track height, threshold-voltage flavor, process node, and PVT corner** — bracketed between a *minimum configuration* and a *feature-rich / typical configuration*.

That's not evasion. It's the only honest way to state it, because a gate count for a configurable soft core is a range, not a number.

So this page does it the right way round: **ARM's published area first, then a derived gate estimate** using a NAND2 cell area representative of each library class. The method is calibrated against ARM's own figure and shown below, so you can redo it for your library.

---

1. Why ARM Shows Up in Every ASIC

ARM sells no chips. It licenses IP — and the licensing model is why it's ubiquitous.

Delivery model	What you get	Trade-off
Soft IP (RTL)	Synthesizable Verilog. You configure, synthesize, and place-and-route it in your flow, on your node.	Maximum flexibility, portable across foundries. You own PPA closure — and you can miss.
Hard macro / POP	Processor Optimization Pack: a physical implementation kit tuned to a specific foundry node and library, with reference floorplans and constraints.	Much lower risk of missing frequency. Locks you to that node.
Architecture license	The right to build your own core implementing the ARM ISA.	What Apple, Qualcomm (Nuvia), and Ampere do. Enormous engineering cost.
Flexible Access	Evaluate and design against a broad IP catalog; pay at manufacture.	How most small teams start.

The reason this matters to you as an ASIC designer: the core is usually not where your design risk lives. ARM has closed timing on that RTL a thousand times. Your risk is in the fabric, the clock/reset architecture, the CDC around it, and the memory subsystem you bolt on.

---

2. The Three Profiles

Everything ARM makes falls into one of three profiles. This is the most load-bearing fact on the page.

┌──────────────┬──────────────────┬─────────────────┬────────────────────┐
│              │   A-PROFILE      │   R-PROFILE     │    M-PROFILE       │
│              │   (Application)  │   (Real-time)   │  (Microcontroller) │
├──────────────┼──────────────────┼─────────────────┼────────────────────┤
│ Runs         │ Linux, Android   │ RTOS, bare metal│ RTOS, bare metal   │
│ Memory       │ MMU (virtual mem)│ MPU (+ optional │ MPU (no virtual    │
│              │                  │  MMU on R82)    │  memory, ever)     │
│ Design goal  │ Throughput       │ Determinism +   │ Area, power,       │
│              │                  │  fault tolerance│  interrupt latency │
│ Caches       │ L1 + L2 (+ L3)   │ L1 + TCM        │ Optional / TCM     │
│ Pipeline     │ Deep, OoO on the │ In-order or     │ 2–6 stage in-order │
│              │  big ones        │  modest OoO     │  (M7 dual-issue)   │
│ Safety       │ Some ASIL support│ Lockstep, ECC,  │ Some (M7, M33)     │
│              │                  │  ASIL-D         │                    │
│ Typical use  │ Phone, server,   │ Storage ctrl,   │ Sensor, IoT node,  │
│              │  set-top, SoC AP │  automotive,    │  power mgmt, PMU   │
│              │                  │  modem, 5G      │                    │
└──────────────┴──────────────────┴─────────────────┴────────────────────┘

  The MMU is the dividing line. If it can run Linux, it's A-profile.

!!! tip "Relevant to your storage work"

**SSD controllers are the R-profile's home turf.** An enterprise NVMe controller typically runs several **Cortex-R5 / R8 / R52** cores for the FTL, media management, and host interface — because the FTL needs bounded, deterministic latency and can't tolerate MMU/TLB-miss jitter. Many designs add a **Cortex-A53/A55** for the management plane (telemetry, secure boot, firmware update) and small **Cortex-M** cores for power sequencing.

The firmware doing the reclaim bookkeeping on the FDP page is almost certainly running on an R-profile core.

---

3. Method: From ARM's Area to a Gate Estimate

The conversion

$$\text{Gate equivalents} = \frac{\text{Area}\ (\mu m^2)}{\text{NAND2 cell area}\ (\mu m^2)}$$

A "gate" in the industry sense is a NAND2 equivalent — total cell area normalized to the area of one 2-input NAND. So all you need is the NAND2 area for the library ARM quoted.

NAND2 reference areas

Representative NAND2 cell areas for the library classes appearing in ARM's Cortex-M datasheets:

Library class	NAND2 area	Notes
90LP, 7-track, RVt (Arm SC7)	2.50 µm²
65LP, 8-track, RVt	1.55 µm²	Taller cells partly offset the node shrink
40LP, 9-track, RVt (Arm SC9)	0.61 µm²
28HPM, 9-track, HVt	0.32 µm²
16nm-class, 9-track	~0.10 µm²	Least reliable of the set — treat as indicative

!!! success "Calibration check — the method validates itself"

ARM separately states the Cortex-M0 minimum configuration is **~12k gates**. Running that core's published areas through the table above:

| Node | ARM's area | ÷ NAND2 | **Derived** |
|---|---|---|---|
| 90LP | 0.0303 mm² = 30,300 µm² | ÷ 2.50 | **12.1k gates** |
| 40LP | 0.0073 mm² = 7,300 µm² | ÷ 0.61 | **12.0k gates** |

Two independent nodes, two independent library classes, and both land on **12k** — matching ARM's own published figure. The method works, and the NAND2 areas above are sound enough to apply to the rest of the family.

!!! warning "Where it drifts: the 28HPM column"

You'll notice below that gate counts derived from the **28HPM** area run systematically **~25–30% higher** than the same core at 90/65/40 nm. That's real, and it's worth understanding rather than hiding:

- **HVt cells** (high threshold voltage) are used at 28HPM in ARM's table, and the library/track mix differs.
- More aggressive synthesis at the smaller node means **more buffering and upsizing** to hit timing — the tool spends area to make frequency.
- My 28HPM NAND2 figure carries more uncertainty than the 90/40 ones.

Treat the 90/65/40 columns as the reliable estimate and 28HPM as the upper bound. **The spread itself is the lesson: the "gate count" of a core is a property of the implementation, not of the RTL.**

---

4. Cortex-M — Area and Derived Gates

ARM's published area (verbatim)

=== "Cortex-M0"

**Armv6-M · 3-stage · 0.87 DMIPS/MHz · 2.25 CoreMark/MHz**

| Configuration | 90LP (SC7 RVT, SS 1.08 V, 125 °C) | 40LP (SC9 RVT C50, SS 0.99 V, 125 °C) |
|---|---|---|
| **Minimum** | 0.0303 mm² · 12.5 µW/MHz | 0.0073 mm² · 5.1 µW/MHz |
| **Typical** | 0.0604 mm² · 16.6 µW/MHz | 0.0155 mm² · 6.7 µW/MHz |
| *Max freq (typical)* | 268 MHz | 280 MHz |

<small>**Minimum** = 1 IRQ, small multiplier, no debug, no WIC, 0 breakpoints, 0 watchpoints<br>
**Typical** = 32 IRQ, fast multiplier, debug, SysTick, WIC (34 lines), 4 breakpoints, 2 watchpoints</small>

=== "Cortex-M0+"

**Armv6-M · 2-stage · 0.95 DMIPS/MHz · 2.39 CoreMark/MHz**

| Configuration | 90LP (SC7 RVT, SS 1.08 V, 125 °C) | 40LP (SC9 RVT C50, SS 0.99 V, 125 °C) |
|---|---|---|
| **Minimum** | 0.0275 mm² · 9.36 µW/MHz | 0.0066 mm² · 3.8 µW/MHz |
| **Typical** | 0.0576 mm² · 13.04 µW/MHz | 0.0141 mm² · 5.5 µW/MHz |
| *Max freq (typical)* | 567 MHz | 297 MHz |

Note the M0+ is **smaller and lower-power than the M0 at every point** — the 2-stage pipeline is a pure win on both axes. There is essentially no reason to choose M0 over M0+ in a new design.

=== "Cortex-M3"

**Armv7-M · 3-stage · 1.25 DMIPS/MHz · 3.34 CoreMark/MHz**

| Configuration | 90LP (7T RVt) | 65LP (8T RVt) | 40LP (9T RVt) | 28HPM (9T HVt) |
|---|---|---|---|---|
| **Minimum** | 0.091 mm² · 31.18 µW/MHz | 0.060 mm² · 24.04 | 0.024 mm² · 11.39 | 0.016 mm² · 8.11 |
| **Feature Rich** | 0.219 mm² · 35.33 µW/MHz | 0.127 mm² · 31.28 | 0.051 mm² · 13.24 | 0.036 mm² · 9.02 |
| *Max freq* | — | — | 248 MHz | 891 MHz |

<small>**Minimum** = no MPU, 1 IRQ, no trace, no debug, no WIC, no bit-banding<br>
**Feature Rich** = MPU, 32 IRQ, trace level 2, debug level 3, WIC (67 lines)</small>

=== "Cortex-M4"

**Armv7E-M · 3-stage + branch speculation · 1.25 DMIPS/MHz · 3.42 CoreMark/MHz**

| Configuration | 90LP (7T RVt) | 65LP (8T RVt) | 40LP (9T RVt) | 28HPM (9T HVt) |
|---|---|---|---|---|
| **Minimum** (no FPU) | 0.119 mm² · 32.82 µW/MHz | 0.076 mm² · 26.40 | 0.028 mm² · 12.26 | 0.020 mm² · 8.47 |
| **Feature Rich** (FPU) | 0.304 mm² · 41.47 µW/MHz | 0.201 mm² · 35.54 | 0.082 mm² · 15.48 | 0.053 mm² · 11.20 |
| *Max freq* | — | — | 223 MHz | 822 MHz |

<small>**Feature Rich** = MPU, 64 IRQ, trace level 2, debug level 3, WIC, **FPU present**</small>

=== "Cortex-M7"

**Armv7E-M · 6-stage dual-issue superscalar · 2.14 DMIPS/MHz · 5.01 CoreMark/MHz**

ARM quotes the M7 **split into core and memory** — because at this size the caches/TCMs are a separate, dominant line item. Typical configuration = 32 KB I/D cache with ECC.

| Configuration | ~40nm-class (RVT 9T) | ~28nm-class (SVT 9T) | ~16nm-class (SVT) |
|---|---|---|---|
| **Typical — core** | 0.213 mm² · 72.2 µW/MHz | 0.108 mm² · 41.4 | 0.055 mm² · 26 |
| **Typical — memory** | 0.261 mm² · 46 µW/MHz | 0.127 mm² · 15.8 | 0.092 mm² · 16 |
| *Max freq* | 400 MHz | 1.1 GHz | 1.4 GHz |

!!! danger "Look at the memory row"

    **The memory is bigger than the core.** 0.261 mm² of SRAM against 0.213 mm² of logic. This is the exact moment where "gate count" starts to lose meaning — and it only gets worse going up into Cortex-A, where caches utterly dominate.

    It also means: **quote M7 area with the cache config attached or the number is meaningless.**

Derived gate estimates

Applying the NAND2 table to ARM's areas:

Core	Config	90LP	65LP	40LP	28HPM	Headline estimate
Cortex-M0	Minimum	12.1k	—	12.0k	—	~12k
Cortex-M0	Typical	24.2k	—	25.4k	—	~25k
Cortex-M0+	Minimum	11.0k	—	10.8k	—	~11k
Cortex-M0+	Typical	23.0k	—	23.1k	—	~23k
Cortex-M3	Minimum	36.4k	38.7k	39.3k	50.0k	~37–40k
Cortex-M3	Feature Rich	87.6k	81.9k	83.6k	112.5k	~85k
Cortex-M4	Minimum (no FPU)	47.6k	49.0k	45.9k	62.5k	~47k
Cortex-M4	Feature Rich (FPU)	121.6k	129.7k	134.4k	165.6k	~130k
Cortex-M7	Typical, core only	—	—	349k	338k	~340k (+ SRAM)

Headline estimate uses the 90/65/40 nm columns, which agree within a few percent. The 28HPM column runs high for the reasons above and is best read as an upper bound.

The shape of the curve

This is the thing worth carrying in your head:

GATE COUNT, minimum config, normalized to Cortex-M0:

  Cortex-M0+   11k   ████                         0.9x   ← smallest
  Cortex-M0    12k   ████                         1.0x   (baseline)
  Cortex-M3    38k   ██████████████               3.2x
  Cortex-M4    47k   █████████████████            3.9x
                                                          (+DSP over M3)

FULLY CONFIGURED (the number that actually lands in your netlist):

  Cortex-M0+   23k   ████                         1.9x
  Cortex-M0    25k   █████                        2.1x
  Cortex-M3    85k   █████████████████            7.1x
  Cortex-M4   130k   ██████████████████████████  10.8x   (with FPU)
  Cortex-M7   340k   ████████████████...          28x    (core only —
                                                          SRAM is extra
                                                          and is BIGGER)

TWO THINGS TO NOTICE:

  1. Configuration costs MORE than architecture at the low end.
     A fully-configured M0 (25k) is 2x a minimum M0 (12k).
     Debug + trace + 32 IRQs is not free — it roughly DOUBLES the core.

  2. The FPU is expensive.
     M4 min (no FPU) = 47k.  M4 feature-rich (with FPU) = 130k.
     Some of that is debug/trace, but the FPU is a large chunk of it.
     If you don't need single-precision float, don't pay for it.

!!! tip "The number to quote in a design review"

If someone asks "how big is a Cortex-M4?", the correct answer is a question: **"In what configuration, on what node, at what frequency?"**

If they insist on one number: **~50k gates without FPU, ~130k with FPU and full debug/trace.** Then immediately add that you'll confirm it by synthesizing the RTL in your own library, because that is the only number that will ever be true.

---

5. Cortex-M Feature Matrix

Core	ISA	Pipeline	DMIPS/MHz	CoreMark/MHz	FPU	DSP	TrustZone	HW Div	Est. gates (full)
Cortex-M0	Armv6-M	3-stage	0.87	2.25	—	—	—	—	~25k
Cortex-M0+	Armv6-M	2-stage	0.95	2.39	—	—	—	—	~23k
Cortex-M1	Armv6-M	3-stage	0.8	—	—	—	—	—	FPGA — sized in LUTs
Cortex-M23	Armv8-M Baseline	2-stage	0.98	—	—	—	Option	✓	~90k†
Cortex-M3	Armv7-M	3-stage	1.25	3.34	—	—	—	✓	~85k
Cortex-M4	Armv7E-M	3-stage	1.25	3.42	SP option	✓	—	✓	~130k (FPU)
Cortex-M33	Armv8-M Mainline	3-stage	~1.5	~4.0	SP option	Option	Option	✓	~150k†
Cortex-M35P	Armv8-M Mainline	3-stage	~1.5	—	SP option	Option	Option	✓	—
Cortex-M55	Armv8.1-M	—	~1.6	~4.4	HP/SP/DP	✓	Option	✓	—
Cortex-M7	Armv7E-M	6-stage dual-issue	2.14	5.01	SP/DP option	✓	—	✓	~340k + SRAM
Cortex-M85	Armv8.1-M	—	—	—	✓	✓	Option	✓	—

Bold gate figures are derived from ARM's published area above. † marked figures are third-party estimates — ARM doesn't publish comparable area tables for these cores, so treat them as much softer.

Notable additions:

• M35P = M33 + physical tamper resistance (anti-DPA, anti-fault-injection).
• M55 / M85 = Helium (M-profile Vector Extension) — SIMD for on-device ML inference.
• M23 = "M0+ with TrustZone." M33 = "M4 with TrustZone" (and AHB5, 480 IRQs, coprocessor interface).

---

6. Cortex-R — Real-Time Profile

Determinism over throughput. TCMs instead of (or alongside) caches, because a cache miss is a latency you cannot bound. Lockstep and ECC for functional safety.

Core	ISA	Key features	Safety	Typical use
Cortex-R5	Armv7-R	Dual-core lockstep, TCM, ECC, low interrupt latency	ASIL-D capable	SSD/storage controllers, automotive, modem
Cortex-R8	Armv7-R	Up to 4 cores, higher perf, TCM + caches	ASIL-D capable	Enterprise SSD controllers, 5G modem
Cortex-R52	Armv8-R	Hardware virtualization (EL2 hypervisor), strong isolation	ASIL-D	Automotive domain controllers, mixed-criticality
Cortex-R52+	Armv8-R	R52, higher performance	ASIL-D	Same, higher tier
Cortex-R82	Armv8-R 64-bit	First 64-bit R-profile. Optional MMU — can run Linux.	ASIL-D	Computational storage, high-end SSD controllers

!!! tip "Why Cortex-R82 matters for storage"

R82 is the first R-profile core with an **optional MMU**, so one core can run a deterministic RTOS *and* a Linux application environment. For **computational storage** — running user workloads on the drive itself — that's the enabling feature. It's the core to know if SSD controllers are your target.

The R-profile pattern: TCM, not cache

CACHE (A-profile / general purpose)
  - Hardware-managed, transparent
  - Hit: fast.  Miss: 100+ cycles, and you don't know when
  - Great average throughput, UNBOUNDED worst case

TIGHTLY-COUPLED MEMORY (R-profile, and M7)
  - Explicit address range. SRAM adjacent to the core.
  - ALWAYS single-cycle. No miss. No eviction. No surprise.
  - Firmware puts the ISR, the hot FTL path, the critical loop here.
  - YOU manage what lives there. That's the cost.

  ITCM = instruction TCM.   DTCM = data TCM.

Why an SSD controller cares:  a 99.99th-percentile latency SLA cannot be
met by a core that might take a 200-cycle cache miss in the middle of an
FTL lookup. Put the lookup in DTCM and the jitter disappears.

---

7. Cortex-A and Neoverse — Application Profile

!!! danger "Gate count is meaningless here — and now you can see why"

Look back at the Cortex-M7 numbers: at 40nm, the core is 0.213 mm² and the *memory* is 0.261 mm². Memory already exceeds logic at the top of the M-profile.

An A-profile core is far worse: L1 I/D caches, L2, TLBs, branch-prediction tables, and often a shared L3/SLC. **Most of the transistors aren't logic gates at all.** Quoting "gates" for a Cortex-A78 tells you nothing. The industry quotes **mm² at a node with a stated cache configuration**, or it quotes nothing.

This is the complete answer to "how many gates?" — it has a clean answer for Cortex-M, a degrading answer for M7, and no meaningful answer for Cortex-A.

Core	Year	ISA	Pipeline	Position
Cortex-A5 / A7	2009–11	Armv7-A	In-order	Legacy little cores
Cortex-A9	2007	Armv7-A	Out-of-order	The classic 32-bit AP
Cortex-A53	2012	Armv8-A	In-order, 8-stage	The workhorse. Still everywhere: set-top, networking, SSD mgmt plane
Cortex-A55	2017	Armv8.2-A	In-order	A53 successor, DynamIQ
Cortex-A510 / A520	2021–23	Armv9-A	In-order	Current LITTLE
Cortex-A72 / A73	2015–16	Armv8-A	OoO	Mid/big of their era
Cortex-A76 / A78	2018–20	Armv8.2-A	OoO	big cores
Cortex-A7xx	2021+	Armv9-A	OoO	Current middle
Cortex-X series	2020+	Armv8/9-A	Wide OoO	Max performance, area be damned

Neoverse — the infrastructure line

Core	Target	Notes
Neoverse E1	Throughput / edge	SMT, efficiency-focused
Neoverse N1	Cloud / scale-out	AWS Graviton2. The one that proved ARM in the datacenter.
Neoverse N2	Cloud	Armv9, SVE2
Neoverse V1	HPC	Wide vectors (SVE), Graviton3
Neoverse V2	HPC / AI	NVIDIA Grace

Why an ASIC designer cares: Neoverse ships with CMN (Coherent Mesh Network). If you're building a many-core SoC, the mesh and its coherency protocol are a far larger integration problem than the cores.

---

8. What You Actually Have to Integrate

The core is the easy part. This is the work.

---

9. Choosing a Core

Do you need to run Linux / a rich OS?
│
├─ YES ──► A-profile.  Cortex-A53/A55 if area & power matter (still the
│          most-shipped 64-bit core). A7xx / X if you need speed.
│          Neoverse if it's infrastructure / scale-out.
│          → You now own an MMU, cache coherency, and a GIC.
│
└─ NO
   │
   ├─ Hard real-time determinism, functional safety, or lockstep?
   │  (storage controller, automotive, modem)
   │  │
   │  └─ YES ──► R-profile.  R5 for classic embedded control.
   │             R8 for more throughput. R52 for a hypervisor.
   │             R82 for 64-bit / optional MMU (→ computational storage).
   │
   └─ Area/power-critical, deeply embedded, no OS or small RTOS?
      │
      └─ M-profile.
         │
         ├─ Absolute smallest (~11k gates min)      ──► M0+
         ├─ Smallest WITH TrustZone                 ──► M23
         ├─ General purpose, no DSP (~85k full)     ──► M3
         ├─ DSP / motor control / audio (~130k+FPU) ──► M4
         ├─ DSP + TrustZone                         ──► M33
         ├─ Physical attack resistance              ──► M35P
         ├─ ML inference at the edge (Helium)       ──► M55 / M85
         └─ Max M-profile performance (~340k+SRAM)  ──► M7 (or M85)

---

10. Study Checklist

The area/gate question

• [ ] Explain why ARM publishes mm² at a stated library/node/corner rather than gate counts
• [ ] Convert an area to a gate estimate: gates = area(µm²) ÷ NAND2 area(µm²)
• [ ] Reproduce the calibration: Cortex-M0 min config → ~12k gates from both 90LP and 40LP
• [ ] Explain why the 28HPM-derived counts run ~25–30% high
• [ ] Explain why gate count degrades in meaning for M7 and collapses entirely for Cortex-A
• [ ] State the two lessons from the gate curve: configuration ≈ doubles the core, and the FPU is expensive

Numbers worth knowing cold

• [ ] Cortex-M0 min ≈ 12k, full ≈ 25k
• [ ] Cortex-M3 min ≈ 38k, full ≈ 85k
• [ ] Cortex-M4 min ≈ 47k, full with FPU ≈ 130k
• [ ] Cortex-M7 core ≈ 340k — and its SRAM is larger than its logic

Fundamentals

• [ ] Name the three profiles and the one feature separating A from R/M (the MMU)
• [ ] Explain why storage controllers use R-profile, not A-profile
• [ ] Explain TCM vs. cache and why determinism forces the choice
• [ ] State what makes Cortex-R82 significant (64-bit, optional MMU → computational storage)
• [ ] Explain what M0+ changed vs. M0 — and why it's smaller and faster and lower power

Integration

• [ ] Name the AMBA protocols and which core family uses each
• [ ] Distinguish AXI, ACE-Lite, and ACE
• [ ] Explain NVIC vs. GIC and which profile uses which
• [ ] Explain MMU vs. MPU vs. TCM
• [ ] Explain how TrustZone's security attribute must propagate through the fabric

---

References

Primary sources — every area, power, and frequency figure on this page

These are the datasheets the §4 tables are transcribed from. If you only bookmark one thing, bookmark these.

• Arm Cortex-M0 Processor Datasheet (PDF) — 90LP / 40LP area + power, min vs. typical config
• Arm Cortex-M0+ Processor Datasheet (PDF)
• Arm Cortex-M3 Processor Datasheet (PDF) — four nodes: 90LP / 65LP / 40LP / 28HPM · landing page
• Arm Cortex-M4 Processor Datasheet (PDF) — note the min (no FPU) vs. feature-rich (FPU) split
• Arm Cortex-M7 Processor Datasheet (PDF) — the one that splits core vs. memory area · landing page

Feature matrix

• Arm Cortex-M Processor Comparison Table (PDF) — the authoritative ISA / TrustZone / Helium / FPU / DSP matrix across the whole M family

Product and TRM landing pages

• Cortex-M0 · Cortex-M4 · Cortex-M7
• Cortex-M7 Technical Reference Manual — build-time config options (FPU, TCM, I-cache, D-cache)

Standards

• AMBA Specifications — AHB5, AXI4, ACE, CHI (developer.arm.com → AMBA)

---

!!! note "Reproducing the gate estimates"

Every gate figure here is `ARM's published area ÷ NAND2 cell area` using the reference table in §3. Swap in the NAND2 area from **your** library's databook and rerun it — that's the number that will actually hold in your netlist.

The calibration to check your NAND2 assumption against: **Cortex-M0 minimum config must come out at ~12k gates**, which is the figure ARM states independently. If your arithmetic doesn't reproduce that, your NAND2 area is wrong.