Quantcast
Channel: Cadence Functional Verification
Viewing all articles
Browse latest Browse all 652

Building Verification Infrastructure for Complex PCIe Verification

$
0
0

Introduction

PCIe (Peripheral Component Interconnect Express) is a high-speed serial interconnect that is widely used in consumer and server applications. Over generations, PCIe has undergone diversified changes, spread across transaction, data link and physical layers. The latest PCIe 6.0 specification, too, has significant changes like the introduction of the flit concept, PAM4 signaling, L0p, shared flow control, and the fixed TLP format. The evolution of several generations has disrupted the existing design flow, thus making the verification process a critical and challenging aspect. Verifying all these new features and enhancements across several generations of PCIe while maintaining backward compatibility requires advanced system-level verification to ensure at a first-order that things did not break and then to verify the intricate new changes. There are several challenges in the verification, as mentioned further, which require corresponding great infrastructure to support it.

Verification Areas

Some of the challenging areas to be addressed in the infrastructure are as follows.

Phy layer encoding formats: Over generations, there has been different encoding modes introduced like 8b/10b, block mode and 1b/1b. The encoding formats are totally different, and particularly, in flit mode that was introduced in PCIe 6.0 specification. The flow control, error detection and correction, and sequence numbering have completely changed. Some of the new challenges introduced by flit mode are sequence number verification, which is not readily available in flit packets, retry buffer verification to check if the same TLPs are retried, validating Nak transmission, which could be a standard Nak or a selective Nak, etc. The verification infrastructure should handle verifying multiple packet types both at the TLP level while operating in older encoding modes and at flit level while operating in 1b/1b encoding mode.

Phy layer link training process: Any LTSSM test sequence should continue to maintain compatibility to work at all speeds. Enhancements added for each new generation had made the test sequences more complex. Specifically, with the introduction of flit mode from PCIe 6.0, all speeds from Gen1 till Gen6 should be validated across all encoding formats. Some of the features that have changed over generations include - low power, equalization, link width support, etc.

Phy layer training sequences (TS): In PCIe 6.0 specification, alongside the Training Set 1 and Training Set 2 sequences, a new set of similar Training Set sequences was introduced with the concept of symbol mirroring. There was also a new Training set added called TS0 for equalization, which is tough to predict because this sequence comes in between TS1 sequences and is transmitted differently for a Root Complex and an Endpoint DUT, respectively. Verifying the compatibility of older Training set sequences at lower speeds, new flit Training sequences at Gen6 speed and older generation tests in each of the evolving newer speeds is challenging. The verification infrastructure should verify all the Training set sequences for timing, correctness, mirrored values, and backward compatibility for all relevant speeds.

Phy layer link width: The linkwidth upconfiguration and downconfiguration till PCIe 5.0 specification happened through entry to Configuration state. But with PCIe 6.0 specification, upconfiguration had to go through link up all over again. Also, downsizing and upsizing had to be done through a new feature called L0p for flit mode. The verification infrastructure should be smart to handle link up and down configurations of all combinations like x1, x4, x8, x16, x32, and for all speeds for both non-flit and flit modes. Some challenges include - older generation tests that cannot be re-used for Gen6 speed, complicated link configuration entry in Gen6 speed for link width change, active and in-active lanes monitoring in L0p, and accommodating multiple specification versions.

Randomization: PCIe has many randomization parameters like packet transaction fields, protocol features, protocol parameters and timing parameters. The randomization is not only limited to these but also includes a combination of several of such parameters. The verification infrastructure should continue to support and maintain all these combinations over several generations, which makes the randomization and test sequences even more complex. This needs to be verified in several topologies like RootComplex/EndPoint/Switch DUT types working with Serial/PIPE interfaces.

Assertionvalidation: There are thousands of assertions in PCIe spread across the generations, across the layers and across the interfaces. The verification infrastructure should be self-checking and continuously monitor any unexpected assertion across all the combinations.

Layer dependencies: The layers in PCIe - transaction, data link and physical layers have a lot of interdependencies and common functionalities. The verification infrastructure should have the common APIs and need to be maintained/enhanced over new generations.

Functional coverage: Functional coverage plays a key role in verification closure. The coverage metrics quantify the feature testing and completeness. The test sequences should be smart, and randomization should be robust to achieve full coverage in quick time across all generations for all DUT and all interface types.

More Information


Viewing all articles
Browse latest Browse all 652

Trending Articles



<script src="https://jsc.adskeeper.com/r/s/rssing.com.1596347.js" async> </script>