Some PCIe 3.0 Test Examples (Part I)

Figure 1: Protocol and electrical views of
slow electrical response to a preset request

We took a tour of a typical PCIe 3.0 testbench setup in a recent post. Now, let's see that testbench in action with some application examples of some common bad behavior one might encounter from a PCIe 3.0 channel. These include: slow electrical response, slow protocol response, and so on.

Slow Electrical Response

We'll start with a scenario in which the PCIe protocol is behaving normally but the system is slow to respond electrically. The link-equalization process is in Phase 3; the root complex on the system board wants to adjust the add-in card's TxEQ. So it sends a preset request to the add-in card to change its preset to preset 1. If we click on this request in the protocol view, it brings up a zoomed view of the pertinent spot in the protocol-level view (yellow trace at center left in Figure 1). The zoom brings us to the exact time at which that preset request was sent.

Meanwhile, in the electrical waveform at top right, the Teledyne LeCroy ProtoSync software shows us the spot in the waveform that the actual preset change occurred; you can see the obvious change in waveform amplitude as the preset value changed to preset 1.

In measuring the time delay between these two occurrences, we arrive at a value of nearly 6 μs. The requirement in the PCIe base specification is 500 ns or less. For compliance testing, the requirement is 1 μs or less. Thus, the DUT is taking far too long to actually change its TxEQ settings. This could be a serious problem in a real-world setting, because during that delay period, the root complex on the system board thinks the add-in card has changed its TxEQ setting and is trying to tune its RxEQ. This would certainly have an impact on the RxEQ tuning algorithm. Not to mention that the device would abjectly fail in compliance testing.

This example highlights the importance of a protocol-enabled receiver tester, which in this case is the Teledyne LeCroy PeRT 3 Phoenix system, and the ProtoSync software that correlates the protocol-level and physical-level views of the link-equalization sequence.

Another possible scenario is that the protocol-level requests and confirmations are happening, but the electrical waveform shows that the TxEQ setting never actually changed as requested. Just because the add-in card is responding to the system board's request to change its preset doesn't mean that change is actually happening. This is another example that shows why the simultaneous, correlated views of the protocol and physical layers is so important.

Slow Protocol Response

Figure 2: Protocol view of a scenario in which the protocol
response lags the actual electrical response

What about a scenario in which the protocol response to a requested preset lags the actual change in the physical waveform? Again, responses to preset or cursor change requests must not exceed the 500-ns base specification or the 1-μs compliance specification. The test procedure here is the same as in the above example of a slow electrical response. In Figure 2, we can see that the add-in card has responded to a "system board" request, which actually comes from the PeRT 3 system, to change its TxEQ preset to preset 4. However, we see that the time delta for the response is almost 10 μs whereas the electrical response came much faster.

We'll look at some more measurement examples in an upcoming Test Happens post.

Previous posts in this series:

The Hows and Whys of PCIe 3.0 Dynamic Link Equalization
PCIe 3.0 Dynamic Link EQ: De-Emphasis, Preshoot, Cursors, and Presets
An Under-The-Hood View of PCIe 3.0 Link Training (Part I)
An Under-The-Hood View of PCIe 3.0 Link Training (Part II)
A Tour of a PCIe 3.0 Test Setup