Physical Layer — Getting Information Across the Connection

Chapter 3.1 decided what operation is being performed. Chapter 3.2 made sure the resulting packet crosses one Link reliably — and assumed a working connection to cross it on.

This chapter examines that assumption:

What responsibilities remain after the upper layers have decided what information must cross a Link?

The honest answer is: a great deal, spanning several engineering disciplines. This is also the layer most often reduced to a single word — "SerDes" — which is misleading enough to be worth correcting early.

1. What Is Actually Left to Do

By the time a packet reaches this layer, the interesting decisions have been made. The operation is defined. Delivery bookkeeping is in place. What remains is a transformation problem with a real constraint attached: the information exists as logical values in a digital domain, and it has to cross a physical connection to a component that has no shared state with this one.

That transformation is not one step. Working outward from the digital side, information must be:

• framed so the receiver can tell where meaningful units begin and end
• conditioned into a form suitable for transmission over a real channel
• distributed across whatever physical resources the connection provides
• serialised from parallel digital words into a signalling stream
• driven onto the physical medium as electrical signals

And at the far end, all of it reversed — by a component that was not told when transmission started, does not share a clock in the way a synchronous parallel bus did, and must recover timing from what it receives.

That last point is worth pausing on. Chapter 1.6 established why a shared bus clock accompanying a wide parallel word stopped scaling, and Chapter 1.8 established that PCIe's answer was to stop requiring one. The consequence lands here: the receiver must derive its timing from the incoming signal itself. That single requirement accounts for a substantial fraction of this layer's complexity, and none of it is visible from above.

2. The Two Paths

Two clarifications about Figure 1, because conceptual pipelines invite over-reading.

These are groupings of responsibility, not mandated blocks. Real implementations partition differently, merge stages, and pipeline across them. The figure shows what work exists, not how anyone must arrange it.

The specific mechanisms are generation-dependent and deliberately absent. How information is conditioned for the channel, what marks unit boundaries, and how the connection's physical resources are used all have precise normative definitions that changed across PCIe generations. Module 5 covers generational evolution, Module 6 covers how a connection's width is expressed and used, and Module 17 covers the physical layer's mechanisms in detail. Learning the encodings before the responsibilities is the wrong order.

3. "The PHY" Is Several Different Engineering Domains

This is the section with the most practical value for anyone working in a real semiconductor organisation, and it is routinely skipped.

"Physical Layer" names a protocol responsibility. It does not name a block, a team, or a design discipline. In practice the responsibility is discharged by logic spanning several domains with genuinely different engineering, different tools, and usually different people:

• Digital logic, close to the Data Link Layer, handling framing, buffering, control, and the interface upward. Ordinary synthesisable RTL.
• Coding and conditioning functions, preparing information for transmission and recovering it — often described with terminology such as a physical coding sublayer. Frequently still digital, though sometimes partly hardened.
• Serialisation and deserialisation, converting between parallel digital words and a high-rate signalling stream. Mixed-signal, typically not written as synthesisable RTL by a digital designer.
• The analog and electrical interface — transmitters, receivers, timing recovery, and the circuitry that copes with a real channel. Analog and mixed-signal design, an entirely separate discipline.

The practical consequence for a digital RTL engineer is worth stating plainly:

You may own a portion of "the PHY" and not the rest of it. Very commonly, a digital designer owns logic up to an interface with a hardened block, and everything beyond that interface is somebody else's problem in a different discipline.

That is not a limitation to work around — it is a normal division of labour in silicon. But it changes what you should be doing. Your correctness obligations end at a defined interface, your verification targets that interface, and when something fails, determining which side of it the fault lies on is the first diagnostic step, not an afterthought.

4. The Digital Boundary You Actually Own

Given that split, the most useful RTL to examine is not a serialiser — which would be misleading to model in synthesisable logic — but the digital boundary around the PHY, which is genuinely where a digital designer works.

One responsibility at that boundary is universal and instructive: the connection is not always usable, and the layers above must be prevented from proceeding as though it were.

A connection has to be established before it carries traffic, and it can become unusable afterwards. Something must gate upper-layer activity on that availability, hold data safely when it is withdrawn, and report status upward. That is ordinary, synthesisable, and worth getting right.

// Illustrative digital-PHY boundary RTL — NOT a PCIe Physical Layer.
// Models gating of upper-layer traffic on an abstract availability signal,
// with data preserved under backpressure and a status path exposed upward.
module phy_boundary_gate #(
  parameter int unsigned DATA_W = 128
) (
  input  logic              clk,
  input  logic              rst_n,
 
  // Abstract connection availability. In a real design this is produced by
  // the link-establishment logic; its semantics are NOT modelled here.
  input  logic              link_ready,
 
  // From the Data Link Layer
  input  logic              up_valid,
  output logic              up_ready,
  input  logic [DATA_W-1:0] up_data,
 
  // Toward the serialising / hardened portion of the PHY
  output logic              phy_valid,
  input  logic              phy_ready,
  output logic [DATA_W-1:0] phy_data,
 
  // Status reported upward
  output logic              stalled_on_link,  // upper layer blocked by availability
  output logic              dropped_error     // held data lost to a withdrawal
);
 
  // One holding stage. Real designs use deeper buffering sized for latency
  // across the boundary; one stage is enough to show the required behaviour.
  logic [DATA_W-1:0] hold_data;
  logic              hold_valid;
 
  // Accept from above only when the connection is available AND we have room.
  assign up_ready  = link_ready && (!hold_valid || phy_ready);
  assign phy_valid = hold_valid && link_ready;
  assign phy_data  = hold_data;
 
  assign stalled_on_link = up_valid && !link_ready;
 
  wire accept = up_valid  && up_ready;
  wire emit   = phy_valid && phy_ready;
 
  always_ff @(posedge clk or negedge rst_n) begin
    if (!rst_n) begin
      hold_valid    <= 1'b0;
      hold_data     <= '0;
      dropped_error <= 1'b0;
    end else begin
      dropped_error <= 1'b0;   // single-cycle pulse
 
      if (!link_ready) begin
        // Availability withdrawn while holding data: that data cannot be
        // delivered. Report it rather than silently discarding — the layer
        // above owns the recovery decision, not this boundary.
        if (hold_valid) begin
          hold_valid    <= 1'b0;
          dropped_error <= 1'b1;
        end
      end else begin
        case ({accept, emit})
          2'b10: begin                 // taking new data, nothing leaving
            hold_data  <= up_data;
            hold_valid <= 1'b1;
          end
          2'b01: begin                 // data leaving, nothing arriving
            hold_valid <= 1'b0;
          end
          2'b11: begin                 // simultaneous — replace in place
            hold_data  <= up_data;
            hold_valid <= 1'b1;
          end
          default: ;                   // idle: hold state unchanged
        endcase
      end
    end
  end
endmodule

What this models: the gating and holding behaviour any digital boundary around a PHY needs — refuse work when the connection is unavailable, preserve accepted data under downstream backpressure, and surface status rather than failing silently.

What is deliberately simplified: one holding stage rather than buffering sized for real crossing latency; no clock-domain crossing, which a real boundary almost certainly needs (§6); no framing or control-information handling; and link_ready treated as a clean synchronous input when in reality it comes from a state machine with its own timing.

What to notice:

• up_ready depends on link_ready, so an unavailable connection produces backpressure, not silent acceptance. Data accepted into a boundary that cannot transmit it is data lost.
• Held data survives downstream stalls. The 2'b11 case handles simultaneous accept-and-emit without dropping either.
• Loss is reported. When availability is withdrawn while holding data, dropped_error pulses. This boundary does not attempt recovery — the layer above owns retention and retry (Chapter 3.2), so its job is to report accurately and let the owner decide.

What production RTL would additionally require: clock-domain crossing with proper synchronisation, deeper and correctly-sized buffering, control-information paths alongside data, handling of link_ready glitching or asynchrony, and coordinated reset with the hardened portion of the PHY.

5. Asserting the Boundary Properties

// SVA over the illustrative boundary module above.
// These check this model's internal contract, not PCIe requirements.
// Assumption: link_ready is synchronous to clk and glitch-free — a real
// design must establish that separately before these properties are valid.
 
// P1 — nothing is accepted from above while the connection is unavailable.
property p_no_accept_when_unavailable;
  @(posedge clk) disable iff (!rst_n)
  !link_ready |-> !(up_valid && up_ready);
endproperty
a_no_accept_unavailable : assert property (p_no_accept_when_unavailable);
 
// P2 — held data is stable while it waits to be emitted.
property p_held_data_stable;
  @(posedge clk) disable iff (!rst_n)
  (phy_valid && !phy_ready && link_ready) |=> $stable(phy_data);
endproperty
a_held_stable : assert property (p_held_data_stable);
 
// P3 — an empty stage never claims to have data.
property p_no_valid_when_empty;
  @(posedge clk) disable iff (!rst_n)
  !hold_valid |-> !phy_valid;
endproperty
a_no_phantom_valid : assert property (p_no_valid_when_empty);
 
// P4 — reset clears local state; nothing survives into the next session.
property p_reset_clears;
  @(posedge clk)
  !rst_n |=> (!hold_valid && !phy_valid);
endproperty
a_reset_clears : assert property (p_reset_clears);

Each addresses a specific failure that is easy to create and hard to find.

P1 prevents the worst boundary bug: accepting data the boundary cannot transmit. The layer above will consider it handed off and stop retaining it in the sense it was retaining it before — and it is simply gone.

P2 matters for the same reason it mattered in Chapter 3.1. If held data can change while waiting, the receiving side may capture a mixture of two different words. The resulting corruption is not detectable as a transmission error, because it was corrupted before transmission — integrity checks computed downstream will be perfectly consistent with the wrong data.

P3 catches phantom valid, which injects undefined data into the transmit path and produces corruption with no obvious source.

P4 matters because this boundary sits between domains that may reset at different times. State surviving reset produces failures at the start of the next session that look like establishment problems and are not.

6. Implementation Realities Worth Knowing

Several concerns at this boundary are genuinely different from anything in the layers above, and they are where a digital engineer's PHY-adjacent work actually gets difficult.

Clock domains. The digital logic and the high-rate serialising portion do not generally operate in one clock domain. Something must cross between them safely. This is standard CDC engineering — synchronisers, correctly-designed asynchronous FIFOs, no combinational paths across the boundary — and it is a common source of intermittent bugs precisely because a functionally-correct design can still be a metastability hazard. Note that the illustrative module above does not model this and would need it in reality.

Datapath width versus signalling rate. Digital logic processes wide words at a manageable frequency; the connection carries a high-rate stream. The width conversion is deliberate: it lets synthesisable logic run at achievable frequencies. A consequence worth internalising is that the digital side does not see the signalling rate, which is exactly why RTL simulation cannot tell you anything about signal integrity.

Reset coordination. Digital logic and hardened blocks often have different reset requirements and sequencing. Getting this wrong produces failures only at initialisation, which are easy to dismiss as environment problems and hard to reproduce.

Latency. The digital pipeline contributes real latency in both directions. It is usually not the dominant term but it is not free, and it matters for any latency budget.

What simulation can and cannot tell you. RTL simulation operates on logical values. It cannot model the electrical behaviour of a real channel — attenuation, reflections, jitter, noise. Those are analysed with entirely different tools and methods. This is not a gap in your testbench; it is a category boundary. A design can pass every RTL test and fail on real silicon for reasons no RTL test could have detected, which is why the verification of this layer is split across scopes (§7).

7. Verification Across Three Scopes

One testbench does not prove this layer. The responsibilities span domains that are verified differently, and conflating them produces false confidence.

Digital PHY RTL. Ordinary RTL verification of the logic you own: handshake integrity, data preservation under backpressure, correct gating on availability, clock-domain crossing correctness, reset behaviour, and status reporting. Assertions like §5's belong here. This scope proves your logic behaves correctly given well-behaved inputs from the hardened portion — and that qualifier is doing real work.

PHY subsystem. Interactions between digital logic and the rest of the PHY, typically using a model or BFM standing in for the hardened block. This is where establishment behaviour, status and error indications, and the response to a connection becoming unavailable get exercised. The fidelity of your results is bounded by the fidelity of that model — a BFM that never produces marginal behaviour will never find your handling of it.

Electrical and mixed-signal validation. Signalling quality, timing recovery behaviour, channel effects, and compliance. Different tools, different expertise, frequently different people, and largely outside RTL simulation entirely.

8. Debugging: Signatures at This Layer

Upper layers have valid data but the boundary never accepts it. Check availability first. If link_ready (or its real equivalent) is deasserted, the question is not why the boundary refuses — it is correctly refusing — but why the connection is unavailable. That is an establishment question, not a data-path one.

The connection reports unavailable. Establishment or maintenance, and the investigation belongs to the state machine governing it, not to the packet path. Confirm whether it ever became available or whether it was lost after working — those have different causes.

Received data reaches the digital boundary corrupted. Determine whether integrity checks are failing. Consistent corruption suggests a systematic problem — a control or framing mismatch, a width or alignment error at the boundary. Intermittent corruption correlating with physical conditions suggests transport, which is not investigable in RTL.

Intermittent failures that correlate with temperature, voltage, or specific hardware. Almost certainly outside the digital domain. Time spent re-reading RTL here is usually wasted; the correlation is the evidence.

Failures only at reset or after a connection is disturbed. Reset coordination or the digital response to availability changing. State surviving reset, or a boundary that does not clean up held data, produce exactly this.

Data corruption with no transaction semantic error. The transaction was well-formed; something below altered it. Work down from the boundary, checking where the data was last known correct. Distinguish corruption before transmission — which upstream integrity checks will happily bless, because they are computed on the already-wrong data — from corruption in transmission, which those checks are designed to catch.

One Link affected while unrelated Links are healthy. Confines the problem to that connection: its physical construction, its hardened block instance, or its digital boundary logic. It rules out anything shared. This is the same reasoning Chapter 3.2 applied — confinement to one Link is diagnostic information, and it eliminates whole categories of suspect immediately.

9. Common Misconceptions

10. Understanding Check

11. Who Owns Which Question

With all three layers defined, the responsibility split can be stated compactly. This is a summary of what each layer answers — not a complete responsibility matrix, which Chapter 3.4 develops properly including the ambiguous cases.

Read down the table and the design logic is visible: meaning, delivery, transport — each complete on its own, each verifiable without the others, and each with its own failure signatures.

12. Summary

The Physical Layer turns logical information into signalling that traverses a Link and reconstructs received signalling into information the upper layers can consume. On transmit that means framing, conditioning, distributing across the connection's resources, serialising, and driving; on receive it means all of that reversed, plus recovering timing from the incoming signal — an obligation that exists because PCIe deliberately abandoned the shared bus clock model.

It is not one thing. The responsibility spans digital logic, coding and conditioning functions, serialisation, and an analog interface — different engineering, different tools, usually different people. A digital RTL engineer commonly owns logic up to an interface with a hardened block, which makes determining which side of that interface a fault lies on the first diagnostic step rather than an afterthought.

At the digital boundary, the durable responsibilities are to gate upper-layer traffic on connection availability, preserve accepted data under backpressure, and report loss rather than discard it silently — since retention and retry belong to the layer above. Real implementations additionally require clock-domain crossing, correctly-sized buffering, and coordinated reset.

Verification splits across three scopes — digital RTL, PHY subsystem with a model of the hardened portion, and electrical validation — and no single scope proves the layer. That split is also a triage structure: deterministic simulation failures are digital, condition-correlated hardware failures are not, and failures at establishment point at the boundary between them.

Hold the model: this layer moves information across the connection; it has no opinion about what the information means or whether it needed to be sent again.

13. What Comes Next

Module 3 has now defined each layer individually: what operation is being performed, whether the packet crossed one Link, and how information crosses the connection.

Chapter 3.4 — Layer Responsibilities makes the boundaries rigorous. Clean cases are straightforward; the value is in the ambiguous ones, where responsibility for a behaviour is genuinely arguable and getting it right determines where you look when it breaks.

Chapter 3.5 — Layer Interactions then traces one packet's complete journey — down the stack at the source, across the Link, up the stack at the destination — and back, showing how the layers actually cooperate rather than merely coexist.

Revisit Data Link Layer for the layer whose assumption of a working connection this chapter examined, or Transaction Layer for where operation meaning is decided. Browse the full path on the PCIe tutorials index.