What Is in an SoC

A system on chip (SoC) puts a complete computer system on one piece of silicon: processors, memory, the interconnect that links them, peripherals that talk to the outside world, and the services that clock, power, protect and debug everything. Almost every phone, car controller, smart device and network card runs on one. Designing an SoC is less about inventing each block and more about choosing the right blocks and making them work together. This article walks through the blocks of a typical SoC and then looks at where a small RISC-V SoC spends its time when it runs a program.

13 min read | Beginner

What You'll Learn

• Name the main blocks of an SoC and what each one is for
• Explain how blocks find each other through an interconnect and a memory map
• Explain how engineers find where a program's time goes across the chip
• Work out the cost of local memory versus memory across the bus

From a Board Full of Chips to One Die

A computer used to be a circuit board: a processor chip, separate memory chips, and more chips for serial ports, timers and graphics, all wired together on the board. Every signal between them crossed package pins and board traces, which cost power, space and time.

An SoC moves most of that board onto one die, the single rectangle of silicon cut from a wafer that ends up inside a chip's package. Wires between blocks become a few millimeters of on-chip metal instead of centimeters of board trace, so they are faster and use far less energy. One chip is also cheaper to build into a product than ten. The price is complexity: a modern SoC holds dozens to hundreds of blocks from many sources, and they must all agree on clocks, resets, power, addresses and protocols.

The Blocks of an SoC

SoCs differ by market, but most contain the same families of blocks. A large application SoC, the kind in a phone, looks roughly like this:

Compute blocks do the work. The CPU cluster runs the operating system and applications, usually several cores sharing a cache. GPUs, AI accelerators and media engines handle tasks that a CPU would do too slowly or with too much energy, such as graphics, neural networks and video.

Memory blocks hold data. Bulk memory is DRAM in separate chips next to the SoC, reached through an on-chip memory controller. Smaller, faster SRAM sits on the die itself, as caches, buffers or scratchpad memory.

The interconnect carries every transfer between blocks. In a small SoC it is a simple bus; in a large one it is a crossbar or a network-on-chip with many paths running in parallel. Buses, Crossbars and Networks-on-Chip compares the options.

Peripherals and connectivity connect the chip to the world: UART, I2C, SPI and GPIO for slow devices, and USB, PCIe or radios for fast ones. System services reach every block: clock generators and reset logic, power control, the security subsystem that holds keys and checks boot code, and debug and test logic.

Very few of these blocks are designed from scratch for each chip. A ready-made block design that can be put into a chip is called IP (intellectual property), and CPU cores, interconnects, memory controllers and interface PHYs (the analog circuits that drive the signals of an interface such as USB or DRAM on the pins) are usually licensed from IP vendors or reused from earlier projects. The SoC team's main work is choosing these blocks, connecting them and proving that the whole system works, which Buy, Reuse or Build: Choosing IP covers in detail.

How the Blocks Talk: The Memory Map

Inside an SoC, almost all communication works the same way: a block that starts a transfer, called a manager or master, reads or writes an address. The interconnect looks at the address and routes the transfer to the block that owns it, called a subordinate or slave. The table that says which block owns which address range is the memory map.

Memory, peripheral registers and even accelerator controls all appear as addresses. Software turns on a peripheral by writing to one of its registers, exactly as it would store to memory. The bus protocol defines how each transfer travels; many SoCs use The AMBA Family: APB, AHB and AXI, which the Bus Protocols tutorial covers in depth.

A Small Example SoC

A small example makes these blocks concrete. The SoC below has one RISC-V core. It is tiny compared with a phone chip, but it has the same kinds of blocks, and many articles in this tutorial use it as an example.

The CPU subsystem holds a RISC-V core with a 5-stage pipeline, the kind of processor the Computer Architecture tutorial explains, and 64 KB of tightly coupled memory (TCM) for code, data and stack. The core reaches the TCM in one cycle. Every other address leaves the subsystem on an AXI4-Lite port.

The AXI4-Lite interconnect decodes the address and forwards the transfer to the 16 KB system SRAM or to an APB bridge that serves the slower peripherals: a UART that sends text, a timer, and GPIO pins. An address that no block owns gets an error response instead of hanging the system. A simulation control block lets the program end a test; it exists only in simulation.

What the Blocks Cost

Every block takes area on the die, and area is cost: a larger die means fewer chips per wafer and a lower share of chips without defects. A first look at the area of this small SoC already shows where an SoC's silicon goes. In one estimate, the logic of each block was built from a 130 nm gate library, and the memories were sized from real SRAM blocks for the same process. The processor came to nearly four fifths of the logic. The timer, UART and bridge took about 5 to 7 percent each, and the GPIO and interconnect less than 2 percent each.

Two lessons come out of this. Among the logic, the processor dominates and the "glue" that connects everything, the interconnect and the bridge, is small. And the logic as a whole is tiny next to the memory: the 80 KB of SRAM take almost 90 times the area of all the logic together, so the logic is about 1 percent of the total. Large SoCs show the same pattern at a bigger scale, where caches and on-chip buffers often fill a large part of the die. Every kilobyte in a spec is therefore a cost decision, which Memories in a System explores.

The timer is larger than the UART, although it seems simpler. The reason is its width: it holds two 64-bit registers, the counter and the compare value, plus a 64-bit adder and a 64-bit comparator. Bits cost area, which is why architects ask for every register's width in the spec, not just its function.

Measuring What the System Does

Before a chip is manufactured, its design is run in a simulation: a program on an ordinary computer that computes, cycle by cycle, what every signal of the hardware would do. The simulated SoC runs real RISC-V programs, and extra code around it loads the program, watches the chip's pins and counts events, such as every data access and the block it went to.

Take a small test program that touches every block once. It prints a line on the UART, reads the timer, writes a pattern to the GPIO pins, fills a 1 KB buffer in system SRAM and checksums it.

The first number to look at is CPI, cycles per instruction: the number of clock cycles divided by the number of instructions executed. A CPI of 1 would mean one instruction finished every cycle; anything above that is time the core spent waiting. This program needed about 2.4 cycles per instruction. The same core needs only about 1.3 when a program stays in its TCM, so the program ran nearly twice as slowly per instruction, and the core spent over a third of its time waiting for the bus. The cycles per access explain why: the TCM answers in 1 cycle, the system SRAM in 4, and a peripheral behind the APB bridge in 6.

The biggest cost is not the memory but the UART. The program writes 71 characters, yet it reads the UART status register about 12 times per character, because the UART sends one bit every 16 clock cycles and the program waits in a loop for room in the UART's buffer. Checking a status register over and over until a device is ready is called polling. Those accesses cost about a third of the whole run.

This is a system-level problem, and the cures are system-level too: a deeper buffer, an interrupt (a signal from the UART that tells the CPU when it needs data), or a DMA (direct memory access) engine, a small block that copies the data to the UART by itself while the CPU does other work. Polling, Interrupts and DMA compares polling with interrupts and DMA. Finding such costs by measuring, and choosing the cure, is the daily work of an SoC architect.

Common Mistakes