Anatomy of an SoC

Beginner10 min read

Module Progress0/7 pages mastered

Prerequisites: None — this is where you start. What you’ll learn: SoC anatomy, real-time concepts, memory hierarchy, power architecture, thermal management, EMC fundamentals, physical interfaces.

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’ve been yelling at QNX, negotiating with AAOS, and making offerings to the AMSS gods — but those are all software layers running on hardware blocks you may never have formally met. Time to shake hands with the silicon that’s been silently judging your flash commands.

Why “SoC” and Not Just “CPU”

If you call an SA8155P a “CPU,” an SoC architect somewhere feels a disturbance in the Force. Here’s why the distinction matters.

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

Qualcomm names its blocks with brand names that sound like sci-fi characters. Learn them once and you’ll recognize them in partition maps, build configs, and crash logs forever. Trust us — this table pays for itself the first time you read a boot log.

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	AI Engine (SA8155P: within Hexagon complex) / HTP (SA8295P+: dedicated Hexagon Tensor Processor)	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 — and like any city, it only works because nobody tries to do everyone else’s job. The CPU (Kryo) is city hall: it runs the government (operating systems, scheduling, policy) and takes credit for everything. The GPU (Adreno) is the billboard factory: it paints pixels fast and in parallel — think “we hired 1,000 interns who can each hold a paintbrush.” The DSP (Hexagon) is the 24/7 radio station: always on, low power, processing audio and sensor streams while city hall sleeps (someone has to keep the lights on). The modem is the post office: it sends and receives packets to the outside world — and occasionally delivers them to the wrong VM, as post offices do. The ISP is the photo lab: raw camera data goes in, usable images come out. The NPU is the pattern-recognition detective: it spots faces, gestures, and road signs without bothering city hall — Sherlock Holmes speed, less dramatic monologue.

Mnemonic: One chip, many departments — cluster down but camera up means one department failed, not the whole city. If everything crashed, that’s when you panic.

Think About It

3 AM. Your phone buzzes. The test driver reports: the speedometer is showing 120 km/h just fine, but the surround-view camera is pitch black. Same chip, same board, same power supply. Your PM just pinged you on Slack with three question marks. Before you reach for logcat, what does this symptom alone tell you about the SoC’s internal architecture?

Reveal Answer

The SoC is a heterogeneous multi-processor, not one CPU — cluster speed comes from Kryo + QNX/CAN gateway, while surround-view needs the Spectra ISP, Adreno compositor, and camera SerDes link as separate subsystems with their own firmware and power domains. One department can fail without taking down the city: a dead ISP partition, missing ADSP camera pipeline, or GPU display routing fault leaves Kryo healthy while the camera path stays black. On a real board, check camera HAL/ISP logs, CSI lane status, and whether GPU vs ISP firmware flashed correctly — not “the SoC is dead.” (That’s what you tell your PM, minus the 3 AM profanity.)

MCU vs MPU vs SoC

These three get mixed up in architecture docs, supplier specs, and safety meetings more often than you’d expect from an industry that builds self-driving cars. Let’s fix that.

	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

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 / HTP<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

Beginner thinks the DSP is faster than the CPU, so slow code should move there. That’s like saying your blender is faster than your oven, so you should bake a cake in it.

Reality: the DSP isn’t faster at general code — it’s optimized 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. The DSP is a specialist, not a faster generalist.

Common Gotcha

If you flash the wrong firmware image to a co-processor block (GPU, DSP, modem), the SoC will boot happily while that subsystem plays dead. Congratulations — you’ve built a very expensive brick with selective amnesia.

You’ll see a working Android UI with no audio (ADSP), no cellular (modem/AMSS), or a black cluster (GPU/display). Always match partition names to the block they feed — adsp, modem, and cdsp are not interchangeable even though they’re all “firmware.” This mistake will cost you exactly one afternoon of your life. Ask us how we know.

What Each Block Means for Your Stack

Now that you know who lives where in the city, let’s talk about what they actually do when you’re debugging at 2 AM.

Kryo CPU — Where Your OS Lives

The CPU cluster is the landlord of the operating system apartment complex. It runs multiple OSes 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

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 — never as high CPU usage. If your CPU looks idle but the UI stutters, the billboard factory is backed up.

Hexagon DSP — The Employee Who Never Goes Home

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. If the DSP had a LinkedIn profile, it would say “always available.”

NPU / AI Engine — Inference at the Edge

Qualcomm’s AI acceleration varies by generation. On SA8155P (7 nm), inference runs on the AI Engine integrated within the Hexagon DSP complex — it shares Hexagon architectural lineage but exposes dedicated tensor MACs for neural networks. On SA8295P (5 nm) and newer cockpit platforms, inference moves to a dedicated Hexagon Tensor Processor (HTP) block with higher throughput and its own power domain. Driver monitoring, occupant classification, and ADAS assist features increasingly run on the NPU rather than the CPU. Models are compiled to AI Engine or HTP targets via the Qualcomm AI Engine SDK.

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. If you’re wondering why “just plugging in a camera” takes three weeks of integration, this is why.

Modem (AMSS) — A Country Inside the Country

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. SA8155P is built on 7 nm process technology; SA8295P on 5 nm — the newer node enables more Kryo cores, a dedicated HTP, and higher GPU throughput at similar TDP budgets. 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.

Connect the Dots

• Module 0.4 (Power Architecture): Each “building” in the SoC city needs its own power rail — the PMIC distributes voltage to CPU, GPU, DSP, and modem domains separately.
• Module 5 (Qualcomm Cockpit SoC): The boot chain, hypervisor, and multi-OS layout all run on the blocks described here. Module 5 zooms into how QNX and AAOS share these blocks.
• Module 7 (AMSS/MPSS): The modem block is a semi-autonomous subsystem with its own RTOS and firmware — Module 7 dives deep into this “country within the SoC.”
• Module 8 (Build, Flash & Update): Each subsystem block has its own partition and flash step — the modem, DSP, and CPU boot images are separate artifacts.

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?

Applied

A. Spectra ISP or camera pipeline — RAW camera processing is a separate subsystem from UI renderingB. Modem / AMSS — cellular baseband firmware faults can cascade to multimedia pipelinesC. Hexagon DSP — sensor fusion paths share memory with camera buffers and can corrupt framesD. Adreno GPU — it composites all visual outputs including camera feeds to every display

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

Recall

A. An MPU is automotive-qualified silicon; an SoC targets consumer mobile devices and smartphonesB. An MPU supports real-time operating systems; an SoC is limited to Android and general-purpose LinuxC. An MPU integrates GPU, DSP, and modem on one die; an SoC only provides a CPU and memory controllerD. An SoC packs CPU, GPU, DSP, and modem onto one die; an MPU is a CPU that needs external chips

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

Recall

A. DSP = city hall, CPU = radio station — the DSP handles OS scheduling and boot policyB. GPU = billboard factory, DSP = 24/7 radio station — parallel rendering and always-on sensingC. CPU = post office, Modem = city hall — the CPU routes packets to the outside worldD. ISP = pattern-recognition bureau, NPU = photo lab — the ISP runs neural network models

4. How does NPU/AI acceleration differ between SA8155P and SA8295P?

Applied

A. Both platforms share identical HTP blocks — only the manufacturing process node differs between themB. SA8155P uses an AI engine within Hexagon; SA8295P has a dedicated Hexagon Tensor Processor (HTP)C. SA8155P runs all inference on Kryo CPU cores; SA8295P offloads neural workloads to the Adreno GPUD. SA8155P lacks any AI acceleration hardware; SA8295P was the first Snapdragon to add neural processing

5. Android UI works but there is no audio and voice wake-word detection is dead. QFIL logs show a successful flash. Most likely cause?

Applied

A. Corrupted Android vendor partition — audio HAL libraries live in vendor and won't load if damagedB. AMSS modem partition mismatch — cellular firmware version conflicts disable multimedia peripheralsC. Wrong or missing ADSP firmware — audio front-end and wake-word run on Hexagon, not on KryoD. GPU firmware loaded to the wrong A/B slot — display and audio share the same rendering pipeline

6. After an OTA, telematics and cellular data work but the instrument cluster is black while the center-stack AAOS UI renders normally. Which cross-subsystem diagnosis is most sound?

Synthesis

Connects to: Module 5 — Qualcomm Cockpit SoC · Module 6 — Three Operating Systems

A. Re-flash AMSS — modem firmware manages display routing priorities for all screens on the SoCB. Corrupt UFS LUN 0 / XBL — primary boot loader corruption always manifests as single-display failureC. QNX display pipeline or GPU contention between cluster and center-stack VMs — modem is irrelevantD. Hexagon DSP audio path conflict — the shared bus blocks cluster frame submission to the GPU

Further Reading

• Qualcomm SA8155P Product Brief (PDF) — Official product brief listing Kryo CPU, Adreno GPU, Hexagon DSP, Spectra ISP, modem, and LPDDR/UFS blocks on the primary cockpit SoC reference platform.
• Snapdragon Cockpit Platform — Qualcomm’s cockpit platform landing page covering SA8155P, SA8295P, and the multi-display domain controller architecture described in this page.
• ARM Architecture Reference Manual for A-profile architecture — Authoritative reference for the ARMv8-A ISA that Kryo CPU cores implement; essential for understanding exception levels, caches, and memory ordering.
• ARM Cortex-A Processor Overview — High-level guide to ARM application processor families and how big.LITTLE-style clusters map to performance vs efficiency cores.
• Qualcomm Hexagon DSP Software — Vendor documentation for the Hexagon DSP block used for audio, sensor fusion, and FastRPC offload paths described on this page.
• Qualcomm AI Engine SDK — Documentation for NPU/HTP inference targets on Snapdragon SoCs, relevant to the AI Engine block in the anatomy diagram.
• System-on-Chip Design and Verification (Springer) — Textbook covering SoC integration, interconnect buses, and co-processor partitioning at the architectural level.