Verification

Demystifying NOP Debug Flits in PCIe Flit Mode

2026-10-12T22:35:00Z

Introduction

As PCIe bandwidth continues to double with every generation, complexity increases. The transition to flit mode, combined with advanced mechanisms such as replay buffers, flow control tracking, PAM4 signaling, and Forward Error Correction (FEC), has significantly improved link efficiency, but it has also made failure cause analysis far more challenging.

When performance drops unexpectedly, retry counts increase, or a switch experiences traffic congestion, debug becomes difficult, making users trace the root cause. Traditional techniques provide only a partial view of what is happening inside the link, making debug a time-consuming and often frustrating process.

To address this visibility gap, PCIe introduced the NOP.Debug flit, a standardized mechanism for transporting diagnostic information directly over the PCIe link. Instead of relying solely on external debug aids, devices can communicate valuable runtime information such as flow-control status, retry counters, buffer occupancy, trace capture triggers, and other diagnostic data through structured debug chunks embedded within a NOP.Debug flit.

Debug flits act as a built-in telemetry channel for PCIe links, rather than guessing why throughput is low or why replay activity is increasing; users can access real-time protocol state information directly from the communicating devices. The result is faster root-cause identification, improved performance analysis, and more efficient validation of complex PCIe systems.

NOP Debug Flit Layout and Details of Fields

A single debug flit can contain multiple chunks, and chunks from different vendors may coexist within the same flit. Unused space is filled using empty debug chunks.

Figure 1: NOP.Debug flit debug chunk

Figure 2: NOP.Debug flit debug chunk fields

Opcode	Debug chunk type	Purpose
0000000b	Empty debug chunk	Padding/alignment, contains no debug data
0000001b	Start capture trigger debug chunk	Trigger trace capture start
0000010b	Stop capture trigger debug chunk	Trigger trace capture stop
0000011b	FC information tracked by transmitter	TX flow-control debug
0000100b	FC information tracked by receiver	RX flow-control debug
0000101b	Flit mode transmitter retry flags and counters	TX retry status and counters
0000110b	Flit mode receiver retry flags and counters	RX retry status and counters
0000111b	Buffer occupancy debug chunk	Reports current buffer occupancy
0001000b	Link debug request debug chunk	Requests debug information from link partner

Table 1: PCI-SIG-defined debug chunk Opcodes

Advantages of Debug Flits

Instead of relying entirely on internal DUT signals, verification environments can now observe protocol state through architecturally defined mechanisms.

This improves:

Root-cause analysis
Debug productivity
Functional coverage
Silicon correlation
Interoperability testing

Debug Flits Verification

From a verification standpoint, debug flits introduce an entirely new feature set that must be validated.
The challenge is not simply verifying that a debug flit is transmitted, but one must ensure that the debug information contained within the flit accurately reflects the internal state of the DUT.
This shifts verification from validating protocol transactions to validating protocol introspection.

For this, some crucial negative scenarios must include:

1. Stress Testing with High-Volume Traffic and Credit Starvation

This scenario verifies how the DUT behaves when flow-control credits are exhausted under heavy traffic conditions. Debug flits carrying flow control information help determine whether throughput degradation is caused by credit starvation, incorrect credit accounting, or transmission throttling.

2. Flit Replays Caused by CRC/FEC Error Injection

Creating error injection scenarios by CRC or FEC corruption, such that replay mechanism is triggered and validate retry behavior. Additionally, debug flits provide visibility into retry counters and replay activity, helping confirm that replay handling and sequence-number management are functioning correctly.

3. Handling Corrupted Debug Flit Headers

A robust PCle implementation must safely detect and discard malformed debug flits without affecting normal traffic. Verification should ensure that corrupted opcodes, invalid lengths, or malformed headers are handled gracefully and do not cause protocol errors or unexpected behavior.

4. Buffer Occupancy Reporting

Buffer occupancy debug chunks provide insight into congestion within endpoints or switches. By creating traffic hotspots and buffer pressure scenarios, validation of the reported occupancy can be done to check whether it accurately reflects the actual buffer usage and helps identify performance bottlenecks quickly.

Conclusion

As PCIe systems continue to grow in bandwidth, scale, and complexity, the ability to understand what is happening inside the link becomes increasingly important. Debug flits represent a major step forward in PCIe observability. By providing standardized access to flow-control state, retry information, buffer occupancy, and trace-capture controls, they enable engineers to debug complex protocol issues with significantly greater efficiency.

In the flit era of PCIe, debug flits are not just another protocol feature. They are a powerful visibility framework that transforms debugging from guesswork into insight. Cadence PCIe VIP solutions are proven to verify the PCIe7 features and provide a seamless usage model to cater to the verification of these complex features.

More Information

For more info on how Cadence PCIe Verification IP and TripleCheck enable users to confidently verify these new disruptive changes, see our VIP for PCI Express, VIP for Compute Express Link, and TripleCheck for PCI Express.
For more information on PCIe in general, and on the various PCI standards, see the PCI-SIG website. 
If you have feedback or need more information, reach out to us at talk_to_vip_expert@cadence.com.

Why Protocol Compliance Is Not Enough: Performance Verification with ATP

2026-10-12T22:00:00Z

Constrained-random stimulus proves that an interconnect is functionally correct. It cannot prove that the interconnect will sustain the bandwidth of real traffic demands. Adaptive Traffic Profiles were defined to answer that second question, and Cadence Verification IP implements the model in full.

A fully passing Advanced eXtensible Interface (AXI) test suite and a system that misses its performance targets in the lab are not a contradiction. The conventional stimulus is written to exercise protocol corners, so it issues bursts as fast as the subordinate will accept. Real traffic sources behave nothing like that. A camera pipeline or a display controller produces a steady, rate-limited stream of bytes and stalls when its buffer runs out of space. A stimulus that ignores that behavior measures peak throughput on an idle fabric, which is rarely the number that decides whether a design ships.

What Adaptive Traffic Profiles Describe

Adaptive Traffic Profiles, defined by Arm as part of the AMBA specification family, take a different approach from a conventional sequence. Rather than describing individual transactions, a profile describes a traffic source or sink that sits behind a first-in, first-out (FIFO) buffer. Three parameters carry most of the meaning: the rate in bytes per clock cycle at which the buffer drains or fills, the buffer depth, and whether the buffer starts empty or full.

Traffic then generates itself from that description. A read profile models a consumer: the buffer drains at the specified rate, and a transaction is issued only when enough space exists to hold the data that will be returned. A write profile models a producer: the buffer fills at the specified rate, and a transaction is issued only once enough data has accumulated to send.

The rate always applies to the traffic side of the buffer; the bus drives the other side. That asymmetry is the whole model.

The word adaptive is the important one. Because the buffer level responds to the latency the design under test actually returns, a profile throttles itself when the fabric gets congested and catches up when the fabric clears. Traffic shapes itself around the design rather than being replayed blindly at it.

Two loops run concurrently. The buffer fills and drains every cycle, while the issue loop consults the level before sending anything, which is where self-throttling comes from.

That property is also what makes a profile portable. Because it expresses a requirement rather than a fixed transaction list, the same description of a video pipeline holds its meaning in a block-level simulation, a full system run, an emulation platform, and a fabric that has since been reconfigured.

What the Model Demands of an Implementation

Expressing traffic this way is straightforward on paper and demanding in practice. A faithful implementation has to track buffer occupancy against in-flight data every cycle, convert a bandwidth figure into issue decisions, generate the address and identifier patterns the specification defines, honor outstanding-transaction limits, reproduce channel-level handshake timing, and do all of it without ever emitting a transaction that breaks protocol rules.

How Cadence Verification IP Delivers the Model

The Cadence Adaptive Traffic Profiles solution is built on the AMBA Verification IP, so profiles run inside a standard Universal Verification Methodology (UVM) environment and compose with existing stimulus rather than replacing it.

Coverage across the AMBA family

Profiles drive AXI, the Advanced High-performance Bus (AHB), AXI Coherency Extensions (ACE) with control over the non-shareable, inner, outer, and system coherency domains, and the Coherent Hub Interface (CHI). Protocol-independent behavior is shared, so a profile written for one protocol carries the same meaning on another. Both Manager-side and Subordinate-side traffic can be modeled.

The full pattern vocabulary

Addresses follow sequential, random, static, wrapping, or two-dimensional patterns, the last describing image-style access through an X range, a Y range, and a stride. Identifiers can be random, fixed, cycling, unique, or drawn from a supplied list, and generated addresses can be constrained to an alignment boundary.

Timing fidelity beyond the rate

Bandwidth is specified as a real number rather than a coarse approximation, outstanding transactions are capped independently, profile start can be offset, and the delay between consecutive transactions can be fixed or normally distributed around a mean. The specification's channel-level handshake delay parameters are supported under their standard names, so a timing requirement transfers directly from an architecture document into the testbench.

Protocol legality guaranteed

Bursts generated from a bandwidth figure are automatically split at the AXI 4KB boundary and the AHB 1KB boundary, and unaligned transfers are handled. A performance requirement cannot accidentally become a protocol violation.

Measurement built in

Every profile tracks the minimum and maximum levels its buffer reached, reports them per burst and per profile, and raises a warning whenever the buffer touches empty or full. The performance result is an output of the run, not something that has to be reconstructed afterward from a waveform.

Repeatable, trace-driven traffic

Addresses, identifiers, and data content can be supplied from plain text files in decimal or hexadecimal, so an address trace captured from software or a previous run can be replayed exactly. Files are shared across profiles and cycle automatically when shorter than the profile requires.
Because profiles are ordinary UVM sequences, many can run concurrently and compete for the same fabric. That is where results get interesting: a profile that comfortably meets its rate in isolation and starves once its neighbors become active is precisely the finding worth having before tapeout.

Seeing the Result

A read profile requesting three bytes per cycle. The buffer holds near 900 bytes while read latency is 30 cycles, drains once latency rises to 420, and then starves for 351 cycles, continuing for 252 cycles after the congestion itself has cleared. A buffer that reaches empty once the profile is running is the failure signature.

The reported buffer levels answer the original question. A read profile whose minimum level stays well clear of zero was served comfortably throughout. One that reaches empty indicates a design that could not meet its own requirement, and the margin between that minimum and the buffer depth quantifies the headroom left for the next derivative. A bandwidth number stops being a spreadsheet entry and becomes a simulation result with a pass or fail attached.

Learn More

Performance questions are easier to answer early, while the fabric can still change. Full details of Adaptive Traffic Profiles support, including the complete parameter set and supported protocols, are available through the Cadence AMBA Verification IP documentation.

UPLI Credit Flow: Why It Matters for UALink and What It Takes to Verify It Right

2026-10-09T00:00:00Z

The Problem Nobody Talks About Picture a world where 1,024 AI accelerator chips work shoulder-to-shoulder inside a single compute node - each one craving data as fast as it can process it, each one firing requests at its neighbours dozens of times ev...(read more)

UCIe 3.0: Faster Links Are Only Half the Story

2026-10-08T08:52:00Z

The chiplet ecosystem continues to push performance boundaries, and the latest UCIe 3.0 specification takes a significant step forward with the introduction of 48 GT/s and 64 GT/s data rates, alongside enhancements to support continuous transmission protocols and improved framing error detection and correction capabilities. Together, these features represent much more than a simple speed upgrade. They fundamentally expand the scope of workloads that can efficiently leverage UCIe-based connectivity.

More Than Just Higher Bandwidth

The move from previous generations to 48 GT/s and 64 GT/s significantly increases die-to-die bandwidth, enabling chiplet-based systems to transfer data at unprecedented rates. For AI training clusters, inference accelerators, memory-centric architectures, and large-scale compute fabrics, this additional throughput helps address one of today's biggest bottlenecks: data movement.

However, higher bandwidth brings new challenges. As bandwidth scales, the tolerance for implementation issues shrinks. Small protocol violations, corner case timing interactions, or recovery sequence bugs that might have gone unnoticed at lower speeds can manifest as level failures in complex chiplet deployments.

Enabling Continuous Transmission Workloads

One of the most significant enhancements in UCIe 3.0 is its support for protocols that require continuous transmission. A notable example is JESD204E, which introduces a UCIe optimized link layer for transporting high speed converter data across chiplet-based systems. By providing the high bandwidth, low latency foundation needed for sustained data streams, UCIe 3.0 extends its reach beyond traditional compute connectivity and into specialized data-intensive applications.

Historically, many interconnect protocols have relied on burst-oriented or packet-based communication models, where transmission gaps occur naturally. Emerging workloads are increasingly different. AI data pipelines, streaming accelerators, memory fabrics, and converter-centric systems often require a continuous, deterministic flow of information across chiplets.

Supporting these workloads demands more than higher bandwidth alone. The interconnect must sustain uninterrupted data transfer while maintaining framing integrity, link reliability, and protocol correctness across a wide range of operating conditions.

Reliability Becomes a First-Class Requirement

At higher speeds and under continuous traffic conditions, framing accuracy becomes increasingly critical. To strengthen link robustness, UCIe 3.0 introduces enhanced mechanisms for valid framing error detection and correction. These capabilities help identify framing-related issues before they propagate across the system, improving overall reliability and resiliency.

The Verification Challenge

While these features unlock new possibilities, they also introduce a new generation of verification challenges. Verification teams must validate not only the happy path, but also countless corner cases:

Can the design reliably sustain 48 GT/s and 64 GT/s operation?
Does continuous transmission behave correctly during congestion and flow control events?
Are framing errors detected precisely when they occur?
Are the correction and recovery mechanisms executed according to the specification?
How does the system behave when multiple protocol features interact simultaneously?
Can interoperability be maintained across different implementations?

The difficulty lies not in testing a few isolated scenarios, but in exercising the enormous state space created by high speed operation, continuous traffic patterns, link recovery flows, and error injection scenarios.

Why Advanced VIP Matters

This is where a comprehensive verification solution becomes critical. Cadence UCIe VIP provides a protocol-aware verification environment that enables engineers to validate both mainstream and advanced UCIe 3.0 features efficiently.

For higher speed operation, the Cadence UCIe VIP helps verify link training, speed negotiation, protocol compliance, and data integrity across supported data rates. For continuous transmission use cases, the VIP can generate realistic traffic patterns, exercise streaming scenarios, and validate system behavior under stress conditions.

Equally important, the Cadence UCIe VIP provides extensive error injection and protocol checking capabilities, enabling teams to verify framing error detection, correction, recovery behavior, and overall protocol robustness before silicon.

By combining automated protocol compliance checking, comprehensive coverage collection, configurable traffic generation, and interoperability-focused verification, engineers can focus on uncovering corner case issues rather than building complex verification infrastructure from scratch.

Looking Ahead

What makes UCIe 3.0 exciting is not simply the introduction of 48 GT/s and 64 GT/s operation. It is the combination of higher bandwidth, continuous transmission enablement, and enhanced reliability mechanisms that broadens the range of protocols and workloads that can leverage the UCIe ecosystem.

But as performance and protocol complexity increase, verification becomes a key enabler of successful deployment. Advanced verification solutions such as Cadence UCIe VIP play a crucial role in helping engineering teams confidently adopt these new capabilities while maintaining interoperability, compliance, and reliability.

Because in the world of chiplets, faster links are only half the story. Confident verification is the other half.

Learn more about Cadence UCIe Verification IP on the Simulation VIP for UCIE | Cadence or simply reach out to our Cadence Verification IP experts at talk_to_vip_expert@cadence.com.

VLAB in Practice: Real Binary, Virtual Board, Real Web Browser

2026-10-04T10:31:00Z

The question posed was simple: how can we show that a virtual platform is actually real? That it runs real software, just like the real hardware board? The answer is quite simple too: build an existing software example for a development board without any changes, load the generated image onto a virtual platform, and run it. Use an application that makes it easy to see what is going on. The selected application was a web server running on an Infineon AURIX^TM MCU.

Real Software Stack?

Reusing the hardware image on the virtual platform keeps the entire development environment—including the compiler, bootloader, drivers, middleware, and application behavior—aligned across both virtual and real environments. This is one of the key advantages of what is commonly known in the automotive industry as “Level 4” or “L4” virtual platforms: run the real binary. It sets L4 apart from “Level 3” and below, where the software is compiled for the host and the software stack is modified to fake parts of the operating system. It allows software development, testing, and integration to begin before hardware is available and continue throughout the development lifecycle, without requiring a separate build process.

Virtual Board and Real Web Browser?

Real software also implies virtually real IO – the software on the virtual platform talks to the outside world through the same hardware drivers and hardware interfaces as the real board. For Ethernet, this results in network packets being sent through a virtual network device to either a virtual network or a connection to the real-world network. In this case, the real-world network is used, allowing a standard web browser to be run on the same host as the virtual platform (or a different host, the virtual platform is on the lab network effectively). The web browser connects to the web server running on the virtual platform, just like it would connect to a real development board.

Building the Software Example “As Is”

We selected Infineon’s iLLD_TC3XX_ADS_GETH_LWIP_HTTP example from the open-source AURIX code examples repository on GitHub. The project was imported into AURIX Development Studio and built as is, using the workflow intended for the hardware target. The resulting ELF image was then loaded into the VLAB AURIX TC37x VDM (Virtual Development Machine) using a VLAB Python script. The script prepares and starts the virtual target, loads the software image, and enables basic interfaces for logging, observing LED activity on a GPIO port, and accessing a UART terminal.

Debugging the First Blocker

After loading the image onto the VDM, the software started without any problems. However, the HTTP server application did not reach its expected operational state. The UART consoles printed out some initial debug messages, but it did not get to reach the code where it finishes the initialization and prints its IP address.

This is where the virtual development workflow became especially useful. By pausing the application at its entry point and attaching GDB from Visual Studio Code, we were able to debug the target software step by step on the virtual platform, just like you could do with a hardware debugger on real hardware. We could inspect the execution and identify where initialization had stopped progressing. The analysis showed that the software example expected an external Ethernet PHY on the physical hardware, whereas the selected VDM contained the AURIX GETH MAC module but did not include the specific board-level PHY expected by the example.

Bridging the Model Gap

There are three ways to handle such a missing component on a virtual platform. You can modify the software, add a full model of the PHY, or stub the PHY sufficiently to let the software work.

Instead of modifying the software source code or the hardware board, we used the VLAB Python API to provide the missing environmental behavior. Software stubs returned the expected results from the Ethernet PHY initialization and link-status functions. An execution-listener callback also updated the GETH PHY interface status register when execution reached the receiver-start routine. This approach kept the target image unchanged while making the board-level assumption explicit in the simulation harness. Because the demo also expects input from the on-chip Die Temperature Sensor (DTS), we used the VLAB Python API to simulate its register value, allowing the original HTTP application to report dynamic temperature information.

This kind of stubbing lets software get going quickly, while the board model is extended with the missing hardware models.

Connecting the Virtual Ethernet Network

With the target software now fully running, the next step was to connect its virtual Ethernet port to the host environment. This can be also easily done by using the VLAB Python API to create a network bridge between the virtual target and the host machine.

Voilà: Accessing the Virtual HTTP Server in a Standard Web Browser

The final result was simple yet satisfying: we opened a web browser on the host machine and connected directly to the HTTP server application running on the virtual target. The page served by the AURIX example code displayed the simulated temperature data and provided controls for exercising the LED port. In the Visual Studio Code output, the resulting LED activity could be observed through logic-port logging.

This result also demonstrates the strong runtime performance of the VLAB virtual target. The web browser regularly requests updated data from the embedded HTTP server—potentially every 100 ms—while the virtual target continues to run the application and respond smoothly. Handling these frequent HTTP requests without noticeable delay shows that the virtual platform provides the performance needed for an interactive web-based application.

From L4 Simulation to a Complete Virtual ECU

The most valuable outcome was not only that the demo worked, but also what it revealed about the flexibility of L4 simulation. The same production software image could be loaded, debugged, observed, and connected to standard host tools while the simulation environment supplied focused models for behavior that was not yet available. This enables developers to begin application development and testing early and continue throughout the development lifecycle on a scalable virtual platform.

Although a virtual MCU model combined with targeted Python-based extensions was sufficient to create a realistic end-to-end workflow for this simple example, a production program requires a broader scope. The complete board or ECU environment—including the relevant processors, peripherals, networks, sensors, actuators, and external devices—must be represented with the fidelity required by each development and validation task. The ability to start with a focused use case and scale toward a complete virtual board or virtual ECU is a key strength of VLAB. It enables teams to preserve the production software image, make hardware dependencies visible, and apply the same L4 simulation approach from early shift-left development through continuous integration and later stretch-right validation.

Learn more about what Cadence has to offer for automotive and embedded software and hardware developers at Cadence Automotive Solutions and VLABworks.com!

New Course Release: Python API and App Store Development with Verisium Debug

2026-10-01T10:07:00Z

Automate debug workflows. Build reusable apps. Extend Verisium Debug with Python.

Course focus:
Python automation, Verisium Debug APIs, GUI customization, batch-mode workflows, and App Store deployment.

Best suited for:
Verification engineers, debug specialists, automation developers, and teams building reusable productivity tools.

Outcome:

Move from manual debug tasks to scalable, reusable, Python-driven debug automation.

The world of digital design verification is evolving rapidly, and automation is becoming a critical skill for engineers seeking to debug faster, improve productivity, and build scalable workflows. To help engineers unlock the full potential of Verisium Debug, we are excited to announce the release of our new online course:

Python API and App Store Development with Verisium Debug

This comprehensive course is designed to help verification engineers, debug specialists, and automation enthusiasts learn how to leverage the Verisium Debug Python API to automate tasks, analyze design data, customize workflows, and build deployable applications using the Verisium Debug App Store framework.

You can find the course here, or search for this course at ask.cadence.com

Why This Course Matters

As design complexity continues to increase, engineers face growing challenges in debugging large datasets, identifying root causes, and managing repetitive analysis tasks. Manual debug processes can consume valuable engineering time and often limit productivity.

The Verisium Debug Python API provides a powerful solution by enabling users to:

Programmatic access: Access design, waveform, and debug databases directly from Python.
Workflow automation: Automate repetitive debug and analysis tasks that consume engineering time.
Advanced analysis: Perform design, signal, transaction, and driver-tracing investigations with scripts.
Custom experiences: Create GUI components and utilities tailored to real debug use cases.
Flow integration: Connect debug automation with larger verification and regression flows.
Reusable deployment: Build applications that can be packaged and shared through the Verisium Debug App Store framework.

By learning these capabilities, engineers can move beyond traditional debugging and begin creating intelligent, reusable automation solutions that improve efficiency across projects.

What You’ll Learn

The course takes a practical, hands-on approach and covers the complete workflow from Python API fundamentals to enterprise-ready application development.

1. Python API Foundations

Learn the architecture of the Verisium Debug Python API, understand GUI and batch-mode execution models, and configure your Python development environment for productive automation development.

2. Design and Value Analysis

Discover how to traverse design hierarchies, access signals, perform driver tracing, extract design information, and automate common debug investigations.

3. Database Handling

Understand how to create, load, and interact with Verisium Debug databases programmatically using Python.

4. GUI Automation and Customization

Learn how to interact with Verisium Debug GUI components, create custom widgets, and build enhanced user experiences inside the debugger environment.

5. Batch Mode Automation

Explore how to execute analysis and automation tasks in batch mode to enable integration with regression and verification flows.

6. App Store Development

Learn how to package, deploy, manage, and distribute Python-based applications through the Verisium Debug App Store, transforming standalone scripts into maintainable and reusable tools.

Learning path	Practical takeaway
API fundamentals	Understand how Python connects with Verisium Debug and how scripts run in GUI or batch mode.
Design exploration	Traverse hierarchy, inspect signals, trace drivers, and extract design information programmatically.
Automation workflows	Convert repetitive debug steps into repeatable scripts that reduce manual effort.
App Store packaging	Turn scripts into reusable applications that can be deployed and maintained across teams.

Key Benefits of Taking This Course

After completing this training, you'll be able to:

Automate repetitive debug tasks and save valuable engineering time
Build reusable Python-based verification and debug utilities
Programmatically access and analyze Verisium Debug data
Customize the debugging environment to match your workflow
Develop scalable solutions that extend beyond standalone scripts
Package and deploy applications through the Verisium Debug App Store
Improve debug efficiency and accelerate issue resolution
Enhance your Python-based automation skills for modern verification flows

Whether you're looking to increase personal productivity or develop shared tools for your organization, this course provides practical skills that can be immediately applied to real-world verification challenges.

Earn Recognition Through the Badge Exam

Learning doesn't stop when the course videos end.

To help learners assess and validate their understanding, the course includes a Badge Exam that measures knowledge gained throughout the training. The exam covers all major course topics, including Python API fundamentals, design analysis, database handling, GUI APIs, batch-mode automation, and App Store development.

The badge exam enables learners to:

Evaluate their understanding of the course material
Verify mastery of key concepts and workflows
Identify areas that may require additional study
Demonstrate proficiency in Verisium Debug Python API development
Showcase their expertise to peers and managers

Successfully completing the badge exam provides learners with confidence that they can apply the concepts and techniques learned throughout the course in real-world projects.

Start Building the Future of Debug Automation

The future of verification is driven by automation, customization, and intelligent tooling. The Python API and App Store Development with Verisium Debug course equips engineers with the practical skills needed to build powerful automation solutions, streamline debugging workflows, and create deployable applications that extend the capabilities of Verisium Debug.

Whether you are just beginning your automation journey or looking to expand your existing Python expertise, this course provides the knowledge, hands-on experience, and validation opportunities needed to take your Verisium Debug skills to the next level.

Enroll today to master the Verisium Debug Python API, build your own applications, and prove your expertise through the course badge exam.

AMBA CXS Interleaving: Shared Transport for Multi-Protocol, Multi-Node Systems

2026-09-30T13:30:00Z

Modern SoCs bring together CPUs, GPUs, AI accelerators, coherent memory devices, PCIe controllers, and chiplet interfaces, all generating packet traffic with different latency, ordering, and delivery requirements. When these flows converge on a shared transport, a basic first-in, first-out packet path can create avoidable blocking and leave expensive link bandwidth underused.

AMBA CXS addresses this challenge with a credited, packetized streaming interface optimized for wide datapaths. Along with packing multiple packets into a flit, CXS can distinguish independent streams and define where traffic from another stream may be inserted. Earlier CXS revisions enabled protocol-aware sharing through CXSPRCLTYPE and controlled insertion through CXSLAST. Issue D extends stream identity with CXSSRCID and CXSTGTID, allowing the same link concepts to scale into multi-node networks.

The architectural value is straightforward: independent traffic can share a high-bandwidth link while preserving the ordering and contiguity guarantees required by each stream. Verification is more complex because the design must identify stream boundaries, preserve in-stream order, prevent illegal insertion, maintain protocol and node identity across flits, and honor credit and continuous-delivery constraints under stress.

Overview of CXS Interleaving

Consider a shared link carrying a long packet sequence while a short, latency-sensitive packet from another independent stream is ready. If the second stream must wait for the first sequence to drain, the system experiences head-of-line blocking. The effect becomes more visible as packet sizes vary, traffic sources multiply, and endpoints operate at different service rates.

Interleaving allows upstream arbitration to select traffic from another stream at a legal insertion point. This can improve responsiveness and keep the link active without violating the ordering of the original stream. CXS, therefore, does not treat interleaving as arbitrary flit switching. It identifies the stream and constrains insertion using protocol type, source ID, target ID, CXSLAST, and the CXSCONTINUOUSDATA property.

Why CXS Needs Stream-Aware Interleaving

Unrestricted switching can violate packet continuity or ordering, while overly conservative arbitration can preserve correctness but unnecessarily reduce link efficiency. CXS resolves this tension by distinguishing independent traffic streams and identifying the boundaries at which another stream can be inserted safely. The result is controlled sharing: the link can carry independent flows without losing the context needed for packet reconstruction, ordering, route attribution, or continuous delivery.

CXS Interleaving Protocol Architecture

Protocol-Aware Stream Identification with CXSPRCLTYPE

CXS issue B added support for multiple protocol streams. When CXS_PROTOCOL_TYPE is True, the optional 3-bit CXSPRCLTYPE signal identifies the protocol type carried by a valid flit. The specification defines encodings for protocol type 0 and protocol type 1; other values are reserved.

A packet spanning multiple flits must use the same protocol type on every flit.
If one flit contains multiple packets, all packets in that flit must have the same protocol type.
When CXSCONTINUOUSDATA is false, flits with different protocol types can be interleaved on any cycle.
When CXSCONTINUOUSDATA is true, the protocol type can change only after CXSLAST is asserted.

These rules allow a receiver to route, decode, or account for traffic without parsing protocol-specific packet contents simply to determine the protocol stream. They also provide a directly observable basis for checking that a multi-flit packet never changes protocol identity during delivery.

Legal Insertion Boundaries with CXSLAST

CXSLAST is an optional flit-level indication that flits from another source or stream can be inserted after the current cycle. It is best understood as an insertion-permission boundary, not simply an end-of-packet indication, because CXS can require multiple complete packets to remain contiguous as a group.

CXSLAST must be de-asserted when the following packet must remain after the current packet, or when a packet has started but has not ended in the current flit. When CXSLAST is low, the receiver expects additional traffic for the protected sequence ,and another source must not be inserted. When the signal is not implemented, it is generally assumed asserted, except while a packet is incomplete in the current flit.

The waveform illustrates how protocol streams share the CXS link while CXSLAST marks where a stream transition is permitted. A transition must not interrupt an incomplete packet or a packet group that is required to remain contiguous.

Continuous Delivery with CXSCONTINUOUSDATA

With continuous delivery disabled, a design can switch among streams more freely while still preserving packet continuation and same-stream ordering. With continuous delivery enabled, a stream change must wait until CXSLAST is asserted. The transmitter must also avoid starting a packet unless the complete packet can be delivered in consecutive cycles while credits are available.

Multi-Node Stream Identity in CXS Issue D

Protocol type can distinguish different protocols, but it cannot distinguish two nodes carrying the same protocol. CXS issue D therefore adds optional source and target identifiers for multi-node networks. CXSSRCID identifies the node from which a flit originated, while CXSTGTID identifies the destination node. Each identifier can be configured from 0 to 8 bits, and both are valid when CXSVALID is asserted.

CXS stream identity = {CXSPRCLTYPE, CXSSRCID, CXSTGTID}

Flits from the same stream must remain in order. Flits from different streams can be inserted, subject to CXSCONTINUOUSDATA and CXSLAST. Because source and target identifiers apply to every packet in a flit, one flit cannot mix packets belonging to different source-target routes. This richer identity allows a shared transport to distinguish flows without dedicating a separate link to every node pair.

Key Protocol Features

Protocol-aware identification through CXSPRCLTYPE
Multi-node source and destination identification through CXSSRCID and CXSTGTID
Controlled insertion boundaries through CXSLAST
Compatibility with continuous-delivery constraints through CXSCONTINUOUSDATA
Preserved ordering within each configured stream identity
Efficient sharing of a wide link across independent traffic flows

Practical Use Cases for CXS Interleaving

Multi-Protocol Controller Connectivity

Independent protocol flows can share a wide CXS transport while retaining explicit protocol identity. This is useful for packetized communication between an on-chip interconnect and protocol controllers such as CHI, PCIe, CCIX, or CXL controllers.

Multi-Node and Modular Subsystem Fabrics

Source and target identifiers allow flows using the same protocol to remain distinguishable when multiple initiators and endpoints share the transport. This supports modular subsystem and multi-node designs without requiring a dedicated physical link for each route.

Mixed-Latency and Variable-Length Traffic

Legal insertion points allow a ready independent stream to use link capacity without waiting for an unrelated long sequence to drain. This can reduce avoidable head-of-line blocking while retaining stream-specific ordering and contiguity requirements.

These are architectural advantages rather than an automatic guarantee of performance. Realized latency and throughput also depend on buffering, credit round-trip latency, arbitration policy, packet-size distribution, and downstream service behavior.

Functional Verification Challenges

Interleaving introduces state that extends beyond a single packet. Many defects are therefore temporal and cross-flit rather than simple signal-value errors.

Stream Identity Integrity

Verification must detect changes to CXSPRCLTYPE, CXSSRCID, or CXSTGTID within a multi-flit packet and reject flits that incorrectly combine packets with different protocol or route identities.

Insertion-Boundary Correctness

The environment must detect another stream inserted after CXSLAST was Low when continuous delivery is required, as well as premature assertion of CXSLAST while a packet or protected packet group remains incomplete.

Ordering and Packet Reconstruction

Flits within the same stream must remain ordered, and packet continuation must be tracked independently for every enabled stream. An incorrect model can either miss same-stream reordering or falsely impose ordering across independent streams.

Credit and Delivery Continuity

Verification must stress packet starts near credit-pressure boundaries and ensure uninterrupted delivery where continuous mode requires it. It should also identify over-constrained arbitration that blocks legal stream insertion and reduces achievable efficiency.

Verification Strategy

Protocol and Flit-Level Checking

Sample CXSPRCLTYPE, CXSSRCID, and CXSTGTID with CXSDATA and CXSCNTL whenever CXSVALID is high. Check identity stability across multi-flit packets, common identity for every packet packed into one flit, and the independent correctness of START, END, pointer, and ENDERROR fields.

Stream-Aware Scoreboarding

Key scoreboard state by the complete enabled stream identity: protocol type for earlier configurations, or protocol type with source and target identifiers for issue D. Track packet continuation, expected bytes, protected packet-group state, ordering, and insertion permission independently for each stream.

Credit and Continuity Stress

Randomize credit depth and credit-grant latency, start long packets near constrained-credit conditions, and verify consecutive delivery where continuous mode requires it. Include simultaneous credit grant and use, as well as legal transitions between independent streams.

Coverage and Negative Testing

Cross protocol type, source ID, target ID, previous and next stream, CXSCONTINUOUSDATA, CXSLAST, packet length, flit count, packets per flit, insertion outcome, and credit conditions. Add directed violations such as mid-packet identity changes, illegal insertion, premature CXSLAST, same-stream reordering, mixed identities within a flit, reserved protocol values, and identifier-width mismatches.

Cadence CXS VIP Solution

Cadence CXS Verification IP provides protocol-compliant stimulus, monitoring, checking, coverage, and debug capabilities for interleaving across multi-protocol and multi-node configurations. It enables verification environments to generate concurrent streams, validate complete stream identities, reconstruct packets independently for each stream, and check insertion, ordering, credit, and continuous-delivery behavior.

Concurrent generation of multi-protocol and multi-node streams

Checks for CXSPRCLTYPE, CXSSRCID, CXSTGTID, and CXSLAST rule compliance

Stream-aware packet reconstruction and ordering validation

Credit-pressure and continuous-delivery stress scenarios

Functional coverage across stream identities and insertion boundaries

Debug visibility into stream transitions, insertion points, and continuity violations

By mapping stream-aware stimulus, checking, coverage, and debug directly to CXS interleaving risks, Cadence CXS VIP helps teams validate both protocol compliance and end-to-end stream correctness across shared CXS fabrics.

Conclusion

AMBA CXS evolves a wide, credited link into a scalable shared transport for multi-protocol and multi-node traffic. Through CXSPRCLTYPE, CXSLAST, CXSCONTINUOUSDATA, CXSSRCID, and CXSTGTID, CXS enables controlled interleaving while preserving stream ordering, route identity, packet reconstruction, and required contiguity.

Because correctness depends on interactions across packets, flits, node routes, credits, and insertion boundaries, verification must be stateful and stream-aware. Cadence CXS VIP provides the stimulus, checking, coverage, and debug capabilities needed to verify these interactions as designs scale from point-to-point protocol links to multi-node fabrics.

For more information on Cadence CXS Verification IP, visit the Cadence Simulation Verification IP Page.

For additional clarification or technical assistance: talk_to_vip_expert@cadence.com.

Why LLMs Are the Best Thing to Happen to Chip Design

2026-09-29T16:00:00Z

By Kartik Hegde, Sr. Engineering Group Director

We live in a world increasingly shaped by artificial intelligence (AI). At the heart of this revolution lies a piece of technology that most people never see: the chip.

Fueled by Moore's Law, compute-per-dollar and compute-per-watt have improved by more than a million times over the past few decades. These massive gains have enabled us to train large AI models on vast datasets, unlocking capabilities we once only imagined, including the large language models (LLMs) that power today's most advanced AI applications.

There is growing evidence that scaling laws are continuing to hold true for AI models. Increasing the compute used for training by an order of magnitude can result in a generational leap in model performance, as depicted by the graph above. As such, in the pursuit of artificial general intelligence (AGI), nearly every major tech company is now racing to build massive compute infrastructure to train these next-generation models.

If chips are so fundamental to achieving AGI, why isn't every large AI company building its own? The answer: They are. In fact, there are more companies building custom silicon today than ever before!

Custom Silicon: Two-Year Minimum, 100+ Engineers

While there is a massive interest in building custom silicon for applications like AI, designing and taping out a chip continues to be a Herculean task. It demands immense engineering effort—estimated at over 1,000 engineering months for an ASIC of typical complexity. Additionally, companies must identify and hire rare talent with expertise across various phases of chip design and have a leadership team willing to invest capital while bearing significant risk.

So, what makes chip design today so complex? Let's find out.

Historical Perspective: Shifting Bottlenecks

Key Insight: Pioneering work in EDA in synthesis, place and route, and HDLs over the last few decades has shifted the bottleneck to chip verification.

To understand the complexity of chip design today, let's first outline the key steps in designing a chip. We'll then travel back in time to examine the historical perspective of how bottlenecks in the chip design process have shifted.

Key Stages of Chip Design

Specification and architecture: Capture functional goals, PPA targets, and draft a high-level micro-architecture that meets the product requirements.
Design and RTL development: Implement the architecture in an HDL (e.g., Verilog), writing clean, synthesizable RTL with clear timing and power intent.
Functional verification: Use simulation, formal, and emulation to exhaustively prove the RTL behaves as intended before silicon dollars are at stake.
Logic design and synthesis: Translate RTL into a gate-level netlist with constraints, optimizing for area, power, and timing while meeting foundry libraries.
Physical design: Floorplan, place, clock-tree, and route the netlist; run STA, DRC/LVS, and power-integrity checks to produce tape-out-ready GDSII.
Packaging and test: Define I/O ring and package, insert scan/BIST for manufacturability, and prepare ATE vectors for wafer sort, assembly, and final silicon validation.

If you are wondering which stage takes more effort and engineering hours, the answer depends on when in history you're asking.

The 1980-2000s: Optimizing Logic Synthesis and Place and Route

Back in the 1980s, when chips had only a few thousand transistors, the design process looked very different from how it does today. Engineers designed circuits and placed transistors by hand. As the number of transistors grew, this approach quickly became unscalable. The emergence of electronic design automation (EDA) transformed the industry, diminishing manual effort and enabling designers to build much larger and more complex chips.

Additionally, the emergence of hardware description languages (HDL) like Verilog in 1986 abstracted away low-level circuit details (much like C and C++ did for assembly programming), allowing engineers to focus on architecture and logic. A combination of HDLs and EDA significantly boosted designer productivity, enabling the production of the massive chips we see today.

In parallel, Moore's Law continued to fuel the semiconductor industry, doubling the number of transistors every two years at the same cost. The availability of these transistors led to scaling the number of cores on a chip and increased the complexity of the architecture.

To summarize:

EDA tools emerged to address difficulties in place and route (P&R) and logic synthesis.
HDLs made it easier to design logic and resulted in a major productivity boost.
Availability of more transistors enabled chip designers to build more complex, higher-performance chips.

The net effect of these factors is clear from the figure above: In the last three decades, innovations in chip design methodologies and Moore's Law have delivered us massive, multi-billion-transistor chips. Evolving maturity of EDA tools for synthesis and P&R continued to support the growth of chips in size and complexity. As such, the key bottlenecks in chip design shifted to the earlier stages of the flow: functional verification, logic design, and architectural innovation.

2000s and Beyond: Increasing Complexity of Functional Verification

As chips grew larger and more complex, ensuring the functional correctness of the RTL became more cumbersome. Today, functional verification accounts for most of the effort in chip development, often as much as 60–70%. These are complex, human-driven processes involving deep architectural reasoning, edge-case testing, and a careful understanding of constraints.

Verification has expanded into a multi-layered, multi-method process that spans both the pre-silicon and post-silicon stages. Below are some examples of how verification approaches might vary:

Design Hierarchy

Block-level verification (unit testing)
Subsystem-level verification
Chip/system-level verification

Methodology

Simulation
Formal verification
Emulation
Gate-level simulation

Abstraction Level

Spec-level (e.g., natural language or executable spec)
RTL-level
Netlist-level
Post-layout (SPICE-level)

Verification Intent

Functional verification (does it do what it's supposed to?)
Structural verification (e.g. connectivity, lint, DRC, CDC, RDC)
Power-aware verification (UPF/CPF checks)
Security verification (e.g. side channels, isolation)
Timing verification (e.g. static timing analysis)

Environment

Pre-silicon (simulation/emulation)
Post-silicon (bring-up, system validation, in-field testing)

Each stage plays a critical role in ensuring correctness as complexity scales. The combinatorial explosion here is real: a chip with n transistors can theoretically exist in 2ⁿ possible states. For a chip with 1 billion transistors (10⁹), the number of possible binary states is 10^{3.0 x 10^{8}} , which is incomprehensibly larger than any physical quantity we can observe! While most of these states are irrelevant or unreachable in practice, this exponential growth gives a sense of the overwhelming complexity of verifying modern chips.

It's Getting Harder—And More Costly—To Build Chips

The challenges continue. It is taking more time and effort to build next-generation chips than before. There are three key drivers:

Moore's Law continues to add more transistors, meaning ever-larger chips
Specialization continues to increase, and algorithms grow more complex
Complexity grows, yet at smaller nodes and with more stringent power budgets

All of these are directly leading to increasing functional verification efforts. Failing to solve the verification bottleneck is not an option for fast-moving chip design teams today.

How LLMs Are Changing the Chip Design Game

AI Is Not New to Chip Design. What's Different This Time?

AI has been used in chip design—most notably for placement and routing tasks, which lend themselves well to black-box optimization techniques like reinforcement learning. They have been shown to improve the chip design flow. Given that the stages of synthesis, P&R, etc., have already been automated to a large extent, applying AI here offers only marginal gains and fails to address the true bottleneck: the cognitive effort required to design and verify chips.

Why didn't the industry create a tool for automating verification as well, much like synthesis?

The answer is simple: Design and verification are fundamentally natural language reasoning problems. Engineers must understand specifications, reason through architectural intent, and ensure that implementation aligns with that intent. All of these tasks involve processing, generating, and interpreting human language. Historically, there has not been a technology to automate this part, hence it has always been manual.

This is where LLMs come in. LLMs excel at precisely what design and verification need: natural language understanding and reasoning. With LLMs, understanding the design intent, figuring out what to test, writing code, employing agentic approaches to run the right tools, debugging the failures, and finding coverage holes have all become possible. These new capabilities have galvanized our team to pioneer the next generation of verification tooling.

There is a lot of excitement in this rapidly evolving landscape, but there are also many more questions to be answered:

How should—or how must—chip design methodology change in the era of LLMs?
How much of the design and verification process can be successfully automated?
How will the roles of human engineers evolve and change alongside their new AI "colleagues"?

… and a whole host of other queries that we, as an industry, have not even considered yet.

The Road Ahead: Rise of New Abstractions for Chip Design

As chips grow in complexity and the demand for compute continues to surge, LLMs may become essential not only to AI workloads but also to the hardware that enables them. These models have the potential to transform chip design itself, closing the loop between silicon and software in ways we've never seen before.

I believe chip design is poised for another "Verilog moment"—a shift to a higher level of abstraction. We expect a move beyond RTL to a new representation that allows engineers to express intent more intuitively, potentially through natural language rather than rigid syntax. We refer to this as the "mental model," and we're actively researching how to make it a practical reality.

The future of AI will be shaped by the chips we build—and, soon, those chips may be shaped by the AI we have trained. It's a two-way street. This cycle promises to accelerate innovation in both silicon and software, bringing us closer to the next generation of computing capabilities.

Learn more about the Cadence ChipStack AI Super Agent.

GDDR7: Highlights of Memory of Choice for Graphics and High Bandwidth Apps

2026-09-26T06:00:00Z

Graphics Double Data Rate 7 (GDDR7) Synchronous Graphics Random Access Memory (SGRAM) is the latest generation of the Graphics DDR memory that is used in applications like graphics cards, high compute data centers. GDDR devices are also increasingly being used in artificial intelligence (AI) accelerators where bandwidth and performance are key requirements.

This blog talks about the key features of the GDDR7 device standard, the latest version of which, JESD239F, was released by JEDEC in August 2026.

GDDR7-Based System Architecture

GDDR7 SGRAM devices support densities of 16GB through 128GB range with the 266-ball BGA package. A GDDR7 device memory subsystem typically contains four fully independent byte-wide channels. Each channel has its own point-to-point command/address, data, error, and read-clock interfaces. A channel contains 16 banks256-bit internal array access, and a 32n. The normal physical organization can be configured at reset as either four active channels or two active channels. In 2-channel mode, channels B and D are inactive, and their high-speed signals remain High-Z; this enables clamshell PCB topologies using channels A and C from devices mounted on opposite sides of the board.

Device Feature Overview

Channel Operation

Each active channel uses a differential WCK_t/WCK_c input for command/address capture, write-data capture, and read-data timing generation. Internally, CK4 is WCK divided by four and is the reference for cycle-based latencies and command timing. Commands that span more than one CK4 cycle use the last CK4 cycle as the timing reference. The output RCK_t/RCK_c read clock is edge-aligned with read data and may be differential or single-ended, always on, started by a read, started explicitly with RCKSTRT, or disabled.

The command/address interface is packetized over five single-ended NRZ inputs, CA[4:0]. CA[2:0] forms a semi-independent row-command path, and CA[4:3] forms a column-command path. This allows row and column commands to overlap when command legality and all timing constraints are satisfied. The protocol supports single- and multi-CK4-cycle commands, with separate NOP encodings for ordinary command slots and transition sequences.

Data Interface, PAM3 Encoding, and Signaling

GDDR7 supports two data modes. PAM3 is the high-bandwidth mode and uses DQ[9:0] plus DQE. NRZ is the lower-speed, lower-power mode and uses DQ[7:0] plus DQE; DQ[9:8] are disabled. Both modes transfer a 256-bit user payload per channel access. A burst is 16 PAM3 symbols or 32 NRZ bits.

PAM3 Mode

PAM3 represents each unit interval with one of three levels: +1, 0, or -1. With nominal 1.2 V VDDQ, the nominal signaling levels correspond to 100%, 75%, and 50% of VDDQ. Internally, the trits use two-bit representations: 11 for +1, 01 for 0, and 00 for -1; 10 is invalid. At an illustrative 7 GHz WCK, data operates at 14 Gbaud per pin, equivalent to 28 Gb/s over each effective binary data lane and 28 GB/s per channel.

A complete PAM3 burst contains 176 symbols across 11 physical data signals. The data and metadata are packed through several codecs like 11b7S, 3b2S, 2b1S, etc.

Command, Clock, and Configuration Model

The CA interface is SDR relative to WCK and packetizes commands over CA[4:0]. GDDR7 separates an 11-bit row-command path on CA[2:0] from a 7-bit column-command path on CA[4:3], allowing compatible row and column commands to be issued in parallel. Core operations include ACT, RD/RDA, WR/WRA, PREpb/PREab, REFab/REFpb, RFM, MRS, IRD, power-state commands, and training commands.

CABI limits low-going CA activity to reduce command-bus power. CAPAR supplies even parity across the command packet. With CAPARBLK, commands are held until parity is validated; a parity failure blocks execution and drives recovery into CA training with self-refresh. CSP aligns the internal CK4 phase to the host’s four-UI command boundary after CA-training or sleep exit. Optional CSP feedback on ERR lets the controller confirm that CSP was captured before normal traffic resumes.

Sixty-four mode-register addresses are available. MR0–MR47 are standardized or reserved; MR48–MR63 are vendor-specific. Key controls cover PAM3/NRZ selection, read/write CRC, poison, and severity, RL/WL, RCK behavior, termination and driver strength, voltage references, CTLE/DFE/TX equalization, refresh management, training patterns, ECC test, and hPPR. MR10–MR15 are frequency-dependent registers whose updates can be deferred until a sleep transition.

Data Integrity, Electrical Limits, Package, and Implementation Guidance

GDDR7 layers protection mechanisms across command, link, data path, and array:

CRC: Separate read and write link CRCs use two interleaved CRC-9 engines with polynomial 0x14B over even and odd 164-bit groups, producing 18 checksum bits. The scheme detects all single-, double-, and triple-bit errors, about 99.95% of four-bit errors, and about 99.99% of random burst errors. Write CRC failures are reported on ERR.
On-die ECC: Minimum capability per 256-bit access is 100% single-bit correction, 100% double-bit detection, and an average 99.3% detection for errors of three or more bits. Corrected data is returned on reads, but ordinary reads don’t scrub the array. Severity metadata reports uncorrectable errors.
Auto ECS: Background Error Check and Scrub reads codewords, corrects correctable errors, writes corrected codewords back, and logs correctable/uncorrectable events. It operates in REFab(TR=L), Self Refresh(TR=L), or Self Refresh Sleep when enabled. The required average ECS interval tightens with channel density, from 5.15 ms at 4 Gb/channel to 0.64 ms at 32 Gb/channel for a 24-hour full sweep.
Poison: The host marks a 256-bit packet as known bad; the status is stored under ECC protection and returned on reads. Severity overrides poison when both occur.
CAPAR/CAPARBLK: Even parity covers the full 20-bit CA packet after CABI processing. Without blocking, a parity error is reported, but the decoded command still executes. With CAPARBLK, the bad command and its paired row/column command are suppressed, subsequent commands are blocked, and the device completes internal work before automatically entering CA Training with Self Refresh.
ERR: A PAM3 output in both data modes. +1 means no error, 0 reports WRCRC/DPP parity or optional severity, and -1 reports CAPAR, which has priority.
DPP: Optional end-to-end internal Data Path Protection adds parity across regions between on-die ECC and link CRC coverage.
hPPR: Permanent row repair protected by a four-command MR31 guard key. The controller must verify spare availability, idle all channels, stop RCK, program at 200–2000 MHz, allow a 2s programming interval, reset, and verify the repaired row.
CSP feedback: Optional CSP Feedback acknowledges the CSP command after exiting sleep mode, self-refresh sleep mode, or CA bus training. The feedback is transferred to the host by an ERR signal, informs it whether the CSP was properly detected, and whether it is safe to continue with normal operation.

Nominal 1.2 V operation specifies VDD and VDDQ of 1.164–1.236 V and VPP of 1.746–1.908 V. An optional 1.1 V range uses 1.067–1.133 V for VDD/VDDQ. Absolute maxima are -0.3 to 1.5 V for VDD/VDDQ and -0.3 to 2.3 V for VPP. HBM and CDM minimum ESD targets are 1000 V and 250 V. GDDR7 relies on vendor-specific AC values, and system validation for jitter, channel loss, supply noise, and timing margin.

Cadence VIPs offers a comprehensive memory subsystem solution that includes memory models for all generations of Graphics DDR devices (with GDDR7 being the latest), compliant to JEDEC specifications defined for each of those devices, DFI Memory Controller/PHY VIPs and a System Performance Analyzer (SPA) for GDDR devices.

If you have any queries, feel free to contact us at talk_to_vip_expert@cadence.com

More information on Cadence GDDR7 VIP is available at Cadence VIP Memory Models Website.

The Ethernet PHY We Knew, The UALink PHY We Needed

2026-09-25T13:45:00Z

Same building blocks. Same lane rates. So why not just use Ethernet PHY unchanged?

The Myth We All Quietly Believe

If you place an Ethernet PHY and a UALink PHY side by side, the first thing you notice is not how different they are. It is how similar they look. If UALink already uses Ethernet PHY technology, why does it need a separate physical layer at all? Why not simply use the Ethernet PHY unchanged?

It is a reasonable question. UALink did not need Ethernet to become faster. Ethernet already had the speed. It did not need a completely new PMD, a new Reed-Solomon code, or a new way to train the link. What changed was something less obvious: the rule the PHY had to obey.

Follow One Flit, and the Difference Appears

Instead of walking through PCS, FEC, PMA, and PMD one block at a time, let us follow something the accelerator actually cares about: a 640-byte DL flit.

At the data link layer, that flit is one meaningful unit. The PHY has to protect it, move it across the link, recover it at the receiver, and hand it back without losing where that flit begins or ends. And here, UALink makes the decision that changes the rest of the story.

Ethernet does not require packet boundaries to line up with FEC-codeword boundaries. A packet could begin in one codeword and end in another, and the PHY would not care. UALink deliberately creates a fixed relationship between a 640-byte DL flit and a single RS(544,514) codeword. Once that rule exists, anything that inserts, removes, delays, or rearranges data has to respect the flit boundary.

The arithmetic explains why this relationship works. A 640-byte DL flit contains 5120 payload bits. After 64B/66B encoding and 256B/257B transcoding, the information expands to exactly 514 ten-bit Reed-Solomon symbols. Adding 30 parity symbols produces a 544-symbol RS(544,514) codeword. Now our flit has armor. But keeping that armor wrapped around exactly one flit creates the first problem.

The First Thing Ethernet Already Solved — Until It Didn't

Ethernet already knows how to align lanes. Alignment markers help the receiver identify lanes, remove skew, and restore the correct lane order. So why would UALink touch something that already works?

Because Ethernet inserts alignment markers into the PCS data stream without caring about packet boundaries. UALink cannot do that. If an alignment marker were inserted using the traditional Ethernet mechanism, the carefully maintained DL-Flit-to-codeword relationship would be disturbed.

To solve this, UALink introduces a coordinated RS and PCS mechanism.

RS generates a 'Start Flit Code Sequence'

PCS recognizes that sequence

PCS overwrites specific 257-bit blocks with Ethernet alignment markers

On receive, PCS reconstructs the marker-containing interval as an AM flit code sequence

RS uses that sequence to recover DL flit phase

The alignment markers on the wire are unchanged from Ethernet. What changes is the mechanism used to introduce and recover them. Same Ethernet alignment markers. Different handling around the flit. UALink did not reinvent the marker. It changed how the PHY makes room for it.

The special start sequence also has to remain recognizable before the PCS replaces part of it with alignment markers. That is why the relevant leading blocks bypass scrambling:

100G: first 20 × 64B/66B blocks

200G: first 4 × 256B/257B blocks

400G: first 8 × 256B/257B blocks

800G: first 8 × 256B/257B blocks per flow

The receiver performs the corresponding descrambler bypass and then resumes with the correct state.

Coming Back Is Harder

Transmit knows exactly where every flit begins. The receiver does not. The receiver sees lanes arriving with possible skew, encoded codewords, alignment markers, and a continuous stream of blocks. Ethernet alignment markers already answer: Which lane is this, and how should the lanes be lined up?

UALink needs one additional answer: Where does the next 640-byte DL flit begin? After the PCS establishes alignment, the marker-containing interval is reconstructed as an AM Flit Code Sequence. The RS recognizes it and establishes the nominal flit phase. From there, the receiver can count the stream in groups of 80 blocks, which is equivalent to one DL flit opportunity.

Then Latency Enters the Story

Our flit is protected. It is aligned. But there is another question: How long does it have to wait? The answer involves FEC interleaving.

Interleaving spreads adjacent symbols across multiple codewords so burst errors become easier to correct. The tradeoff is additional latency because codewords become dependent on one another.

Figure: Standard Ethernet combines PCS symbol distribution with an additional PMA delay to produce 4-way interleaving.

UALink's reduced modes remove the PMA delay and, for 1-way mode, also remove PCS pre-FEC distribution. In the reduced 2-way paths, UALink removes the additional PMA two-codeword delay.

The tradeoff is intentional.
Less interleaving → lower latency.
More interleaving → better burst-error spreading.

Ethernet's choice was not wrong. UALink simply needed another choice.

The Problem Ethernet Gets for Free

Ethernet packets naturally leave gaps. Those gaps provide Idle blocks, giving the PHY convenient places to absorb small clock differences. UALink's normal data path can instead look like this:

Where does rate matching happen if there are no natural gaps? UALink solves this by creating its own opportunities. The RS periodically inserts an idle flit code sequence. UALink solves this by creating its own opportunities. The RS periodically inserts an idle flit code sequence.

In the applicable operating states, the RS provides an idle flit code sequence for every 1,024 codewords, unless that position is being used for an alignment-marker opportunity. Rate matching can then add or remove Idle blocks at safe locations.

Back-to-Back Does Not Mean Boundary-Free

A normal UALink data flit already occupies one complete 80-block unit. So, another flit can immediately follow it.

No new Ethernet start delimiter. No terminate delimiter. No mandatory inter-frame gap. Control sequences occupy complete flit opportunities only when the PHY needs them for alignment-marker handling, rate matching, Idle behavior, or fault signaling.

What UALink Refused to Reinvent

After seeing all these changes, it is easy to think UALink created a completely new PHY. It did not. UALink kept the parts the Ethernet had already solved well.

Inner FEC is conditional. It should only be shown where the selected IEEE PHY actually uses it; it is not a universal UALink KR/CR payload-path stage.

One Last Thing

We started with a myth: If UALink uses the same sublayers and the same speeds as Ethernet, why not simply use Ethernet PHY unchanged? Now the answer is clearer. The same building blocks do not mean the same behavior. Ethernet already had speed.

It already had PAM4, RS-FEC, alignment markers, lane recovery, auto-negotiation, and link training. UALink did not need to reinvent those things. What it needed was for those familiar mechanisms to obey a different rule: Keep the flit together. Once one 640-byte DL flit became associated with one protected FEC codeword, everything around that relationship had to cooperate.

Alignment marker handling changed. Receive synchronization gained a flit boundary. Reduced-interleave options appeared. Rate matching moved to safe opportunities. Back-to-back traffic followed a fixed 80-block rhythm. Not because Ethernet failed. Because Ethernet was solving a different problem, and the Ethernet PHY we knew already knew how to move bits fast. The UALink PHY we needed taught those same building blocks how to move flits predictably.

Testing this carefully coordinated PHY behavior requires more than checking that bits move across the link. Verification must prove that the DL-flit-to-FEC-codeword relationship is preserved, alignment-marker opportunities are handled without breaking flit phase, receive logic can recover the correct 640-byte boundary, reduced-interleave modes behave as intended, and rate matching occurs only at safe Idle Flit Code Sequence locations.

Cadence UALink VIP helps verification teams validate this end-to-end behavior with flit-aware and protocol-aware visibility across the stack, from UPLI down to PHY. Teams can drive realistic traffic, monitor flit/codeword alignment, exercise marker and idle-sequence scenarios, inject malformed conditions, and validate recovery behavior—turning UALink PHY architecture into measurable proof of design robustness. To integrate this validation capability into your environment, contact Cadence Support, visit the Simulation VIP for UALink product page, or explore the wider range of Cadence Simulation VIP solutions. For any clarification or technical assistance, please reach out to us at talk_to_vip_expert@cadence.com.

Untangling PCIe L0p: How Four Bytes DLLP Reshape a Live Link

2026-09-23T09:30:00Z

PCIe links in AI accelerators, storage subsystems, and data-centric platforms see traffic that arrives in bursts. Keeping every lane active through the quiet stretches burns power for bandwidth that isn't being used. PCIe 6.0 addresses this tradeoff with L0p, a power-saving substate of L0 supported only in flit mode. At the center of the transition to L0p is the link management DLLP. It carries the requested width, response semantics, and priority information, allowing both sides of the link to agree on a width change without forcing the entire link back through the traditional recovery and configuration path. The simplicity is only on the surface. Underneath the surface sits a multiphase sequence with arbitration rules, response timing, post-response tracking windows, and a physical link reconfiguration that must be completed before the clocks run out. That is exactly what makes the link management DLLP worth a closer look.

This blog walks through how link management DLLPs work under the hood, where the verification complexity actually lives, and how Cadence PCIe VIP addresses that coverage space.

When a Power Saving Feature Becomes a Protocol Puzzle

For years, changing link width was a disruptive event—the link had to leave L0, traverse recovery, pass through configuration, and return to L0. With L0p, PCIe introduces a cleaner way to change link width while the link remains logically up.

It is tempting to picture L0p as a power knob: drop the active lane count on the fly, unused lanes go idle when bandwidth demand drops, bring them back when demand rises, and the link stays in L0 throughout. Getting it right means following a width change the way the silicon does: a link management DLLP exchange at the data link layer, an L0p Ack or Nak response within the required timing window, per-lane electrical idle signaling aligned with ordered set behavior, and training on lanes that are brought back into service. The lanes that remain active continue carrying flits. There is no full teardown. Just a live link changing its width under traffic. That's the design intent, and it's where most of the verification complexity begins.

Inside the Link Management DLLP

Link management DLLP is four bytes wide with a compact but highly structured format:

The key semantic fields are:

L0p.Cmd: Encodes operations such as request, Ack, and Nak.
L0p.Priority: Indicates requests that are policy or urgency-sensitive.
L0p link width: Carries the requested or desired link width.
Response payload: Qualifies the response behavior when responding to a request.

Same DLLP Encoding, Different Protocol Universe

Link management DLLP shares the same encoding as conventional DLLPs (Ack/Nak, PM, UpdateFC), but the resemblance ends there. Those three are housekeeping—the continuous background work that keeps the Data Link Layer operational. Link management DLLP carries no credits, no sequence numbers, no replay information. Its purpose is more direct: carry the L0p command, the priority bit, and the target width to the link partner, and get back a deterministic L0p Ack or Nak. Conventional Ack/Nak DLLPs track TLP sequence numbers and gate the replay buffer. By contrast, an L0p Ack does not acknowledge a TLP, and an L0p Nak does not request TLP replay. They answer a width management proposal: an L0p Ack indicates that the requested Link Width change is accepted, whereas an L0p Nak indicates that it is not accepted.

The Request-Response Contract

The link management DLLP operates within a tightly defined envelope. It is a flit mode mechanism, and if the link is not operating in flit mode, the receiver silently discards it. The same applies when reserved encodings are present in the DLLP fields. The DLLP must carry a valid link management type, a valid L0p command, and a valid link width encoding. Reserved fields are transmitted as zero, and reserved encodings do not go on the wire. The link management DLLP either fits the envelope completely, or it is treated as though it never arrived. A port initiates a link width change by transmitting up to three identical link management DLLPs within five consecutive flits. It gives the requester enough tolerance against loss without turning the request into noise on the link.

The responder side is just as constrained. When duplicates arrive within the observation window, the responder must return the same L0p Ack/Nak for every copy received. No divergence is permitted—identical requests within the window get an identical response. That consistency is what keeps the exchange deterministic: the requester is allowed to repeat the ask, but the responder is not allowed to create ambiguity inside the same observation window.

Ack, Nak, or Abandon: The Clock Keeps Running

Response timing is where the link management DLLP becomes more than a request-response packet. It becomes a bounded protocol sequence. For links using 128b/130b or 1b/1b encoding, the responder must transmit an L0p Ack or Nak within 1 µs. For 8b/10b encoding, the response window extends to 4 µs. If the requester does not receive a response within 4 µs on 128b/130b or 1b/1b links, or within 8 µs on 8b/10b links, it must either re-request the same link width change or abandon the request. Once a response is out, both ports enter the post-response tracking window. The conditions for abandonment differ depending on the request direction and the response type. After an upsize Ack, the partner considers the request abandoned only if the requester does not initiate the link width upsize within 16 µs of the Ack and does not resend the upsize request within 8 µs of that Ack. For a downsize Ack, the request is considered abandoned only if the requester neither resends the downsize request within 4 µs of the Ack nor initiates the downsize within 16 µs. For a downsize Nak, if the requester does not resend the downsize request within 4 µs of the Nak, the partner considers the request abandoned.

Small on the Wire, Big in Verification

A robust verification strategy has to follow it all the way down—from the link management DLLP exchange to the physical realization of the width change on the lanes. Cadence PCIe VIP helps exercise and observe L0p behavior across the protocol stack. Representative capabilities include protocol-aware generation and checking of link management DLLP transactions, Flit-aware DLP visibility for debug, timing, and protocol checks for request-response behavior, configuration, and LTSSM-aware scenario validation, and a combination of directed and constrained-random testing for negative and corner-case scenarios.

More Information

For more information on how Cadence PCIe Verification IP and TripleCheck enable users to confidently verify these new disruptive changes, see our VIP for PCI Express, VIP for Compute Express Link and TripleCheck for PCI Express.
For more information on PCIe in general, and on the various PCI standards, see the PCI-SIG website. 
If you have feedback or need more information, reach out to us at talk_to_vip_expert@cadence.com.

Not Every Byte in a UALink DL Flit Is a Payload

2026-09-22T07:47:00Z

Imagine a cargo train carrying three kinds of shipments: the railway company's own cargo, customer packages, and unfinished packages that are continuing from an earlier train. Now imagine you're unloading the train. Looking at a coach full of...(read more)

Secure Imaging Starts at the Sensor: Understanding SEP in MIPI CSE v2.0

2026-09-21T09:18:00Z

Secure imaging starts at the sensor. How the SEP protocol in MIPI CSE v2.0 protects every CSI-2 packet, and how Cadence VIP verifies it.(read more)

Verifying FSED in MIPI CSE v2.0 with Cadence VIP

2026-09-21T06:47:00Z

Automotive camera systems face a threat model that goes beyond packet-level tampering. Someone with physical access to the camera data link could swap out an entire live video frame for a fabricated one while every individual packet checksum stays untouched — a gap that per-packet protection alone can't close. At the same time, that same link has to prove it can catch faults reliably enough to meet automotive safety requirements, frame after frame, at scale.

The Frame-based Service Extensions Data (FSED) protocol in MIPI CSE v2.0 (Simulation VIP for MIPI CSI-2 | Cadence) takes on both challenges at once. It inserts dedicated cryptographic messages at defined frame partition boundaries to authenticate entire frame segments (the security service), while appending interlocking CRC-32 checks and message counters to those same messages to satisfy functional safety detection requirements (the Functional Safety, or FuSa, service). This frame-level approach is fundamentally more efficient for high-resolution camera systems than per-packet Service Extension Packet (SEP) protection, and verifying its correctness demands an equally sophisticated tool.

Figure 1. FSED messages sit at fixed points in the CSI-2 frame FSED_CTRL_SYNC after frame start, an optional FSED_TOP_TAG mid-frame, and FSED_FRAME_TAG before frame end.

Introduction to FSED

FSED works by inserting up to three dedicated messages directly into the CSI-2 frame, at fixed points in the packet sequence, rather than adding headers or footers to every packet the way MIPI's other CSE protocol, SEP, does. Each FSED message is simply a CSI-2 Embedded Data (ED) Long Packet — FSED_CTRL_SYNC right after frame start, an optional FSED_TOP_TAG mid-frame, and FSED_FRAME_TAG just before frame end — so no new packet type needs to be introduced into the protocol. The key advantages of this frame-level approach include:

Frame-level efficiency: One authentication and safety check per frame segment instead of per packet, which scales far better for high-resolution ADAS and autonomous-driving cameras.

Three services, one structure: The same three messages carry a mandatory base service plus two independently selectable services — Security (authentication, with optional encryption) and Functional Safety (CRC-based fault detection) — so designs get either or both protections without duplicating the frame structure.

Backward-compatible by design: The mid-frame message is optional, so implementations can start with the minimum message set and add mid-frame checking only where latency budgets allow.

Built-in replay protection: Layered frame counters embedded in the authentication tag catch replayed or stale frames, even across session boundaries.

Security Meets Functional Safety

FSED is actually three independently selectable services, layered on top of each other rather than bundled as one fixed feature. The FSED Base Service is mandatory — it tags every FSED message with a source identifier, the eVC (virtual channel) it belongs to, and a frame counter, so every message is uniquely identified and ordered no matter which protections are switched on above it. Layered on that foundation, designs can independently enable the Security Service, the FuSa Service, or both — with Security sitting at a higher layer than FuSa, a detail that turns out to matter once both are active.

FSED's Security service offers a choice of two ciphersuites on the same message structure - a performance mode (AES-GMAC, with optional AES-CTR encryption) built for high-throughput, forward-facing ADAS cameras, and an efficiency mode (AES-CMAC, no encryption) for area- and power-constrained image sensor silicon. Switching between them is a configuration choice, not a redesign.

The Functional Safety service layers five interlocking Cyclic Redundancy Check (CRC-32) checks plus two independent counters (frame-level and message-level) on top of the same messages, catching corrupted, dropped, duplicated, or reordered frames before they ever reach the application layer. When both services run together, Security is applied first at the transmitter and verified last at the receiver — a direct consequence of Security sitting above FuSa in the layering — so the safety checks cover the fully protected data, not just the raw payload.

FSED is actually three independently selectable services, layered on top of each other rather than bundled as one fixed feature. The FSED base service is mandatory — it tags every FSED message with a source identifier, the eVC (virtual channel) it belongs to, and a frame counter, so every message is uniquely identified and ordered, no matter which protections are switched on above it. Layered on that foundation, designs can independently enable the security service, the FuSa service, or both — with security sitting at a higher layer than FuSa, a detail that turns out to matter once both are active.

FSED's security service offers a choice of two ciphersuites on the same message structure - a performance mode (AES-GMAC, with optional AES-CTR encryption) built for high-throughput, forward-facing ADAS cameras, and an efficiency mode (AES-CMAC, no encryption) for area- and power-constrained image sensor silicon. Switching between them is a configuration choice, not a redesign.

The Functional Safety service layers five interlocking Cyclic Redundancy Check (CRC-32) checks plus two independent counters (frame-level and message-level) on top of the same messages, catching corrupted, dropped, duplicated, or reordered frames before they ever reach the application layer. When both services run together, security is applied first at the transmitter and verified last at the receiver — a direct consequence of security sitting above FuSa in the layering — so the safety checks cover the fully protected data, not just the raw payload.

Key Verification Challenges

Security variant coverage: Each security variant, including Cadence's own region-of-interest extension, defines a different MAC coverage boundary across the frame partitions, so each one needs its own targeted test scenarios.

Optional payload encryption: When AES-CTR encryption is layered on top of the MAC, verification has to confirm the plaintext round-trips byte-for-byte through encryption and decryption without disturbing MAC coverage.

Optional packet presence and absence: The pre-image and post-image embedded data packets and the mid-frame message are all optional, so verification has to exercise every combination of which ones are present or missing, since that directly changes what gets MAC- and CRC-covered.

MAC validation across every message type: CTRL_SYNC, TOP_TAG, and FRAME_TAG each carry independent MAC coverage, and all three need correct generation and checking under both ciphersuites.

Counter roll-over without false alarms: Frame counters must wrap and hand off to a secondary counter without triggering a false frame-loss error.

Fault injection granularity: Proving out diagnostic coverage requires corrupting each MAC and CRC field independently and confirming the matching checker fires.

Figure 2. Six key FSED verification challenges: Security variant coverage; optional AES-CTR payload encryption; optional packet presence; MAC validation across all three FSED messages; counter roll-over; and per-field fault injection granularity.

Simplifying FSED Verification with Cadence CSI-2 VIP

Figure 3. Cadence CSI-2 VIP test bench: Active and passive primary/secondary agents generate and check FSED CTRL_SYNC, TOP_TAG, and FRAME_TAG messages against a PHY-agnostic DUT.

Cadence CSI-2 Verification IP (Simulation VIP for MIPI CSI-2 | Cadence) is built to close every one of these gaps with a single, spec-compliant verification solution. It provides a golden reference model that runs as primary or secondary, generating and checking all FSED messages in real time, exercising every Security Variant defined in the specification. Backed by an industry-standard cryptographic library, it verifies AES-CTR payload encryption round-trips byte-for-byte and validates the MAC independently at CTRL_SYNC, TOP_TAG, and FRAME_TAG under both ciphersuites.

It also exercises every combination of optional pre-image, post-image, and mid-frame message presence, includes a dedicated regression for frame-counter roll-over, and ships with independent, targeted fault injection for every MAC and CRC field, so teams can generate per-mechanism diagnostic-coverage evidence and confirm each checker fires exactly when it should. With this breadth of coverage, Cadence CSI-2 VIP eliminates the verification gap for FSED, letting design teams validate frame-level security and functional safety together, out of the box.

Learn more about Cadence MIPI CSI-2 Verification IP, including key features, capabilities, and benefits, by visiting our product page: Simulation VIP for MIPI CSI-2 | Cadence

For more details, connect directly with Cadence Verification IP experts at talk_to_vip_expert@cadence.com

DisplayPort Adaptive-Sync: When Fixed Refresh Rate Is Not Enough

2026-09-16T19:53:00Z

Displays are central to nearly every modern computing experience. Whether we are watching a video or playing games, we expect motion to appear clear and continuous. However, when the rate at which a Graphics Processing Unit (GPU) produces frames does not align with the rate at which a display refreshes, visible artifacts such as screen tearing and stutter can occur. Adaptive-Sync addresses this mismatch by allowing the display's refresh rate to follow the timing of frames driven by the GPU.

Understanding the Artifacts that Can Occur without Adaptive-Sync

A conventional display refreshes at a fixed rate. For example, a display operating at 120 Hz begins a new refresh approximately every 8.33 ms, calculated as 1000 divided by 120. The GPU, however, may not produce every frame in exactly 8.33 ms. One frame might take 8 ms to render, another 12 ms, and another 20 ms, causing screen tearing or screen stutter.

Screen tearing can occur when a new frame is transported while the display is still scanning the previous frame. The resulting image may contain portions of two different frames.
Screen stutter can occur when a frame is not ready for the next fixed refresh interval. The display may repeat the previous frame, momentarily pausing motion.

Adaptive-Sync reduces these artifacts by allowing the GPU to vary the interval between transmitted frames within the refresh rate range supported by the display.

Fixed Refresh Rate vs Variable Refresh Rate (Adaptive-Sync)

Let's assume the monitor is configured for its maximum refresh rate of 125 Hz, which makes its refresh period set at 8 ms. If the GPU renders frames at intervals of 8 ms, 12 ms, and 20 ms, the monitor continues to refresh every 8 ms, regardless of when the GPU makes each frame available. This creates a mismatch between the GPU and monitor, which produces undesirable visual artifacts.

With Adaptive-Sync, the source can dynamically vary the frame interval based on the application, allowing the display's refresh rate timing to more closely track the GPU's output. For example, an 8 ms frame interval corresponds to a 125 Hz refresh rate, a 12 ms interval corresponds to approximately 83.3 Hz, and a 20 ms interval corresponds to a 50 Hz refresh rate. Synchronizing the GPU and display reduces artifacts while improving the overall experience.

The link rate and lane count do not need to change. See Figure 1 for a comparison of the GPU-to-display timing relationship before and after Adaptive-Sync.

Figure 1: Adaptive-Sync aligns the display refresh interval with the GPU’s frame interval

How DisplayPort Frame Timing Works

All frames have a blanking region and an active video region. The DPTX, such as the GPU, transmits Main Stream Attributes, or MSA, describing the frame. The key MSA timing parameters include:

HTotal;
HStart;
HSync Width;
VTotal;
VStart;
VSync Width;

During fixed timing operation, the DPRX (display) uses the MSA timing parameters to interpret the transmitted video timing and reconstruct the displayed frame.

What Changes with Adaptive-Sync?

Under Adaptive-Sync, the duration between frames may change. The active video resolution can remain the same while the vertical blanking interval is shortened or extended.

Figure 2: Adaptive-Sync varies frame duration by adjusting the vertical blanking interval

Because the actual frame duration is now variable, certain fixed MSA timing parameters can no longer be relied on for the frame's timing and reconstruction.

Before Adaptive-Sync can be used, the DPRX must advertise support for ignoring MSA timing parameters during the discovery phase before link training. Once link training is complete, the DPTX can enable this functionality by setting the MSA_TIMING_PAR_IGNORE_EN bit (bit 7) in DisplayPort Configuration Data (DPCD) address 00107h. After this bit is enabled, the DPRX ignores the applicable MSA timing parameters as defined in the DisplayPort specification. The Adaptive-Sync SDP communicates the information needed to coordinate variable frame timing. The DPRX uses this information, together with the transmitted video stream and MSA, to control its refresh timing.

Adaptive-Sync Secondary Data Packet (SDP)

Modern Adaptive-Sync operation uses an Adaptive-Sync SDP to communicate frame-related timing information. Depending on the SDP version and operating mode, its payload can identify the Adaptive-Sync operating mode and carry information such as:

Target refresh rate
Target refresh-rate divider
Frame duration increase constraints
Frame duration decrease constraints
Panel Replay timing information

This allows the source and sink to coordinate variable timing without changing the active frame.

AVT and FAVT Adaptive-Sync Features

More advanced Adaptive-Sync features add greater flexibility.

Adaptive Video Timing, or AVT, allows the source to vary frame duration dynamically within the capabilities advertised by the sink. The DPTX may increase or decrease the interval between frames while respecting the supported timing boundaries.
Fixed Average Video Timing, or FAVT, allows individual frame durations to vary while maintaining a specified average frame duration or target refresh rate over time.

Conclusion

The key capability provided by Adaptive-Sync is the ability for the DPTX to vary frame duration while communicating the associated timing information to the DPRX through Adaptive-Sync protocol mechanisms. This enables smooth operation without requiring link-rate or lane count changes.

Cadence has a very mature Verification IP solution. Verification over many different configurations can be used with eDP 1.5, DisplayPort 1.4, DisplayPort 2.1, and USB4 DP tunneling designs, so you can choose the best version for your specific needs.

Learn more about Cadence’s Verification IP solutions.