Skip to content
Automotive Fundamentals

Anatomy of an SoC

TL;DR

A System-on-Chip (SoC) is not one processor; it’s a small city of specialized compute blocks sharing memory and buses. On a Qualcomm cockpit SoC (SA8155P, SA8295P), you’ll find Kryo CPU cores for general OS work, Adreno GPU for graphics, Hexagon DSP for always-on audio/sensor processing, NPU for AI inference, ISP for camera pipelines, and a modem for cellular connectivity. Each block runs different firmware and gets flashed separately. Understanding which “building” does what is the foundation for everything else in this curriculum.

You interact with QNX, AAOS, and AMSS every day, but those are software layers running on hardware blocks you may never have mapped. This page gives you that map.

Why “SoC” and Not Just “CPU”

Section titled “Why “SoC” and Not Just “CPU””

A microcontroller (MCU) might be a single ARM core with a few kilobytes of RAM. A microprocessor (MPU) is a general-purpose CPU that needs external chips for memory and peripherals. An SoC integrates CPU, GPU, DSP, memory controllers, I/O, and often a modem onto one die: one package soldered to the board.

In automotive cockpit platforms, that single chip runs:

  • Your QNX hypervisor and safety VMs
  • Your AAOS infotainment stack
  • Your AMSS modem firmware for LTE/5G telematics

The Snapdragon Cockpit City

Section titled “The Snapdragon Cockpit City”

Qualcomm names its blocks with brand names. Learn them once and you’ll recognize them in partition maps, build configs, and crash logs forever. Worth the effort.

Block Qualcomm Name Primary Job Typical Automotive Use
CPU Kryo (ARM-based) General-purpose compute, OS scheduling QNX, Android kernel, app runtime
GPU Adreno Parallel graphics rendering Instrument cluster UI, nav maps, 3D HMI
DSP Hexagon Low-power signal processing Audio processing, sensor fusion, wake-word detection
NPU Hexagon / AI Engine Neural network inference Driver monitoring, cabin sensing, voice AI
ISP Spectra (Image Signal Processor) Camera pipeline (debayer, HDR, noise reduction) Surround-view, DMS camera, rear camera
Modem Snapdragon X-series (inside AMSS) Cellular baseband, RF control Telematics, OTA, eCall, connected services
Mental Model

An SoC is a city. The CPU (Kryo) is city hall — it runs the government (operating systems, scheduling, policy). The GPU (Adreno) is the billboard factory — it paints pixels fast and in parallel. The DSP (Hexagon) is the 24/7 radio station — always on, low power, processing audio and sensor streams while the city sleeps. The modem is the post office — it sends and receives packets to the outside world. The ISP is the photo lab — raw camera data goes in, usable images come out. The NPU is the pattern-recognition bureau — it spots faces, gestures, and road signs without bothering city hall.

MCU vs MPU vs SoC

Section titled “MCU vs MPU vs SoC”

These terms appear in architecture docs, supplier specs, and safety discussions. Don’t conflate them.

MCU MPU SoC
What it is Single (or few) cores + minimal on-chip RAM/flash General-purpose CPU; needs external memory & I/O Integrated CPU + GPU + DSP + peripherals on one die
Typical use Body control, door modules, sensor nodes Older head units, industrial PCs Modern cockpit domain controller
Memory KB–MB on-chip External DRAM required External LPDDR + on-chip caches
OS Bare-metal or RTOS (FreeRTOS, AUTOSAR) Linux, Windows Linux, QNX, Android, hypervisor stacks
Examples NXP S32K, Renesas RH850 i.MX6 (older IVI) Qualcomm SA8155P, SA8295P, SA8775P
Your daily touch Rarely direct (CAN/LIN gateway ECUs) Legacy platforms This is your world

Block Diagram: Inside the Chip

Section titled “Block Diagram: Inside the Chip”

Each subsystem connects through interconnect buses (AXI, NoC) to shared DRAM (LPDDR). The CPU doesn’t “run” the GPU; it submits work to it. Same for DSP, NPU, and ISP.

flowchart TB
    subgraph SoC["Qualcomm Cockpit SoC (e.g. SA8155P)"]
        CPU["Kryo CPU Cluster<br/>QNX · AAOS · Hypervisor"]
        GPU["Adreno GPU<br/>Graphics · Surfaces · OpenGL/Vulkan"]
        DSP["Hexagon DSP<br/>Audio · Sensors · FastRPC"]
        NPU["AI Engine / NPU<br/>Inference · CV models"]
        ISP["Spectra ISP<br/>Camera pipelines"]
        MODEM["Modem / Baseband<br/>AMSS · LTE/5G"]
        MMU["Memory Controller"]
        IO["I/O · PCIe · USB · Ethernet · Display"]
    end


    DRAM[("LPDDR DRAM<br/>Shared system memory")]
    FLASH[("UFS Storage<br/>Boot images · OS partitions")]


    CPU <-->|"AXI / NoC bus"| MMU
    GPU <-->|"AXI / NoC bus"| MMU
    DSP <-->|"AXI / NoC bus"| MMU
    NPU <-->|"AXI / NoC bus"| MMU
    ISP <-->|"AXI / NoC bus"| MMU
    MODEM <-->|"AXI / NoC bus"| MMU
    MMU <--> DRAM
    CPU --> IO
    CPU --> FLASH
    MODEM -->|"Cellular RF"| ANT["Antenna"]
Common Gotcha

“The CPU is slow, so we moved it to the DSP” is almost never accurate. The DSP isn’t faster at general code; it’s better suited for fixed-point signal processing with strict power budgets. You don’t port a Java service to Hexagon. You offload a specific algorithm (AEC, beamforming, FFT) via FastRPC or a signed firmware image.

What Each Block Means for Your Stack

Section titled “What Each Block Means for Your Stack”

Kryo CPU — Where Your OS Lives

Section titled “Kryo CPU — Where Your OS Lives”

The CPU cluster runs multiple operating systems simultaneously via a hypervisor. QNX owns real-time safety functions; AAOS runs the infotainment domain. When you adb shell into Android or attach a QNX debugger, you’re on Kryo cores.

Cores aren’t equal. Big.LITTLE or similar arrangements put performance cores on critical paths and efficiency cores on background work. Hypervisor pinning assigns VM vCPUs to physical cores, a topic we’ll revisit in Module 5.

Adreno GPU — Pixels, Not Politics

Section titled “Adreno GPU — Pixels, Not Politics”

The GPU renders frames for displays (cluster, center stack, HUD). Android’s SurfaceFlinger and QNX Screen compositors submit draw calls here. GPU load shows up as jank, thermal throttling, and frame drops, not as high CPU usage.

Hexagon DSP — Always-On, Never Complaining

Section titled “Hexagon DSP — Always-On, Never Complaining”

The DSP runs Hexagon SDK workloads: audio front-end, voice trigger, vibration sensing. It can run while the CPU sleeps, which is critical for power budgets. AMSS and audio tuning teams spend significant time here.

NPU / AI Engine — Inference at the Edge

Section titled “NPU / AI Engine — Inference at the Edge”

Driver monitoring, occupant classification, and ADAS assist features increasingly run on the NPU rather than the CPU. Models are compiled to HTP (Hexagon Tensor Processor) or similar targets via Qualcomm AI Engine SDK.

Spectra ISP — Cameras Are Not Webcams

Section titled “Spectra ISP — Cameras Are Not Webcams”

Automotive cameras output RAW Bayer data at high frame rates. The ISP handles demosaic, auto-exposure, tone mapping, and multi-camera sync. Camera HAL and QNX camera drivers talk to the ISP, not directly to sensor registers in most cases.

Modem (AMSS) — A World Inside the World

Section titled “Modem (AMSS) — A World Inside the World”

The modem is a semi-autonomous subsystem with its own RTOS, ARM cores, DSP, and firmware (AMSS/MPSS). It shares the SoC die but has separate boot, update, and crash domains. Module 7 covers this in depth.

Qualcomm Naming: SA vs SM vs QCM

SA prefixes (SA8155P, SA8295P) denote automotive-grade Snapdragon platforms with extended temperature ranges and automotive qualification. SM prefixes appear on mobile variants with similar silicon but different packaging and lifecycle. QCM modules are reference designs combining SoC + memory + PMIC on a module, common in telematics boxes. The silicon blocks inside are largely the same family; your partition layout and AMSS version are what differ.

Where You'll See This

When you flash vCPU images, you’re loading software for specific “buildings” in this city. A typical flash session might include:

  • XBL/UEFI: CPU boot firmware (city foundation)
  • QNX IFS: real-time OS image for the safety VM (city hall staff)
  • Android boot/vendor/system: AAOS partitions (infotainment district)
  • ADSP/CDSP firmware: DSP images (radio station equipment)
  • AMSS/MPSS: modem firmware (post office)

If cluster graphics fail but Android UI works, suspect GPU or QNX display, not the modem. If telematics dies but IVI is fine, suspect AMSS, not AAOS. Mapping symptoms to subsystems saves hours of blind log-diving.

This page is the hardware floor of the stack diagram on the homepage. Module 5 (Qualcomm Cockpit SoC) zooms into boot chains and VM layout on this exact silicon. Module 7 connects the modem block to AMSS. Module 8 maps each “building” to partition names you’ll flash with QFIL.

Takeaways

Section titled “Takeaways”
  1. An SoC is many specialized processors, not one fast CPU.
  2. Learn the names Kryo, Adreno, Hexagon, Spectra, and Modem; they appear in every build artifact.
  3. Different subsystems have different firmware, different flash tools, and different failure modes.
  4. Your hypervisor stack orchestrates the CPU; it does not replace the GPU, DSP, or modem.

Check Your Understanding

1. Your surround-view camera shows corrupted colors but the center-stack UI renders fine. Which subsystem is the most likely culprit?

2. What is the key difference between an MPU and an SoC in automotive context?

3. Using the 'city' mental model, which pairing is correct?