Computer bus

A computer bus connects components through agreed communication paths and transfer rules. On a shared computer bus, a CPU and a DMA engine can both want the same path to computer memory: attaching another initiator does not create another independent path. Bus arbitration chooses who may start; bus ownership states who may use each resource; bus throughput measures the useful data delivered. This makes sharing a performance question as well as a correctness question.

A computer bus whose communication resources serve multiple attached components. A common physical path reduces wiring, but competing bus transactions must share its capacity. Address bus, data bus and control bus name logical roles; they need not be three permanently separate bundles of wires. Some designs reuse lines for addresses and data in different phases.^[ref]

The computer bus path identifying the destination or location of a bus transaction. An initiator supplies an address; decoding selects the intended target. Address width describes the available address encodings, whereas data bus width describes how many bits can be carried at once.^[ref]

The computer bus path carrying payload. A write sends data from the initiator to the target; a read returns data from the target. Owning the request path does not mean driving the data bus in both directions.^[ref]

The computer bus paths specifying operations and coordinating progress, including requests and acknowledgments. Some control travels from initiator to target and some returns. In the diagram, bus arbitration requests and grants are shown separately from transfer control to distinguish choosing an initiator from executing its bus transaction.^[ref]

One requested operation and its completion, potentially including several payload transfers. A bus transaction identifies a target, specifies an operation and exchanges data or status. A CPU or DMA engine can initiate one; a target responds. The terms “master” and “slave” in older hardware documents refer to these initiator and target roles.^[ref]

One clock period in a synchronous computer bus. A bus transaction can occupy several bus cycles. An asynchronous computer bus instead coordinates progress through acknowledgments, so a clock-based count requires an additional timing model.^[ref]

An extension while a bus transaction awaits readiness. A bus wait state spends time without completing the next payload transfer. In a blocking design it also postpones another initiator's access; completion and bus ownership changes must follow the protocol.^[ref]

A group of related payload transfers, often to consecutive addresses, arranged under one transfer sequence. A bus burst can amortize setup and bus arbitration overhead; a longer period of exclusive bus ownership can also make another initiator wait longer. The exact overhead and permitted handover boundaries depend on the protocol.^[ref]

Selecting among initiators requesting a shared resource. An arbiter grants permission before an initiator starts its bus transaction. Fixed priority can indefinitely postpone a lower-priority requester under continuing higher-priority demand. Rotating priority can provide starvation freedom when every owner releases the resource after bounded work. Neither policy alone determines bus throughput: waiting, setup and target readiness also matter.^[ref]

The permission to use a particular computer bus resource during a specified phase. A pending grant need not authorize immediate use. Arm's AMBA Specification, revision 2.0 (section 3.11.3, figures 3-15–3-17) makes address-path handover depend on completion, and delays data bus ownership relative to address bus ownership. Consequently, a single whole-bus transaction owner is a useful simple model, but does not describe every overlapping implementation.

Here, competition between pending initiators for the same shared computer bus resource. Correct bus arbitration converts this competition into waiting. Simultaneously driving incompatible values on the same electrical lines is a different, erroneous kind of bus contention; multiple pending requests need not cause it.

Useful payload completed per unit elapsed time, with the observation interval stated. A raw data bus rate counts available transfer capacity; achieved bus throughput also depends on setup, bus wait states, idle intervals and sharing. Bus contention can increase a requester's delay even when the aggregate bus throughput remains unchanged, as the shared-bus timing example shows.

Consider a stipulated synchronous shared computer bus, rather than a timing claim about any named hardware protocol. Assume a 32-bit data bus, a 100 MHz clock, and one four-byte payload transfer per bus cycle during the data phase. Both initiators $A$ and $B$ request at time zero. $A$ has one four-transfer write bus burst and $B$ one two-transfer write bus burst, to an immediately ready target in computer memory. Each bus burst pays one bus cycle for bus arbitration and one for its starting address and command; subsequent addresses advance implicitly. The arbiter chooses $A$ first, owners finish their entire bus bursts, and no phases overlap. There are no bus wait states, retries, extra completion cycles, direction changes or intervening requests. Payload is counted when each data phase completes; the observation interval starts at the first bus arbitration cycle and ends at the last payload completion.

A bus cycle lastsThe timeline uses half-open intervals of bus cycles: $A$ has bus arbitration on $[0,1)$, address and command on $[1,2)$, and four payload transfers on $[2,6)$. Then $B$ has bus arbitration on $[6,7)$, address and command on $[7,8)$, and two payload transfers on $[8,10)$. Their final payload completions are at 60 ns and 100 ns respectively. $B$ waits 60 ns before its own selection cycle even though both requests arrived together.

The six payload transfers contain 24 bytes. Ten bus cycles take 100 ns, giving finite-interval bus throughputwhere MB means $10^6$ bytes. The raw data bus rate is $4\mathrm{bytes}\times 100\times 10^6{\mathrm{s}}^{-1}=400MB/s$. Payload occupies $6/10=60\%$ of the interval. If this same pair repeats with no gaps, its long-run bus throughput equals the finite-interval value; isolated observations need not predict a later workload.

Reverse the bus arbitration order, keeping these assumptions. $B$ finishes after four bus cycles, at 40 ns; $A$ finishes at 100 ns. Aggregate bus throughput stays 240 MB/s, but $B$'s request-to-completion time falls from 100 ns to 40 ns and $A$'s rises from 60 ns to 100 ns. Scheduling changes who waits without changing the available payload capacity in this example.

For an independent perturbation, retain $A$ first and add two bus wait states before $B$'s final payload transfer. The interval grows to 120 ns with the same 24 bytes, so bus throughput falls to 200 MB/s. For another workload, one initiator sends all six transfers in a single bus burst: the stipulated overhead is paid once, giving eight bus cycles, 80 ns and 300 MB/s. This latter comparison assumes one combined request is valid; combining different initiators' operations is not automatically permitted.

The word “bus” is also used for interconnect families that do not give all components a single shared electrical path. Intel's An Introduction to the Intel QuickPath Interconnect (January 2009, p. 8, “Interconnect Overview”) explicitly describes Intel QuickPath Interconnect as a point-to-point link despite the serial-bus terminology, and compares it with PCI Express. Here each link connects two endpoints. Independent links can carry traffic concurrently; traffic converging on one link or target still competes for that resource. The shared-bus timing example's single owner and serialized service must therefore not be assumed for a whole network of links merely because its interfaces are called buses. Serial versus parallel transfer and shared versus point-to-point topology are separate distinctions.

An interconnect family using point-to-point links; the topology distinction is explained under shared buses and point-to-point links.

A processor interconnect using point-to-point links; shared buses and point-to-point links explains why the word “bus” alone does not determine its topology.

// Destination: computer-science.bigb

Direct memory access transfers data between a device and computer memory without the CPU executing a copy instruction for each item. The CPU still sets up the operation and observes completion. DMA answers who moves the data; an interrupt answers how a need for attention is announced. A DMA transfer can therefore finish with interrupt-driven input-output or with polled input-output. ^[ref]

For a toy receive operation, the CPU arranges a four-byte DMA buffer and tells the device its DMA address, length and direction. The device writes the bytes A, B, C, D into that DMA buffer. After completion and any required DMA buffer synchronization, the CPU can read those four bytes. There are four payload bytes, but no four-item CPU copy loop on the device-to-computer memory path. This is a schematic example, not an instruction to operate real hardware.

The useful separation is that the CPU can perform other work while a larger transfer proceeds. The reasoning is a division of responsibilities: setup specifies the destination and extent once; the transfer engine advances through the payload; completion reports the result. The data still crosses an interconnect such as a computer bus, which must share access among competing initiators. Setup, mapping, synchronization and completion cost work, so DMA does not promise a speedup for every transfer size. ^[ref]

Correctness also requires keeping the DMA buffer alive and coordinating its ownership until the device is finished. A DMA address need not equal a CPU virtual address or physical address. An IOMMU, when present and configured, translates device addresses and can restrict access to authorized computer memory; it is not the CPU's memory management unit. Operating-system process isolation through virtual memory alone does not establish those device-access restrictions. ^[ref][ref]

A region of computer memory prepared for DMA. In the four-byte receive example it is the payload destination, and must remain available until the transfer and required DMA buffer synchronization are complete.

An address supplied to a device for DMA, in the device's address system. The Linux kernel's mapping interface returns this separately from the CPU's virtual address; an IOMMU can translate it to a physical address. ^[ref]

Coordinating CPU and device access to a DMA buffer, including any required memory cache maintenance and ordering. A completed device write must be made visible before the CPU consumes it. The Linux kernel distinguishes coherent mappings from streaming mappings needing synchronization at ownership changes; even coherent mappings can require ordering of writes. ^[ref][ref]

Hardware translating device DMA addresses to physical addresses, with access restrictions used for device isolation. Availability, configuration and isolation boundaries depend on the platform; merely having an IOMMU does not establish complete isolation. ^[ref]