Verification

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

Bhairava prasad — Thu, 01 Oct 2026 10:07:00 GMT

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

Ravi Vora — Wed, 30 Sep 2026 13:30:00 GMT

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

Corporate — Tue, 29 Sep 2026 16:00:00 GMT

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

Shyam Sharma — Sat, 26 Sep 2026 06:00:00 GMT

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

durgarentikota — Fri, 25 Sep 2026 13:45:00 GMT

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

ManasiYadav — Wed, 23 Sep 2026 09:30:00 GMT

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

budarapuujwalk — Tue, 22 Sep 2026 07:47:00 GMT

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

Mohit1702 — Mon, 21 Sep 2026 09:18:00 GMT

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

DhyeySoni — Mon, 21 Sep 2026 06:47:00 GMT

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

tfox — Wed, 16 Sep 2026 19:53:00 GMT

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.

AMBA AXI5 MPAM: Control and Visibility for Shared Memory Resources

DivyaBora1 — Tue, 15 Sep 2026 08:58:00 GMT

As modern SoCs become increasingly heterogeneous, the shared memory system has become a critical performance and isolation boundary. CPUs, GPUs, AI accelerators, DMA engines, display controllers, and virtualized workloads often compete for shared cache capacity and memory bandwidth. In these systems, high performance depends on more than simply moving data quickly. Resources must be shared fairly, usage must be tracked accurately, and interference between workloads must be controlled.

Verifying MPAM, however, is challenging because the metadata must travel correctly with every memory transaction across the system. Arm Memory Partitioning and Monitoring (MPAM) addresses this challenge by adding transaction-level information to AMBA AXI5. This information identifies the resource partition associated with a memory access and the monitoring group to which its activity must be attributed. By making resource usage visible on the bus, MPAM supports more predictable performance, stronger workload isolation, and improved system-level observability.

Overview of Memory Partitioning and Monitoring

MPAM provides a framework for controlling and monitoring shared memory system resources. It allows system software and hardware to associate each memory transaction with a resource partition and a performance monitoring context. Components such as interconnects, caches, and memory controllers can use this information to apply resource policies and account usage.

Partitioning and monitoring are complementary but independent. Partitioning determines how shared resources are controlled, while monitoring records how those resources are used. This separation allows workloads within the same resource partition to be measured independently, or different partitions to be managed under distinct allocation policies.

Why AXI5 Needs MPAM Support

Standard AXI transaction attributes describe properties such as ordering, cacheability, protection, and Quality of Service. They do not, by themselves, identify the resource partition that should manage a transaction or the monitoring context that should account for its bandwidth and cache usage.

AXI5 MPAM support closes this gap by carrying partitioning and monitoring metadata with every read and write request. This enables downstream components to consistently recognize the workload context, enforce resource-management policies, and collect meaningful usage information across the memory hierarchy.

AXI5 MPAM Protocol Architecture

MPAM is defined as an optional AMBA 5 feature. Support is controlled through the MPAM_Support interface property. When MPAM is enabled, read and write address requests carry MPAM information using ARMPAM and AWMPAM. When the feature is not supported, these signals are not present on the interface.

The MPAM information contains three logical fields:

MPAM_NS: Security Context

MPAM_NS provides the security indicator associated with the transaction.

PARTID: Partition Identifier

PARTID identifies the resource partition associated with the transaction. Interconnects, caches, and memory controllers can use the identifier when applying controls to shared resources such as cache capacity or memory bandwidth.

PMG: Performance Monitoring Group

PMG identifies the context used for performance accounting, traffic monitoring, profiling, and debug. It enables resource usage to be attributed to the appropriate workload or monitoring group without changing the partition assignment.

How MPAM Information Flows Through the System

MPAM information travels as metadata alongside the transaction address. An MPAM-enabled master drives the appropriate value on a read or write address request, and downstream components sample the value with the corresponding valid address transfer. The interconnect can propagate the metadata toward caches, bridges, and memory controllers that implement partitioning or monitoring functions.

The values generated by a master are implementation-defined and are typically selected through software, firmware, or system configuration. MPAM identifiers have global scope, so an interconnect is not required to remap them or make them unique for each master. Where system components use different MPAM configurations, the implementation must define how widths, defaults, and unsupported fields are handled.

Key Protocol Features

Configurable identifiers: Implementations can select partitioning and monitoring granularity appropriate to the system and interface configuration.
Independent resource partitioning: PARTID values allow transactions to be associated with resource partitions used by components in the memory hierarchy.
Independent monitoring: PMG values allow traffic within a partition to be accounted for through separate monitoring contexts.
End-to-end metadata propagation: MPAM information can travel through compatible interconnects and protocol bridges while preserving the transaction context.
Efficient signaling: Separating partitioning from monitoring avoids unnecessary coupling between resource-control and accounting requirements.
Throughput management and workload isolation: By making each transaction’s resource context visible, MPAM helps memory-system components reduce workload interference, avoid unfair bandwidth usage, and improve performance predictability when multiple agents compete for shared resources.

Practical System Use Cases

Cloud and Virtualized Workload Isolation

Hypervisors and system software can associate virtual machines, containers, or applications with distinct resource partitions and monitoring groups. This helps prevent one workload from monopolizing shared cache capacity or memory bandwidth, while enabling usage to be profiled or accounted for independently.

AI Accelerators and Heterogeneous SoCs

CPUs, GPUs, AI accelerators, and DMA engines frequently share DRAM bandwidth. Assigning different PARTID values enables the memory system to distinguish traffic classes for resource control, while PMG values provide visibility into the bandwidth consumed by each monitored workload.

Monitoring, Debug, and Accounting

Because monitoring information accompanies the transaction, memory-system usage can be attributed at multiple points in the hierarchy. This supports workload profiling, bottleneck analysis, latency debug, resource accounting, and placement optimization.

Automotive and Real-Time Systems

In systems where predictable latency matters more than peak throughput, MPAM information can distinguish safety-critical or latency-sensitive traffic from background activity. Resource controls can then limit interference, while monitoring provides visibility into actual consumption.

Functional Verification Challenges

MPAM verification adds resource-context correctness to standard AXI protocol verification. A complete environment must verify not only that the AXI transfer is legal, but also that MPAM information is configured, generated, propagated, interpreted, and monitored consistently.

IP-Level Verification

Validate the presence and configuration of the partition and monitoring information.
Check identifier values against the configured widths and legal constraints.
Verify boundary configurations, including zero-width identifiers and maximum supported widths.
Confirm protocol consistency across read and write transaction types.
Validate interoperability between MPAM-capable and non-MPAM-capable interfaces.

SoC-Level Verification

Confirm end-to-end preservation of MPAM information through interconnects, caches, bridges, and memory controllers.
Validate that transactions are associated with the intended resource partition and monitoring group.
Exercise width adaptation, tied-off fields, truncation, default values, and potential identifier aliasing.
Check behavior through virtualization events, context switches, and heterogeneous protocol configurations.
Cover partition identifiers, monitoring groups, identifier crosses, width configurations, and bridge interoperability.

Cadence AXI5 VIP Solution

Cadence AXI/ACE Verification IP provides a comprehensive solution for creating, observing, and checking MPAM-aware traffic across configurable AXI environments. It enables verification teams to validate protocol behavior at the IP level and preserve MPAM transaction context through system-level scenarios.

Cadence AXI5 VIP accelerates MPAM verification closure by providing:

Ready-to-use generation of MPAM-aware read and write transactions
Configurable partition and monitoring signaling
Protocol checks for MPAM configuration and transaction consistency
Validation of identifier widths and interface interoperability
Functional coverage for MPAM values, configurations, and feature interactions
End-to-end observability for MPAM metadata across the verification environment

These capabilities help teams progress beyond basic signal checks and validate MPAM behavior under heterogeneous traffic, configurable widths, protocol bridges, and realistic resource-monitoring flows.

Conclusion

AMBA AXI5 MPAM makes shared memory-resource usage identifiable, controllable, and measurable at the transaction level. By carrying partition and monitoring information with read and write requests, it gives SoC implementations a practical mechanism for improving workload isolation, applying resource policies, attributing usage, and increasing performance predictability across heterogeneous systems.

As MPAM behavior spans interface configuration, transaction signaling, metadata propagation, resource control, and monitoring, verification must address both protocol compliance and end-to-end system intent. Cadence AXI5 VIP provides the traffic generation, checking, coverage, interoperability validation, and observability needed to verify robust MPAM implementations from IP-level configuration through full-system operation.

For more information on Cadence AXI/ACE VIP for AMBA AXI5 MPAM verification, visit the Cadence Functional Verification community or contact the Cadence VIP team.

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

More information: https://www.cadence.com/en_US/home/tools/system-design-and-verification/verification-ip/simulation-vip.html

Why Faster Isn't Always Better: UALink Transmitter Pacing Explained

SchrodingerBug — Tue, 15 Sep 2026 05:03:00 GMT

Imagine two accelerators connected through a UALink link operating at full bandwidth. The link is running at full line rate, DL flits are flowing across the wire, and transactions are moving between devices. Yet one of those accelerators may already be falling behind.

The reason is subtle. In UALink, the physical link and the accelerator behind it do not necessarily operate at the same rate. An accelerator may reduce its UPLI clock frequency for power-saving purposes while the link itself continues operating at line rate. This situation can occur when an accelerator is not fully utilized and chooses to lower its operating frequency to reduce power consumption, even though the UALink connection remains active. That creates an interesting engineering challenge: how do you prevent data from arriving faster than the receiver can consume it?

The answer is transmitter pacing.

The Journey from Transaction to Wire

Before discussing pacing, it helps to understand where it fits in the UALink stack.

A transaction begins at the functional/protocol layer, is packaged into 64-byte TL flits by the transaction layer, packed into 640-byte DL flits by the data link layer, and ultimately transmitted by the PHY across the serial link.

Figure 1: The UALink protocol stack

Under normal conditions, data enters and exits the receive path at roughly the same rate. The interesting part begins when the receiver intentionally slows down.

When the Link Is Faster Than the Accelerator

UALink allows accelerators to operate their UPLI clock below the maximum rate to reduce power consumption. The physical link, however, does not automatically slow down.

The receive-side adaptation FIFO is written using a rate derived from the recovered link clock, while data is removed by the transaction layer running on the local UPLI clock. If that UPLI clock is reduced, data can arrive faster than it is consumed. FIFO occupancy grows over time, eventually creating an overflow risk.

Figure 2: Receive-side rate mismatch

This is the problem transmitter pacing was designed to solve.

What Transmitter Pacing Actually Does

A common misconception is that pacing slows the physical link. That is not what happens.

The serial link continues operating at line rate. DL flits continue being transmitted. What pacing controls is the rate at which TL flits are admitted into the DL transmit path. In other words, pacing acts between the transaction sayer and the data link layer, regulating how quickly useful traffic enters the link.

This distinction is important because the goal is not to throttle the wire. The goal is to prevent the receiver from becoming overloaded when it is operating at a lower UPLI frequency.

The Challenge Hidden Behind a Simple Requirement

So far the solution sounds straightforward:

Notify link partners about rate changes
Adjust pacing
Prevent receive-side overflow

What the specification does not fully define is how pacing should be implemented. That creates an interesting design challenge.

Consider a simple example. A transmitter is operating at full UPLI rate. Its link partner is operating at half that rate. Now, assume the link remains idle for a period of time. No TL flits are being admitted, and no useful traffic is sent. When traffic suddenly arrives, a natural question appears: Can the transmitter take advantage of that earlier idle period and temporarily send data more aggressively?

From a utilization perspective, that sounds attractive. After all, no traffic was sent during the idle interval. But from the receiver's perspective, sending a large burst immediately afterward may create much higher instantaneous FIFO occupancy. This is where implementation choices begin to matter.

Should pacing strictly match the advertised long-term rate? Should some accumulation of unused opportunities be allowed? If so, how much? The specification intentionally leaves these implementation decisions open while still requiring that receive-side overflow never occurs. That turns pacing from a protocol feature into an engineering problem.

Why Verification Gets Interesting

Many protocol features can be validated with straightforward directed tests. Transmitter pacing is different. A simple test may show:

TL rate notifications were exchanged
ACKs were returned
Traffic continued flowing

Everything appears correct. The difficult cases emerge over time. Questions quickly arise:

Was the new rate applied when expected?
Was the receiver protected under sustained traffic?
Did idle periods affect behavior correctly?
What happens when both ends of the link change rates independently?

These are not packet-level questions. They are behavioral questions that play out over thousands of cycles. That is what makes pacing a particularly interesting verification problem.

The Takeaway

UALink transmitter pacing exists because the physical link and the accelerator behind it are not always operating at the same rate. The specification allows accelerators to lower their UPLI clock frequency for power reduction while the UALink link continues operating at full speed. Without pacing, the receive-side adaptation FIFO could fill faster than it is drained, eventually leading to overflow.

What makes the feature especially interesting is that the specification defines the goal but largely leaves the implementation strategy to the designer. The protocol tells us what must be achieved. The details of how it is achieved are implementation-specific. For verification teams, that turns pacing from a simple protocol mechanism into a system-level behavior that must be validated across changing rates, idle periods, and real traffic scenarios.

Cadence UALink VIP is designed to help verify exactly these situations. By providing visibility across UPLI, TL, DL, and PHY, it enables engineers to observe the impact of rate changes throughout the protocol stack. Protocol-aware checkers continuously monitor rate notifications, pacing-related behavior, and receiver-protection requirements, while detailed logs provide visibility into how the design responds to changing operating rates. Together, these capabilities help engineers validate pacing behavior and receiver protection while ensuring compliance with UALink protocol requirements.

For further details, contact Cadence support or visit the Simulation VIP for UALink product page. You can also explore Cadence Simulation VIP solutions for broader protocol VIP support.

The result is a simple but powerful lesson: in UALink, maximum performance is not achieved by sending data as fast as possible. It is achieved by matching transmission behavior to the rate the receiver can sustainably consume, even when the link itself continues operating at full speed.

Flexible UALink Verification for Any Layer, Interface, and Design Configuration

SG202607104355 — Wed, 02 Sep 2026 09:30:00 GMT

Modern AI training and inference clusters rely on hundreds or even thousands of GPUs and accelerators working together as a unified compute fabric. As models continue to grow in size and complexity, communication between accelerators has become just as critical as the compute engines themselves.

UALink was created to address this challenge. Designed as a high-bandwidth, low-latency scale-up interconnect, UALink enables efficient accelerator-to-accelerator communication and supports the construction of large AI fabrics where accelerators can exchange data quickly and predictably. Simulation VIP for UALink | Cadence

To achieve the scalability required by modern AI workloads, UALink adopts a layered architecture that cleanly separates protocol, transport, reliability, and physical communication functions. While this layered approach provides significant implementation flexibility, it also creates unique verification challenges. Different projects often implement different portions of the stack, resulting in a wide variety of valid design configurations that must all be verified with equal confidence.

The UALink Layered Architecture

UALink is organized as a four-layer stack:

Each layer serves a distinct function, from protocol transactions at UPLI to reliable transport, replay handling, and physical communication at the lower layers.

Because development often progresses layer by layer, customers rarely verify a complete stack from day one. Depending on project needs, verification may target individual layers, partial-stack implementations, full-stack designs, or custom partitions.

As a result, verification environments must accommodate a variety of implementation boundaries and DUT to efficiently support the full development lifecycle of a UALink design.

Why Layered Protocols Need Layer-Aware Verification

The complexity of UALink verification is not simply a matter of supporting multiple configurations.

Many of the protocol's most important features span multiple layers.

Consider link error recovery. The physical layer is responsible for detecting and recovering from transmission errors, but the behavior ultimately depends on interactions with neighboring layers.

For example, protocol transactions initiated at UPLI traverse multiple layers before reaching the physical interface, while reliability features such as replay and recovery depend on coordinated behavior across layer boundaries. A protocol-only environment may be sufficient for early bring-up, but full-stack validation is often required to expose latency-dependent and integration-related issues.

Consequently, many of the most challenging bugs appear not within a single layer, but at the boundaries between layers.

Successful verification therefore requires visibility into both protocol-level behavior and lower-level link operations.

Multiple Interfaces, Maximum Flexibility

UPLI Interface

Provides a protocol-level entry point for validating UPLI implementations as well as lower-stack DUTs through realistic protocol traffic generation.

DL-PL Interface

For customers focusing on data-link or physical-layer functionality, the DL-PL interface provides direct access to replay, retry, flow control, error handling, and PHY integration behavior, allowing customers to verify DL (w/o PL) or PL (w/o) centric implementations.

Full-Stack Verification

For integrated designs, a full-stack VIP configuration provides complete end-to-end validation across the entire UALink protocol stack.

One VIP for Every UALink Design Configuration

In addition to standard interfaces, Cadence UALink VIP architecture is flexible enough to support implementation-specific environments and custom integration flows, allowing it to fit naturally into customer verification infrastructures. A key differentiator of the Cadence UALink VIP is its flexibility to adapt to any verification interface. It supports a large number of topologies including but not limited to the ones shown in the figure below:

UALink Verification Topologies

Cadence UALink VIP (Simulation VIP for UALink | Cadence) is designed to support the entire UALink verification lifecycle, from early layer bring-up to full-stack integration.

The solution includes:

Complete protocol stack support
UPLI, DL-PL, and full-stack connectivity
Protocol compliance checking
Functional coverage
Error injection capabilities
Replay and recovery validation
Advanced debug visibility
Support for standard and custom verification topologies

The same VIP infrastructure can therefore be used across protocol-layer, subsystem, PHY, hybrid, and full-stack verification environments.

Conclusion

The flexibility of UALink architecture is one of its greatest strengths. However, that flexibility also means there is no single "typical" UALink implementation. Customers may be verifying protocol-layer functionality, link-level reliability mechanisms, standalone PHY implementations, full-stack designs, or any combination in between.

Cadence UALink VIP (Simulation VIP for UALink | Cadence) is built for exactly this reality.

With support for all UALink layers, standard interfaces such as UPLI and DL-PL, full-stack verification capabilities, and the flexibility to adapt to customer-specific architectures, the VIP enables verification across virtually any UALink topology.

For any clarification or technical assistance, please reach out to us at talk_to_vip_expert@cadence.com.

Learn more about Cadence VIP on the Cadence VIP website.

Software-Defined Coffee Machine

JEngblom — Wed, 26 Aug 2026 14:55:00 GMT

When I go to a hotel, a key component of the experience is the morning coffee. I am a Swede, and I want my coffee strong and plentiful. In most places outside the Nordic countries, this means figuring out the best approximation in the menus of coffee machines.

During vacation this summer, we stayed in a hotel where there was indeed a coffee machine that had to be mastered in order to have a decent breakfast. The first morning, it featured a “large coffee” option that pretty much perfectly fit the bill. However, something happened the second morning…

When we got down to the hotel restaurant, the staff seemed to be doing some simple maintenance of the coffee machines. Getting closer, it became clear that they were doing maintenance that was not so basic – they were actually performing software updates! The result was a brand new menu where the large coffee was gone, forcing me to order an Americano, which turned out to be not quite the same thing.

This offers an inadvertent but clear illustration of how software can change the characteristics of a device – even with exactly the same hardware underneath, the available coffee variants changed. The functionality offered to the user was substantially different by changing the parameters and maybe even the control code, even as the hardware stayed constant.

That is the essence of software-defined vehicles – and indeed software-defined anything. Use a single hardware platform in different ways depending on the software load. It might mean adding new functionality to products that are already out in the world (over-the-air updates, ideally), or it might mean doing different things with the same hardware product to target a new market.

The coffee example here is kind of both. Clearly, it is an example of updating existing hardware with new functionality in the field. But it also shows how the manufacturer found a way to create a branded product for hotels. Using software, it is easy to add the hotel logo to the screen saver. Doing this physically would require manufacturing customer-specific plates or signs. With software, it is just an image file to do some image work.

I also admit loving the image used when the machine was out of order…

Happy coffee cup when it cannot serve any coffee cups. The irony. At least the error message is clear.

When it comes to developing software for a machine like this, a simulation environment can be a real game-changer. Especially one that combines software execution with a simulation of the dynamics of the brewing system. Engineers can see how their code behaves in realistic conditions without waiting for hardware or risking damage to an expensive prototype. Imagine the fun that can be had if you experiment freely with a system that runs a coffee grinder and is able to boil water and steam milk.

Cadence has a full range of products to simulate everything from computer systems to systems dynamics to the world around it.

When the Bug Is in the Waveform, the UALink Story Should Be There Too

Sandeep Grover — Fri, 31 Jul 2026 13:30:00 GMT

Real design debug often ends in the same place: a waveform window full of DUT signals, a failing transaction, and a room of engineers trying to reconstruct what the protocol really did.

This is not a niche problem. It is one of the most common patterns in complex SoC and protocol bring-up. Logs, checkers, scoreboards, and coverage all matter, but when the bug becomes subtle, the debug conversation usually moves to the waveform. Designers want to see the DUT. Verification engineers want to see protocol intent. The hard part is making both views meet in one timeline.

A request disappears. A response arrives late. A credit counter looks suspicious. A link state moves at the wrong moment. Everyone can see the signals, but the real question is still open: which protocol event caused this behavior, and where did the packet actually go wrong?

The mass problem is not waveform visibility. Designers already have visibility. The problem is that raw visibility is not the same as protocol understanding.

The Debug Scene We All Know

Picture a late bring-up failure. The test times out after a transaction that looked legal at the top level. The first error message is not enough. The team loads resets, clocks, interface pins, internal state, VIP signals, and selected DUT hierarchy. The waveform has everything, but it does not explain itself.

Someone now has to decode fields by hand, jump between log timestamps and waveform cursors, remember protocol rules, and keep a mental model of the packet as it moves through the stack. One missed tag, credit class, sequence number, or state transition can send the debug down the wrong path.

Where Waveform Debugger Changes the Story

Waveform Debugger (WD) changes this from a signal-hunting exercise into a protocol story. The VIP already understands the protocol: callbacks, fields, ports, layers, credits, state, and packet movement. WD brings that intelligence into the waveform as time-aligned transaction streams.

The designer still sees raw RTL behavior. The verification engineer still sees protocol meaning. But now both are looking at one correlated debug view. Instead of asking, “Which signal transition maps to this protocol event"? the team can ask a better question: “What happened to this packet at each layer"?

A UALink Example: One Transaction, Four Layers

UALink makes this need very clear because a single transfer naturally crosses multiple layers. A transaction may begin at UPLI as intent: a read, write, atomic, or response with tags and credit context. TL turns that into 64-byte flits. DL packs data into 640-byte flits with headers, CRC, sequencing, and replay behavior. PHY carries the activity through lanes, FEC, alignment, and link behavior.

Without Waveform Debugger (WD), the user may bounce between VIP logs, packet tracker output, register dumps, and raw waveforms. With WD, the same debug becomes a time-correlated path: UPLI intent, TL packing, DL flit movement, PHY activity, and DUT signal behavior around each step.

Why the VIP Side Is the Right Place

The DUT owns the implementation, but the VIP owns protocol interpretation. That is why Waveform Debugger (WD) is powerful from the VIP side. It does not replace the waveform. It makes the waveform more useful by adding the protocol lens that the designer otherwise has to reconstruct manually.

That lens matters in real customer debug, where the issue is rarely “I cannot see the signal.” The issue is usually “I can see too many signals, and I do not know which transition matters.” WD helps separate noise from meaning: which transaction is this, which layer touched it, which port did it use, and what happened just before the failure?

The pitch is simple: Waveform Debugger does not ask designers to leave their natural debug environment. It brings VIP protocol intelligence into that environment.

The Takeaway

Waveform debug is not going away. It is where designers correlate evidence, challenge assumptions, and finally understand what went wrong. The opportunity is to make that environment smarter.

Real design debug is collaborative. A protocol-aware waveform gives RTL, VIP, and testbench owners a shared object to reason about. That is the difference between visibility and productivity: visibility shows everything; productivity shows the right thing at the right time.

Waveform Debugger turns VIP from a checker that reports protocol behavior into a debug companion that explains protocol behavior in the waveform. It connects packet flow, register state, and DUT signals in one timeline. For real design debug, that is the difference between staring at transitions and following the story.

Explore UALink Debug with Cadence

Cadence UALink VIP Waveform Debugger is designed for exactly this challenge, bringing protocol-aware, flit-accurate, and cross-layer visibility directly into the waveform. By connecting activity across UPLI, TL, DL, and PHY on a common timeline, it helps engineers move faster from a visible failure to an understood root cause. To discuss how it fits your verification environment, contact Cadence Support or visit the Simulation VIP for UALink product page. You can also explore Cadence Simulation VIP solutions for broader protocol VIP support.

The waveform already has the truth. Waveform Debugger helps it tell the protocol story.