Intermediate PCIe Interview Questions — Mechanisms, Not Definitions

27.1 tested what kind of thing PCIe is. This round tests whether you know how it is assembled — and the difference shows up in one specific way: intermediate answers name a mechanism with a sequence of steps, where beginner answers name a thing.

1. Sources, Scope, and What This Chapter Refuses to Do

2. What the Intermediate Level Tests

Three readings.

Every row moves from what to how. The beginner answers in the right column are not wrong — they are the correct answers to easier questions, and the interviewer is checking whether you have the next layer.

Rows 2 and 8 are the two that most often separate candidates. BAR sizing is a negotiation with a specific trick (§4), and completion matching requires identity (§10). Both are mechanisms with an exact sequence, and both are commonly assumed rather than known.

And row 6 is where an intermediate candidate can outperform expectations. Most candidates can list ordering rules if they revised them. Being able to say why the rules exist — what would break without them — is an advanced-level answer given early (§8).

3. "What Exactly Is a Configuration Request?"

15 seconds. "It's the transaction type the Root Complex uses to read and write a function's configuration space. It's the only way a device is discovered and set up, and only the Root Complex originates it."

60 seconds. Add the two types and why there are two: "a Type 0 Configuration Request targets a function on the link it arrives at — the device is right there. A Type 1 is targeted at a device behind a bridge: a switch's upstream port receives it, looks at the bus number, and forwards it downstream, converting to Type 0 when it reaches the target bus. That's how configuration reaches into a tree from a single origin" (8.1, 2.4).

Then the consequence worth volunteering (7.1): "and because it's the only discovery mechanism, enumeration is a walk — configure the bridge, assign a bus number behind it, then configure what's behind that. The topology is discovered depth by depth, not read from a table."

And a related question that arrives with it: "what does the host learn from the configuration header?" — what the device is, what class it is, what capabilities it advertises, and how much address space it wants (8.6). The last of those is §4.

4. "How Does the Host Know How Big a BAR Should Be?"

This is the intermediate question most often assumed rather than known, and the mechanism is elegant.

The answer. "The device tells it, through the BAR register itself. The host writes all ones to the BAR and reads it back. The device only implements the upper bits — the bits corresponding to the size it needs are writable, and the low bits are hardwired to zero. So the value that reads back has a run of zeros at the bottom, and the position of the lowest writable bit tells the host both the size and the required alignment. The host then writes a real base address into the writable bits."

Why this is a good design, which is the follow-up: "the device declares its requirement in a way that makes size and alignment the same fact. A window has to be naturally aligned to its size, and encoding the size as 'which low bits are not implemented' makes an unaligned assignment structurally impossible" (9.4, 9.5).

Illustrative worked example (invented values for arithmetic — §1):

Two more things an interviewer may pull.

"What else is in a BAR besides the address?" — bits indicating the kind of window: memory versus I/O space, and for memory whether it is prefetchable and whether it is 32- or 64-bit (9.2, 9.3). Do not quote bit positions (§14).

"What if the host cannot fit it?" — the window is not assigned and the device is unusable, which is a real bring-up failure and a resource-allocation problem rather than a protocol one.

5. "How Is a TLP Routed?"

15 seconds. "Three methods: by address, by ID, and implicitly. Which one applies depends on the transaction type."

60 seconds. "Memory requests are routed by address — a switch compares the address against the windows it has learned for each downstream port and forwards accordingly. Completions and Configuration Requests are routed by ID: the requester's bus/device/function identifies where a Completion must return, so a Completion follows the requester ID rather than an address. And some messages are routed implicitly — for example toward the root — without either" (11.5, 21.1).

The consequence worth volunteering, because it is the reason this question is asked: "ID routing is why a Completion can find its way back through a tree without the requester having to encode a return path — and it is why a requester must be able to match a returning Completion to the request that produced it" (§10).

6. "What Is in a TLP Header?"

Answer by category, never by field position (§1, §14).

The strong framing. "The header is what makes a packet a transaction rather than bytes: it says what kind of operation this is, where it goes, who asked, which of that requester's outstanding operations it is, and how much data is involved."

And the honest close (§14): "the exact field widths and bit positions are revision-specific and I'd read them from the specification revision in use rather than recall them."

7. "Max Payload Size and Max Read Request Size — What Is the Difference?"

They are two different limits and candidates routinely merge them.

60 seconds. "MPS caps the payload of a single packet, so it controls how many packets a large transfer becomes and therefore the header overhead. MRRS caps how much a single read request may ask for, so it controls how many requests a large read becomes — which matters because each request consumes a tag and a round trip. They interact: a large MRRS with a small MPS means one request answered by many Completions" (22.4, 13.3).

The connection that makes this an intermediate answer rather than a definition: "and that's why 'bigger is faster' is only true up to a point — a large MRRS reduces request count but the data still arrives as MPS-sized Completions, so the payload efficiency is set by MPS while the round-trip count is set by MRRS" (26.4 §2 works the efficiency arithmetic).

Do not quote permitted values (§1). Do say that a path's usable MPS is constrained by what every component along it supports.

8. "What Ordering Rules Exist, and Why?"

The strong answer starts with the why, because the rules are memorable only once their purpose is clear.

The purpose. "Producer-consumer. A device writes data and then writes a flag, or raises an interrupt. Software reads the flag and then the data. For that to work, the flag must not become visible before the data — so the ordering rules exist to make a later signal unable to overtake earlier data" (26.1 §6).

Then the structure. "Ordering is defined between transaction classes — posted, non-posted and completion — and per direction on a link. The rule that matters most for producer-consumer is that a posted write cannot be passed by another posted write from the same requester, which is what keeps a flag behind its data. Some relaxations exist and are requested explicitly through attributes" (13.4, 11.6).

Two follow-ups to have ready.

"Is an MSI ordered with respect to the data it announces?" — "yes, because an MSI is a posted memory write, not a signal. That's the whole reason producer-consumer works with interrupts" (19.2, 26.1 §6). Volunteering this is an advanced answer.

"Where can the ordering still be lost?" — "below the Root Port. PCIe orders the stream on the wire; preserving that to the point where a core can observe it is the Root Complex's obligation, and it is a separate problem" (26.1 §5).

9. "What Does a Completion Tell You Besides the Data?"

A status, and the intermediate point is that a Completion can arrive and mean failure.

The strong framing. "A Completion is a response, not a confirmation. A non-successful status means the request reached something that answered and declined, which is very different information from no Completion arriving at all — one says 'the target rejected this', the other says 'nothing answered'. Those point at different parts of the topology."

And the intermediate trap: "which is why a DMA engine must handle a non-successful Completion as a terminating event rather than accumulating it as data" (26.2 §8) — a design that treats status as a field to ignore builds a transfer out of partly undelivered bytes.

Do not quote status encodings (§14).

10. Read the Trace — the Obvious Reading Is Wrong

The question: "Which request does the completion at cycle 6 answer?"

The obvious answer is A, and it is wrong. The completion at cycle 6 carries tag 7, so it answers request B — the second one issued. Completions for different requests are not required to return in issue order (13.4), and the tag is the only thing in the trace that identifies which request a completion belongs to.

The follow-up: "What breaks if your engine assumes FIFO order?"

B's data is written to A's destination and A's to B's — silently, with every Completion well-formed and correctly routed. No protocol error occurs, because nothing on the wire was violated: the requester simply mis-attributed two correct responses (26.2 §7 works this failure out in RTL, and 23.3 owns the correct engine).

The second follow-up: "So what state makes this safe?"

A table indexed by tag, holding the destination and the byte accounting for each outstanding request, with retirement driven by the tag in the arriving Completion rather than by arrival order. And the tag must not be reused until its request has fully retired — because a tag reused early makes a late Completion indistinguishable from a new one.

One more observation available in the trace: outstanding decrements on completion, not on issue — the same point as 27.1 §10, now load-bearing, because it is the count that tells you a tag is still live and must not be reallocated.

11. Whiteboard RTL — a BAR Decode

An intermediate interview may ask for small RTL. A BAR hit is the ideal size: five lines, and it tests whether §4's alignment insight was understood.

// ILLUSTRATIVE. A single BAR hit. The mask is derived from the window size, so
// alignment and size remain the same fact (§4) — which is exactly why the
// probe-with-ones mechanism encodes them together.
localparam int  BAR_SIZE_LOG2 = 12;                        // 4 KB window
localparam logic [63:0] BAR_MASK = ~((64'd1 << BAR_SIZE_LOG2) - 64'd1);
 
logic [63:0] bar_base_q;      // written by the host at enumeration (§4)
logic        bar_enabled_q;
 
// Hit when the request address falls inside the window. Comparing MASKED
// addresses is what makes this correct for any naturally aligned size.
assign bar_hit = bar_enabled_q &&
                 ((req_addr & BAR_MASK) == (bar_base_q & BAR_MASK));
 
// The offset within the window — the low bits the BAR does not implement.
assign bar_offset = req_addr & ~BAR_MASK;

Architecture. One comparison and one mask, because a BAR window is naturally aligned to its size — which makes a masked compare exactly equivalent to a range check, at a fraction of the logic.

State. bar_base_q, written by the host during enumeration (9.5); bar_enabled_q, because a window that has not been assigned must not respond.

Event. Evaluated per inbound request.

Contract. The host's contract is that it assigned a naturally aligned base (9.4). If it did not, the masked compare aliases — and this decode would claim addresses outside the window.

Failure. Two realistic errors. Omitting bar_enabled_q makes the device respond before it has been assigned an address, so it claims whatever bar_base_q resets to. And a range compare with a hand-written upper bound — addr >= base && addr < base + size — is correct but wider, and it invites an off-by-one that a mask cannot express.

DV/debug. The assertion worth stating is that the base is aligned to the window size — which is §4's insight turned into a check, and an interviewer asking "how would you verify this?" is looking for exactly one line:

// MANDATORY. English: an enabled BAR's base address is aligned to the window
// size. This is §4's "size and alignment are the same fact" as a property —
// and it is what makes the masked compare above equivalent to a range check.
// Catches a host, a test, or a driver that assigned an unaligned base, which
// would otherwise silently alias addresses outside the window.
a_bar_base_aligned: assert property (
  @(posedge clk) disable iff (!rst_n)
    bar_enabled_q |-> ((bar_base_q & ~BAR_MASK) == 64'd0)
);

It uses |-> because the property is about a state, not a sequence — whenever the BAR is enabled, its base must already be aligned. And it is a good formal target: two registers of context, and a counterexample is a concrete misaligned address rather than a trace.

12. The Traps

And the pattern across all six: each is the correct answer to a simpler system. A function call does return its own value; a bus does broadcast. These are transfers of valid intuition into a system that works differently, which is why they survive study and fail in a room.

13. Whiteboard — Enumerate a Device

"Walk me through what happens between power-on and a driver being able to read a device register."

A strong answer is a sequence with named steps, and it should take about ninety seconds:

Link training brings the physical link up (18.5). The Root Complex issues Configuration Requests and gets a valid response, which is discovery (8.1). It reads the configuration header to learn what the device is and what it advertises (8.6). It probes each BAR with ones and reads back to learn size and alignment (§4). It assigns naturally aligned base addresses (9.5). It enables the device's memory decoding. The driver binds and maps the window, and a read of that window now reaches the device (9.6).

Two additions that demonstrate depth. If a switch is in the path, insert the Type 1 forwarding step and the bus-number assignment behind it (§3). And note the deadline — a device not answering when the host scans is indistinguishable from an empty slot (26.5 §5).

The weak version of this answer names the steps in the wrong order — assigning BARs before sizing them, or having the driver do the assignment. Order is the whole content of the question.

14. When You Do Not Know

Intermediate questions invite requests for exact values, and this is where a candidate is most likely to bluff.

The correct answer, in two parts. "That's revision-specific — I'd check the revision we're building to rather than recall it. What I can tell you is what the field accomplishes and what goes wrong if it is set incorrectly…" and then continue.

Applies to: header field widths and bit positions, completion status encodings, permitted MPS and MRRS values, tag width, register offsets, timer values, and generation-specific rates and encodings.

Two readings.

The knowledge being tested is the mechanism, not the constant. An interviewer asking about MPS almost always wants the consequence (§7), and a candidate who supplies the consequence and declines the value has answered the real question.

And one invented value contaminates the rest of the interview. It is a cheap way to lose credit already earned — whereas naming the boundary of your knowledge and continuing is what a colleague sounds like.

15. Readiness Markers

Ready for this level when, without preparation, you can:

• distinguish Type 0 from Type 1 Configuration Requests and say why both exist (§3)
• explain enumeration as a depth-by-depth walk from a single origin (§3)
• describe BAR sizing as a probe — write ones, read back, read the implemented bits (§4)
• explain why size and alignment are the same fact in a BAR (§4)
• name the three routing methods and which transactions use each (§5)
• explain why Completions are ID-routed rather than address-routed (§5)
• describe a header by category rather than by field position (§6)
• distinguish MPS from MRRS and name what each one's smallness costs (§7)
• state the purpose of ordering rules before the rules themselves (§8)
• volunteer that an MSI is a posted write and therefore ordered (§8)
• say that a Completion carries a status, and what a refusal means versus a timeout (§9)
• read a trace and use tags to match completions to requests (§10)
• state what breaks under FIFO completion matching, and what state fixes it (§10)
• write a BAR decode and justify the masked compare (§11)
• decline to quote an encoding or permitted value, and continue usefully (§14)

16. What Comes Next

This round asked how PCIe is assembled. The next asks about the parts that fail under load.

27.3 covers flow control, the LTSSM and MSI-X — credits and what they actually represent, the link states and which transitions matter, and interrupt delivery at the level where its ordering properties matter. The trace and the state diagram both carry a question, and the advanced round is where "I would check the specification" stops being sufficient on its own and has to be paired with a derivation.