Link Structure

Chapter 4.3 ended with the PHY arranging bits across lanes. This chapter is about that arrangement — the actual organisation of a UCIe link — and it exists because link width is not a free parameter you turn up when you need bandwidth. It is bought with die edge, bumps, package routing, power, and PHY area, and Chapter 2.6 already showed that those are finite.

The reason this matters for an architect rather than only a PHY designer is that link organisation propagates upward. It sets achievable bandwidth, constrains which dies can sit next to which, determines what redundancy is possible, and appears in RTL as configuration and health state that has to be managed and verified.

1. A Link Is Not a Wire

The word "link" invites a picture of one connection. A UCIe link is a structured collection of parallel physical resources, organised in a specific hierarchy, and that structure is the subject of this chapter.

A UCIe link is an organised set of parallel physical resources whose structure becomes an architectural parameter — not a single channel whose speed you select.

Two levels of organisation matter: the lane, which is the individual physical resource, and the module, which is the unit the specification organises lanes into and the unit a link is built from.

2. The Lane

A lane is one physical data path: a single-ended connection carrying data in one direction. Lanes are unidirectional, and a link provides them in both directions.

Two properties matter architecturally. Lanes operate in parallel — the link's data path is many lanes carrying different bits of the same transfer simultaneously, which is what makes a die-to-die link wide rather than fast-and-narrow. And a lane is a physical resource that can fail: it is a specific conductor through specific bumps, and manufacturing or assembly defects can render one unusable, which is why lane health is real state a design must track (§7).

3. The Module

Individual lanes are not the unit a link is built from. The specification organises them into modules, and the module is the basic building block.

A module carries a group of data lanes in each direction plus the signals needed to use them: a valid indication, a track lane, and a forwarded clock per direction. Those extras are what make the data lanes interpretable — a receiver needs to know when data is valid and needs a clock to sample against, and neither can be inferred from the data lanes alone.

The number of data lanes per module depends on the packaging class the link targets:

That difference is the whole packaging argument from Chapter 2.6 appearing as a specification parameter. An advanced package — an interposer or bridge providing dense silicon routing — supports far more connections in the same physical space, so a module can be four times wider. A standard organic-substrate package cannot route that density, so its module is narrower.

A module is therefore the granularity at which the link's physical organisation is specified, and it is the unit that gets replicated when a link needs more width.

4. Aggregating Modules

A link is not limited to one module. Multiple modules can be aggregated — the specification supports aggregating 1, 2, or 4 modules — so a link's total width is the module width multiplied by the number of modules.

This is a deliberate scaling mechanism, and it has the same character as Chapter 2.2's compute-die replication: build a well-characterised unit once, then instantiate it. It also means a designer choosing a link configuration is making two decisions, not one — which packaging class (setting the module width) and how many modules (setting the multiplier).

5. Mainband and Sideband

A UCIe link carries two distinct paths, and conflating them causes confusion later.

The mainband is the data path: the module's data lanes plus its valid, track, and forwarded clock. This is what carries transport units, and it is what the width discussion above is about.

The sideband is a separate, much narrower path — a data lane and a forwarded clock in each direction. It exists to carry the traffic needed to manage the link rather than to use it: link training, register access, diagnostics, and management including firmware operations.

The separation is architecturally deliberate. Bringing a link up requires communication before the mainband works — the two dies must agree parameters and train the physical link, and they cannot do that over the path they are still training. A separate, simpler, lower-rate path that comes up first solves a bootstrapping problem the mainband cannot solve for itself.

This also connects back to Chapter 4.2's reset-versus-operational distinction: the sideband is much of how an endpoint gets from "out of reset" to "link operational", and it is the reason that transition takes real time rather than a cycle.

6. Width Is Bought, Not Chosen

Now the architectural cost, which is the heart of the chapter.

Doubling link width doubles the data lanes, and every lane is a physical resource with a chain of consequences:

• Bumps. Each lane needs connections at both ends. More lanes means more bumps, and bump availability is finite.
• Die edge. A PHY sits near the die edge because its connections must reach the package, and edge length is finite regardless of how much die area exists. Chapter 2.6's "add a fourth chiplet" failure was partly an edge failure.
• Package routing. Every lane must be routed between the two dies, competing for the corridors Chapter 2.6 described, and at densities the packaging class supports.
• Power. More lanes switching means more power, in both the PHY and the delivery network.
• PHY area. Each lane needs drivers, receivers, and its share of the digital logic around them.

So the honest framing:

There is no free bandwidth. Width is a request for die edge, bumps, routing, power, and area — and the package decides whether the request is grantable.

This is also why the module abstraction is useful beyond specification tidiness: a module is a quantum of physical cost, so "two modules instead of one" is a statement about roughly doubling that cost, which is a far more actionable planning unit than a lane count.

7. Width, Rate, and Which One to Buy

Bandwidth is, roughly, width multiplied by the per-lane signalling rate. Both are levers and they have different costs.

More width costs the physical resources of §6, scales bandwidth close to linearly, and is limited by what the package and die edge can support. A higher rate costs signal-integrity margin, likely more power per lane and more complex circuitry, and is limited by what the channel can sustain — which, per Chapter 2.6, degrades with distance.

The interesting consequence is that the two levers fail in different ways. Running out of width is a placement and routing problem discovered in package design. Running out of rate is a channel problem discovered in signal-integrity analysis. A design blocked on one is not necessarily blocked on the other, which is why real configurations mix them — the Consortium's own material discusses trading module count against rate to reach a bandwidth target.

8. Bump Pitch and the Packaging Classes

The two packaging classes differ in the density of connections they support, and that difference is what sets the module widths in §3.

Published UCIe material gives approximate bump-pitch ranges of roughly 100–130 µm for standard package and 25–55 µm for advanced package. Treat those as indicative rather than exact — pitch is a packaging-technology property that evolves, and the Consortium has indicated it expects advanced-package pitches to reduce over time.

The architectural reading matters more than the numbers. A finer pitch means more connections in the same edge length, which is precisely why an advanced-package module can carry 64 data lanes where a standard-package module carries 16. Bump pitch is the physical parameter that converts into achievable link width, and it is a property of the packaging technology rather than of the specification — which is why the specification defines two classes rather than one.

9. Lane and Module State in RTL

The organisation above appears in hardware as configuration and health state that must be kept consistent.

Illustrative link-configuration RTL — not UCIe normative signal naming or register definitions.

// Conceptual per-lane configuration and health, for one module.
parameter int unsigned NUM_LANES   = 16;
parameter int unsigned NUM_MODULES = 2;
 
logic [NUM_LANES-1:0]   lane_enable_q;   // configured: this lane is in use
logic [NUM_LANES-1:0]   lane_good;       // observed: this lane is usable
logic [NUM_MODULES-1:0] module_enable_q; // configured: this module is in use

Architecture. Two independent facts about every lane: whether the configuration says it is in use, and whether the physical resource actually works. They are separate because they come from different places — configuration from bring-up and negotiation, health from training and monitoring.

State. lane_enable_q and module_enable_q are configuration registers written during bring-up. lane_good reflects observed physical status.

Contract. Everything above the PHY assumes that enabled resources work. That assumption is only safe if the design keeps the two in agreement.

Failure/DV. If configuration enables a lane that health says is bad, the design transmits on a failed physical resource. Bits placed there are lost or corrupted; whether that is caught depends on the error detection configured at the Adapter, and even when caught it produces persistent errors rather than a clean failure. That is exactly the kind of invariant worth asserting:

// Illustrative property: never have a lane enabled that health says is bad.
property p_enabled_lanes_are_good;
  @(posedge clk) disable iff (!rst_n)
    (lane_enable_q & ~lane_good) == '0;
endproperty
assert property (p_enabled_lanes_are_good)
  else $error("a lane is enabled while reported unusable");

And the module-level equivalent, which catches a different bug — logic driving a module the configuration has disabled:

// Illustrative property: a disabled module must not transmit.
generate
  for (genvar m = 0; m < NUM_MODULES; m++) begin : g_mod_chk
    property p_no_tx_from_disabled_module;
      @(posedge clk) disable iff (!rst_n)
        !module_enable_q[m] |-> !module_tx_valid[m];
    endproperty
    assert property (p_no_tx_from_disabled_module)
      else $error("module %0d transmitted while disabled", m);
  end
endgenerate

Why both. The first is a configuration consistency property — the design's own two views of a lane must agree. The second is a behavioural property — logic must respect the configuration. A design can satisfy one and violate the other, which is why they are separate checks.

10. Deterministic Lane Mapping

A wide transfer has to be distributed across lanes, and the mapping must be deterministic and agreed by both ends.

// Illustrative width partitioning across lanes -- not UCIe's mapping.
localparam int unsigned LANE_W = 8;
 
logic [NUM_LANES*LANE_W-1:0] wide_data;
logic [LANE_W-1:0]           lane_tx_data [NUM_LANES];
 
generate
  for (genvar i = 0; i < NUM_LANES; i++) begin : g_lane_map
    assign lane_tx_data[i] = wide_data[i*LANE_W +: LANE_W];
  end
endgenerate

Architecture. One wide transfer becomes per-lane slices. The receiving side performs the inverse to reconstruct it.

Cycle behaviour. Purely combinational here; a real implementation may register the per-lane data and will serialise it, but the mapping is a fixed relationship rather than a decision made per transfer.

Contract. Transmitter and receiver must agree on the mapping exactly. This is a specific instance of Chapter 3.2's general point: a shared invariant that must be identical on both sides, not merely implemented on each.

Failure/DV — the interesting case. Suppose the receive side reconstructs with two lanes transposed relative to the transmit side. Every bit arrives; no lane fails; the physical link is healthy by every measure. But the reassembled transfer has two slices swapped, so the payload is wrong while the link looks perfect.

Whether this is caught depends on what protection is configured. With Adapter-level error detection enabled, the corrupted transport unit fails its check and is rejected — which surfaces as a persistent error rate rather than a transient one, and a link that trains successfully and then fails all traffic is a strong signature of a mapping fault. In a configuration without that protection, the corruption may propagate upward as valid data. This is a concrete case of Chapter 4.3's misconception: electrical health does not imply transport correctness.

11. Common Misconceptions

12. Understanding Check

13. Summary and What Comes Next

A UCIe link is a structured set of parallel physical resources. A lane is one unidirectional physical data path that can fail. A module groups data lanes with the valid, track, and forwarded-clock signals that make them interpretable, and is the unit a link is built from: 16 data lanes per module for standard package, 64 for advanced, with 1, 2, or 4 modules aggregated per link. A separate sideband — a data lane and forwarded clock per direction — carries training, register access, diagnostics, and management, and exists because bringing up the mainband requires communication before the mainband works.

Width is bought, not chosen. Every lane demands bumps, die-edge length, package routing, power, and PHY area, so a width request is a physical budget request the package may refuse. Rate is the alternative lever, with different costs and a different failure mode — width runs out in placement and routing, rate runs out in signal integrity. Bump pitch is the parameter that converts packaging technology into achievable width, which is why the specification defines two packaging classes at roughly 100–130 µm and 25–55 µm.

In RTL this appears as configuration and health state that must be kept consistent — enabled lanes must be healthy, disabled modules must not transmit — and as a deterministic lane mapping both ends must agree exactly, whose failure mode is uniquely instructive: transposed lanes give a perfectly healthy link that corrupts every transfer.

We now have the stack and the link. The last question in this module is what actually happens, cycle by cycle, when one die sends a payload to another:

• 4.5 — Die-to-Die Communication Flow — the full end-to-end sequence as a chain of local handshakes, with buffering, backpressure, the error path, and a debug method you can reuse.

Browse the full path on the UCIe tutorials index.