RISC-V Processor Cores

You'll run into a RISC-V core anywhere someone wanted an ARM-class CPU without an ARM-class licensing bill — SSD/HDD controller management planes, sensor hubs, security enclaves, and increasingly the application core itself. This page covers the ISA structure, the vendor landscape (since there's no single company to point at the way there is with ARM), and what that means for silicon integration.

!!! abstract "Why there's no 'gate count' table on this page"

ARM can publish a clean **area-at-a-node-and-library** datasheet because there's one company, one set of hard macros, and a handful of blessed configurations. RISC-V has none of that by design.

RISC-V is an **open ISA specification**, not a product. SiFive, T-Head, Andes, Western Digital, and dozens of others all implement it independently, in their own RTL, targeting whatever node and library their customer wants. There is no "Cortex-M0 of RISC-V" with one datasheet — there's an *E902 from T-Head*, an *E21 from SiFive*, an *AX25 from Andes*, all roughly the same class, all with different area/power depending entirely on who implemented them and how.

So this page does it the way that's actually honest for RISC-V: **the ISA and its extensions first** (that part *is* standardized), **then the vendor/core landscape** (that part isn't), with area and gate-count treated as "ask your vendor" rather than something you can look up centrally.

---

1. Why RISC-V Shows Up Where It Does

RISC-V sells no silicon and, in its base form, isn't even a company's product — it's a specification maintained by RISC-V International, a nonprofit. Anyone can implement it, royalty-free, without asking permission. That's the entire reason it shows up in your flow.

Delivery model	What you get	Trade-off
Open-source RTL (Rocket, BOOM, CVA6, VexRiscv, T-Head's Open* cores)	Free, synthesizable Verilog/Chisel, often Apache/BSD licensed	You own verification and PPA closure entirely. Support is community-based.
Commercial IP core (SiFive, Andes, Codasip, Syntacore)	Verified, supported RTL with a real vendor behind it — closer to the ARM soft-IP experience	You pay a license/royalty, same as ARM soft IP, but for the implementation, not the ISA.
Architecture license / build your own	Design your own core against the open ISA spec, no permission needed	Same enormous engineering cost as an ARM architecture license — except you never had to ask.
Custom extensions	Add your own instructions in the reserved opcode space	Not available on ARM at all outside Arm's own roadmap. This is RISC-V's headline differentiator.

The reason this matters to you as an ASIC designer: the ISA license fee is zero, but "free RTL" and "verified, silicon-proven RTL" are very different things. Your risk shifts from "can I afford the IP" to "do I trust this vendor's verification" — and for open-source cores, the answer is often "not without doing a lot of it yourself."

---

2. The ISA Is Built From Parts — That's the Whole Idea

Where ARM ships you a fixed architecture per profile, RISC-V ships you a minimal mandatory base plus a menu of standard extensions you compose yourself. Everything else on this page is downstream of that one design decision.

RV32I / RV64I / RV32E / RV64E   ← the base: integer-only, load/store, ~40 instructions
        │
        ├── M   Integer multiply/divide
        ├── A   Atomics (LR/SC, AMOs)
        ├── F   Single-precision float
        ├── D   Double-precision float
        ├── C   Compressed 16-bit instructions (code density)
        ├── V   Vector (variable-length SIMD, RVA23's headline feature)
        ├── B   Bit manipulation
        ├── H   Hypervisor (virtualization)
        └── Zicsr, Zifencei, Zk*, Zve*, Zb*, ...   dozens of smaller "Z-named" extensions

"RV64GC" is shorthand for RV64I + M + A + F + D + C ("G" = the common bundle M+A+F+D)

The base ISA (RV32I/RV64I) is what's frozen and ratified — it will never change underneath you. Everything above it is opt-in, which is exactly why RISC-V needed profiles.

!!! tip "The E vs I base — smaller than you'd guess"

**RV32E / RV64E** halve the integer register file (16 registers instead of 32) for the smallest embedded targets, trading some performance for meaningfully less area. There's no ARM equivalent to this — Thumb changes encoding, not register count.

---

3. Profiles — RISC-V's Answer to "A/R/M"

RISC-V didn't have anything like ARM's A/R/M split until fragmentation forced the issue: if every vendor picks a different combination of extensions, no OS distribution or binary app market can target "RISC-V" as a platform. Profiles are the fix — a named, ratified bundle of mandatory + optional extensions, refreshed on a yearly cadence.

Profile family	Rough analogue	Target	Ratified releases
RVA (Application)	A-profile	64-bit, rich-OS application processors (Linux, Android)	RVA20, RVA22, RVA23 (current, Oct 2024)
RVB (Application, options)	A-profile, budget tier	Custom 64-bit application processors built from source, not binary distros — fewer mandatory extensions than RVA	RVB23
RVM (Microcontroller)	M-profile	Deeply embedded, bare-metal / small RTOS	RVI20, RVM23

!!! tip "What RVA23 actually locked in"

RVA23 is the profile release that matters right now: it's the first to make the **Vector extension (V) mandatory** for application-class cores, and it added the **Hypervisor extension (H)**. Vector is also the baseline for the Android RISC-V ABI going forward, so RVA23 compliance is becoming the practical bar for "can this core run mainstream binaries."

There's a real difference from ARM's SVE here: RVV is **vector-length-agnostic** — the same compiled binary runs on a core with a 128-bit vector unit or a 1024-bit one without recompiling, because the hardware width isn't baked into the instruction encoding.

Notice what's missing: there's no RVA-equivalent machine-mode profile, and no RISC-V profile plays the exact role of ARM's R-profile (hard real-time + lockstep + MPU). Real-time RISC-V designs today are built from the RVM/embedded space plus vendor-specific safety features (ECC, lockstep) rather than a single ratified "R-profile."

!!! tip "Relevant to your storage work"

**This is exactly the gap Western Digital's SweRV cores were built to fill.** WD open-sourced the SweRV EH1/EH2/EL2 family specifically for **flash and HDD controller firmware** — deterministic, low-latency, no MMU, the same job Cortex-R5/R8 does in an ARM-based controller. If you see a RISC-V core doing FTL/media-management work instead of an ARM R-profile core, SweRV (or a similar small in-order commercial core from SiFive's E-series or Andes) is the likely shape of it.

---

4. The Vendor Landscape

This is the section that has no ARM equivalent at all — there is no "the" RISC-V core lineup, because there is no single vendor. Below are the ones you'll actually encounter in silicon today.

=== "SiFive"

The RISC-V vendor closest to ARM's soft-IP business model: configurable, licensed, verified core families sold across the same market segments ARM's profiles cover.

| Family | Analogue | Class | Examples |
|---|---|---|---|
| **Essential — E-series** | Cortex-M | 32/64-bit deeply embedded, area-optimized | E2 (smallest), E6, E7 |
| **Essential — S-series** | Cortex-M/R boundary | 64-bit, power/area-balanced embedded | S2, S6, S7 |
| **Essential — U-series** | Cortex-A5x | 64-bit, Linux-capable, in-order superscalar | U54, U74, U84 |
| **Performance — P-series** | Cortex-A7x/A75-A77 | Out-of-order application cores | P270 (in-order+vector), P550/P650 (OoO) |
| **Intelligence — X-series** | — (no ARM analogue) | Vector-heavy cores for edge AI/ML | X280 (512-bit vector datapath) |

The **U74** is the one you've most likely already touched indirectly — it's the application core in the SiFive FU740 SoC that powers the HiFive Unmatched board, and it's the reference point most benchmarks compare newer RISC-V cores against.

=== "T-Head (Alibaba)"

China's dominant commercial RISC-V core supplier, and unusual for having **open-sourced its RTL** (Apache 2.0) alongside a closed commercial offering — the "Open" prefix distinguishes the two (OpenC910 vs. C910).

| Core | Class | Pipeline | Notes |
|---|---|---|---|
| **XuanTie E902** | Smallest MCU-class | 2-stage in-order | Roughly Cortex-M0 territory |
| **XuanTie E906/E907** | Mid MCU-class | In-order | Roughly Cortex-M3/M4 territory |
| **XuanTie C906** | Application, low-power | 5-stage in-order | Powers the Allwinner D1 — the first mass-market RISC-V Linux SBC chip |
| **XuanTie C910** | High-performance | 12-stage, 3-issue **out-of-order** | One of the only OoO RISC-V cores in volume silicon; roughly Cortex-A73 class |
| **XuanTie C920 / C920v2** | High-performance, RVV 1.0 | 12-stage OoO | Powers the SG2042/SG2044 64-core RISC-V HPC chips |

!!! tip "Why C910/C920 matter beyond the spec sheet"

    Independent microarchitecture teardowns (Chips and Cheese) put the **C910 in the same performance class as Cortex-A73** — respectable, but a clear step behind current ARM big cores, and well behind SiFive's own P550. It's the honest current answer to "how close is RISC-V to ARM on performance": closing, not closed.

=== "Andes"

A long-established embedded CPU IP vendor (pre-dating its RISC-V pivot) that now ships the **AndesCore** family — strong in the automotive and general MCU space, with DSP and vector variants.

| Family | Class |
|---|---|
| **N-series / NX-series** | 32-bit embedded, DSP-capable |
| **A-series / AX-series** | 64-bit application-class, MMU-capable, Linux |
| **AX45MPV / NX27V** | Vector-extended variants (configurable 128–1024-bit) |

=== "Western Digital"

Not a general-purpose IP vendor — WD built and **open-sourced the SweRV family** to run its own storage controller firmware, then released it for anyone to use. This is the one on this page you're most likely to touch directly in a storage design.

| Core | Pipeline | Target |
|---|---|---|
| **SweRV EH1** | 9-stage, dual-issue in-order | General embedded control |
| **SweRV EH2** | EH1 + 2-way SMT | Higher throughput per area |
| **SweRV EL2** | 2-stage, smallest | Area-critical, lowest power |

=== "Open-source cores"

No vendor, no license fee, no verification guarantee beyond what the community has thrown at it.

| Core | Origin | Notes |
|---|---|---|
| **Rocket** | UC Berkeley (the original RISC-V reference design) | In-order, 5-stage — the "it just works" baseline everyone benchmarks against |
| **BOOM** | UC Berkeley | Out-of-order superscalar, research-grade, the OoO reference design |
| **CVA6 (Ariane)** | ETH Zürich / OpenHW Group | 64-bit, Linux-capable, widely used in academic and OpenHW-verified flows |
| **VexRiscv** | SpinalHDL community | Highly configurable, FPGA-friendly, popular for small SoCs |

---

5. What "Gate Count" Even Means Here

For an ARM Cortex-M, "area at 40LP, minimum config" is a real, look-up-able number because ARM controls the implementation. For RISC-V, the honest answer is a chain of questions:

"How big is a RISC-V core?"
  │
  ├─ Which core? (E902 ≠ E21 ≠ VexRiscv, even at the same nominal class)
  │
  ├─ Whose RTL? (vendor-verified commercial IP vs. open-source, unverified-by-anyone-but-you)
  │
  ├─ Which extensions enabled? (M/A/F/D/C/V all cost area — same lesson as ARM's FPU line item)
  │
  └─ Synthesized by whom, on what library, with what timing target?
       → THIS is where the real number comes from. Not a datasheet. Your own synthesis run.

!!! danger "The comparison that actually holds"

The **shape** of the ARM gate-count lesson still applies to RISC-V — configuration costs area, floating-point and vector costs a lot of area, caches dominate at the top end — you just can't get the numbers from a vendor PDF the way you can with ARM. You get them by **synthesizing the RTL yourself**, which for a commercial IP core (SiFive, Andes) is a normal part of the evaluation license, and for an open-source core is simply the first thing you have to do before trusting any area claim you read online.

Third-party area comparisons (SiFive vs. ARM equivalents, T-Head vs. Cortex-A73) exist and are directionally useful, but treat every one of them as **one data point at one node with one toolchain**, not a datasheet.

---

6. What You Actually Have to Integrate

Largely the same job as an ARM integration, with two differences worth flagging up front.

---

7. Choosing a Core

Do you need to run Linux / a rich OS, and want commercial support?
│
├─ YES ──► SiFive Performance (P270/P550/P650) or T-Head C910/C920.
│          → You now own an MMU, and — same as ARM — a bus fabric and
│            interrupt controller integration, but NOT a standardized
│            security architecture. Budget separately for that.
│
└─ NO
   │
   ├─ Deterministic, real-time, storage/automotive control-plane firmware?
   │  (the RISC-V analogue of "R-profile" territory)
   │  │
   │  └─ YES ──► WD SweRV (open, storage-proven), SiFive S-series,
   │             or Andes N/A-series. No ratified "R-profile" exists yet —
   │             expect to assemble determinism from PMP + tightly-coupled
   │             memory + vendor-specific lockstep, not a single named feature.
   │
   └─ Area/power-critical, deeply embedded, no OS or tiny RTOS?
      │
      └─ MCU-class.
         │
         ├─ Absolute smallest, license-free      ──► T-Head OpenE902, VexRiscv
         ├─ Smallest, commercially verified       ──► SiFive E2-series
         ├─ General purpose 32-bit                ──► SiFive E21/E6, Andes N-series
         ├─ 64-bit embedded with DSP              ──► SiFive S7/E7, Andes NX-series
         ├─ Vector at the edge (AI/ML inference)  ──► SiFive X280, Andes NX27V
         └─ Need silicon-proven + support contract ──► Pay for SiFive or Andes,
                                                         don't roll your own from Rocket/BOOM

---

8. Study Checklist

The gate/area question

• [ ] Explain why RISC-V has no centralized area/gate datasheet the way ARM does, and what that implies for your evaluation process
• [ ] State the chain of questions ("which core, whose RTL, which extensions, synthesized how") that any RISC-V area claim needs answered before it's usable
• [ ] Explain why configuration and extension choice (M/A/F/D/C/V) still costs area on RISC-V, same as ARM's debug/trace/FPU lesson — just without a vendor PDF to read it off of

Fundamentals

• [ ] Explain the base-ISA-plus-extensions model and what "RV64GC" expands to
• [ ] Name the three profile families (RVA, RVB, RVM) and what each targets
• [ ] Explain what RVA23 made mandatory and why that matters for binary software portability
• [ ] Explain vector-length agnosticism (RVV) and how it differs from a fixed-width SIMD extension
• [ ] Explain why there's no ratified "R-profile" equivalent yet, and what fills that role today

Vendor landscape

• [ ] Name at least one commercial vendor and one open-source core in each rough performance class (MCU / embedded / application)
• [ ] Explain the difference between T-Head's open (Apache 2.0) and closed core offerings
• [ ] Explain why Western Digital's SweRV cores are directly relevant to storage-controller work
• [ ] State which RISC-V core is the most-benchmarked reference point for "how fast is RISC-V getting" (U74) and which is the current OoO high-water mark (C910/C920, SiFive P550)

Integration

• [ ] Name the RISC-V equivalents of AMBA (no single mandated bus), GIC/NVIC (PLIC), CoreSight (RISC-V Debug Spec), and TrustZone (PMP + vendor-specific — no single standard)
• [ ] Explain PMP vs. MPU vs. MMU vs. Sv39/Sv48
• [ ] Explain why security architecture does not port cleanly across RISC-V vendors the way TrustZone ports across ARM licensees
• [ ] Explain the added verification burden of open-source RTL versus a commercially verified core

---

References

ISA and profiles — primary sources

• RISC-V Ratified Specifications Library — the unprivileged and privileged ISA specs, and every ratified profile (RVA20/22/23, RVB23, RVI20/RVM23)
• RVA23 Profile — RISC-V International announcement
• riscv/riscv-profiles GitHub — source of truth for profile definitions, including RVB23

Vendor core families

• SiFive RISC-V Core IP portfolio — Essential, Performance, Intelligence families
• SiFive Performance P550 launch — BusinessWire
• T-Head XuanTie core overviews — RISC-V International IP catalog
• Alibaba/T-Head open-sources E902, E906, C906, C910 — CNX Software
• Western Digital SweRV core family — GitHub

Independent performance analysis

• Inside SiFive's P550 Microarchitecture — Chips and Cheese
• Alibaba/T-Head's Xuantie C910 — Chips and Cheese
• A RISC-V Progress Check: Benchmarking P550 and C910 — Chips and Cheese
• Commercially available RISC-V silicon — Muxup

---

!!! note "Reproducing an area estimate for your own use case"

There's no calibration table to hand you here the way there is for ARM. If you need a real number: get evaluation RTL from the vendor (or pull the open-source core), synthesize it in **your own library** at **your own target frequency**, and treat every third-party comparison you've read as a sanity check on that number — not a substitute for it.