19  IoT System-on-Chip Architecture

19.1 Start With the Work Inside the Chip

A system-on-chip is easier to reason about when you assign the work inside it. Sensing, radio, security, signal processing, memory movement, power management, and application code may share one package but still need clear ownership.

Start with those internal boundaries. The SoC architecture matters because it decides which block wakes up, which block protects keys, which block moves data, and which evidence proves the chip can support the larger IoT architecture.

Phoebe’s Field Notes: Why a Power Island’s mAh Isn’t Its Wh

Phoebe’s Why

A milliamp-hour is a charge count – how many electrons crossed a boundary – and it says nothing about energy until you multiply by the voltage those electrons crossed at. That distinction usually hides in a single-rail product, but a SoC with separate power islands makes it visible: the always-ready domain that keeps a wake timer alive typically runs its retained state at a low core-retention voltage, while the main compute, radio, and peripheral domains run at a higher regulated rail. The same 1 mAh spent in the always-ready domain and 1 mAh spent in the radio domain are not the same energy, and a review record that only tracks “domain current in mA” without naming each domain’s rail voltage is quietly comparing charge, not the energy the battery actually has to supply.

The Derivation

\[P = IV \quad\Rightarrow\quad E = \int P\,dt = V\!\int I\,dt = V\,Q \ \ (\text{for near-constant } V)\]

Converting a domain’s measured charge to energy needs that domain’s own rail voltage \(V_{island}\):

\[E_{island} = Q_{island}\times V_{island}\]

Total device energy per cycle sums island energies, not island currents:

\[E_{total} = \sum_{island} Q_{island}\,V_{island} \ \ne\ \left(\sum_{island} Q_{island}\right)\times V_{battery}\]

The usable charge feeding that sum still needs the derating and sag physics derived in the Connected Device Fundamentals chapter: \(Q_{usable}=f_{derate}Q_{nominal}\) and \(V_{term}=V_{oc}-I R_{int}\).

Worked Numbers: One Milliamp-Hour, Two Power Islands

• Catalog-typical rails: always-ready retention \(V_{ar}=1.20\) V; main-compute/radio rail \(V_{main}=3.30\) V (this chapter names no voltages, so both are labeled catalog-typical).
• The same 1 mAh: \(E_{ar}=1\times1.20=1.20\) mWh; \(E_{main}=1\times3.30=3.30\) mWh – \(2.75\times\) more energy for identical charge, purely from which rail it crossed.
• For the vibration-monitor walkthrough’s DMA-fed accelerometer path, that means “samples move without CPU involvement” is a data-path proof, not an energy one: the DMA engine, the SRAM it targets, and the SPI/ADC front end can sit on different islands, so the record needs each island’s charge and rail voltage before “low mAh” becomes a defensible energy budget.
• The same DMA path carries a timing constraint the mAh number cannot see: sampling the accelerometer at \(f_s\) only recovers vibration content up to \(f_s/2\) (the Nyquist limit derived in the ADC Fundamentals chapter). A catalog-typical pump vibration band up to \(f_{max}=2.00\) kHz needs \(f_s\ge2(2.00)=4.00\) kHz sustained through the DMA path – a rate the slow always-ready timer cannot serve, which is exactly why this chapter separates a slow wake domain from a faster sensing domain instead of running everything off one clock and one rail.

In 60 Seconds

A System-on-Chip is not just a small board collapsed into one package. It is a set of hardware blocks that share clocks, buses, memory, security roots, radio paths, and power islands. A good SoC selection asks what each block owns, which data path avoids the main processor, which state can sleep, which boundary protects secrets, and which validation proof shows the chip fits the device role.

19.2 Overview

IoT designs often use an SoC because integration reduces board complexity and lets firmware coordinate sensing, compute, radio, security, and power behavior inside one hardware boundary. That integration also hides important design choices. A device may fail because a sensor path cannot use DMA, a radio shares pins with a service port, a security key leaves protected storage, or a peripheral remains awake in a state that was supposed to save energy.

This chapter treats SoC architecture as a boundary-proof problem. It avoids product lists and short-lived device assertions. The goal is to help you read an SoC block diagram, map the data paths, identify the boundaries, and write a selection record that can survive firmware, board, and deployment changes.

19.3 Learning Objectives

By the end of this chapter, you should be able to:

• read an IoT SoC block diagram as a set of owned hardware responsibilities;
• trace sensor, actuator, radio, service, and update data paths through buses, DMA, memory, and accelerators;
• connect power islands and clock domains to the device states from the power-management decision;
• decide when hardware accelerators prove workload fit rather than decorate a block diagram;
• identify security roots, protected storage, debug boundaries, and update paths inside the SoC;
• document SoC fit, rejected options, validation tests, and reopen triggers.

Vibration Monitor SoC Proof

19.4 SoC Selection Route

Start with the device role and work inward. Do not approve an SoC because it has many blocks; approve it because the right blocks own the right paths with testable proof.

The overview depth layer below carries this route map so the shortcut stays attached to the three-layer explanation.

Use this route:

1. Define the device role, signal boundaries, and failure behavior.
2. Mark the SoC blocks that must own sensing, control, radio, service, update, and recovery.
3. Trace data paths from input to decision to output or report.
4. Identify which paths can use DMA, accelerators, or autonomous peripherals.
5. Check memory, protected storage, debug access, and update recovery.
6. Link clocks and power islands to boot, active, sleep, fault, service, and update states.
7. Record validation tests and the proof that would reopen the selection.

19.5 Block Ownership

An SoC block diagram is useful only when each block has a clear responsibility. Treat ambiguous ownership as a design risk.

19.5.1 Application Core

Runs firmware that coordinates the product behavior. It should not poll every sensor or move every byte when a peripheral can handle that work directly.

19.5.2 Always-Ready Controller

Handles low-rate sensing, wake decisions, timers, watchdogs, or safe outputs while the main core sleeps.

19.5.3 Memory System

Includes flash, RAM, cache, retention memory, update slots, logs, and buffers. Its capacity matters only when mapped to simultaneous workload needs.

19.5.4 Peripheral Fabric

Connects GPIO, ADC, timers, PWM, I2C, SPI, UART, I2S, USB, storage, and service ports through multiplexed pins and bus bridges.

19.5.5 Radio and Baseband

Owns modulation, packet timing, filtering, antenna interface, coexistence signals, and wake or receive behavior.

19.5.6 Security Root

Stores identity, verifies boot, protects keys, controls debug access, and supports update rollback or recovery.

SoC block ownership map showing application core, always-ready controller, memory, peripheral fabric, radio and baseband, security root, and power manager with clear responsibilities.

19.6 Data Path Trace

The most important question is not “what blocks exist?” but “what path does each byte take?” A clean path keeps the main core asleep or focused while hardware moves samples, checks thresholds, encrypts messages, or schedules radio work.

Trace these paths:

• Sensor path: sensor interface, timing source, DMA option, buffer, filter, threshold, timestamp, and error flag.
• Control path: input condition, safety decision, output driver command, feedback, and fault fallback.
• Radio path: packet buffer, encryption, baseband, coexistence signal, antenna boundary, and retry policy.
• Service path: debug or diagnostic interface, access control, timeout, and safe output rule.
• Update path: image storage, verification, rollback, recovery, and failure logging.

SoC data path trace showing sensor input through peripheral fabric, DMA, memory, accelerator, security block, radio buffer, and output decision while the main core only handles bounded coordination.

19.7 Power Islands and Clock Domains

An SoC can include several power islands and clock domains. The architecture decision record must show which island remains available in each device state.

Island or Domain	Typical Responsibility	Boundary Proof
Always-ready domain	wake pins, slow timer, watchdog, small retained state	wake source works in the selected sleep state
Main compute domain	application firmware and burst processing	shuts off or idles when not needed
Peripheral domain	ADC, timers, buses, DMA, PWM, capture units	only required interfaces remain enabled
Radio domain	packet timing, baseband, transmit, receive, coexistence	radio state matches the reporting and wake plan
Security domain	secure boot, key storage, protected operations	keys remain protected during boot, update, and debug
Memory retention domain	retained RAM, logs, counters, calibration	retained data is defined and bounded

SoC power island map showing always-ready, main compute, peripheral, radio, security, and memory-retention domains connected to boot, active, sleep, fault, service, and update states.

19.8 Hardware Accelerators

Hardware accelerators are useful when they match a repeated workload that would otherwise keep the main core active or increase memory movement. They are not useful just because the feature list is longer.

Common accelerator proof:

• cryptography block for frequent encryption, authentication, or secure update verification;
• CRC or checksum block for packet validation and storage integrity;
• DSP block for repeated filtering, transforms, correlation, or sensor fusion;
• neural or matrix block for local inference that fits within memory and model limits;
• capture, compare, or timer block for deterministic pulse measurements;
• DMA engine that moves samples without repeated CPU intervention.

The selection record should name the workload, input size, rate, memory buffer, expected duty pattern, fallback behavior, and test method. If the accelerator cannot access the required memory region or peripheral stream, it may not help the real design.

Hardware accelerator decision route from repeated workload and data movement through DMA access, memory fit, fallback behavior, validation, and final keep-or-ignore decision.

19.9 Reusable and Fixed Logic

Programmable logic, reusable IP, and fixed silicon sit on the same design path but carry different evidence burdens. An FPGA keeps gates reconfigurable after deployment, which can be valuable for unusual I/O, deterministic timing, or a hardware pipeline that is still being validated. An ASIC burns the design into silicon, so it can reduce unit cost, power, or package size at high volume, but the non-recurring engineering cost and respin risk make it a poor fit while requirements are still moving. Reusable IP cores and cell libraries can shorten either path, but the integration record still has to prove licensing, toolchain support, timing closure, verification coverage, security review, and long-term maintenance ownership.

19.10 Memory and Security Boundaries

Memory architecture drives what the device can do at the same time. Security architecture drives what the device is allowed to expose when something goes wrong.

Check memory for:

• firmware image size, update slot, rollback image, and bootloader space;
• stack, heap, packet buffers, sensor buffers, model data, logs, and retained state;
• DMA-accessible memory versus protected or cached regions;
• nonvolatile write endurance for logs, counters, and calibration;
• service-mode memory pressure during diagnostics and update.

Check security for:

• secure boot root and image verification;
• device identity storage and key access rules;
• debug lock and service unlock process;
• protected execution path for sensitive operations;
• rollback protection and recovery after an interrupted update;
• failure logs that do not expose secrets.

SoC memory and security boundary map showing boot ROM, firmware image, update slot, RAM buffers, retained state, key store, debug lock, and recovery path.

19.11 Radio Integration

Integrated radio simplifies the board but adds RF, antenna, coexistence, certification, and layout obligations. External radio modules can isolate some RF design work but add board space, interface ownership, and supply sequencing.

Check radio integration through questions:

• Does the protocol, range, latency, and duty pattern match the device role?
• Which block owns packet timing and retry behavior?
• Where does encryption happen, and how are keys protected?
• Which pins are unavailable because of antenna, crystal, coexistence, or debug needs?
• Can the radio wake the device, or does it require the main domain to remain active?
• How will antenna tuning, enclosure material, and nearby conductors be validated?
• What is the recovery plan when radio join, association, or channel access fails?

SoC radio boundary map comparing integrated radio and external radio module paths across packet buffer, baseband, antenna interface, coexistence pins, wake behavior, and validation proof.

19.12 Walkthrough: Vibration Monitor SoC

Consider a sealed vibration monitor on an industrial pump. It samples an accelerometer, extracts a compact vibration signature, stores fault proof, and reports summaries to a gateway. It must wake on a scheduled interval, detect severe vibration locally, preserve proof after a fault, and support field firmware updates without exposing keys.

Architecture proof

Decision Area	Proof Needed	Acceptance Question
Sensor path	SPI accelerometer, timer trigger, DMA buffer, timestamp	Can samples arrive without CPU polling?
Processing path	filter or transform block, memory buffers, fallback firmware path	Does hardware reduce active time for the repeated workload?
Fault path	threshold, output or alert, retained event record	Does the device keep useful proof after reset?
Radio path	packet buffer, encryption path, retry limit, wake behavior	Can reports be sent without breaking sleep targets?
Security path	secure boot, key storage, debug lock, update rollback	Can service staff update without exposing identity material?
Power path	always-ready timer, main domain, sensor rail, radio domain	Are only necessary domains active in each state?

Selection decision

The SoC is acceptable if it supports timed sensor capture through DMA, has enough memory for sample and packet buffers, provides a protected boot/update path, and lets the radio and sensor domains match the power-state ledger. A faster core alone is not enough proof. The selection should reopen if the sample rate, radio protocol, retained proof, update image size, enclosure, or service access changes.

19.13 Selection Record

The selection record turns the architecture check into a testable decision.

• Device role: sealed vibration monitor for pump health proof.
• Chosen SoC proof: DMA-capable sensor path, bounded local processing, protected boot/update path, retained fault record, radio wake behavior, and enough memory for update plus buffers.
• Rejected path: processor-class hardware with external radio because it adds boot and service burden for a bounded sensing role.
• Validation: sample-path timing, DMA buffer ownership, accelerator fallback, radio recovery, update rollback, debug lock, retained fault log, and state draw at the device input.
• Reopen triggers: higher sample rate, larger local model, new radio protocol, larger update image, external storage, changed service interface, or failed field wake proof.

SoC selection record linking device role, chosen architecture proof, rejected path, validation tests, and reopen triggers.

19.14 Common Pitfalls

Map Pins Before Feature Lists

An SoC may list several buses, but pin multiplexing can prevent the needed combination from being used at the same time. Map service, sensor, radio, clock, and debug pins before board layout.

Map Accelerator Data Access

An accelerator helps only if data reaches it without extra copying or unsupported memory access. Check DMA paths, buffer alignment, memory regions, and fallback behavior.

Debug Access in Security Boundary

Debug interfaces can bypass normal firmware boundaries. Decide how debug is locked, how service unlock works, what proof is logged, and how outputs remain safe during service.

Integrated Radios Need Layout

Integrated radio still needs antenna tuning, keep-out, enclosure checks, coexistence planning, and RF validation. The integration reduces parts; it does not remove the physics.

Reserve Update and Rollback Space

Memory that looks sufficient for the application may fail once update slots, rollback, logs, packet buffers, and diagnostic mode are included. Check simultaneous memory needs, not headline memory size.

19.15 Knowledge Check

Quiz: SoC Architecture Fit

Match SoC Proof to Boundary Question

Order the SoC Architecture Selection

Key Concepts

• System-on-Chip: An integrated circuit that combines compute, memory, peripherals, radio, security, and power-management blocks into one hardware boundary.
• Block ownership: The assignment of responsibility for sensing, control, communication, security, service, and recovery to specific SoC blocks.
• Peripheral fabric: The internal bus and pin-multiplexing structure that connects interfaces such as GPIO, ADC, PWM, I2C, SPI, UART, I2S, timers, and DMA.
• DMA: A data-movement engine that transfers samples or packets without repeated CPU handling.
• Power island: A hardware domain that can be powered, paused, retained, or shut off separately from other domains.
• Clock domain: A set of hardware blocks driven by a shared timing source, often with different sleep and wake behavior.
• Hardware accelerator: A specialized block for repeated work such as cryptography, checksum, filtering, transforms, capture timing, or local inference.
• Security root: Hardware-backed trust boundary for boot verification, identity storage, debug control, and update recovery.
• Rollback path: A recovery method that returns the device to a known-good image after an interrupted or invalid update.

19.16 Overview: Assign Work To Blocks

If you only need the selection shortcut, this layer is enough: an SoC fits when the right hardware block owns each real device responsibility. A long feature list is not proof until sensing, control, radio, security, update, and sleep behavior are mapped to testable paths.

The first review question is therefore not “does the chip have the block?” It is “can the block sit on the real path without breaking another obligation?” An accelerometer path might need a timer, SPI peripheral, DMA engine, accessible buffer, filter, timestamp, interrupt, and fault flag. A radio path might need a packet buffer, crypto engine, wake source, retry state, and antenna boundary. A security path might need protected storage, debug lock, boot verification, rollback, and a service rule. If any of those paths share memory, pins, clocks, or power domains, the record should show the interaction.

A useful shortcut is to draw one path per responsibility and mark every shared block. Shared blocks are where timing, isolation, and recovery assumptions usually break.

Those marks become the first lab tests.

For example, if radio retries share memory bandwidth with vibration sampling, the architecture should prove the alarm path still keeps its deadline during reconnect bursts.

The SoC selection route connects device role, block ownership, data paths, memory and security boundaries, power islands, radio integration, and the validation record.

Mobile summary: Approve an SoC only when the device role, internal block owners, data paths, memory and security boundaries, power and radio behavior, and validation record line up.

Sensor path

Show how the sensor reaches a timer, bus, DMA buffer, filter, timestamp, and error flag without unnecessary core polling.

Radio path

Show packet buffer, encryption point, baseband, antenna boundary, retry policy, wake behavior, and recovery after join failure.

Security path

Show secure boot, identity storage, debug lock, protected operations, rollback, and service unlock proof.

19.17 Prove Vibration Monitor Path

For the sealed pump monitor, the SoC decision should be written as a path record. It should prove the accelerometer stream, compact vibration signature, fault proof, gateway report, update path, and sleep plan with the actual SoC blocks selected.

Make the record concrete. The accelerometer sample rate should match the SPI clock, DMA burst size, buffer depth, timestamp source, and processing deadline. The DSP or filter block should read the same memory region the DMA writes, or the design needs a copy step with a measured cost. The radio should not wake a high-power domain just to discover there is no packet to send. The update path should have enough slot space and a rollback rule. The service path should prove debug access cannot expose keys or leave unsafe outputs active.

For each path, name the fallback. If DMA is unavailable, does the CPU polling path still meet the alarm deadline? If the radio cannot join, how long is the fault retained and who sees it? If a firmware image fails, which image boots and what state is reported? These fallback answers are part of the SoC fit, not later implementation detail.

Close the record with the measurement that would reopen the choice: missed samples, buffer overflow, excessive wake time, failed rollback, or a service procedure that needs unsafe debug access.

Each measurement should have an owner.

The owner can then decide whether the issue is a firmware fix, a board constraint, or a reason to reject the SoC for this product.

DMA and buffers

Record sample rate, SPI timing, DMA ownership, buffer size, timestamp source, overflow behavior, and fallback if DMA is unavailable.

Power islands

Name which timer, wake pin, retained memory, sensor rail, main core, radio, and security domains remain active in each state.

Update and service

Check boot verification, update slot size, rollback, debug lock, service timeout, safe output rule, and non-secret failure logs.

19.18 Why Integrated Blocks Fail

Integration reduces board parts, but it increases coupling. A single SoC choice can tie together pin multiplexing, memory regions, DMA access, radio layout, power domains, debug exposure, and update recovery.

The hidden failure is usually a shared resource. A peripheral may be listed in the datasheet but unavailable on the package pins chosen for the board. A DMA engine may be able to reach SRAM but not a protected or retained memory region. A radio may require a clock or regulator that prevents the advertised sleep current. A secure element, boot ROM, or debug fuse may protect keys only if the service workflow follows the intended lock and unlock sequence. These details decide whether the integrated chip actually behaves like the architecture record says.

That is why the under-the-hood evidence should include a pin and bus check, a memory-access check, a power-state check, and a security-state check. The review does not need every register setting, but it does need proof that the selected blocks can be active, idle, retained, or locked in the same states the product will use. Integration is a benefit only when those couplings are visible before the board and firmware choices harden.

The same evidence also protects later maintenance: a board spin, firmware update, radio variant, or service jig can change the coupling even when the product name stays the same.

• Pin conflicts: a listed peripheral may be unusable if radio, crystal, service, or debug pins need the same package pins.
• Memory visibility: DMA or accelerators may not reach protected, cached, retained, or external memory regions.
• Power leakage: a peripheral, pull-up, radio receive state, or retained domain can stay awake when the design expects sleep.
• Security bypass: debug unlock, service mode, and update recovery must not expose keys or unsafe outputs.

19.19 Summary

SoC architecture selection is a block-ownership and data-path decision. The device role determines which hardware blocks matter, which domains must remain available, which memory boundaries are safe, and which validation proof shows fit. A strong selection record explains why the SoC supports the real sensing, control, radio, security, service, and update paths, and it names the changes that would reopen the decision.

19.20 Key Takeaway

SoC architecture selection should include integrated radio, memory, security, power states, software support, and supply risk as one system-level decision.

19.21 See Also

Hardware architecture

• MCU vs MPU Selection - deciding whether a controller-class or processor-class design fits the device role
• Power Management and Device Interfaces - checking states, wake sources, GPIO, ADC, PWM, and bus boundaries
• Enablers Fundamentals - computing, integration, and miniaturization enablers

Wireless and security

• Bluetooth Fundamentals - radio integration and BLE device behavior
• LoRaWAN Architecture - long-range radio architecture and device classes
• IoT Security Fundamentals - secure boot, identity, and update practices

Design workflow

• Energy-Aware Considerations - low-power design and state validation
• Prototyping Hardware - development boards and hardware evaluation workflow

19.22 What’s Next

Direction	Chapter	Focus
Next	Reference Architectures Index	Module navigation and architecture study paths
Back	Power Management and Device Interfaces	State, wake, signal, and interface decisions
Related	MCU vs MPU Selection	Hardware class selection proof