Cadence Functional Verification

Serial Wire Debug (SWD) Protocol: Efficient Debug Interface for Arm-Based System

Divya Chawla — Fri, 06 Mar 2026 12:00:00 GMT

Modern embedded systems are becoming increasingly compact, power efficient, and feature rich. As SoCs integrate more functionality, developers need reliable debug access without increasing pin count or board complexity. Serial Wire Debug (SWD) addres...(read more)

Breaking Down UPLI: A Protocol-Level Perspective on UALink 200

Jamdagni — Thu, 12 Feb 2026 03:30:00 GMT

In the evolving landscape of high-performance computing, particularly in AI and ML workloads, efficient interconnects between accelerators are critical. The Ultra Accelerator Link (UALink) 200 specification introduces a robust framework for scalable,...(read more)

Validating UPLI Protocol Across Topologies with Cadence UALink VIP

Jamdagni — Wed, 11 Feb 2026 04:30:00 GMT

The UPLI (UALink Protocol Level Interface) is a logical signaling interface that facilitates communication between devices—specifically between originator devices (which initiate transactions) and completer devices (which respond to them). Each transaction comprises a request and a corresponding response, forming a complete communication cycle. Cadence UALink VIP supports various topologies to verify UPLI layer of DUT.

1. Standalone UPLI topology enables users to verify UPLI originators and/or UPLI completers independently and would help user verify protocol layer functionality, bypassing lower layers and saving sim cycles.

Cadence UALink VIP has three flavors to verify the standalone UPLI layer as shown below.

1. DUT originator and VIP completer: In this topology the DUT is responsible for initiating transactions by issuing request messages such as reads, writes, or atomic operations. The verification focuses on ensuring the DUT correctly forms these requests, manages transaction tags for multiple outstanding transactions, and properly processes the corresponding responses returned by the VIP. The VIP acts as a target device that can respond to requests. Passive originator VIP agent receives and validates the format and legality of the Requests from the DUT. As a completer, the VIP must generate and transmit a valid response for every request it receives, as all requests require a response. The VIP can be configured to control responses and their timing to test the DUT's ability to handle many outstanding transactions.
2. VIP originator and DUT completer: The VIP generates a wide range of legal requests (commands) and sends them to the DUT. The VIP can create complex scenarios with multiple outstanding transactions using different transaction tags to stress the DUT's processing capabilities. After issuing requests, the passive VIP agent monitors and validates the responses from the DUT. The DUT must be able to receive and process incoming requests from the VIP. Verification focuses on the DUT's ability to correctly parse different command types, perform the requested memory operations, and generate and send back a valid, properly tagged Response for each transaction.
3. DUT and VIP both has originator + completer pair (combined agent): This setup verifies the DUT's ability to manage simultaneous, bidirectional traffic. The DUT's originator initiates transactions that are received by the VIP's completer, while the DUT's completer receives and processes transactions initiated by the VIP's originator. This configuration can emulate the complex request and response paths found in a switched environment. For example, a request from the DUT's originator might be received by the VIP's completer, which then emulates a switch by re-issuing a new request from its originator back to the DUT's completer. This verifies the DUT's ability to handle the symmetrical, but opposite-direction flows of requests and responses that occur in multi-device UALink pods.

2. Full stack DUT with UPLI: This full-stack topology enables users to verify the entire UALink protocol stack, from the UPLI layer down to the physical layer, in a realistic and integrated environment. It ensures that end-to-end data integrity is maintained across the complete communication path, which is critical for validating correctness in real-world scenarios. By including both the originator and completer roles on both DUT and VIP sides, this setup allows for bi-directional traffic, simulating actual system behavior. Additionally, it helps verify real-time path delays, buffering behavior, and flow control across intermediate layers such as the transport, data link, and physical layers. These intermediate layers play a crucial role in flit conversion, CRC/FEC handling, and serialization, all of which must be validated to ensure protocol compliance and performance.

For more info on Cadence UALink Verification IP, please visit our product page Simulation VIP for UALink.
To know more about UALink specification and its updates, please visit the UALink consortium website.

Cadence VLAB at the Automotive Software Frontier

JEngblom — Tue, 10 Feb 2026 19:30:00 GMT

The VLAB team at Cadence is participating in the 11th Automotive Software Frontier 2026 (ASF 2026) Online event, organized by Impress in cooperation with the Global Research Institute for Mobility in Society Institutes of Innovation for Future Society, Nagoya University, Japan. It is an online-only event that runs from February 4 to March 18, 2026 (free with registration).

The ASF 2026 explores the latest technological trends in the rapidly evolving automotive software domain, including SDV (Software-Defined Vehicles), use of AI, Over-the-Air (OTA) updates, and cybersecurity. Cadence VLAB supports software developers in all these areas and throughout the product life cycle.

VLAB helps software developers with everything from early software porting to a new platform, to debugging and testing software applications, to long-term software maintenance and continuous updating.

The VLAB team will showcase our VLAB product capabilities along with several of our popular automotive virtual development machines (VDMs). VDMs will include RH850, Aurix, J7, and R-Car running various automotive software stacks.

Learn more about Cadence's VLAB and automotive solutions.

Palladium – Power Estimation Efficiency from Days to Minutes

HSV Marketing — Fri, 23 Jan 2026 18:30:00 GMT

In the competitive semiconductor industry, leading innovators consistently set the bar with high-performance and power-hungry silicon. Their latest multi-billion-gate designs exposed the practical limitations of traditional pre-silicon power estimation methods—which were slow, unscalable, and posed risks to fully optimized power and performance for next-generation AI silicon.

A major semiconductor customer used a gate-level power methodology that relied on traditional software tools, limited to a few million gates per job. Estimating power for very large blocks with real application workloads (billion+ gates and billion+ cycles) became impractical with traditional software power estimation methods.

To overcome this, the customer adopted Cadence's Palladium DPA's Hardware-Native Power Estimation (HW-NPE) technology. With this solution, multi-billion-gate designs were analyzed and power estimation performed across a few billion cycles in just hours—accelerating development and reducing power estimation time in a significant way.

Cadence partnered with key customers to measure power consumption and overcame scalability challenges using Cadence Palladium Platform's Hardware-Native Power Estimation (HW-NPE), which leverages specialized hardware and a compiler-based methodology to efficiently measure and analyze application power at the gate level. Key features of HW-NPE include:

Next-Gen Estimation Engine: Capable of processing over a billion gates and performing power calculations for billions of cycles in just hours, delivering a 1000X or more improvement in turnaround time, ideal for the most advanced power-intensive silicon.
High Accuracy: Delivers results with up to 97% accuracy versus sign-off power tools, providing reliable power data for critical power/performance optimization decisions.
Unprecedented Visibility: HW-NPE provides full visibility into power consumption across billions of cycles with real-world applications, something previously impossible.

For example:

App1: A 1.26 billion-cycle application's end-to-end power analysis completed in just 42 minutes.

App2: A multi-threaded, 3.83 billion-cycle application's full power analysis was completed in 85 minutes.

This cycle visibility graph illustrates that users can "get visibility for every cycle amidst billions of cycles of power," a key feature for power profiling.

The Cadence Palladium DPA's Hardware-Native Power Estimation solution is a game-changer, enabling semiconductor innovators to overcome the limitations of traditional methods and achieve ambitious goals. By combining specialized hardware, ultra-fast compile, and power streaming capabilities, the technology enables detailed power analysis previously unattainable for multi-billion-gate designs.

With this newfound efficiency, engineering teams can focus on creating highly power-efficient designs, a strategic advantage that helps meet critical sustainability objectives. This methodology not only solves immediate challenges but also establishes a superior standard for gate-level power estimation in the semiconductor industry.

Success with this technology underscores a core belief that innovation is driven by partnership. The adoption of the Cadence Palladium DPA's HW-NPE helped deliver unprecedented precision in early-stage designs, enabling analysis across billions of cycles. This empowers companies to stay at the forefront of semiconductor innovation and set new standards for rapid, accurate power estimation.

If you're designing billion-gate AI/ML chips or GPU-accelerated applications and need early, accurate power modeling to boost energy efficiency and avoid costly design delays, connect with the Cadence Sales Support Team to discover how Palladium DPA's Hardware Native Power Estimation can help transform your development process

Discover the full story behind this breakthrough—visit the "Customers Stories" section at our Cadence Dynamic Duo Emulation and Prototyping page.

Cadence’s Training and Education Journey Through 2025

ulrike — Fri, 23 Jan 2026 09:30:00 GMT

As we step into 2026, it's a great time to reflect on the most popular blogs and videos from the past year, and to review key developments in education throughout 2025.

In 2025, we published 9 of fresh Training Blogs each unlocking secrets of System Design and Verification.

We’d like to express our sincere appreciation to all our colleagues who consistently contribute insightful and engaging content—sharing valuable teaching and learning resources with the community.

Below, you'll find links to some of the most viewed Blogs, Training Byte videos, Webinars and RAKs.

Among the Blogs, Two Stood Out Like Beacons for Learners Everywhere

The blog about a free online course on Tcl scripting that empowered both beginners and experts which is a creation from the old combined Tcl/Tk course. It has and audio transcript for self-paced learning. In the meantime, the Introduction to Tk training has also been released.

Apart of this there was a blog about a deep dive into the art of debugging with Verisium WaveMiner —a tool that became a hero for engineers chasing efficiency. WaveMiner, part of the Verisium Suite, transforms regression debugging. It pinpoints critical signals and timepoints, visualizes root causes, and dramatically reduces debug effort. For designers and verification engineers, that means higher efficiency and better outcomes. Discover how WaveMiner can revolutionize your workflow.

But the Learning Didn´t Stop There

Videos brought concepts to life like:

Exploring the Protium Flow which gives high level steps to process a design to run on Protium system
Jasper FPV App - this video shows how to run the Jasper tool using a TCL file, steps for design bring-up, and how to perform reset and clock analysis. You’ll also get an overview of FPV App features and learn to use key options in the FPV App GUI.

For Those Who Missed the Live Energy of Our Webinars

You can find the recording of the Training Webinar on Protium X3: Using FullVision for Debugging stored here. Discover how the Cadence Protium X3 simplifies your debugging process in this free technical Training Webinar. We'll show you how FullVision on Protium X3 lets you dump all design signals at once, eliminating the need for multiple recompilations!

Additionally, we offered Streamlining Digital Front-End Design and Verification with Cadence Tools, a two-part, extended webinar series conducted on November 13 and 18.

Day-1:

Plan, Simulate and Debug with Cadence Tools

Day-2:

Regressions, Coverage Integration, and Verification Closure with Cadence Tools

Topics include:

SystemVerilog testbench development
Metric Driven Verification (MDV) and first-phase planning
UVM methodology for building verification infrastructure
Simulation with Xcelium Logic Simulator
Debugging with Verisium Debug
Regression management, metrics, runs, vPlan analysis, and coverage aggregation with Verisium Manager
Real-time progress monitoring and gap analysis
Hardware acceleration and emulation with Palladium Z3
Integrating simulation, formal, and emulation coverage in Verisium Manager

Watch the recordings. You’ll get essential insights as industry experts guide you through a complete, integrated verification flow, from initial design to coverage closure. Learn about interactive features, experience live tool demonstrations, and much more.

Behind the scenes, the ASK portal transformed into something extraordinary. Powered by generative AI, the new ASK Assistant became a trusted guide, answering questions with intelligence and speed.

Rapid Adoption Kits (RAKs) continued to accelerate success, introducing advanced modeling techniques and debugging strategies that felt almost futuristic:

Digital Badges

We should definitely not forget to mention our digital badges as well - symbols of achievement, proof of mastery. Learners proudly displayed them, each one telling a story of persistence and growth, please find some of the newly created here:

And the most popular in 2025

You can find an overview of all available Badges here.

For those craving more, Cadence always opens its doors for "live training" sessions, "Blended" training and flexible online options.

Find Some of Our Most Popular Online Trainings Here:

SystemVerilog Accelerated Verification with UVM

Digital IC Design Fundamentals

Verilog Language and Application

And Here Is Some More Interesting News from 2025

Perhaps the most thrilling development was the launch of Accelerated Learning. Imagine skipping what you already know, diving straight into what matters most, and reaching your goals faster than ever before. That dream became reality end of 2024, this option has been added to many more trainings during 2025, setting the stage for even more innovation in 2026. A small choice of trainings for which this option is available:

Thank you for your incredible commitment! Let’s make the upcoming year a time of bold ideas and meaningful achievements together.

Contact Us

For any questions, general feedback, or even if you want to suggest a future blog topic please leave a comment in the Cadence Community Forum. You can also subscribe to the blog series to stay up to date about new trainings and training videos available at our Cadence Training site.

News from Cadence ASK Portal

Race to First-Pass RTL: Improve PPA targets using Stratus™ HLS

Don’t Let Bugs Slip Through Your RTL Design!

Training Insight: Unlocking the Power of the Xcelium Logic Simulator

Smarter Chips, Faster Checks: GravityXR Leading the XR Verification Shift

Faster and Intelligent Customer Case Resolution with Cadence ASK Portal

Virtual Platforms Keynote at RAPIDO 2026

JEngblom — Fri, 16 Jan 2026 17:00:00 GMT

Jakob Engblom from Cadence will be presenting a keynote at the RAPIDO (Rapid Simulation and Performance Evaluation for Design) workshop at the HiPEAC 2026 conference. The keynote title is "Virtual Platforms for System Architecture, Development, and Test" and it will draw on his long experience with virtual platforms in automotive and embedded.

Virtual platforms, virtual prototypes, and adjacent simulation solutions are used throughout the life cycle of a system. From initial architecture, through to hardware and software implementation, validation, and eventually long-term maintenance.

Different abstractions and model types will be used at different times for different purposes. In general, solving a particular problem will involve integrating a range of models from different domains. The real world is complex and multifaceted, and our simulation solutions will necessarily reflect this. There is no single true model that makes sense across the entire life cycle.

The RAPIDO workshop has been running since 2009, and this year's edition takes place as part of the HiPEAC 2026 conference in Kraków, Poland, from January 26 to 28. RAPIDO is on January 27. See you there!

PSS Randomization Semantics and Numeric Expressions

OK202502201742 — Thu, 15 Jan 2026 23:00:00 GMT

Understanding how PSS defines numeric expressions—and how Perspec supports these rules is important when writing constraints that involve mixed types, limited bit widths, or signedness to make sure you get exactly what you meant and might save you debugging time.

The definition of numeric expression semantics is in the PSS 3.0 LRM, sections 8.7 (Expression Evaluation) and 8.8 (Type Conversion Rules). These rules precisely define how operand bit widths are determined, how signedness is propagated, and how overflows are handled.

Perspec’s support for the PSS randomize (procedural randomization) adheres to these standard rules. In other cases, support does not yet fully conform to the PSS LRM, but future updates will bring it into alignment.

The following examples illustrate how PSS randomization semantics work, how Perspec applies them today in PSS randomize, and how users can make their intent explicit when needed.

All the examples in this blog can be just copied into a PSS file and solved by Perspec.

Example 1: Operands with a Specific Bit Width

This example demonstrates how PSS evaluates expressions involving operands of the same type when that type has a specific bit width.

import std_pkg::*;

component pss_top{

struct S {

rand bit[2] a, b, c;

}

action test {

exec post_solve {

S my_struct;

// Call randomize explicitly on the struct instance

randomize my_struct with {

my_struct.a + my_struct.b == my_struct.c;

my_struct.a != 0;

my_struct.b != 0;

}

// Print the randomized values

print ("Randomized values: a=%d, b=%d, c=%d\n",my_struct.a, my_struct.b, my_struct.c);

}

According to the PSS standard rules:

The expression a + b is evaluated using the maximum bit width of its operands.

Since both a and b are bit[2], the result is also bit[2].

Arithmetic overflow is therefore possible and well-defined.

For example:

a = 3, b = 3 → a + b = 6, truncated to 2 in 2 bits.

When this struct is randomized with PSS randomize, Perspec applies exactly these standard semantics. As a result, valid solutions include combinations such as:

a=3 b=3 c=2

a=2 b=3 c=1

a=3 b=1 c=0

If your intent is instead to treat the computation as a wider (for example, 32-bit) operation, this can be made explicit using a cast:

randomize my_struct with {

my_struct.a + my_struct.b == (bit[32])my_struct.c;

my_struct.a != 0;

my_struct.b != 0;

}//randomize

Or, more explicitly:

randomize my_struct with {

(bit[32]) my_struct.a + (bit[32])my_struct.b == (bit[32])my_struct.c;

my_struct.a != 0;

my_struct.b != 0;

}//randomize

By making the bit width explicit, the constraint behavior becomes unambiguous and independent of automatic type propagation rules.

Example 2: Mixed Bit Widths in an Expression

Consider a constraint that mixes operands of different bit widths:

import std_pkg::*;

component pss_top{

struct S {

rand bit[32] a, b;

rand bit c;

}

action test {

exec post_solve {

S my_struct;

// Call randomize explicitly on the struct instance

randomize my_struct with {

my_struct.a + my_struct.b= my_struct.c;

}

// Print the randomized values

print ("Randomized values: a=%d, b=%d, c=%d\n",my_struct.a, my_struct.b, my_struct.c);

}

Per the PSS standard:

The expression is evaluated using the largest bit width among the operands, which is 32 bits.

The result of a + b is therefore a 32-bit value.

The 1-bit variable c must match the truncated result (either 0 or 1).

When this struct is randomized with PSS randomize, Perspec correctly produces values such as:

large 32-bit values for a and b

c equal to the least significant bit of their sum

If your intent is to restrict a and b to small values (for example, to mimic a narrower arithmetic model), this intent should be expressed explicitly:

randomize my_struct with {

(bit[32]) my_struct.a + (bit[32])my_struct.b == (bit[32])my_struct.c;

my_struct.a in [0..1];

my_struct.b in [0..1];

}

This makes the constraint semantics clear and avoids relying on implicit truncation effects.

Example 3: Signed Variables and Unsigned Range Bounds

This example illustrates how signedness is determined in set membership constraints.

import std_pkg::*;

component pss_top{

struct S {

rand int a;

}

action test {

exec post_solve {

S my_struct;

// Call randomize explicitly on the struct instance

randomize my_struct with {

my_struct.a in [0..0xffffffff];

}//randomize

// Print the randomized values

print ("Randomized values: a=%d", my_struct.a);

}

According to the PSS rules:

The presence of an unsigned operand (the literal 0xffffffff) causes the entire expression to be evaluated as unsigned.

The signed variable a is therefore treated as an unsigned 32-bit value for the purpose of this constraint.

As a result:

Both positive and negative values of a may satisfy the constraint, because negative values become large unsigned numbers.

If your intent is to restrict a to non-negative values, this must be stated explicitly:

randomize my_struct with {

my_struct.a in [0..0xffffffff];

my_struct.a>=0;

}//randomize

Example 4: Range Lists with Mixed Signed and Unsigned Bounds

Consider a range with mixed signed and unsigned literals:

import std_pkg::*;

component pss_top{

struct S {

rand int a;

}

action test {

exec post_solve {

S my_struct;

// Call randomize explicitly on the struct instance

randomize my_struct with {

my_struct.a in [-256..0xff];

}

// Print the randomized values

print ("Randomized values: a=%d\n", my_struct.a);

}

According to the PSS rules:

The presence of the unsigned literal 0xff causes all operands to be treated as unsigned.

The lower bound -256 becomes 0xffffff00 when interpreted as unsigned.

The resulting range is empty, since the lower bound is greater than the upper bound.

An empty range produces a contradiction during procedural randomization.

To express the intended signed range, the bounds should be made explicitly signed:

randomize my_struct with {

my_struct.a in [-256..(int)0xff];

}//randomize

This ensures that all operands are treated consistently as signed values.

Summary and Best Practices

PSS defines precise rules for numeric expression evaluation during randomization. Perspec’s support for PSS randomize (procedural randomize) follows these standard semantics, enabling predictable behavior that aligns with the LRM.

However, when expressions involve mixed bit widths, mixed signedness, or implicit type promotion, the resulting behavior may not always be intuitive at first glance. Therefore, it is recommended to follow the following best practices:

Make bit widths explicit when overflow or truncation matters.

Use casts to control signedness deliberately.

Add explicit constraints when you want to restrict value ranges.

By expressing intent clearly in the code, you avoid relying on implicit rules and ensure that your constraints behave exactly as intended during PSS randomization.

Learn more about Cadence Perspec System Verifier and how it supports PSS.

Don’t Let Bugs Slip Through Your RTL Design!

Ankita Soni — Tue, 16 Dec 2025 10:22:00 GMT

To validate your RTL design, are you still relying solely on simulation? Is there anything else that needs to be done to validate it further?

Simulation has been a cornerstone of hardware verification for decades. Its ability to generate random stimuli and validate RTL across diverse scenarios has helped engineers uncover countless issues and ensure robust designs. However, simulation is inherently scenario-driven, which means certain rare corner cases can remain undetected despite extensive testing.

This is where formal verification adds significant value. Formal doesn’t just simply mathematically analyze the entire state space of your design; it checks every possible value and transition your design could ever encounter, providing exhaustive coverage that complements simulation. No corner case is left unchecked. No bug is left hiding. Together, they form a powerful verification strategy.

Why Formal Matters in Modern Validation

Any modern validation effort needs to take advantage of formal verification, where the apps in the Jasper Formal Verification Platform analyze a mathematical model of RTL design and find corner-case design bugs without needing test vectors. This can add value across the design and validation cycle. Let’s look at some standout Jasper applications: Jasper’s Superlint and Visualize can help designers to quickly find potential issues or examine RTL behaviors without formal expertise. Jasper’s FPV (Formal Property Verification) allows formal experts to create a formal environment and signoff on the IP, delivering the highest design quality and better productivity than doing block level simulation. Jasper’s C2RTL is used to exhaustively verify critical math functions in CPUs, GPUs, TPUs, and other AI accelerator chips.

Jasper enables thorough validation in various targeted domains, including low power, security, safety, SoC integration, and high-level synthesis verification.

“The core benefit of formal exhaustive analysis is its ability to explore all scenarios, especially ones that are hard for humans to anticipate and create tests for in simulation.”

Why Formal? Why Now?

Here’s why formal verification matters now:

No more test vectors or random stimulus. Formal, mathematically, and automatically explores all reachable states; verification can start as soon as RTL is available without the need to create a simulation testbench.
Powerful for exploring corner-case bugs. Exhaustive formal analysis can catch corner case bugs that escape even the most creative simulation testbenches.
Early design bring-up made easy. Validate critical properties and interfaces before your full system is ready.
Debugging is a breeze. When something fails, formal provides a precise counterexample, often with the shortest trace, eliminating the need for endless log hunting.
Perfect partnership with simulation. Simulation and formal aren’t rivals; they are partners. Use simulation for broad system-level checks, and Formal for exhaustive property checking and signoff of critical blocks. Merge formal and simulation coverage for complete verification signoff.

Not Sure Where to Start? We’ve Got You Covered!

If you’re new to formal, start with Cadence Online training like the Jasper Formal Fundamentals Training. Whether you’re a designer, verification engineer, or just curious about formal, this course gives you hands-on experience with formal verification.

After taking the Jasper Formal Fundamentals Course, you’ll be able to:

Build a complete formal verification flow from spec to signoff.
Write efficient, reusable SVA properties for formal tools.
Set up, run, and analyze formal results with confidence.
Understand all proof outcomes and debug counterexamples
Handle formal complexities.
Leverage formal coverage basics.

This course gives you hands-on experience with formal verification labs. And don't forget to obtain your digital badge after completing the training!

Jasper University Page: Supercharge Your Formal Skills

Explore Jasper University Page, the ultimate hub for expert-led training, hands-on labs, and industry-recognized certification from Cadence!

Related Trainings

Virtualization, Collaboration, and Software at SDV Europe

JEngblom — Mon, 15 Dec 2025 20:30:00 GMT

The SDV Europe conference took place in Berlin (Germany) last week. It was a meeting of technical experts and business leaders from all over Europe, focusing on the current state of software-defined vehicle (SDV) technology and applications. The conference mixed talks with structured interactive workshops, providing a platform for the exchange of ideas and plenty of time for networking and discussions. It was great fun!

The most important observation is that SDV is not just a buzzword. As a speaker said, "The current message for SDV is 'Let's make it real.'" And making it real requires changes to technology and tools—as well as processes and organizations.

Collaboration

One thing that is clear is that SDV will require much closer collaboration between suppliers and customers. Where traditionally companies would buy a complete point solution for a specific function or subsystem as a physically installable unit, with SDV, the emphasis shifts to software and its deployment on shared physical computers. This changes how deliveries and deliverables are handled—moving towards something much more like traditional IT.

SDV also requires faster collaboration. In a traditional flow, based on requirements and deliverables, making a change to a component can take a considerable amount of time as bureaucracy and project planning get in the way. It is not unusual to hear about software fixes taking many months to get delivered. That does not work in an SDV world.

Instead, as illustrated above, a more agile model can be used where a supplier sends a series of deliverables to the customer and gets feedback to guide the next delivery. This is better, but it still suffers from some friction. In the extreme, we might see companies working together in shared source code repositories.

Note that the fact that we are talking about collaboration between companies for SDV applications shows the maturity of SDV. Successful SDV projects used to require vertical integration inside a single OEM, but today SDV systems are being built from components from both commercial vendors and incorporating open-source software.

Indeed, open source is another hot topic in the automotive industry. Several open-source projects aim to build non-differentiating common software bases for the SDV. However, using open-source code in vehicles requires very careful consideration of licenses.

Virtualization

Virtualization for software development and testing is a key supporting technology for SDVs. You cannot depend on hardware rigs for software testing—they are never available in sufficient amounts, or early enough, or flexible enough. Automotive software developers need to be able to run and test code as soon as it is built, and this can only be realized by using virtualization, i.e., by simulating both the computer systems as well as the environment in which it is operating.

VLAB is commonly used to virtualize the ECU hardware for such setups, allowing the target software to run as-is, interacting with a simulation of the vehicle and the world in which it operates. The virtual test rigs complement the physical test rigs, allowing testing at scale without using physical test rigs except for final testing before release.

In addition, it is not uncommon to virtualize a network of ECUs—for example, zonal controllers alongside their geographical control nodes. Or zonal controllers connected to the vehicle's main "HPC" nodes. Or multiple zones. Or an old-school ECU-rich network. Whatever the architecture of the vehicle happens to be.

Virtualization and collaboration also combine nicely with cloud-based development environments. It is much easier to collaborate on software when new software builds can be tested immediately in the same environment as the build—and using pure software virtualization and simulation definitely makes that much easier than relying on physical hardware test rigs sitting in a lab somewhere.

Artificial Intelligence

There were several talks and discussions on how AI is used to implement vehicle features. For example, using AI to create smart adaptive and learning user interfaces, where the vehicle learns the habits and preferences of the driver/user and, as a result, gets more personalized over time.

AI is also playing a huge role in how the industry is implementing autonomous driving. The original idea was to explicitly program rules into the software stack, but that has been replaced by learning approaches—i.e., teaching AI systems how to drive by example.

Finally, AI is a tool for software developers that creates automotive software, everything from standard copilot approaches to methods that create tests from natural-language specifications. Automotive software development can clearly benefit from developments in the "IT" world at large—keeping in mind the safety requirements that are much stronger in automotive and aerospace compared to your average web application.

Unexpected Discoveries

Any good conference will bring up something novel or interesting or unexpected. In this case, my award for "most unexpected technology" goes to tire intelligence. The key idea is that the tires are the only part of the car that touch the road—and as a result, they can tell you a lot about what is going on.

For example, the current actual friction between each tire and the surface is very useful for ABS brakes and other safety features. It can be done without tire-mounted sensors (TMS), but with TMS, much more precision and many more features are possible. Even a simple thing like tracking the total runtime and wear on a tire helps maintain safety (and enable predictive maintenance for fleets). Software is eating the world—and reaching into every corner of the car, including something so obviously physical as tires.

As an aside, a TMS is the epitome of an automotive-grade electronic component. They need to be reliable in extreme cold and heat, and the batteries inside need to last as long as the tire itself. Nobody would accept having to charge the car tires every week… but we can build these things today!

What Can You Do with an API?

Implementing software-defined vehicles typically involves defining various hardware-independent APIs and accompanying middleware solutions. But which APIs should be made available? And how can the fundamental safety of a vehicle be guaranteed and certified when over-the-air updates and app stores add new software to the existing fleet?

As an example, we discussed the concept of a motion API. In theory, such an API could let an app control where the car is going. It would allow new functionality to be delivered as pure software (just like we have physical aftermarket additions today). One obvious application could be an automated parking app—give the app access to cameras and other sensors, and it will take care of parking your car for you. This already exists, but if we use the "car is a smartphone on wheels" analogy, it seems that there is always a market for slightly better versions of standard functions.

A motion API could also be used for more unorthodox purposes. Imagine a novelty app that lets your car follow you as you walk, like a very large puppy. Big fluffy ears and giant bug eyes are included in the package! It could also enable slightly mad applications, such as an app that burns donuts for you autonomously.

Then reality hit—what would an OEM actually allow, and what would they be legally able to allow? The smartphone analogy is quite useful here, too. While applications can make use of the camera and microphone of a phone, access is usually controlled to some extent. However, when it comes to driving the wireless interfaces, applications are only allowed access to very high-level APIs that maintain the correct functionality of the wireless certification on the phone.

On the topic of software updates, it is also worth noting that there must be room for software growth in the hardware. Memory and processing capacity need to be over-provisioned compared to the needs of the release software, and it makes perfect sense to ship a car with sensors that will only be used in later software releases.

Such discussions are part of the fabric and point of conferences.

Learn more about Cadence VLAB and automotive solutions.

What's New in PSS 3.0? Key Additions to the Portable Stimulus Standard

OK202502201742 — Mon, 15 Dec 2025 05:41:00 GMT

The Portable Stimulus Standard (PSS) Language Reference Manual (LRM) has evolved significantly since its introduction by Accelera in 2018. It has become a powerful language for creating portable and reusable stimulus specifications. The PSS LRM has matured to meet the complex needs of verification workflows while also incorporating essential language general-purpose elements like a robust type system and clear semantics.

This blog explores the additions of the PSS 3.0, released in August 2024, through these two parallel axes, focusing on Cadence Perspec support aspects and highlighting relevant planned additions for the next LRM version: PSS 3.1.

Language General-Purpose Additions
Portable and Reusable Stimulus Aspects
PSS 3.1

Language General-Purpose Additions

Collection of Reference Types

PSS reference types are described in PSS 2.1 already for special modeling types such as components and actions. In PSS 3.0 they get additional enhancement by the ability to declare collections of references. These are polymorphic, meaning that, for example, the same list<ref C> can hold references to component instances of different subtypes of C. The main usage is for storing in advance references to register components and doing read/write operations on them within the exec body.

array<ref C,3>

list<ref C>
array<list<array<ref C,2>>,3>

Perspec supports collections (lists and arrays, including multi-dimensional) of component references from 24.06.

In PSS 3.1 it is expected that it will be possible to declare fields of reference types and also fields of collections of ref types in actions. This approach enhances the user's flexibility by enabling the selection of registers at solve time.

Comments in Template Blocks

Target template exec and function blocks have been supported since PSS 1.0. Previously, all code within the target template was generated. However, there are scenarios where users may want to exclude certain code from generation. The main reason for this is the presence of mustache expressions that users prefer not to evaluate in specific cases.

To address this need, PSS 3.0 introduces the ability to differentiate between code that should be included in the generated output and code that should remain excluded. This is achieved by using {#..#} comments inside the template exec block.

See the following example:

action my_action {

exec declaration C = """

//This comment will appear in the target code.

{#

This comment code.

#}

"""";

}

Perspec has been supporting target template exec code since its early days and supports the new enhancement of {#..#} comments since version 24.11.

“Sub-String Operator” and String Methods

String data type exists in the PSS LRM from version 1.0. In PSS 2.1, string formatting capability was added (similar to C printf()). Strings are usually used for messages and file content, but also for generating statements for the generated C code. However, de facto, it was very hard to use them till PSS 3.0.

In PSS 3.0 the sub-string operator and a few string methods (such as size(), find(), split(), etc.) were added, as well join() and str_from_chars().

For example:

string str = "hello Perspec";
int size_result = str.size(); // 13
list<int> find_all_result = str.find_all("e"); // {1; 7; 11}
int find_last_result = str.find_last("e", 8); // 7
string upper_result = str.upper(); // "HELLO PERSPEC"
string lower_result = str.lower(); // "hello perspec"
list<string> split_result = str.split(" "); // {"hello"; "Perspec"}
list<bit[8]> chars_result = str.chars(); // {104; 101; 108; 108; 111; 32; 80; 101; 114; 115; 112; 101; 99}
string slice_result = str[2..7] // "llo Pe"

Perspec supports all of them starting from 25.08.

Const Parameters

PSS 3.0 supports declaring function parameters as const. This means that the value of such a parameter cannot be modified within the function body. It is mainly useful for parameters of aggregate types, which are passed by handle and therefore can be modified by the function. Declaring such a parameter as const is supposed to guarantee that the content of the aggregate parameter will not be modified upon the return from the function. This will be supported by Perspec in a future version.

Portable and Reusable Stimulus Aspects

Address Space Group

The PSS Core library, introduced in PSS 2.0, provides standard portable functionality and utilities for common PSS applications. This also includes utilities to manage memory allocation in a system. Among those are address spaces, which contain memory regions, allowing actions to claim memory from. Each address space is considered completely disconnected from all others.

However, different IP PSS models may have different usage models for claiming address space storage atoms. Therefore, in PSS 3.0 an address space group defines the union of multiple individual address spaces that share common storage elements. The PSS input model can allocate common storage elements for the exclusive use of certain behaviors. The usage model is determined by the address space trait type, the address space region types, etc.

For example:

component chiplet {

transparent_addr_space_c<subsys_1_trait> mem1; // 4 regions x 8MB, some shareable

transparent_addr_space_c<subsys_2_trait> mem2; // 8 regions x 4MB, some secure

addr_space_group_c mem_group;

exec init_down {

// by being in the same group, the two address-spaces represent the same physical memory:

mem_group.add_addr_space(mem1);

mem_group.add_addr_space(mem2);

}

Perspec supports it from 24.04.

Yielding Control with Cooperative Multitasking

When a yield statement is used in a target exec block or function, it pauses the current block, giving other parallel exec blocks on the same executor a chance to run.

Perspec has supported this functionality from early days, however, as a function (yield ()) rather than a statement (yield). Therefore, from 24.09, yield() has been deprecated, and yield has been introduced.

Enhanced Support for Platform Qualifiers on Function Prototype Declarations

Perspec supports these from 24.10. Deprecations were added for the previous behavior where the restrictions were not enforced to enable backwards compatibility.

Note that these qualifiers existed before PSS 3.0 but were redefined and improved in PSS 3.0.

Behavioral Coverage

Until PSS 3.0, the PSS LRM defined data coverage, covering value ranges and combinations, similar to UVM coverage.

PSS 3.0 adds behavioral coverage, meaning coverage of scenarios. A scenario is defined as one or more actions that are expected to be observed. Perspec has been supporting a proprietary solution called Activity Based Coverage (using monitor actions), which provides the same needs, but with different syntax.

PSS 3.1

The upcoming PSS 3.1 is expected to contain several new features and enhancements, such as: annotations, activity statement enhancements, component instantiation enhancements, core library enhancements (such as ability to share an address claim between overlapping actions, target time communication) and more.

Some of these items are already supported by Perspec, such as:

Initialization of non-rand attributes in action handles: Perspec supports it from 25.03.
Defining component reference fields in actions (Perspec supports it from earlier versions).
Triple-quoted string with mustache notation, in the solve platform. Perspec supports it from 24.03.
PSS annotations have been supported since 22.02 in proprietary format and will soon be enhanced to align with the LRM definition.

With version 3.0, PSS has achieved a level of maturity that enables the language to effectively articulate system-level scenarios while also ensuring the model stability necessary for large teams and long-term design projects.

While staying tuned for the upcoming release of PSS 3.1, check out the PSS 3.0 (and upcoming PSS 3.1) items supported by Perspec. Explore how these can enhance your current code and methodology.

Smarter Chips, Faster Checks: GravityXR Leading the XR Verification Shift

HSV Marketing — Fri, 05 Dec 2025 20:00:00 GMT

As XR technology accelerates, complexity rises—but speed to market remains the ultimate differentiator. GravityXR is setting the standard with the Cadence Palladium Emulation Platform, delivering MHz-level emulation, automated debugging, and comprehensive system-level coverage. This breakthrough approach empowers teams to catch issues early, streamline workflows, and deliver high-quality XR chips with confidence. Discover how GravityXR is transforming verification and shaping the future of immersive technology.(read more)

VESA Adaptive-Sync V2 Operation in DisplayPort VIP

Vaibhav Sirvi — Thu, 04 Dec 2025 01:00:00 GMT

Need for Synchronization

In a computer system, both the GPU as well as the monitor have a certain rate at which they render or update an image, respectively. The rate is nothing but the frequency at which the image is refreshed (updated in the image it shows/displays), usually expressed in hertz, and can vary based on the content displayed on the screen.

Figure 1: Refresh rate requirements under different applications

For both the GPU as well as the monitor, it is mandatory that their rates should be in sync with one another, because when the display's refresh rate is not synchronized with the content's frame rate, then there are two scenarios t can occur and can create undesirable effects for the user:

Scenario – I: When the GPU's frame rate is higher than the display's refresh rate, the user can experience screen tearing, i.e., parts of the screen display different frames at the same time.

Scenario – II: When the GPU's frame rate is less than the display's refresh rate, the user can experience screen stuttering, i.e., the frames will be either repeated or frozen.

Now, to eliminate this, there are two options.

Option – I: The GPU dynamically adjusts its fps to always comply with the display's refresh rate.

Option – II: The display's refresh rate adjusts to the GPU's variable fps.

With Option-I, the GPU will be capped to the display's maximum refresh rate and will not be used to its full extent, which will eventually eliminate screen tearing (Scenario - I), but the same GPU will also be forced to generate higher FPS above its capability to match the display's refresh rate, which will eventually generate screen stuttering (Scenario-II).

With Option-II, the display will always adapt to the GPU's unpredictable fps and will eliminate both screens tearing as well as stuttering.

Till now, we have already been using a similar technology to Option-I known as "V-Sync". But as this technology was not able to solve the problem of screen stuttering, a new technology was developed similar to Option-II, known as "Adaptive Sync," which was developed by VESA.

Modes of Adaptive-Sync Operation

The Adaptive Sync operation is divided into two parts, namely FAVT (Fixed Average VTotal) and AVT (Adaptive VTotal) where VTotal(Vertical Total) represents the total number of horizontal lines in a frame that consists of pixel information.

The FAVT is typically meant for media playback, whereas the AVT is typically meant for games or other applications where the content's frame rate is unpredictable.

During both the operations, the VTotal is changed to indirectly increase/decrease the refresh rate. As the refresh rate is inversely proportional to frame duration, the increase in VTotal/Frame duration decreases the refresh rate and the decrease in VTotal/Frame duration increases the refresh rate. The VTotal is nothing but a summation of blanking lines and active lines (refer Figure – 2.). The active lines are the ones that contain the actual pixel information that will be used to create the image that will be displayed on the screen and the blanking lines are used to share additional information (such as Secondary Data Packets, Mainstream Attributes, etc.) that are related to a frame.

Figure 2: Pictorial representation of Video Frame and Active Video Image

To change the VTotal, the blanking lines are increased/decreased by changing the relative position of Adaptive Sync SDP as described in Figure – 3. This SDP is always sent with each frame before the "Start of Vertical Blanking", resulting in the Actual Vtotal to be the summation of "AS SDP position (blanking lines before AS SDP) + VStart (Vertical blanking lines) + VHeight (active lines)" so that the source could calculate the successive frame parameters such as successive frame's AS SDP position, VTotal and refresh rate.

Figure 3 - AS SDP Transmission Timing

The Adaptive Sync SDP is a secondary data packet sent during blanking regions that contains various header and payload bytes which defines their type and functionality such as its version, mode of operation i.e., FAVT or AVT and the refresh rate transition information whether the transition is bounded (might take more than one frame to achieve target refresh rate) or unbounded (target refresh rate is achieved in single frame boundary) and what will be the constraint (frame duration increase/decrease limit) for the transition during bounded scenario as described in Table-1 and Table-2.

Table 1 - AS SDP Header Bytes
Byte	Bit	Content
HB0	7:0	Secondary-data Packet-ID
HB1	7:0	Secondary -data Packet Type 22h = Adaptive sync
HB2	4:0	Version Number 01h = Version 1 02h = Version 2
	7:5	RESERVED
HB3	5:0	Number of Valid Data Bytes Version 1 00h = No payload data bytes Version 2 09h = Nine payload data bytes
	7:6	RESERVED

Table 2 - AS SDP Payload Bytes
Bytes	Bit	Content
DB0	0	VARIABLE_FRAME_RATE_DISABLE
	1	Adaptive Sync Operation Mode
	2	Adaptive Sync SDP Transmission Disable in PR Active State
	3	Remote Frame Buffer (RFB) Update in PR Active State
	7:4	RESERVED
DB1	7:0	Minimum Vertical Total 7:0
	7:0	Minimum Vertical Total 15:8
DB3	7:0	Target Refresh Rate 7:0
DB4	1:0	Target Refresh Rate 9:8
	4:2	RESERVED
	5	Target Refresh Rate Divider
	6	Successive Frame Duration Increase Configuration
	7	Successive Frame Duration Decrease Configuration
DB5	7:0	Duration Increase Constraint Value in ms Unit
DB6	7:0	Duration Decrease Constraint Value in ms Unit
DB7	7:0	Coasting VTotal 7:0 in PR Active State
DB8	7:0	Coasting VTotal 15:8 in Pr Active State
DB9 through DB31	191:0	RESERVED Read all 0s

Conclusion

The Cadence VIP Model supports both modes of operation for Adaptive-Sync i.e., FAVT(DB0[1] = 1) & AVT(DB0[1] = 0).

During FAVT mode of operation, in case of bounded config the model increase/decrease the frame duration once per frame using the constraint values (DB5/DB6) until the on-panel frame duration matches the Target frame duration (inverted {DB4[1:0], DB3[7:0]}). In case the increase/decrease frame duration is unbounded the TRR is achieved across a single frame boundary.

During AVT mode of operation the model increase/decrease the frame duration to reach minimum or maximum frame duration supported by Sink device. The Source will honor the frame duration constraint in case of bounded transition and in case of unbounded transition the Refresh Rate may transition to minimum/maximum frame duration across single frame boundary.

Learn More

Cadence has a very mature Verification IP solution. Verification over many different configurations can be used with DisplayPort 2.1 and DisplayPort 1.4 designs, so you can choose the best version for your specific needs.
The DisplayPort VIP provides a full-stack solution for Sink and Source devices with a comprehensive coverage model, protocol checkers, and an extensive test suite.
More details available on Simulation VIP for Display Port
For more information on VESA's DisplayPort in general. Visit the official website at vesa.org.
If you have more feedback or need more information, reach out to us.

ONFI 5.2: What’s new in Open NAND Flash Interface's latest 5.2 standard

Shyam Sharma — Wed, 26 Nov 2025 06:00:00 GMT

Non-volatile memories like Nand Flash are key components of most modern system-on-chip (SoC). The I/O speeds and bandwidth of these types of memories are seeing tremendous improvements and advances in the underlying technology are making them increasingly used for a large variety of applications. These applications rely on not just the high density that traditionally has been the main benefit of flash memories, but throughput that can be comparable to DRAMs and other high data rate memory devices. Some of the most used applications of Nand flash devices include mobile/handhelds, data centers, automotive, gaming, and have found applications in memory intensive AI workloads.

NAND Flash

NAND Flash is one of the most popular types of storage technologies. It’s a non-volatile memory where the data is retained even when there is no power supplied to the device. NAND flash technology has evolved over the years to allow for higher density for the same number of memory cells. The initial generation of NAND Flash memory cell only stored a single bit per cell (SLC), which later evolved into multi-level cell (MLC that can store 2 bits per cell) and Triple Level Cell (TLC, where 3 data bits can be stored in each cell). Recent developments have NAND Flash devices using three-dimensional TLC cells and quad-level cells (QLC) to allow for even higher density than a planner TLC device would offer at the expense of additional complexity and cooling challenges. Traditionally, NAND Flash memory devices offered by different memory vendors have all differed in terms of pin interfaces, commands, and timings, to list a few variations.

Open NAND Flash Interface Specification (ONFI) started as an industry initiative to bring standardization to the I/O interface to NAND Flash based devices with more than 100 companies being part of this effort. The first ONFI 1.0 standard was published in 2006. The ONFI Specification has had multiple revisions since then to cater to the needs of higher performance, density, and power efficiency of today’s market.

ONFI 5.2

ONFI 5.2 is the latest generation of ONFI device standard, published in 2024. ONFI 5.2 devices have added several major features over previous generation ONFI standards. Some of the important changes are as follows:

Separate Command Address (SCA)

SCA protocol is a major change for ONFI 5.2 devices. SCA allows Hosts to optimize the command and data scheduling significantly to increase overall available bandwidth. It includes

Separate command/address (CA) and data busses

ONFI 5.2 compliant devices have additional signals for command/address packet (CA[1:0]_x), command/address bus enable (CA_CEy_x_n), and command/address clock (CA_CLK_x). The host can use these to issue a new command to the device while the previous read or program command’s data transfer hasn’t been completed. Allowing the separation of commands and data transfers helps with concurrent command/address (CA) and data traffic improving NAND interface throughput. This is also used in other high-speed memory devices, such as DRAMs.

SCA Protocol Command Set

ONFI 5.2 defines a new SCA Protocol Command Set along with the Conventional Protocol Command Set supported by ONFI compliant devices until v5.1. The SCA Protocol Command Set can include a third cycle for operations such as multi-plane page program, page cache program, multiplane copyback program, etc.

Timing and signal requirements

Other changes in the SCA protocol include new signal value requirements during power on reset initialization and additional timings requirements, such as tWLCEL_CA (CA_CLK low setup to first CE# low after SCA protocol has been enabled) that the host should follow.

Device Trainings

SCA interface Device training for reads, writes and CA bus/training, etc., is recommended for the proper operation of an ONFI 5.2 device.

DC and Operating Conditions for Raw NAND

ONFI 5.2 has higher values for read, program, standby, and active external supply voltage (Vpp). The LUN Array Read and Program current depends on the operating speeds for ONFI 5.2 devices and can be up to 150 mA. The host must account for the additional current requirements while planning for the device power budget.

Cadence VIP offers memory models for all generations of ONFI devices, including the recently released ONFI5.2 model. Cadence ONFI memory model is not only functionally accurate; but it also checks for specification compliance to all host requirements defined in the standard.

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

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

Powering Up Efficiency: A Deep Dive into CXL L0p and its Verification

Rajneesh Chauhan — Wed, 19 Nov 2025 11:49:00 GMT

Compute Express Link (CXL) is revolutionizing data center architecture, with power management emerging as a key area of innovation. Among its power-saving mechanisms, the L0p (Low Power) state plays a pivotal role in reducing energy consumption during periods of low link activity. But what exactly does L0p mean for a CXL link, and how can we ensure its reliable implementation through comprehensive verification?

Understanding CXL L0p: The Path to Power Efficiency

L0p (short for "Low Power") is a specialized sub-state of the L0 operational state in which the CXL link maintains partial lane activity. In this mode, some lanes remain active while the others transition to an electrical idle state. This is achieved by dynamically adjusting the link width—downsizing to use fewer lanes during low demand, and upsizing to utilize more lanes when demand increases. Despite these adjustments, the link remains fully operational within the L0 state, ensuring efficient power management without compromising performance.

How L0p Works

Initiation: Either side (root or endpoint) can initiate a lane width change.
Negotiation: A new L0p ALMP packet is used to send a request (e.g., downsize from x8 to x4).
Acknowledgment: The partner device responds with L0p ALMP ACK or NAK within a defined time (e.g., 1 µs).
Lane transition:
- Downsizing: Inactive lanes send EIOSQ and go to electrical idle.
- Upsizing: New lanes are trained and brought online.
Traffic continuity: Active lanes continue transmitting FLITs during the transition.

The Verification Challenges: Making Sure L0p Always Works

Making sure CXL's L0p feature works perfectly, especially with dynamic link width adjustments, comes with a few tricky parts:

Complex steps and width changes: Entering and exiting the L0p (Low Power) state involves a series of precise operations, now further complicated by the dynamic addition or removal of active data lanes. These transitions must be validated across all aspects of the CXL link—including data handling, link integrity, and physical layer signaling—to ensure seamless and error-free operation.
Power efficiency vs. performance trade-off: It is essential to verify that L0p mode delivers meaningful power savings by adjusting link width, without introducing significant latency or performance degradation during bandwidth ramp-up. This is particularly critical under fluctuating data traffic conditions, where responsiveness and efficiency must be balanced.
Cross-layer coordination: Robust validation is required to ensure that all protocol layers—Transaction Layer, Link Layer, ArbMux, and Physical Layer—operate in harmony during L0p transitions. Any misalignment or delay across layers could compromise link stability or performance.
Fault handling and recovery scenarios: Testing must cover fault conditions such as errors, resets, or unexpected state changes during L0p operation. Special attention should be given to recovery entry and transitions into deeper power states, ensuring that the link can gracefully handle disruptions and resume normal operation without data loss or corruption.

How Verification IP (VIP) Makes Testing L0p Easy

CXL Verification IP (VIP) is a super helpful tool for tackling these challenges:

Configurable L0p scenarios with dynamic link width control: CXL VIP enables engineers to easily configure and execute a wide range of L0p scenarios, including precise control over link width scaling—both downsizing and upsizing. This allows for thorough validation of component behavior during dynamic lane transitions.
Protocol-aware error detection: Equipped with intelligent protocol monitoring, the VIP automatically detects violations in L0p operations, such as incorrect negotiation sequences or non-compliant link width transitions. This significantly reduces manual debugging effort and accelerates issue identification.
Fault Injection during transitions: The VIP supports targeted error simulation during L0p transitions, including injecting unexpected protocol messages or faults during lane reduction or expansion. These tests help assess system robustness and recovery mechanisms under adverse conditions.
Performance and power efficiency analysis: Advanced metrics provided by the VIP allow for detailed analysis of L0p entry/exit latency, link width transition efficiency, and associated power consumption. These insights are critical for optimizing power-saving strategies without compromising performance.
Comprehensive coverage across scenarios: CXL VIP offers exhaustive test coverage for all L0p-related conditions—ranging from varying traffic loads and dynamic link width changes to error recovery paths. This ensures high confidence in the reliability and efficiency of L0p implementation.

Conclusion

By using CXL VIP, teams can confidently build and test the clever L0p power-saving feature, including its dynamic link width capabilities. This means CXL systems will not only be fast but also incredibly energy-efficient for the powerful computing systems of today.

Cadence Functional Verification

Serial Wire Debug (SWD) Protocol: Efficient Debug Interface for Arm-Based System

Breaking Down UPLI: A Protocol-Level Perspective on UALink 200

Validating UPLI Protocol Across Topologies with Cadence UALink VIP

Cadence VLAB at the Automotive Software Frontier

Palladium – Power Estimation Efficiency from Days to Minutes

Cadence’s Training and Education Journey Through 2025

Virtual Platforms Keynote at RAPIDO 2026

PSS Randomization Semantics and Numeric Expressions

Example 1: Operands with a Specific Bit Width

Example 2: Mixed Bit Widths in an Expression

Example 3: Signed Variables and Unsigned Range Bounds

Example 4: Range Lists with Mixed Signed and Unsigned Bounds

Summary and Best Practices

Don’t Let Bugs Slip Through Your RTL Design!

Why Formal Matters in Modern Validation

Why Formal? Why Now?

Not Sure Where to Start? We’ve Got You Covered!

Jasper University Page: Supercharge Your Formal Skills

Related Trainings

Virtualization, Collaboration, and Software at SDV Europe

Collaboration

Virtualization

Artificial Intelligence

Unexpected Discoveries

What Can You Do with an API?

What's New in PSS 3.0? Key Additions to the Portable Stimulus Standard

Table of Contents

Language General-Purpose Additions

Collection of Reference Types

Comments in Template Blocks

“Sub-String Operator” and String Methods

Const Parameters

Portable and Reusable Stimulus Aspects

Address Space Group

Yielding Control with Cooperative Multitasking

Enhanced Support for Platform Qualifiers on Function Prototype Declarations

Behavioral Coverage

PSS 3.1

Smarter Chips, Faster Checks: GravityXR Leading the XR Verification Shift

VESA Adaptive-Sync V2 Operation in DisplayPort VIP

Need for Synchronization

Figure 1: Refresh rate requirements under different applications

Modes of Adaptive-Sync Operation

Figure 2: Pictorial representation of Video Frame and Active Video Image

Figure 3 - AS SDP Transmission Timing

Conclusion

Learn More

ONFI 5.2: What’s new in Open NAND Flash Interface's latest 5.2 standard

Powering Up Efficiency: A Deep Dive into CXL L0p and its Verification

Understanding CXL L0p: The Path to Power Efficiency

How L0p Works

The Verification Challenges: Making Sure L0p Always Works

How Verification IP (VIP) Makes Testing L0p Easy

Learn More