PCIe Chapter 1: Topology, Transaction Roles, and Per-Link Observations

Record cards, Functions, and Links as different objects

A component is one physical package. A Device is a collection of Functions sharing a Bus Number and Device Number within a hierarchy. A Function is individually addressable in Configuration Space; a Port interfaces a component to a Link.

A Link comprises two adjacent Ports and their interconnecting Lanes. Each Lane has one transmit differential pair and one receive differential pair. An x4 Link has four Lanes. In this example, A's two Functions share one Port and LA; two configuration targets do not create two external Links.

The diagram uses Endpoint A as a label for the component providing Endpoint Functions. Formally, Endpoint is a Function type. Card assembly, packages, configuration targets, and external connections answer different questions.

Base 6.0, Terms and Acronyms: component, Device, Function, Lane, Link, and Port, document/PDF pp.83–85, 87, 89; §1.2, pp.100–102.

Which roles remain the same during a Read and its response?

The Switch Upstream Port faces the Root Complex; its Downstream Ports face the downstream branches. These names follow topology. The Requester initiates the transaction, while the Completer handles the original Request and produces the required response. Transmitter and Receiver describe an individual Link transfer.

The example stays within one Root Port's downstream path. It does not generalize ordinary Switch forwarding to the special rules for Root Complex forwarding between Root Ports.

Base 6.0, Terms and Acronyms, document/PDF pp.82–84, 90, 93–94; §1.3.1, pp.103–104; §1.3.3/Figure 1-3, p.107; §2.2.6.2, p.157.

Why does one Switch need three sets of Link observations?

The dashed internal connection is not a fourth external Link. For A, collect both ends of LA first. Link Status at the Switch Upstream Port describes LR. Adding another Switch requires another adjacent-Port pair for each added external Link.

Base 6.0, §§1.2–1.3, Figure 1-2 Example PCI Express Topology and Figure 1-3 Logical Block Diagram of a Switch, document/PDF pp.100–107.

Does A's 64.0 GT/s capability describe the entire host path?

Compare the two Ports on each Link, then record current speed and width separately. These decoded teaching values assume the Links are up and both ends were observed at the same time. Target settings, training history, and board wiring are not supplied.

Read LA first. Both Ports support 64.0 GT/s and x8, but currently operate at 16.0 GT/s and x4. Capability and current operation are different observations. Explaining this result requires valid control settings, wiring information, and training history.

Then follow LR. The host path also crosses LR, whose two Ports support up to 32.0 GT/s. Each Link trains and operates separately; the path does not negotiate one shared speed. Endpoint capability alone cannot describe the intervening Link.

This table does not predict application performance. Workload, other branch traffic, packet overhead, and transport behavior also affect progress.

1. Locate capability fields
   Figure 7-27/Table 7-23: Max Link Speed and Maximum Link Width. Figure 7-38/Table 7-35: Supported Link Speeds Vector.
2. Locate current results
   Figure 7-29/Table 7-26: Current Link Speed and Negotiated Link Width. Their definitions depend on the Link being up.
3. Return each value to its Link
   Compare adjacent Partners before moving to the next Link. Keep controls, current results, and event records separate.

This is a specification-reading route, not a training timeline. The complete field-offset and speed-decoding example remains in Chapter 0.

Is a PCI/PCI-X Bridge the same component as a Switch?

No. A PCI Express to PCI/PCI-X Bridge connects a PCI Express fabric to a PCI/PCI-X hierarchy. A Switch instead appears as an assembly of virtual PCI-to-PCI Bridges forwarding transactions among PCIe Ports. Both can expose Bridge structures in Configuration Space, so a Bridge Header alone does not establish the component type: check Device/Port Type and the actual downstream connection.

Teaching example: if a topology shows a PCI Express to PCI/PCI-X Bridge below a PCIe Port, identify its PCIe side and PCI/PCI-X side before selecting protocol and configuration rules. Do not draw the downstream PCI/PCI-X bus as another PCIe Link, or infer a Switch Downstream Port from Header Type alone. This is an identification starting point; the complete conversion and exceptions require the applicable Bridge specification.

Base 6.0 §§1.3.3 and 1.3.5, Figure 1-3, pp.106–108; Device/Port Type: §7.5.3.2.

Can Endpoints under different Root Ports always communicate?

Teaching example: Endpoint A and B are below different Root Ports of the same Root Complex (RC). Figure 1-2 places them in different hierarchy domains, so A's access to B must cross the RC. Base 6.0 §1.3.1 makes peer-to-peer routing between hierarchy domains optional and implementation-dependent. Enumerating both Endpoints does not establish that the RC offers this path.

When supported, an RC can use different designs: for example, take ownership of a Request, reform packets as needed and handle returning Completions, or use an internal physical or virtual Switch. Section 1.3.1 generally permits an RC to split packets while routing between domains; §1.3.3 prohibits a Switch from splitting one packet into smaller packets. Each remains subject to its applicable packet rules.

There are exceptions: an RC must not split a Deferrable Memory Write Request; splitting a Vendor-Defined Message is subject to 128-byte boundary conditions. Practical analysis also needs platform routing, Bridge Windows, the target BAR and access policy. The topology alone establishes the path through the RC, not delivery to B.

BAR

Base Address Register

Base 6.0 §1.3 and Figure 1-2, pp.102–103; §§1.3.1 and 1.3.3, pp.103–104 and 106–107; Deferrable Memory Write: §6.32.

Why does an Endpoint sometimes have no Link partner?

The add-in card in the earlier example is an Endpoint connected outside a Port. Figure 1-2 also shows a Root Complex Integrated Endpoint (RCiEP) inside the Root Complex. It is still a Function that supports Configuration Requests, but it does not appear in the external hierarchy domains exposed by Root Ports or inside Switches.

Teaching example: suppose a readable Function identifies its Device/Port Type as RCiEP. Check fields applicable to that type: an RCiEP must not implement Link Capabilities, Link Control, Link Status, or their version 2 registers. Missing those registers does not establish that an external Link failed. A different Device/Port Type needs its own applicability rules.

An RCiEP may be associated with an optional Root Complex Event Collector (RCEC), which terminates error and PME (Power Management Event) messages from associated RCiEPs. Check the RCEC's Endpoint Association Extended Capability to establish an association. RCECs are optional; do not assume every RCiEP has one. If an RCiEP is associated with an RCEC, it must signal PME and errors through that RCEC and cannot be associated with more than one.

All three Endpoint types use a Type 0 Configuration Header, but their constraints differ. Compare §§1.3.2.1–1.3.2.3 before applying a field-specific rule.

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

These rules describe Function roles and capabilities. The address used by one Request is not the Function's complete addressing capability.

Base 6.0 §1.3 and Figure 1-2, pp.102–103; §§1.3.2.1–1.3.2.3 and 1.3.4, pp.104–106 and 108; Device/Port Type: §7.5.3.2.

Which two fields establish a Function's role?

At the selected Function, read the 8-bit Header Type at offset 0x0E. The low seven bits select the header layout and bit 7 indicates possible multiple Functions. Then locate the PCI Express Capability and read its 16-bit register at base + 0x02; Device/Port Type in bits 7:4 identifies the role. The first field selects the layout used to read the second.

Header format: 0x80 & 0x7F = 0
Multi-Function Device: (0x80 & 0x80) >> 7 = 1
Device/Port Type: (PCIe_Capabilities & 0x00F0) >> 4

The value 0x80 means neither “Type 128” nor “eight Functions are present.” A set Multi-Function Device bit means that the device may contain multiple Functions. Actual Function presence still needs discovery evidence. Endpoint A here means the component providing Endpoint Functions; the example separately assumes that both Function 0 and Function 1 of that component have been found.

Device/Port Type identifies a Function type. An RCiEP has a Type 0 Header but must not implement the listed Link Capabilities/Control/Status registers or their corresponding 2 registers. Before interpreting Data Link Layer Link Active, check Reporting Capable: a hardwired zero can mean reporting is not implemented, rather than an inactive Link. (Base 6.0 §1.3.2.3, pp.105–106; Table 7-19, pp.953–954; Tables 7-23 and 7-26, pp.969, 979.)

Which downstream path reaches 0000:03:00.1?

The example places a Root Port and a Switch with two Downstream Ports in Segment 0000. Endpoint A's two Functions are on Bus 03, while Endpoint B is on Bus 04. The table is a snapshot of an already configured topology. This chapter interprets the result; assigning Bus Numbers belongs to the enumeration chapter.

Secondary Bus Number identifies the Bus immediately downstream of a Bridge. Subordinate Bus Number bounds the upper end of its downstream Bus Number range. Target Bus 03 is within the Root Port's 01–04, the Upstream Port's 02–04, and Downstream Port A's 03–03 ranges. Downstream Port B covers only 04–04, so it is outside the path to this target.

These ranges check the known topology; they do not establish that every number in a range has a populated Bus. A Bridge's own BDF (Bus, Device, and Function identifier) also differs from the Bus it leads to: 02:01.0 is on Bus 02 and has Secondary 03. This chapter does not derive a Bridge's own BDF from Primary Bus Number. Base 6.0 retains that field for legacy compatibility, and PCIe generally does not use it.

BDF

Bus/Device/Function

What information do BDF, Segment, and Requester ID retain?

Under conventional addressing, BDF contains an 8-bit Bus Number, a 5-bit Device Number, and a 3-bit Function Number. The first four digits of 0000:03:00.1 identify the Segment; the remaining 03:00.1 is the BDF within that Segment. These numbers describe a logical identification location, not a physical slot number.

As a further teaching assumption, 03:00.0 has also been discovered in Segment 0001. This is a second logical scope created for the example, not a downstream branch of the preceding table. Dropping the Segment would incorrectly merge distinct records.

When 0000:03:00.1 originates a Request, its 16-bit Requester ID is formed as follows in this example:

Requester ID = (Bus << 8) | (Device << 3) | Function
             = (0x03 << 8) | (0x00 << 3) | 0x1
             = 0x0301

Example deduction: 0x0301 preserves the BDF but does not encode Segment 0000 into those 16 bits. This conclusion applies only to the Requester ID field. It does not mean that all PCIe packets lack Segment information: some Base 6.0 Flit Mode packets have separate related fields. BDF is also not a permanent hardware identity. If records come from different configurations at different times, matching or changed BDF values alone cannot establish whether they describe the same physical device.

What evidence should the next observation include?

For a speed/width report, retain the Port, its direct Partner, the time, and the field name. For a tool's Endpoint label, return to Header Type and Device/Port Type. For one captured Request, identify the Link and direction before assigning transfer roles. These records let later training, error, and Completion evidence refer to the same object.

The simulated snapshot supplies neither a full training history nor a unique fault diagnosis. BDF is not used as a permanent hardware identity.