In my last blog, I referred to the use of run-control technology to very quickly exercise the PCI Express link training state machine. What other kinds of tests can be run with this approach?
Run-control technology operates at the very lowest level of silicon instrumentation, thereby bypassing the requirements for boot loader, kernel, driver or OS services. This makes it a very powerful utility for performing certain operations very quickly and effectively, provided they are supported within the device DfX (which is short for Design for “X”, where “X” can be “T” for Test, “V” for Validation, “D” for debug, and so on).
In the case of PCI Express, we saw last time (Using Embedded Run-Control for PCIe Link Training Testing) how run-control can be invoked to exercise the Link Training Status & State Machine (LTSSM), which performs such functions such as link width negotiation, link data rate negotiation, bit lock per lane, symbol lock/block alignment per lane, decision-feedback equalization (DFE), etc. etc. This not only can uncover problems at the lowest level of the silicon (at the RTL level), but also identifies problems with reference clock quality, signal voltage level, platform margins, firmware and driver issues, and so on.
Depending upon the support within silicon, a number of different types of tests can be applied to the link, including for example:
Basic Link Retrains
Speed Changes (i.e. Gen1 -> Gen2 -> Gen3)
L1 ASPM (Active State Power Management)
It can be seen that validating PCI Express connections is a complex, multi-faceted function. It is necessary to fully verify the physical layer (confirm that margins are acceptable), check the functionality of the datalink layer, and execute performance and conformance test suites on the transaction layer.
For more information on the use of embedded run-control, please see our technical overview document, ScanWorks Embedded Diagnostics. For more information on Intel Customer Scripts (ICS, also known as CScripts), see Intel Debug Using Python CScripts.