EDA
System
IP
SolvNetPlus
Training & Education
Key Highlights:
- Explore verification challenges that arise when dynamically resizing links during runtime. These challenges are especially relevant in AI, HPC, automotive, and mobile SoC applications that demand aggressive power management without sacrificing responsiveness
- The complex interactions between L0p and other states—such as L1 (Low Power Idle), Recovery, and simultaneous link width changes—play a critical role in thoroughly verifying PCIe 6.0 and newer designs
- Synopsys offers PCIe Verification IP (VIP) and System Verification Solutions that simulate and validate complex scenarios to accelerate compliance and ensure design robustness
L0p Verification Complexity and challenges Deep Dive
L0p’s dynamic behavior introduces complex verification scenarios, especially when link width changes occur during normal operation. These include race conditions and interactions with other LTSSM states such as L1 entry and Recovery.
Figure 1: L0p flow diagram
Simultaneous Width Change Requests
When both ends of the link initiate width changes in opposite directions (e.g., one upsizing, the other downsizing), arbitration rules from the PCIe base specification determine the winner. The losing side must acknowledge the winning request, but a NAK is not guaranteed to be received, which can complicate verification.
Example:
- Downstream port requests x16
- Upstream port requests x4
Only one side proceeds; the other must gracefully abandon its request
Figure 2: Simultaneous width change requests
Concurrent L0p and L1 Negotiation
L0p and L1 can occur concurrently, and the LTSSM should prioritize the lower power state. This overlap introduces complex timing interactions:
- L1 entry may interrupt an ongoing L0p width change
- Receivers must continue processing data until all lanes detect EIOS and not just any lane.
- EIEOS may arrive after transmitters enter electrical idle, requiring careful handling
Concurrent L0p downsize and L1 example
Concurrent L0p upsize and L1
• Receivers may receive EIEOS after transmitters enter electrical idle for L1
• Data stream processing continues if EIEOS is not received on an active lanes
Recovery During Width Changes
Either side of the link may decide to enter Recovery for various reasons while a L0p link width change is in progress, leading to mismatches in link width and SKP intervals between the transmit and receive data paths:
L0p Downsizing and Recovery
- Downsizing in progress: Receiver may already be operating at reduced width while the transmitter is required to revert to full width on entry to recovery.
- Transmitter enters recovery, EIOS is received while in recovery.
L0p Upsize in Recovery
- Upsizing in progress: Scrambling and deskew synchronization become critical, especially if EIEOS is received mid-transition. Due to lane-to-lane skew and the rules surrounding EIEOS and scrambling in L0p vs recovery, it can be unclear if the scrambler should behave on upsized lanes when the link partner transitions to recovery.
These scenarios require the receiver to process data correctly despite mismatched conditions, and the transmitter must revert to maximum width and initiate retraining.
Special Error Cases
Several cases must be handled gracefully:
- Abandoned requests: If an L0p request has been ACKd but not completed, no new requests can be made until the timeout expires.
- Lost ACKs: If an ACK DLLP is lost but EIOS is received after a L0p downsize request was sent, the requester must treat it as an implicit ACK.
- Partial EIOS reception: If not all lanes receive EIOS during a L0p downsize, this is treated as a framing error, which requires retraining the link.
- Failed upsizing: For L0p upsize, If the TS1/TS2 handshake fails or lane to lane deskew is not achieved before SDS is detected on the newly activated lanes, the link must be retrained.
Verification Strategies and Randomization
To ensure robust coverage, verification environments should include:
- Randomization of the initial link width
- Lane skew up to 80 symbols at 128.0 GT/s
- Lane reversal
- L0p at all encoding types (8b/10b, 128/130b, 1b/1b)
- SRIS/SRNS clocking schemes
- For 1b1b encoding, bit errors in ordered sets (TS1/TS2, EIOS, EIEOS, SKP, SDS) to test the redundancy built into these Ordered sets.
These randomized conditions help uncover subtle bugs and ensure the design is resilient under real-world conditions.
Synopsys Solution for L0p Verification Challenges
- Synopsys provides a comprehensive suite of protocol checks, functional coverage models, and targeted test scenarios to validate L0p behavior across all supported link speeds, link widths and transitions.
- The Synopsys PCIe VIP enables users to simulate width change requests, control SKP and ordered set behavior, inject edge conditions such as lost ACKs or EIEOS mid-transition, and verify correct response to Recovery events.
- All the waveform screenshots shown in this blog are captured using Synopsys PCIe VIP during actual L0p verification, demonstrating real-world validation scenarios.
- This comprehensive support ensures that dynamic conditions such as overlapping L0p and L1 transitions or failed upsizing are fully exercised for PCIe 6.0 and above designs.
Synopsys PCIe VIP Key Features
- Easy integration: Uses System/Verilog UVM architecture to easily fit into simulation environments and speed up test bench development.
- Flexible and reliable: Offers many configuration options and built-in protocol checks to keep up with market trends and ensure reliability.
- Accelerated Verification: The solution includes a verification plan and test suites to speed up the verification process and stay ahead of the competition.
- Available on SoC Verification Kit (SVK): for interoperability and subsystem/SoC level verification using Synopsys IP
PCIe VIP Architecture Diagram
Conclusion
L0p is a powerful feature for achieving energy-efficient PCIe operation, but its dynamic behavior introduces significant verification challenges. By understanding the intricacies of link width changes and thoroughly exercising edge cases, engineers can ensure robust, compliant, and power-optimized designs.
Synopsys is partnering with early customers and collaborators to enhance the standard architecture for their next-generation designs, incorporating new features now available with the latest specifications.
Synopsys VIP is natively integrated with the Synopsys Verdi® Protocol Analyzer debug solution as well as Synopsys Verdi® Performance Analyzer.
Running system-level payload on SoCs requires a faster hardware-based pre-silicon solution. Synopsys transactors, memory models, hybrid and virtual solutions based on Synopsys IP enable various verification and validation use-cases on the industry’s fastest verification hardware, Synopsys ZeBu® emulation and Synopsys HAPS® prototyping systems.
More information on Synopsys PCIe VIPs and Test Suites is available at http://synopsys.com/vip
Continue Reading
Are You Stuck in PCIe Traffic? From Software to Hardware to System
