PCIe Chapter 0: From the System View to Your First Specification Query

What must happen after a device is connected?

A Root Complex connects the CPU/memory subsystem to the I/O hierarchy. A Root Port establishes an outward Link, a Switch extends the connection paths, and an Endpoint provides device functionality. A Link connects two adjacent ends; Lanes make up that Link. x4 means four Lanes, not four devices.

The basic object identified and configured by software is a Function. One card can expose multiple Functions. The example notation 0000:03:00.0 identifies a Segment, Bus, Device, and Function; Bus, Device, and Function are commonly abbreviated as BDF (Bus, Device, and Function identifier). A Segment is a logical grouping, not an additional hardware component, and this identifier is not a memory address.

BDF

Bus/Device/Function

Hardware at both ends must first meet the conditions for establishing a Link. System software discovers Functions and assigns resources; the device driver prepares the device-specific working interface. This is a teaching model of dependencies, and a platform may perform the work in stages. Firmware 3.3 §3.5 requires firmware to configure the complete paths to boot and console devices, as well as all Host Bridges. It does not guarantee that every Endpoint has been configured.

A BAR is a Base Address Register in Configuration Space, not the data buffer itself. Readable Configuration Space alone does not establish that MMIO or DMA is ready.

MMIO

Memory-Mapped I/O, mapped device-register access

DMA

Direct Memory Access, device access to memory

Why examine one read through three layers?

Continue the earlier memory read: an Endpoint sends a Request through a Switch to its target and waits for a Completion. Figure 1-4 separates send and receive responsibilities into three logical layers; Figure 1-5 illustrates the packet's conceptual path. This structure helps readers navigate the specification; it does not prescribe three separate hardware blocks.

On a phone, scroll the table horizontally to see all columns.

A useful path is: identify the observed Link → inspect the physical connection and Link state → check that segment's transmission and Flow Control → match the Request and Completion. Successful delivery on one Link establishes a local result; the read is confirmed only by checking the response received by the Requester.

Figure 1-5 illustrates layers conceptually. Check the applicable Non-Flit or Flit Mode chapter for actual carrying and protection details instead of applying every detail of the figure to both modes.

Adjacent layers also exchange data boundaries, transfer handshakes, power and Link state information. Section 1.5.4.4 describes the information passed at each interface; the conceptual layer diagram does not prescribe the internal implementation.

Base 6.0 §1.5, Figures 1-4 and 1-5, pp.109–110; §§1.5.1–1.5.4.4, pp.110–114. The read and Switch path are a teaching scenario.

Why does current speed not tell us which speeds are supported?

Capability fields describe supported behavior, control fields provide settings, and status fields report the current result. Follow the local Port query in that order of purpose: first locate the supported-speed set, then inspect the Link status. A control-setting query is a separate next step.

Each Function has 4096 bytes of PCIe Configuration Space. The PCI Express Capability is in the conventional Capability list within the first 256 bytes. Its name does not mean that it belongs to the separate Extended Capability list. (Base 6.0 §7.2 / Figure 7-3, pp.905–906; §7.5.3, p.951.)

Configuration Space uses little-endian formatting, so the lower-addressed byte of 0x7001 is 0x01 (Base 6.0 §7.5.1.1, p.916). List locations and ordering can differ; 0x70 is not a universal constant.

If the list ends without the target, or a read fails, there is no basis for interpreting an arbitrary location as that structure. An unsuccessful read is not a valid response declaring lack of support.

Capability Version 2 does not mean PCIe Gen2, and by itself does not guarantee that older hardware implements the speed vector. Implementation is a separate assumption here. Using Base 6.0 to interpret the fields also does not mean that the device must support 64 GT/s. For older hardware, see the implementation note in §7.5.3.18 (p.1000).

How do the register values become an answer?

Start with Figure 7-21 (p.952) and add each register's relative offset to the Capability base. Then consult the capability definition in Figure 7-38 / Table 7-35 (pp.998–1000), followed by the status definition in Figure 7-29 / Table 7-26 (pp.978–979). The question determines the reading order. Figures locate fields; tables and surrounding requirements explain their interpretation. Check the revision and applicable component at every step rather than inferring meaning from a field name alone.

Link Capabilities 2: 0x70 + 0x2C = 0x9C; read 32 bits → 0x0180001E
Link Status:         0x70 + 0x12 = 0x82; read 16 bits → 0x0043

The Supported Link Speeds Vector occupies register bits 7:1. Mask those positions, then shift the field down:

(0x0180001E & 0x000000FE) >> 1 = 0x0F

Field bits 0–3 are all set, indicating support for 2.5, 5, 8, and 16 GT/s. Bits 4–5 are clear, so 32 and 64 GT/s are not advertised; bit 6 is reserved. Field bit 0 was originally register bit 1, so these two numbering systems must remain distinct. The full read value keeps register bits 23 and 24 set to meet Table 7-35's detection-capability requirements for devices supporting 16 GT/s or above. Those bits do not prove that Retimers are present in the path.

Link Status instead contains an encoded value, not another supported-speed bitmap:

Current Link Speed: 0x0043 & 0x000F = 3
Negotiated Link Width: (0x0043 & 0x03F0) >> 4 = 4

Code 3 selects field bit 2 of the speed vector, meaning 8 GT/s; width 4 means x4. These masks assume the stated read widths. They cannot be applied directly to a 32-bit value read at a different offset.

Table 7-26 makes both fields undefined when the Link is not up. The value 0x0043 does not itself establish that the Link is up. Nor does a clear bit 13 alone establish that the Link is down: implementation of that status bit depends on reporting capability (Table 7-23 and Table 7-26, pp.969 and 979).

Does operating at only 8 GT/s prove a fault?

Figure 7-21 (p.952) locates the fields relative to the Capability base. Read Figure 7-38/Table 7-35 (pp.998–1000) to interpret the supported-speed vector, then Figure 7-29/Table 7-26 (pp.978–979) for the current speed and width. At each step the table supplies the encoding and applicability that the layout alone cannot provide.

Does the same conclusion survive a changed condition?

The complete query selects a Function, follows its list, checks the structure, and interprets two separate fields. The following variations show which part of that route must be checked again.