Buses and Transactions

Inside a chip, blocks talk to each other through buses: bundles of wires, together with rules for using them, that carry reads and writes from one block to another. Every exchange is a transaction, started by a block such as a processor and answered by another such as a memory. This article explains what a bus is made of, the roles of managers and subordinates, what a read and a write consist of, how the valid/ready handshake paces every transfer, and what happens when an address belongs to nobody, all shown on real transactions of a small SoC.

14 min read | Beginner

What You'll Learn

• Explain what a bus is and the roles of managers and subordinates
• Describe the parts of a read and a write transaction and their channels
• Read a valid/ready handshake on a waveform
• Explain bus responses and what happens on an access to an unowned address

What a Bus Is

Two blocks on a chip exchange information through wires. To send a 32-bit value from a processor to a memory takes 32 wires, one per bit, plus wires for the address that says where the value should go, plus a few control wires that say when the wires carry something meaningful. Such a group of wires is a bus. In the simplest case several blocks share the same wires, which is where the name comes from: like a bus route, one set of wires visits every stop.

Wires alone are not enough. The two sides must agree on what each wire means, when a value is valid, how the receiver says it has taken it, and what happens if it is busy. That agreement is the bus protocol. Most SoCs use standard protocols, so that blocks from different teams and vendors can be connected without redesign. The most widely used family is Arm's AMBA, which includes APB for simple peripherals, AHB, and AXI for high-performance blocks; the Bus Protocols tutorial covers APB, AHB and AXI in depth.

A physical shared bus is common only in small systems. Larger chips connect blocks through switches, crossbars or networks-on-chip that let many transfers travel at once. The word "bus" stuck anyway, and engineers still speak of "the bus" for whatever connects the blocks.

Managers and Subordinates

Every transfer has a side that starts it and a side that answers. The block that starts a transfer is the manager (also called master or initiator): a CPU core executing a load or a store, a DMA engine copying data, a display controller fetching pixels. The block that answers is the subordinate (slave or target): a memory, or the registers of a peripheral such as a UART or a timer. Some blocks are both: a DMA engine is a subordinate when the CPU programs it, and a manager when it then moves data.

Each transfer carries an address. Part of it says which subordinate the transfer is for, and the rest says which location inside that subordinate. The table that assigns address ranges to subordinates is the system's memory map, introduced in What Is in an SoC. The interconnect between managers and subordinates reads the address and delivers the transfer to the right one.

In a small SoC there may be one manager, the CPU subsystem, and two subordinates on its AXI4-Lite interconnect: the system SRAM, and a bridge to the simpler APB bus, which in turn serves the UART, timer, GPIO and simulation control blocks.

Reads and Writes

A complete exchange, from the manager's request to the subordinate's answer, is a transaction. There are two kinds.

A read has two parts. The manager sends the address it wants to read. The subordinate sends back the data stored there, together with a response code that says whether the read worked.

A write has three parts in AXI. The manager sends the address and, separately, the data with its byte strobes: one bit per byte of the data that says which bytes to write, so that a single-byte store changes only one byte of the word. Once the write is done, the subordinate sends a response. Memory, Addresses and Endianness explains why stores need these byte enables.

The response matters even for a write. A write is only complete, and its effect visible to other blocks, when the response has come back. Until then the manager cannot know whether the value is in place, or whether something went wrong.

Channels

AXI, and its simplified version AXI4-Lite, give each part of a transaction its own group of wires, a channel:

Separate channels allow parts to travel at the same time: the address and data of a write can be sent together, and reads and writes need not wait for each other. Full AXI adds bursts, several data transfers for one address, and transaction IDs that let many transactions be in flight at once. AXI4-Lite leaves these out: every transaction moves exactly one 32-bit word, which is all a small processor and its peripherals need.

The Valid/Ready Handshake

The sender and receiver on a channel may not be ready at the same moment. A memory may be busy, or a manager may have nothing to send. Every AXI channel solves this with the same two control signals. The sender drives VALID high when the channel's wires hold something to send. The receiver drives READY high when it can accept it. The transfer, called a handshake, happens on the clock edge where both are high. Two rules make it safe:

• Once the sender raises VALID, it must keep VALID high, and the information on the channel unchanged, until the handshake happens.
• The receiver may raise or lower READY as it likes, so it can slow the sender down for as long as it needs.

Here is one write by a small program to a system SRAM, recorded cycle by cycle from a simulation. "core ready" is the signal that tells the processor's memory stage it may continue:

From the cycle the store needed the bus to the cycle the core moved on, the write took 4 cycles. A read goes the same way: an AR handshake with the address, then an R handshake with the data and the response.

A simple CPU subsystem has at most one transaction outstanding, meaning in progress, at a time: it waits for each response before sending the next request. That is simple, and it is why every bus access stalls the core for its full latency. Larger managers keep many transactions outstanding to hide the wait, which Latency and Bandwidth explains.

Responses and Errors

Every AXI read and write ends with a 2-bit response:

(Code 01, EXOKAY, belongs to exclusive accesses, which AXI4-Lite does not have.) An address that no block owns must still get an answer, or the manager would wait forever and the system would hang. The interconnect therefore answers such accesses itself with DECERR, and an APB bridge answers SLVERR for an empty peripheral slot.

Imagine a test program that reads three addresses that belong to nobody: 0x2000_4000, just past the end of the 16 KB system SRAM; 0x3000_0000, in a gap of the memory map; and 0x4000_3000, an unused peripheral slot.

In one test, all three reads completed, each with an error response and the data 0, and the program went on to finish. What a processor does with an error response is a system decision. A large core raises an exception, so that the operating system can stop the faulty program. A very small core may have no exceptions, so the CPU subsystem just records the error in a status bit and returns 0. Either way, the important property is that the system did not hang.

Shared Buses, Crossbars and Networks

How the managers and subordinates are wired together is the topology of the interconnect, and it decides how many transfers can happen at once.

On a shared bus, all blocks use the same wires, so only one transfer can be in progress at a time. When two managers want the bus in the same cycle, an arbiter decides who goes first, for example by fixed priority or in turn (round robin), and the other waits. A shared bus is small and simple, and it is enough when there is one busy manager, as in a small microcontroller.

A crossbar gives every manager its own path to every subordinate. Two managers can then talk to two different subordinates at the same time; they only wait for each other when both want the same subordinate. An interconnect with one manager and two subordinates is a crossbar too, the smallest possible case, which makes it little more than an address decoder and a set of multiplexers. Crossbars grow quickly, though: the wiring grows with the number of managers times the number of subordinates.

A network-on-chip (NoC) breaks transfers into packets and sends them through small routers connected by links, the way a computer network does. It scales to the dozens of managers and subordinates of a large SoC, at the cost of more latency per hop. Buses, Crossbars and Networks-on-Chip compares the three in detail.

Bridges: From AXI4-Lite to APB

Not every block needs a high-performance protocol. A UART register is written a few times per character; giving it five AXI channels would waste area. Simple peripherals therefore sit on APB, the Advanced Peripheral Bus, and a bridge translates between the two protocols. On the AXI4-Lite side the bridge is a subordinate; on the APB side it is the manager.

APB has no separate channels and handles one transfer at a time. Every transfer has two phases. In the setup phase the manager drives the address, the direction (PWRITE) and, for a write, the data, and raises the select line PSEL of the chosen peripheral. In the following access phase it also raises PENABLE, and the transfer ends in the cycle where the peripheral answers with PREADY high, returning read data on PRDATA and an error flag on PSLVERR. A peripheral that needs more time simply keeps PREADY low.

A simple bridge takes one AXI4-Lite read or write, runs it as one APB transfer, setup then access, and returns the result as an AXI4-Lite response. It selects the peripheral from address bits 15 to 12, so each of up to 16 peripherals gets a 4 KB window. The extra protocol step is why, in one small SoC, a peripheral access costs 6 cycles where an SRAM access costs 4. For registers that are touched rarely, that is a good trade: APB logic in each peripheral is tiny.

Common Mistakes

  target    base            reads  writes  cycles/access
  TCM       0x0000_0000       57       5     1.00
  SRAM      0x2000_0000      256     256     4.00
  UART      0x4000_0000      835      71     6.00
  TIMER     0x4000_1000        2       0     6.00
  GPIO      0x4000_2000        1       1     6.00
  SIMCTRL   0x4000_F000        0       1     6.00
  unmapped  -                  0       0        -