Reference Architectures · Study deck

IoT SoC Architecture: Blocks and Data Paths

This first route reads a SoC as owned blocks and traces data and power across their boundaries.

Blueprint Bina is your guide for this deck.

hardwarechar

Blueprint Bina, the module guide, in a scene from this chapter.

After studying this chapter

Learning objectives

You will 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;

Major section

Start With the Work Inside the Chip

Firmware is the software stored on a device.

It reads a sensor, moves samples, checks a limit, protects a key, sends a message, and spends most of its life asleep.
A fast special block may wait on memory.
A built-in radio saves board space but can make layout and power harder.

Major section

Start With the Work Inside the Chip (continued)

Turning off one area saves energy, yet needed state or wake signals may be lost.

This monitor story cannot choose a chip from a block diagram.
Those need board and device tests.
The deeper work tests ownership while keeping the same trace.
A built-in radio still needs a sound board.

Major section

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

The mathematical gist.: Charge is not energy until voltage enters the ledger: $E=QV$.

Separately, a 2.00 kHz vibration band requires at least 4.00 kHz sampling through the active data path.

Major section

SoC Selection Route

The first review question is not simply whether the chip lists a block.

An accelerometer path may need a timer, SPI peripheral, DMA engine, accessible buffer, filter, timestamp, interrupt, and fault flag.
Sensor path Show how the sensor reaches a timer, bus, DMA buffer, filter, timestamp, and error flag without unnecessary core polling.

Major section

Block Ownership

An SoC block diagram is useful only when each block has a clear responsibility.

It should not poll every sensor or move every byte when a peripheral can handle that work directly.
Its capacity matters only when mapped to simultaneous workload needs.

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

Major section

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.
Their combined proposition is: 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.

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.

Major section

Cortex-M Address Map and the Vendor Boundary

A 32-bit Cortex-M core can name $2^{32}$ byte addresses, from 0x00000000 through 0xFFFFFFFF.

On ARMv6-M the high-level map below gives software and bus designers a shared vocabulary; it does not promise that every address contains implemented memory.
The arithmetic is worth doing once.

ARMv6-M default address map and MCU review.

Major section

Cortex-M Address Map and the Vendor Boundary (continued)

That tells you the access should behave like device I/O, but it does not tell you which peripheral, whether the address is implemented, or which bit starts an operation.

The portable boundary is therefore precise: toolchains can share instruction generation, exception entry, vector-table concepts, and core-control definitions.
Vendors can map different clock controllers, GPIO ports, DMA engines, and ADCs into the peripheral region, with different offsets and bit meanings even across one vendor's families.
A linker script, startup file, and board-support package must pin the actual flash/RAM layout.

Deck summary

Key takeaways

Firmware is the software stored on a device.

Turning off one area saves energy, yet needed state or wake signals may be lost.
The mathematical gist.: Charge is not energy until voltage enters the ledger: $E=QV$.
The first review question is not simply whether the chip lists a block.
An SoC block diagram is useful only when each block has a clear responsibility.

Retrieval practice

Recall check

Blueprint Bina says: answer from memory, then check your reasoning.

Q1A vibration-monitor SoC design routes accelerometer samples through DMA into shared memory while the radio, security engine, and sleep power island also need that memory and bus path. Which first check keeps the SoC boundary choice traceable?

ATrace the sensor, DMA, memory, security, radio, power-island, debug, update, and service paths

BStart with package integration and board area, using fewer external connections as the main evidence of fit.

CRun a clean DMA sensor capture first and use its buffer usage to size the shared-memory design.

DLeave bus contention, buffer ownership, key isolation, retained power rails, debug exposure, and recovery ownership until after board bring-up.

Show answer

Answer: A A traceable SoC decision separates each internal block path and proves the shared memory, power, security, update, debug, and service boundaries before integration hides the failure mode.

Print reference

Answers

Answer key.

A · A traceable SoC decision separates each internal block path and proves the shared memory, power, security, update, debug, and service boundaries before integration hides the failure mode.