In compliance we trust, for integration we verify

So, you dropped that piece of complex IP you just licensed into an SoC design, and now it is time to fire up the simulator. How do you verify that it actually works in your design? If you didn’t get verification IP (VIP) with the functional IP, it might be a really long day.

Compliance checking something like a PCIe interface block is a stringent process that has to explore every sequence of a protocol. A diligent IP vendor will have performed exhaustive testing on a block to assure the protocol execution conforms within interoperability guidelines. For most third-party blocks that have been released, it is a fairly safe assumption that the block executes the protocol under controlled conditions.

An SoC design, with multiple cores operating in a complex application generating traffic asynchronously, usually doesn’t qualify for “controlled conditions”. The job of integration testing is to expose known-good IP to stimuli within the complete environment, subjecting it to just enough chaos to increase confidence in the overall design.

A recent Synopsys webinar titled “Accelerate PCIe Integration Testing with Next-Generation Discovery VIP” walks through the thought process behind verifying a piece of complex interface IP. Paul Graykowski, Senior Corporate Application Engineer (CAE) for Synopsys, outlines four areas that should be explored. My Cliff Notes version:

Link testing – first, a PCIe link must be trained. VIP allows setting the number of lanes and the link speed, verifies that L0 is reached, and performs enumeration. From L0, link speeds can need to be renegotiated, from 8Gbps for Gen3, down to 5Gbps and 2.5 Gpbs. Finally, lane reversal needs to be checked and verified.

Traffic testing – first, the PCIe block is set up as requester, and the VIP block as completer. A set of reads and writes with different completion and payload sizes is done, looking for proper multiple completions with random data sets. Then the roles are reversed, and the VIP is the requester. Config writes and reads to random registers and random addresses with randomized payload sizes are performed. Finally, a series of writes and reads is performed with other AXI traffic in the system.

Interface testing – supported PCIe interfaces include SERIAL, PARALLEL, and PIPE; all must be verified. Also important is verifying lane error handling, forcing negotiation to a lower number of lanes, and looking at common errors such as disparity and bit-flipping. Gen3 equalization should also be checked, seeing that coefficients are requested and rejected. Finally, the behavior under power management scenarios, including things like hot plug and clock gating, should be verified.

Performance testing – with things working, performance can then be verified. With background AXI traffic not targeting the PCIe block running, concurrent traffic is then generated with direct I/O for PCIe, and the latency and throughput is verified.

Sounds easy, right? Even if you’re a PCIe expert, generating the cases is non-trival, and that is assuming everything works. When is enough coverage enough? And how do you debug something subtle when it goes wrong?

The architecture includes coverage models, so you can track things like tests for all the layers of the protocol – transaction, data link, and PHY – and combinations of traffic class and virtual channels, including cross combinations. It allows you to track DLLPs, looking at ack/nak, power management, flow control, and injected errors. It also allows you to track TLPs, looking at transaction types, header values, sequence numbers, error injections, and completion status.

For protocol-aware debug, the Protocol Analyzer understands a TLP, DLLP, credits, ordered set, LTSSM state – all presented in graphical way – and also understands waveforms. You can select a particular TLP, and see address, data, byte enables, and descendants. You can also put more than one protocol side-by-side, say AXI in, PCIe out, to explore deeper issues.

There’s more in this webinar, and if you are new to verification, or having a hard time justifying the outlay of buying into commercial verification IP, or just curious what the verification process looks like beyond the mechanics of writing SystemVerilog, it is definitely worth a look. Synopsys has a full range of verification IP for a variety of interfaces and protocols, and the site has more information on things like error injection, coverage tracking, and protocol-aware debug.