Verification

From Pacemakers to ADAS: Verifying Systems Before Tapeout

2026-07-07T14:30:00Z

Imagine discovering a critical bug in a heart pacemaker, not after deployment, not during final qualification testing, but months before the chip itself exists.

At first glance, that sounds impossible. After all, how can engineers validate a system that has not yet been manufactured? Yet this question sits at the center of modern semiconductor development, where the challenge is no longer simply building silicon. Increasingly, the real challenge is proving that the software, algorithms, interfaces, and system behavior will function correctly long before the first wafer reaches the fab.

As systems become more software-defined, the traditional development model is being pushed to its limits. Medical devices, automotive safety systems, and intelligent robotics platforms all depend on increasingly sophisticated SoCs that integrate hardware, firmware, operating systems, communication stacks, sensors, and application software. Waiting for first silicon before beginning meaningful validation is no longer practical. Development cycles are too short, software stacks are too large, and the cost of finding problems late in the process is simply too high.

This shift is driving a new approach to verification: one that enables software bring-up, system validation, and large-scale testing months before physical hardware is available. Platforms such as Cadence Palladium Emulation System and Protium Enterprise Prototyping System are helping engineering organizations make that transition by allowing teams to validate complex systems earlier, iterate faster, and reduce risk throughout development.

Different Industries. The Same Verification Challenge.

A pacemaker.

An ADAS controller.

A humanoid robot.

At first glance, they seem to have little in common.

One monitors heart rhythms.

Another helps prevent vehicle accidents.

The third navigates the physical world through sensors, perception, and motion control.

Yet beneath the surface, they share the same engineering reality. All three depend on increasingly sophisticated SoCs that combine hardware, firmware, operating systems, communication interfaces, sensor processing, and application software.

And all three must answer the same question:

How do you validate system behavior before the hardware exists?

Traditional simulation remains essential, but as designs grow larger and software stacks become more complex, simulation alone often becomes the bottleneck. Teams need environments that can execute real workloads, run longer test scenarios, and support software development months before first silicon arrives.

That is where hardware-assisted verification changes the equation.

When a Pacemaker Needs Years of Confidence

Consider a modern implantable cardiac device. The algorithms inside these systems continuously analyze physiological signals and make decisions that directly impact patient safety. Testing them is not simply a matter of running a handful of unit tests. Engineers must evaluate thousands of signal variations, operating conditions, and edge cases to build confidence that the system will behave correctly over years of operation. For many organizations, the challenge is compounded by the fact that relatively small hardware teams must support large, globally distributed software organizations working on multiple product variants simultaneously.

In these environments, the bottleneck is often not engineering expertise but access to realistic hardware platforms. Cloud-based prototyping environments help remove that constraint by allowing software teams to begin algorithm validation, firmware development, and long-duration testing long before silicon becomes available. Instead of compressing validation into the final stages of development, teams can start earlier, test longer, and uncover issues when they are far less expensive to fix.

ADAS: Where "Almost Correct" Is Not Good Enough

The automotive industry faces a different but equally demanding challenge. Advanced Driver Assistance Systems (ADAS) must interact reliably with sensors, communication networks, safety mechanisms, and vehicle control systems while operating under strict functional safety requirements. Here, verification is not simply about proving that software runs correctly. It is about proving that the entire system behaves correctly under realistic operating conditions.

A software model may suggest everything is working as intended, but real-world behavior is often influenced by interface timing, protocol interactions, and system-level effects that only emerge when hardware and software execute together. This is why many automotive teams use emulation platforms to perform large-scale hardware verification and regression testing before transitioning to hardware-accurate prototyping environments for software validation. The goal is not merely faster execution. It is confidence that the complete system will behave as expected when exposed to real interfaces, real workloads, and real operating conditions.

Accelerating the Learning Loop in Robotics

Robotics introduces yet another layer of complexity. Every movement a robot makes depends on a constant stream of data flowing through sensors, vision systems, accelerometers, motion controllers, and software algorithms. What appears effortless from the outside is the result of thousands of iterative development cycles. A robot attempts a movement, fails, the software is adjusted, and the process repeats. Innovation depends on how quickly teams can complete that loop.

Traditional simulation often becomes a bottleneck because realistic robotics workloads require long-running execution and continuous interaction between hardware and software. Hardware-assisted verification environments allow engineers to run larger workloads, validate software against realistic hardware behavior, and iterate faster without waiting for physical silicon. The result is not simply accelerated verification, it is accelerated learning, which often becomes the difference between a promising concept and a viable product.

The Bigger Shift: Verification Is Becoming a Continuous Workflow

Across all three industries, the most important transformation is not technological. It is organizational. Historically, software teams waited for hardware. Today, software development often begins months before silicon arrives. Historically, validation happened late in the project schedule. Today, it starts much earlier and continues throughout development. Historically, verification resources were tied to physical labs and limited infrastructure. Today, cloud-enabled environments allow globally distributed teams to access sophisticated verification platforms from virtually anywhere.

This shift is changing how engineering organizations operate. Small hardware teams can support much larger software organizations. Verification scales more effectively with growing design complexity. Development no longer stalls while teams wait for physical hardware to arrive. Most importantly, organizations gain confidence earlier in the lifecycle, when design changes are easier to make and risks are easier to manage.

Why This Matters More Than Ever

As semiconductor systems continue to grow in complexity, this capability is becoming increasingly important. Medical devices are becoming smarter. Vehicles are becoming more autonomous. Robots are becoming more capable. Every advancement introduces more software, more interfaces, more sensors, and more opportunities for failure. The traditional approach of waiting for silicon before validating complete system behavior simply cannot keep pace.

The organizations pulling ahead are not necessarily those building the most advanced chips. They are the ones finding ways to validate reality earlier. They are reducing iteration cycles, enabling hardware and software teams to work in parallel, and creating development environments that closely mirror real-world operation long before tapeout.

That is why hardware-assisted verification platforms such as Palladium and Protium matter. They are not simply tools for running tests faster. They are helping redefine when validation happens, how teams collaborate, and how confidence is built throughout the development process.

Final Takeaway

The most compelling lesson from mission-critical semiconductor development is surprisingly simple: the earlier you can validate reality, the fewer surprises you encounter later. Whether the product is a pacemaker, an ADAS controller, or a humanoid robot, the objective remains the same: find issues earlier, validate longer, and move faster without sacrificing confidence.

For engineering leaders navigating increasingly complex SoC development, that may be one of the most important competitive advantages emerging in modern verification.

Want to hear the full discussion?

Click here to listen to the complete discussion by Lance Tamura, product management director and see how leading teams are accelerating software and system validation before first silicon.

DFI 6.0 Key Highlights of the Latest DFI Specification

2026-07-07T09:23:00Z

The DDR PHY Interface (DFI) protocol specifies the signals, timing parameters, and configurable options necessary for the transfer of command information and data across the DFI, facilitating communication between the DDR memory controller (MC) and the DDR PHY (PHY). Programmable parameters are system-defined or provided by either the MC or PHY and are set within the MC and/or PHY as required. The DFI 6 protocol is applicable to DDR5, DDR5 RDIMM, DDR5 LRDIMM, DDR5 MRDIMM, LPDDR5, LPDDR6, and HBM4 DRAM technologies.

DFI 6.0.1 (also referred to as DFI 6.0 in the rest of the blog) is the latest standard of the DFI specification. It removes support for earlier DDR/LPDDR generations, adds support for LPDDR6 and HBM4, adds/modifies low-power features, reorganizes WCK and memory-error handling, removes the disconnect protocol, and adds support for 1:3 and 1:6 DFI ratios.

Highlights of the DFI 6.0 standard (as compared to DFI 5.2):

Supported Memory Standards

DFI 6.0 narrows the legacy scope and re-centers the specification on newer memories, while adding explicit support for LPDDR6 and HBM4. DFI 6.0 also removed DDR/2/3/4 and LPDDR/2/3/4 support that were supported until DFI 5.2 specification.

DFI 6.0 includes LPDDR6 and HBM4 while describing various DFI bus operations like CA bus mapping, functional-use sections, and figures for specific device timing.

Command Bus Signal Naming Change

The command/address signaling was updated in DFI 6.0 from a dfi_address in v5.2 to a dfi_cmdaddr to better align with the current protocols. There is no functional impact of this change. While DFI 5.2 describes CA mapping onto the dfi_address bus, including detailed mapping text for LPDDR2/3/4/5 and DDR5, in DFI 6.0, the contents and functional timing examples refer to mapping the CA bus to the dfi_cmdaddr bus, and the LPDDR6 timing figures explicitly use dfi_cmdaddr fields such as dfi_cmdaddr_p0[3:0] and dfi_cmdaddr_p1[3:0]. DFI 6.0 also adds command bus enable dfi_cmd_en, to allow selective command sampling that can be used for runtime power optimization for command path.

Disconnect Protocol Removed

DFI 5.2 includes support for the “disconnect protocol” that can be used to break up a handshake between two DFI signals. This information is conveyed through the dfi_disconnect_error signal. DFI 6.0 doesn’t have any explicit “disconnect protocol”. However, DFI6.0 does allow using existing handshake signals in a different way to allow for ending early.

Error Handling Reorganized and Expanded

DFI 6.0 presents error reporting in a more explicit memory-oriented structure than DFI 5.2. DFI 5.2 specification includes an “error interface” and an “error signaling” section.

In DFI 6.0, the contents include “memory errors/interrupts” under the command interface and a dedicated “memory error/interrupt reporting” chapter with explicit examples for dfi*errmode = 0 and dfi*errmode = 1, as well as command, write-data, and read-data error timing parameters.

Low-Power and Sleep Enhancements

The DFI 6.0 added and modified low-power features. DFI 6.0 adds explicit top-level status and functional use sections for sleep, including “sleep request protocol,” and specifically calls out corrections to the frequency change and sleep protocols. DFI 6.0 also removed the disconnect protocol from all handshakes

By contrast, 5.2 has low-power-control handshaking and frequency-change sections, but it does not have a standalone top-level sleep section in the table of contents.

Frequency Ratio Support Expanded

DFI 5.2 matched-frequency and frequency-ratio systems include 1:2, 1:4, or 1:8 ratios, and their figures show 1:2 and 1:4 phase definitions. DFI 6.0 added support for 1:3 and 1:6 DFI ratios. All ratios are optional, and what is supported is an implementation decision.

Data Path Extensions

DFI 6.0 adds new capabilities to data path, which includes:

Write data parity (HBM4)
Read data parity along with valid separation (HBM4)
Data severity signaling (rddata_sev) (HBM4)
Expanded ECC coverage (HBM4 + LPDDR6)

These improvements align with the reliability requirements for HBM4 and LPDDR6-based memory subsystems.

Legacy 3DS Content Removed with Older DDR Support

DFI 5.2 contains a dedicated “3DS stack support” section, including “3DS addressing with dfi_cid and dfi_cs for DDR3” and “for DDR4.” DFI 6.0 no longer supports dfi_cid and dfi_cs pins as the standard removes DDR3 and DDR4 support.

Here is a tabular summary of the differences between DFI 5.2 vs DFI 6.0 standard:

Feature	DFI 5.2	DFI 6.0
3DS stack pin support	Yes	No (no separate dfi_cid)
Frequency ratio support	include 1:2, 1:4, or 1:8 ratios	include 1:2, 1:3, 1:4, 1:6 and 1:8 ratios
Power states	No sleep support but does support low-power-control handshaking and frequency-change	adds Sleep Protocol Support
Error handling	Basic	PHY error + data/command split + severity
Data reliability	ECC/CRC/DBI	Added HBM4 Parity/severity
Command bus signal naming change	dfi_address-centric description	dfi_cmdaddr-centric description
Supported memory standards	No support for LPDDR6 and HBM4. Supports DDR/2/3/4/5 and LPDDR/2/3/4/5.	Added LPDDR6 and HBM4 support and dropped DDR/2/3/4 and LPDDR/2/3/4 support.

Cadence provides DFI Memory Controller, PHY, and monitor Verification IP for all generations of DFI standards that work with all of the recent generation of DRAM devices like LPDDR4/LPDDR5/LPDDR6, DDR4/DDR5/DDR5 DIMM, HBM3/HBM4, and GDDR6/GDDR7. Cadence also offers industry-leading VIPs for all generations of DRAMs and non-volatile (Flash/cards) memory solutions.

Reach out to Cadence Verification IP experts at talk_to_vip_expert@cadence.com

More information on Cadence DFI VIPs is available at Cadence VIP DFI VIP Website, and Cadence's offered memory models can be found at Cadence Memory Model Website.

UALink Under the Hood: Why Full-Stack Verification Wins

2026-07-06T06:52:00Z

Inside the UALink stack: How 640 bytes travel from intent to wire, and why full-stack verification catches what layer testing misses.(read more)

NVMe 2.0 Explained: What’s New and Why It Matters

2026-07-01T11:18:00Z

Non-Volatile Memory Express (NVMe) has become the dominant protocol for high-performance storage across client SSDs, enterprise drives, and hyperscale data centers. With NVMe 2.0, the specification expands beyond traditional block-based SSD access with new command sets, broader media support, improved transport organization, and enhancements for modern deployments. This post explores what is new in NVMe 2.0, why these additions matter, and how they impact storage architects, implementers, and verification teams.

Why Was NVMe 2.0 Needed?

NVMe 1.4, while powerful, centered on a largely monolithic base specification - a single large document covering the PCIe transport, queuing model, admin and I/O commands, and command-set behavior together. As the ecosystem expanded beyond SSDs into new domains (computational storage, key-value stores, zoned namespaces), the single-spec model became unsustainable:

Specification bloat: Adding every new feature to one document made it unwieldy for implementers who only needed a subset.
New transport needs: NVMe was no longer PCIe-only. Fabric transports such as RDMA and TCP had grown important enough to require separate, dedicated NVMe transport specifications.
Diverse command sets: As NVMe evolved, emerging command sets such as Zoned Namespaces (ZNS) and Key-Value (KV) storage required independent specifications and lifecycle management rather than being maintained as extensions within a single evolving specification family.
Industry velocity: Cloud, edge, automotive, and AI/ML workloads demanded faster iteration on specific features without revising the entire specification.

Some Key Enhancements in NVMe 2.0

1. Modular Specification Architecture

NVMe 2.0 breaks the monolithic spec into a family of focused documents:

Document	Purpose
NVMe Base Specification	Core architecture, admin commands, queuing model
NVMe Command Set Specifications	NVM (block), ZNS, KV command sets - each independent
NVMe Transport Specifications	PCIe, RDMA, TCP - each independent
NVMe Management Interface (NVMe-MI)	Out-of-band device management

Why it matters: An implementer building a ZNS SSD over TCP can focus primarily on the Base specification, ZNS command set, and TCP transport specification instead of navigating one large monolithic document. Under NVMe 1.4, a single errata or feature addition required revising the entire specification, coordinating across all stakeholders.
Under 2.0:

A new transport can be standardized as an independent document instead of being folded into one monolithic specification.
A new command set, such as computational storage or other emerging models, can evolve through its own specification.
Spec revisions are scoped - a change to ZNS doesn't require re-review of the NVM command set or TCP transport.

2. Zoned Namespaces (ZNS) - Independent Command Set

ZNS evolved through the NVMe technical proposal process and became an independent command set specification in the NVMe 2.0 family.

Exposes the internal zone structure of flash to the host.
Reduces write amplification and over-provisioning.
Gives the host direct control over data placement.
Result: Higher endurance, reduced write amplification, more predictable latency, and potentially lower cost per GB for suitable workloads.

3. I/O Command Set Independence and Namespace Types

NVMe 2.0 formalizes the concept of I/O command sets as independent, pluggable modules.
Each namespace is now associated with a specific command set identifier (NVM, ZNS, KV).
Controllers can advertise support for multiple command sets simultaneously.
Enables future command sets to be added without revising the base specification.

4. Simple Copy Command

Enables offloaded data copy within a namespace without host-side data movement.
Reduces host CPU and memory usage during copy-heavy tasks such as garbage collection, deduplication, and snapshots.
The device performs the copy operation without requiring the host to read and rewrite the payload data across PCIe.

5. Rotational Media Support

NVMe 2.0 broadens the architecture so that rotational media such as HDDs can be represented within the NVMe ecosystem.
Helps enable a more common NVMe-based command interface across flash and rotational media.
Helps simplify software stacks by using a more consistent NVMe-based interface across different media types.

6. Vendor-Specific I/O Command Sets

NVMe 2.0’s command set model provides a cleaner path for vendor-specific or future command-set extensions.
Vendors can introduce proprietary capabilities while maintaining alignment with the broader NVMe architecture.
Keeps the ecosystem open while allowing differentiation.

7. Persistent Memory Region (PMR) Enhancements

NVMe 2.0 carries forward and refines Persistent Memory Region support.
Defines clearer behavior for host access to controller-side persistent memory.
PMR can be used by software designed to exploit controller-resident persistent memory for applications such as metadata acceleration, journaling, or write-ahead logging.

Who Benefits from NVMe 2.0?

Cloud and hyperscalers: ZNS reduces TCO through lower write amplification and over-provisioning.
Database and KV Stores: Native KV command support reduces unnecessary block-layer translation.
Storage vendors: Modular spec allows focused implementation and faster time-to-market.
Enterprise IT: Modular specifications and command-set flexibility simplify the adoption of new NVMe capabilities while maintaining long-term scalability.
Automotive and edge: Leaner implementations by adopting only the needed command set and transport.

Verification Challenges

NVMe 2.0 adds verification complexity because the protocol is no longer tied to one monolithic specification or one block-oriented command model. A controller may support different combinations of base functionality, command sets, namespace types, transports, multipath behavior, and optional features, so verification must cover both individual features and their interactions.

Command set selection: Ensuring the controller correctly advertises and enables supported I/O command sets such as NVM, ZNS, and vendor-specific command sets.
Namespace association: Verifying that each namespace is mapped to the correct command set identifier and that unsupported commands are rejected with the appropriate status.
ZNS behavior: Checking zone state transitions, sequential write rules, zone append handling, reset behavior, and error cases for invalid zone operations.
Feature interaction: Covering combinations such as Simple Copy, PMR behavior, and rotational media support across different controller configurations.

Cadence’s NVMe Verification IP addresses these challenges with configurable host and subsystem models, protocol checkers, constrained-random traffic, error injection, coverage, and debug support. The VIP helps teams validate NVMe 2.0 features such as command set independence, namespace management, ZNS behavior, PRP/SGL handling, and transport-specific scenarios across IP, SoC, and system-level environments. In addition, the NVMe VIP testsuite provides reusable building blocks that make it easier for users to create targeted verification scenarios, configure traffic patterns, exercise feature-specific behavior, and inject error conditions as needed for their environment. As NVMe evolves toward modular, workload-specific storage architectures, comprehensive verification support is essential for compliance, interoperability, and faster time-to-market.

More information on Cadence NVMe Verification IP is available at Simulation VIP for NVMe | Cadence.

Reach out to Cadence Verification IP experts at talk_to_vip_expert@cadence.com with any questions.

Understanding USB4 Retimers and Their Role in Gen2 and Gen3 - Link Training

2026-07-01T04:30:00Z

USB4 systems rely on retimers to enable reliable high-speed communication across complex topologies where maintaining signal integrity over extended channels is a significant challenge. Retimers act as intermediate elements that restore signal quality at each hop by performing clock and data recovery (CDR) and retransmitting a clean, regenerated signal.

The USB4 link bring-up process follows a structured sequence from initial connectivity to high-speed operation. The process begins with lane initialization, where routers establish connectivity with the link partner through sideband communication. During this phase, the required parameters for link operation are exchanged and configured. Once initialization is complete, the router drives the transition into link training, where the link progresses toward stable high-speed communication.

The retimer operates based on its channel state machine, which follows router lane initialization and link training and performs corresponding state transitions based on link conditions on both sides.

Router: Lane Initialization

USB4 lane initialization is divided into five phases, where routers control link configuration and parameters synchronization across the topology.

Figure 1: Five-stage lane initialization

Phase 1 and Phase 2 – Electrical Initialization: Sideband signaling is used to establish USB4 mode, lane orientation, polarity, and electrical readiness. Retimers forward these signals to maintain continuity across the link.
Phase 3 – Capability Exchange (Router Controlled): Routers exchange capability information such as supported link speeds, lane bonding configuration, and adapter capabilities. During this phase, the retimer does not actively participate in protocol decision-making and remains transparent, forwarding sideband transactions without modification.
Phase 4 – Parameter Distribution (Broadcast RT): Routers distribute final link parameters using Broadcast RT transactions, including link speed and lane configuration. Retimers update their internal configuration based on these broadcasts and propagate them across their upstream and downstream ports to ensure consistency across the topology. When a Retimer detects an LT_Resume Transaction on any USB4 Port, it shall transition to phase 5.
Phase 5 – Equalization (TxFFE Negotiation): Equalization is performed using addressed RT transactions between directly connected link partners. TxFFE parameters are negotiated independently for each segment, allowing per-hop optimization before high-speed training.

Retimers detect the receiver SLOS symbol and begin transmitting CL_WAKE1.X using a local clock once Rx Active is detected. After completing training across all segments and meeting the required clock switch conditions, the retimer transitions from the local clock to the recovered clock. It then stops generating training symbols and begins forwarding the received bit stream, moving the link into steady-state data operation.

Retimers: Channel State Machine

The retimers follow a channel state machine that aligns with the router-driven link initialization and training flow, tracking receiver activity and adapting as the link progresses. They align with the incoming signal and transition toward stable data transfer as training completes. As shown in the figure below, this sequence ensures proper synchronization before steady-state data forwarding.

Figure 2: Retimer channel state machine

CLd (Channel Detect): State where retimers wait for receiver activity and detect the presence of a valid signal on the channel.
Bit Lock: Retimers enter this state once activity is detected on the receiver side. In this state, the receiver achieves clock/data recovery (CDR) and ensures reliable sampling of the incoming data, enabling proper Rx equalization and further link training progression.
Bit Forwarding: In this state, retimers use the recovered clock and forward the received bit stream directly from receiver to transmitter without modifying the data.

Training Sequence Flow: Retimers

The table illustrates the packet flow during link initialization and transition into link training between two routers with two retimers present in the path.

Step	Router A	Retimer 1	Retimer 2	Router B
1	Broadcast RT->	Update->	Update->
2		<-Update	<-Update	<-Broadcast RT
3	LT_Resume->	Forward->	Forward->	Detect
4	Detect	<-Forward	<-Forward	<-LT_Resume
5	SLOS1 ->	CL_WAKE1.1->	CL_WAKE1.2->
6		<-CL_WAKE1.2	<-CL_WAKE1.1	<-SLOS1
7			CL_WAKE1.2->
8		<-CL_WAKE1.2
9	SLOS1 ->	SLOS1 ->	SLOS1 ->	SLOS1
10	<-SLOS1	<-SLOS1	<-SLOS1	<-SLOS1
11	Link Training (forwarding state)	Link Training (forwarding state)	Link Training (forwarding state)	Link Training (forwarding state)

Table 1: Packet flow in retimers

Steps 1 – 2 (RT Broadcast and Update propagation): Router A initiates link bring-up by broadcasting RT packets. Retimers receive these packets and update the information before propagating it toward Router B. The same update flow is mirrored back from Router B toward Router A.
Steps 3 – 4 (LT_Resume handshake and detection): Router A sends LT_Resume to trigger link initialization. Retimers transparently forward this signal, enabling Router B to detect link activity. The acknowledgment follows the reverse path through retimers.
Steps 5 – 8 (CL_WAKE exchange through retimers): CL_WAKE ordered sets are generated by the retimer with each retimer, sending CL_WAKE1 corresponding to its retimer index. This stage ensures link partners are synchronized before progressing further.
Steps 9 – 10 (SLOS1 exchange): SLOS1 ordered sets are transmitted and propagated across both retimers without modification. At this stage, retimers primarily act in forwarding mode, maintaining the integrity of training sequences.
Step 11 (Transition to Link Training): Once ordered set exchanges are complete, all components (routers and retimers) transition into link training. Retimers operate in forwarding mode, directly passing received bits to the transmitter without alteration.

Verification Challenges for the Retimers

Verification of USB4 retimer topologies presents challenges in ensuring the correct propagation of training sequences across multiple segments. Each retimer must receive, regenerate, and forward sequences while maintaining signal integrity and timing alignment.

Retimer identification and topology discovery ensure correct mapping of logical indices across the chain. Any mismatch can lead to incorrect targeting of training transactions.

Lack of proper verification of retimer behavior can lead to link instability or failure in multi-retimer topologies. If such issues are identified post-silicon, time-to-market is impacted due to the additional effort required for debug and re-verification.

Cadence has a mature verification IP solution for the verification of various topologies of retimers in a USB4 design, with verification capabilities provided to do a comprehensive verification of these topologies.

Learn more about Simulation VIP or reach out to our Cadence Verification IP experts for further information.

The Infineon Automotive Ecosystem Summit 2026

2026-06-30T17:30:00Z

The 2026 Infineon Automotive Ecosystem Summit took place in late June at the Infineon headquarters at am Campeon in Munich. The event brought together the ecosystem around Infineon's automotive microcontrollers, with a particular emphasis on software...(read more)

Demystifying Address Translation Services (ATS) in PCIe 6.0

2026-06-23T10:50:00Z

Address Translation Services (ATS) is one of the toughest verification problems to solve as it is the fast lane for PCIe memory access, cutting delays by caching address translations directly on the device. It keeps software behavior consistent across both PCIe Devices and RC Integrated Endpoints, making performance gains simple to adopt.

Key Features updated for ATS

Translation Agent (TA):
- Central entity, which is responsible for translating virtual addresses to physical addresses that validates and returns translated addresses to requesting devices
Address Translation Cache (ATC): Cache within a PCIe Function to store translated addresses
Address Translation and Protection Table (ATPT) – Optional feature contains the set of address translations accessed by a TA to process PCIe requests.
AT Field in TLPs: Indicates whether a memory address in a transaction is translated
Support for Multi-Function Devices: ATS can be implemented per Function
- Shared ATC resources must behave consistently with independent ATCs
Shadow Functions:
- ATS supports Shadow Functions, which share ATC and translation resources with a main Function

Here is a diagram illustrating the interaction flow of Address Translation Services (ATS) in PCI Express:

Translation Request /Completion exchange

Address translation and caching are performed with the help of Memory Request transmitted from ATC to TA. Upon reception of the Translation Request, TA determines whether the translation can be provided to the function and indicates the success or failure of the request by generating a translation completion with the right response status.

Invalidate Request/Completion exchange

When a translation changes, the TA sends an Invalidation Request, so the ATC stays in sync with the ATPT. This request is a MsgD transaction that tells the ATC to remove specific address-range entries.

The Invalidate Completion message includes tags from the original request, so the TA can identify which function finished the invalidate operation.

Page Request/PRG Response message exchange

Page Request helps a PCIe endpoint (like a storage device) to request a page in a specific virtual memory address by transmitting a Msg TLP to RC. To notify a Function that the page request(s) associated with the corresponding PRG has (have) been satisfied with a PRG Response Message is a PCIe Message Request that is Routed by ID back to the requesting Function.

Basic Rules and Requirements

Translation Validity:
- A Function must not issue TLPs with the AT field set unless the address was obtained via ATS. ATC entries must only be populated using the ATS protocol
Ordering and Routing:
- ATS Translation Requests follow standard PCIe routing and ordering rules
Access Permissions:
- Translated addresses must have appropriate permissions (Read, Write)
Consistency:
- Shared ATC implementations must behave as if each Function has an independent ATC. Shadow Functions must be treated identically to their main Function by the TA

Advance requirements with other features

ATS and PASID (Process Address Space ID)

ATS works with PASID to translate a process’s virtual addresses into physical addresses. An ATS Translation Request can carry a PASID to identify the target process address space. The ATS response then returns both the translation and the allowed access rights (Read, Write, Execute) for that PASID.

ATS and IDE (Integrity and Data Encryption)

ATS interacts with IDE to ensure that address translations and memory access remain secure by following all rules mentioned in the IDE section.

Key Interactions:

IDE TLPs and ATS:
- ATS must ensure that translations used in IDE TLPs are valid and not tampered with
- IDE Streams must be configured to reject TLPs with invalid or misrouted translations
Security Enforcement:
- ATS must comply with IDE’s security model, especially when used with Selective IDE Streams, which allow TLPs to pass through switches

ATS and segments

All standard segment rules apply to ATS-related TLPs. This is especially important for Invalidate Request/Completion and Page Request/PRG Response TLPs, since they are Msg TLPs with OHC-A4 and include a destination segment. If these TLPs are IDE encrypted, it must also follow Requester Segment rules, and IDE-specific Segment Base rules.

Randomization considerations

Randomization testing always helps to catch corner case scenarios. The main parameters that can be tested are:

Parameter	Description / Validation Consideration
Address	Overlapping address ranges or duplicate Requester IDs can lead to undefined behavior.
Size	Translation Requests can be random in size, so ATC and ATPT should be initially implemented with sufficient capacity to accommodate variability.
TLP types	Validation should test MRd Translation Requests and Translated Requests of type MWr, MRd, UIOMWr, and UIOMRd.
Exe, Priv	Permissions can be randomly assigned and determine how the responder returns data for a request.
Ordering	Translation Requests can be transmitted with random ordering; corresponding responses must follow specification-defined ordering rules.
PASID	ATS Requests/Completions may include PASID, which can take random values.

ATS verification challenges and solutions

	Verification approach	Challenge
ATS coexistence with other capabilities (e.g., IDE optional)	Verify ATS behavior remains consistent with and without optional capabilities enabled.	Requires multiple test environments/configurations.
ATS testing with and without PASID	Execute ATS flows for each TLP type with PASID off/on and randomized PASID values; check all PASID-related rules.	Rule space increases significantly with PASID combinations.
Reset scenarios clearing ATC (Detect, HotReset, FLR, etc.)	Prove ATC is correctly invalidated after each reset type.	Carefully monitor system behavior before and after reset.
Random Completion Count (TC/VC mapping)	Validate completion distribution/count correctness under randomized TC/VC mappings.	Randomization can make debug harder unless seed/logging is strong.
Negative scenarios marked “undefined behavior”	Define practical verification strategy for undefined-behavior cases.	It is difficult to assert deterministic expected result from spec.

Cadence PCIe VIP verification test suite is built to solve challenges like the ones described above, by delivering a verification solution in terms of test cases and coverage model. It provides a golden reference that can fully verify any specification defined feature by applying randomization and cross feature verification. Our test suite includes self-checks or protocol checks, error injections, checker evaluation, callback verification, user configurable parameters and coverage model to make sure the feature is thoroughly verified. Cadence test suite eliminates the verification gap, and customers can effectively validate their design by using the provided test suite.

PCIe Express VIP Verification testbench architecture

More information:

For more info on how Cadence PCIe Verification IP and TripleCheck VIP enable users to confidently verify PCIe 6.0, see our VIP for PCI Express, VIP for Compute Express Link and TripleCheck for PCI Express
See the PCI-SIG website for more details on PCIe in general and the different PCI standards.
For more details, connect directly with Cadence Verification IP experts at talk_to_vip_expert@cadence.com.

Enhancing Ethernet Security with MACsec

2026-06-22T05:13:00Z

Understanding MACsec in Today’s Ethernet World

Today, Ethernet is being widely adopted across domains ranging from high-performance computing (HPC) and cloud data centers to automotive systems, where security has become a critical requirement. If network security is compromised, sensitive data can be modified, intercepted, or stolen, leading to serious reliability and privacy concerns. Ethernet was originally designed for high-speed data transfer and interoperability between devices. However, traditional Ethernet does not provide built-in mechanisms for securing data traffic, such as encryption or authenticity protection. This is where MACsec comes into the picture. Media Access Control Security (MACsec) helps bridge this security gap by identifying and preventing the security threats at Data Link Layer (Layer 2) of Ethernet communication.

MACsec ensures data confidentiality, integrity, and authenticity for Ethernet communication. MACsec uses the Advanced Encryption Standard with Galois/Counter Mode (AES-GCM), which enables both encryption and integrity protection with high performance. Unlike security protocols such as Transport Layer Security and Internet Protocol Security, which operate at upper layers of the networking stack, MACsec is implemented directly at the Ethernet port level. This allows Ethernet links to be secured transparently at the Data Link Layer without requiring modifications to higher-layer protocols such as IP, TCP, UDP, or application software. MACsec is standardized under IEEE 802.1AE and is widely adopted in systems where secure and reliable Ethernet communication is essential.

Today, MACsec is widely deployed in environments where both high-speed communication and strong security are essential. In cloud data centers and enterprise networks, MACsec helps secure traffic between switches, routers, and servers against unauthorized access and packet tampering. In 5G infrastructure, MACsec protects fronthaul and backhaul communication carrying massive amounts of network traffic. The growing adoption of Automotive Ethernet has also increased the importance of MACsec, where secure communication between Electronic Control Units (ECUs) is critical for vehicle reliability and safety. Similarly, in HPC systems and secure chip-to-chip communication, MACsec provides hardware-level link security while maintaining high throughput and low latency.

Inside a MACsec Frame

Before MACsec protection is applied, a standard Ethernet frame contains the Destination MAC address, Source MAC address, EtherType field, payload, and Frame Check Sequence (FCS). As shown below.

When the frame enters the MACsec processing engine, MACsec modifies the frame structure by inserting a Security Tag (SecTAG) after the Source MAC address and appending an Integrity Check Value (ICV) before the frame check sequence (FCS). As shown below.

Let’s first look at the SecTAG. It carries control and security-related information such as the Packet Number (PN), Association Number (AN), Tag Control Information (TCI), Short Length (SL), and optionally the Secure Channel Identifier (SCI). These fields help the receiving device identify the secure channel, detect replay attacks, and process the frame correctly.

After the SecTAG is inserted, MACsec encrypts the Ethernet payload using AES-GCM. Encryption ensures that sensitive information carried within the Ethernet frame cannot be read by unauthorized devices while traversing the network.

Once encryption is completed, MACsec generates an Integrity Check Value (ICV), which acts as a cryptographic integrity tag appended near the end of the frame. The receiving device uses the ICV to verify that the frame has not been modified or tampered with during transmission.

MACsec inserts a dedicated EtherType value of 0x88E5 after the Source MAC address to identify a MACsec‑protected frame, while the original EtherType is preserved inside the encrypted payload.

How MACsec Secures Communication

Before secure communication begins, both devices must first authenticate each other and establish encryption keys. MACsec uses the MACsec Key Agreement (MKA) protocol to manage this process. MKA authenticates peers using the CAK and derives Secure Association Keys (SAKs) used by MACsec for frame encryption.

The communicating devices share a secret key called the Connectivity Association Key (CAK), which is used by MKA to authenticate peers. Once authentication is successful, MKA derives and distributes Secure Association Keys (SAKs) that are used by MACsec for frame encryption.

After the secure connection is established, MACsec starts encrypting Ethernet frames using AES-GCM. Each transmitted frame also carries a Packet Number (PN) inside the SecTAG. When replay protection is enabled, the receiving device validates the Packet Number to detect duplicated or replayed packets.

That's how MACsec provides data authenticity, confidentiality, integrity, and replay protection.

MACsec Verification with Cadence VIP

With the availability of the Cadence Verification IP for Ethernet MACsec, adopters can start working with these specifications immediately, ensuring compliance with the standard and achieving the fastest path to IP and SoC verification closure. Incorporating the latest protocol updates, the mature and comprehensive Cadence Verification IP (VIP) for the Ethernet protocol provides a complete bus functional model (BFM), integrated automatic protocol checks, and coverage model. Designed for easy integration in test benches at IP, system-on-chip (SoC), and system levels, the VIP for Ethernet helps you reduce the time to test, accelerate verification closure, and ensure end-product quality. The VIP for Ethernet runs on all major simulators and supports System Verilog and e-verification languages and associated methodologies, including the Universal Verification Methodology (UVM).

Ethernet Auto-Negotiation: Enabling Seamless Link Optimization

2026-06-19T11:11:00Z

Ethernet has evolved significantly from 10 Mbps shared media to today’s multi-hundred gigabit high-speed links. One foundational feature that has enabled this scalability and ease of deployment is Auto-Negotiation (AN). Defined in multiple IEEE 802.3 clauses, Auto-Negotiation allows two connected devices to automatically determine the best possible operating parameters for a link, eliminating manual configuration and ensuring optimal performance.

Why Auto-Negotiation Is Required

In early Ethernet deployments, link parameters such as speed and duplex mode had to be manually configured on both ends of the link. This approach led to frequent issues, the most common being duplex mismatch, where one device operates in full-duplex and the other in half-duplex, causing severe performance degradation.

Auto-Negotiation addresses these challenges by:

Automatically selecting the highest common speed and mode: This ensures both devices operate at the best mutually supported configuration
Avoiding configuration errors: Eliminates manual mismatches that can lead to packet loss and poor throughput
Supporting feature compatibility: Modern Ethernet requires negotiation of additional capabilities such as:
- Flow control (pause frames)
- Forward Error Correction (FEC)
- Energy Efficient Ethernet (EEE)
- Link training for high-speed channels
Providing scalability for future standards: As speeds increase, negotiation becomes essential to decide lane counts, encoding, and error correction mechanisms.

In short, Auto-Negotiation ensures plug-and-play interoperability across diverse devices and generations of Ethernet technology.

Auto-Negotiation Clauses and Applicable Speeds

Different IEEE 802.3 clauses define how Auto-Negotiation works for various physical layers and speeds:

Clause	Applicable Speeds/Media	Key Characteristics
Clause 98	MultiGig BaseT1	Classic Auto-Negotiation using Fast Link Pulses (FLPs); negotiates speed and duplex
Clause 37	1000BASE-X (fiber), SGMII	Uses ordered sets instead of FLPs; supports gigabit links
Clause 73	10G to upto 1.6T (KR/CR/backplane)	Advanced AN with base + next pages; supports FEC, link training, multi-lane speeds

Key trend:

Lower speeds → Simple negotiation
Mid speeds (1G) → PHY-specific signaling
High speeds (10G and above) → Multi-stage negotiation with extended capabilities

Top-Level Overview: How Auto-Negotiation Works

At a high level, Auto-Negotiation is a structured handshake between two link partners. The process is similar across clauses, with increasing complexity at higher speeds.

Step 1: Capability Advertisement

Each device advertises its supported capabilities using a structured data format called a link code word (LCW).

In Clause 98: Sent using fast link pulses
In Clause 37/73: Sent using encoded ordered sets

Information is exchanged through base/next pages. Base/next page contains core capabilities:

Supported speeds
Duplex modes (for lower speeds)
Link types (e.g., KR, KX)
FEC support
Advanced speeds (e.g., 25G, 50G)
Link training capability

Step 2: Acknowledgment Handshake

Once a device receives its partner’s base page, it sets an ACK bit and continues transmitting its own advertisement.

Both partners must confirm:

They have received each other’s capabilities
The information is stable (not corrupted)

This ensures synchronization before proceeding further.

Step 3: Extended Capability Exchange (Next Pages)

For modern Ethernet (Clause 73), Auto-Negotiation continues with the exchange of next pages.

These pages are used to:

Negotiate Forward Error Correction (FEC)
Indicate support for link training (clause 72)
Advertise newer speed modes beyond base page limitations

A toggle bit mechanism ensures that new pages are distinguished from retransmissions.

Step 4: Resolution of Link Parameters

A deterministic priority resolution function selects the final link mode based on the common capabilities of both devices.
Typical rules:

Highest speed wins (e.g., 25G over 10G)
Compatible lane configuration selected
FEC enabled only if both sides support/request it

Key Takeaway

Auto-Negotiation is far more than just speed selection is a multi-stage protocol that ensures compatibility, reliability, and optimal operation across Ethernet links. At lower speeds, AN selects which link to use. At higher speeds (clause 73), it also decides how the link operates (FEC, training, lanes).

Conclusion

Auto-Negotiation is a critical feature that underpins Ethernet’s flexibility and backward compatibility. From simple duplex selection in early networks to complex multi-parameter negotiation in high-speed systems, AN has evolved to meet the demands of modern communication.

For engineers working with high-speed Ethernet, especially clause 73, understanding the interplay between base pages, next pages, and the state machine is essential for debugging and ensuring robust link bring-up.

With the availability of the Cadence Verification IP for Ethernet, adopters can start working with these specifications immediately, ensuring compliance with the standard and achieving the fastest path to IP and SoC verification closure. Incorporating the latest protocol updates, the mature and comprehensive Cadence Verification IP (VIP) for the Ethernet protocol provides a complete bus functional model (BFM), integrated automatic protocol checks, and coverage model. Designed for easy integration in test benches at IP, system-on-chip (SoC), and system levels, the VIP for Ethernet helps you reduce the time to test, accelerate verification closure, and ensure end-product quality. The VIP for Ethernet runs on all major simulators and supports SystemVerilog and e-verification languages and associated methodologies, including the Universal Verification Methodology (UVM).

DDR5 MRDIMM: A Transformational Evolution for DDR5 DIMM

2026-06-09T18:00:00Z

DDR5 is the latest generation of DDR server memory capable of supporting data rates of up to 9,200Mbps, which is a huge leap over the previous generation of DDR memories. It is used in a wide variety of applications, with the huge server and data center market being the key driver behind the adoption of DDR5-based memory systems. As systems move towards more CPU cores, bandwidth, and capacity, DDR5 is considered the most widely used DDR memory as compared to the previous generation, DDR4.

DDR memories are typically used as a part of dual in-line memory (DIMM) cards. DIMMs are a JEDEC-defined standard for increasing density and bus width by connecting several individual DRAM memories to a DIMM card. Traditionally, DIMMs can be categorized as Small Outline-DIMM/Unbuffered DIMM (uses just the DRAM memories), Registered DIMM (uses RCD + the DRAM), and Load Reduced DIMM (uses RCD + DRAM + DB).

The Registering Clock Driver (RCD) and Data Buffer (DB) help the RDIMM and LRDIMM with better Command/Clock and Data signal quality and help with Electrostatic Overstress (EOS) and electrostatic discharge (ESD) issues. However, even with these, bringing DDR5 LRDIMMs to support higher data rates has become a challenge beyond 4800Mbps due to issues like clock loading.

To enable DDR5 DIMM in supporting higher speeds like 12,800Mpbs, JEDEC members have produced a new architecture and a new category of DIMMs called Multiplexed Rank DIMM (MRDIMM). This is a paradigm shift for the DDR memories that not only enable DDR5 DIMM to support DDR5 SDRAM's current highest speeds of 9200 but can also allow for higher data rates. Some of the key features for DDR5 MRDIMM Generation 2 are:

For the first time, there will be two sets of clocks within the DIMM, including a Host side clock, which will run at twice the speed of the internal clock on which DRAMs will be operating. This will allow DRAM and DB's DRAM side interface to only require meeting half-rate operating speed requirements.
DDR5 MRDIMM will benefit from being able to support higher densities than traditional RDIMM/LR-DIMM, since it will have twice the number of DRAMs. These DRAMs are connected to support two Pseudo Channels for MRDIMMs, doubling the DIMM capacity.
DDR5 MRDIMM is pin compatible with traditional DIMM, and it can be used in the same DIMM slots that are used for DDR5 RDIMMs.
There is no change to the DRAMs used for DDR5 MRDIMM. DDR5 MRDIMM Generation 2 cards only require the use of new DDR5 MRCD and DDR5 MDB components and will use the same DDR5 SDRAM components.
DDR5 MDB has two DRAM side interfaces named as the A and B sides. It multiplexes DRAM data and sends it to the Host in an interleaved pattern at twice the speed at which it is sampling Data from the DRAMs on its A and B sides.
Unlike traditional DDR5 DIMMs that can only have two Physical Ranks, DDR5 MRDIMM is capable of supporting up to four physical ranks.
While DDR5 MRDIMM is pin compatible with traditional DDR5 RDIMM and follows the same DDR5 protocol. The memory controller and PHY will still need changes to support MRDIMMs, such as changes in the training sequences, handling two sets of DRAMs connected to PS0/PS1, programming of additional RCD/DB Control words, supporting burst with twice the burst lengths, etc.
DDR5 MRDIMM will have multiple generations, with Generation 2 supporting up to 12.8GT/s and Generation 3 supporting even higher data rates.

DDR5 MRDIMM is an evolving standard that is still in progress at JEDEC.

The Cadence memory model for DDR5/DDR5 DIMM aims to support all generations of DDR5 MRDIMM with Cadence DDR5 MRDIMM (including MRCD and MDB) VIPs features tracking JEDEC DDR5 MRDIMM Generation 2 and Generation 3 Specification development.

Learn more about Cadence DDR5 MRDIMM VIP at the Cadence VIP Memory Models webpages and reach out to our Cadence Verification IP experts with any questions.

Controller Memory Buffer (CMB): NVMe 2.0’s On-Controller Memory Feature

2026-06-08T05:18:00Z

Non-volatile Memory Express (NVMe) has become the dominant interface protocol for high-performance storage devices. As workloads demand ever-lower latencies, the NVMe specification has evolved with features that reduce data-path overhead. One such fe...(read more)

Inside Akeana and Cadence’s Secret Sauce for Faster RISC-V Chip Verification

2026-05-26T23:00:00Z

The Nightmare of Chip Testing (And How to Fix It)

Let's be real: designing ambitious new RISC-V chips is cool, but testing them is an absolute nightmare. When you are building crazy complex pipelines and custom instructions, you eventually hit a massive brick wall. Your designs are brilliant, but traditional simulators are too slow to run actual software on them. To catch every glitch before making the physical chip, you need trillions of test cycles. Who has the time to wait around for that while the launch deadline creeps closer?

The crew at Akeana hit this exact roadblock. Instead of crying into their coffee, they teamed up with Cadence Palladium Cloud to speed things up. Here is how they turned a scheduling nightmare into a massive win.

The Backstory and The Big Problem

In just four years, Akeana built a massive tech portfolio. We are talking about everything from tiny edge microcontrollers and smart car brains to data center AI chips. They do way more than basic processor cores; they build the heavy-duty system infrastructure like cache controllers, data highways, and advanced AI engines. But mixing and matching all these parts creates a giant puzzle. Testing individual blocks is easy. Testing how they all interact when running actual operating systems and AI software? That is a different beast. Traditional testing methods could not keep up. Akeana needed a way to test everything at scale without blowing their budget or burning out their engineers.

Enter Cadence Palladium Cloud

Instead of just buying a mountain of expensive new servers, Akeana upgraded their strategy by moving to Cadence Palladium Cloud. This gave them instant access to top-tier hardware acceleration in the cloud, allowing them to subscribe massive emulation computing power exactly when they needed it. No huge upfront hardware costs and no new IT infrastructure to build up. Their engineers just code securely on-site, push the massive workloads to the cloud, and let it rip. Even better, they aligned their emulation models so they could run massive system checks every single night with zero drama.

The Results: Working Like Tech Giants

This partnership turned Akeana into a speed machine, giving them the kind of agile development power usually reserved for trillion-dollar tech giants.

Supercharged tuning: They managed 10 to 15 performance upgrade iterations per month.
Two-day turnaround: They cut the time between writing code and getting system feedback down to just two days.
Running real AI workloads: They ran continuous AI data tests to prove their hardware handles real-world software without breaking a sweat.
Trillions of cycles: By running 24/7 in the cloud, they ran trillions of test cycles. When customers get their tech, it is already battle-tested.

"Using Cadence Palladium Cloud was critical for Akeana to get to high-quality product readiness in a short time. The platform enabled fast development and debug cycles... and provided a cost-effective way to scale."

Your Turn!

If your engineering team is losing its mind trying to validate massive AI workloads or complex chip architectures, stop waiting on traditional simulators. Reach out to the Cadence Sales Support Team to see how Palladium Cloud can save your timeline.

Cadence Announces PCIe 8.0 Verification IP Availability at PCI‑SIG US

2026-05-18T05:17:00Z

At the recent PCI‑SIG Developers Conference US held on May 6-7,2026, Cadence announced the availability of its PCIe 8.0 Verification IP (VIP)—taking another significant step in enabling early, confident adoption of the PCI Express roadmap.

As PCIe continues to evolve to meet the growing demands of AI accelerators, high‑performance computing, and hyperscale data centers, the complexity of verification grows alongside bandwidth. With PCIe Gen8 VIP, Cadence equips customers with a production‑ready verification solution aligned with emerging specifications, helping translate evolving standards into reliable silicon implementations.

Built on a Proven, Scalable VIP Architecture

PCI Express remains the backbone interconnect for modern compute platforms, delivering scalable performance while preserving backward compatibility across generations. Each new generation introduces architectural advances that require equally advanced verification capabilities.

Cadence PCIe Gen8 VIP is built on the same C/C++‑based VIP architecture that has been widely adopted across previous PCIe generations and complementary interconnect standards. This architecture delivers a consistent user experience across protocols and verification environments, while enabling reuse from IP‑level verification through full SoC integration.

The VIP supports both serial and PIPE‑based architectures and maintains protocol behavior consistency across transaction, data link, and physical layers—allowing verification teams to adopt Gen8 with minimal disruption to existing flows.

Supporting System‑Level Verification at Extreme Speeds

PCIe Gen8 extends the PCIe architecture to support significantly higher data rates while preserving core concepts introduced in earlier generations, such as PAM4 signaling, FLIT‑based transfers, and low‑power states. Cadence PCIe Gen8 VIP is designed to validate these capabilities across realistic system configurations.

The VIP supports verification of root complexes, endpoints, switches, and retimers, along with monitor components for serial, pipe interface, and switch topologies, enabling customers to validate complex topologies and interoperability scenarios. Integration‑friendly building blocks, configurable checking, and coverage‑driven flows help verification teams scale from focused IP validation to full system‑level verification.

Enhancing Debug and Productivity

As PCIe speeds increase, observability and debug efficiency become critical. Cadence PCIe Gen8 VIP provides rich debug visibility through protocol‑aware packet tracking, waveform‑based transaction views, and trace‑file correlation across layers.

Complemented by Cadence’s verification ecosystem—including GUI‑based configuration, reusable test suites, and automated verification planning—the Gen8 VIP helps reduce bring‑up time and accelerates convergence toward verification closure.

Moving the PCIe Ecosystem Forward

The announcement of PCIe Gen8 VIP at PCI‑SIG US reflects Cadence’s continued role in advancing the PCIe ecosystem—from early standards participation through customer‑ready verification solutions.

With its combination of early availability, architectural consistency, and system‑level verification focus, Cadence PCIe VIP continues to set the benchmark for PCI Express verification, empowering customers to innovate with confidence as the industry transitions into the PCIe Gen8 era.

For more info on how Cadence PCIe Verification IP and TripleCheck VIP enable users to confidently verify PCIe designs, see our product pages on  VIP for PCI Express and Triplecheck.

Refer to the PCI-SIG website for more details on PCIe in general and upcoming revisions on PCIe 8.0

Reach out to Cadence Verification IP experts at talk_to_vip_expert@cadence.com

VLAB at the MATLAB Expo Japan 2026

2026-05-06T22:05:00Z

The Cadence VLAB team will be part of the Cadence team present at the MATLAB Expo Japan on May 26 in Tokyo. We will be demonstrating how MATLAB and Simulink models can be used to co-simulate with VLAB virtual development machines (VDMs), allowing software to be tested in a virtual hardware-in-the-loop environment.

Virtualized hardware-in-the-loop (HIL), processor-in-the-loop (PIL), and software-in-the-loop (SIL) techniques provide the ease of testing and development agility needed to realize software-defined vehicles (SDV). Virtualization provides developers and automated continuous integration and deployment (CI/CD) systems with instant access to any amount of hardware, avoiding the need to queue up tests for execution on limited physical test rigs.

A VLAB VDM typically runs the complete software stack from the target system—applications, operating system, and drivers. The software is compiled for the target system, with no need for a special simulation variant. The VDM contains models of various input and output devices, both digital and analog. Sometimes it is as simple as a GPIO pin being driven in pulse-width modulated (PWM) mode. But it can also be analog signals or high-current drivers on a separate board, whatever is in the hardware.

From a VLAB perspective, it does not matter if the software being tested is written manually or generated from MATLAB/Simulink models. The software running on the VDM can be debugged and tested using standard software tools. It can be subjected to faults injected by VLAB scripts. This makes it possible to test the system under conditions like faulty sensors and actuators, exploring system stability and error handling. And, of course, challenging physical conditions can be simulated by the MATLAB/Simulink side.

Learn more about Cadence's VLAB and automotive solutions.

Unraveling Precision Time Measurement (PTM)

2026-05-01T17:00:00Z

Introduction

Precision Time Measurement (PTM) is an optional capability for communicating precise timing information between components. PTM enables precise coordination of events across multiple components with independent local time clocks. Such precise coordination is difficult, given that individual time clocks have differing notions of the value and rate of change of time. PTM is used in links/domains where the system needs its devices to have precise coordination. Good examples of systems that may take advantage of PTM include media processing, telecommunications, and scientific instrumentation.

PTM Theory and Operation

PTM enables components to calculate the relationship between their local times and a shared PTM Master Time: an independent time domain associated with a PTM Root.

Each Upstream Port initiates PTM dialogs to establish the relationship between its local time and the PTM Master Time provided by the Root Port.

PTM-capable components can make their PTM context available for inspection by software, enabling software to translate timing information between local times and the PTM Master Time. In turn, this capability enables software to coordinate events across multiple components with very fine precision.

PTM Requester - A Function capable of using PTM as a consumer associated with an Endpoint or an Upstream Port.
PTM Responder - A Function capable of using PTM to supply the PTM Master Time associated with a Port or an RCRB.
Time Source - A local clock associated with a PTM Responder.
PTM Root - The source of PTM Master Time for a PTM Hierarchy. A PTM Root must also be a Time Source and is typically also a PTM Responder.

PTM Link Protocol

A PTM dialog is defined as a matched pair of messages consisting of a PTM Request and the corresponding PTM Response or PTM ResponseD message.

The timestamps captured during the PTM dialogs enable the calculation of the timing relationship between the PTM Requester and PTM Responder (please see the image below for reference). The value (t3-t2) measures the time consumed by the PTM Responder for a given PTM dialog. The time (t4-t1) is the time from request to response. Therefore, ((t4 - t1) - (t3 - t2)) effectively gives the round-trip message transit time between the two components, and that quantity divided by 2 approximates the Link delay - the time difference between t1 and t2.

PTM Link Protocol

A PTM Requester must update its stored t1 timestamp when transmitting a PTM Request Message, even if that transmission is a replay.
A PTM Responder must update its stored t2 timestamp when receiving a PTM Request Message, even if the received TLP is a duplicate.
A PTM Responder must update its stored t3 timestamp when transmitting a PTM Response or ResponseD Message, even if that transmission is a replay.
A PTM Requester must update its stored t4 timestamp when receiving a PTM Response Message, even if the received TLP is a duplicate.

The PTM Master Time field is a 64-bit value containing the value of PTM Master Time at the receipt of the PTM Request Message for the current PTM Dialog. In the shared image, for the 2nd PTM dialog, this is the PTM Master Time at time t2'.

The Propagation Delay field is a 32-bit value containing the interval between the receipt of the PTM Request Message and the transmission of the PTM Response Message for the previous PTM dialog. In the shared image, for the second PTM dialog, this is the time interval between t2 and t3 captured during the first PTM dialog.

In NFM, Timestamps must be based on the STP Symbol or Token that frames the TLP, as if observing the first bit of that Symbol or Token at the Port's pins. The image below shows the PTM Request and Response Messages for Non-Flit Mode:

PTM Request/Response Message - Non-Flit Mode

PTM ResponseD Message - Non-Flit Mode

In Flit Mode, timestamps for PTM messages are measured at the Flit level rather than at the TLP level. There is the bit "PTM Message contained in this Flit" in the Flit_Marker field, which signals the presence of a non-nullified PTM Message inside the Flit. The PTM timestamps must be based on the Flit_Marker field.

The images below show the PTM Request and Response Messages for Flit Mode, and the Flit_Marker indicator:

PTM Request/Response Message - Flit Mode

PTM ResponseD Message - Flit Mode

Flit_Marker

PTM Extended Capability Structure

The Extended Capability structure is required for any port of the Root-Complex that supports PTM and in only one function of the Endpoint. The images below show the PTM Capability and Control registers:

PTM Capability Register

PTM Control Register

Enhanced Precision Time Measurement (ePTM) places additional requirements on PTM Devices. It must be implemented in all PTM devices that support Flit-Mode. Support for ePTM is indicated by the ePTM Capable bit.

PTM Verification Challenges and Solutions

The PTM feature introduces the PTM Request and Response Messages, whose proper utilization requires careful coordination between the devices. The new Messages may be checked to avoid any violation of the reserved fields, time accuracy, and data precision.
The PTM Extended Capability structure brings a new set of configuration registers. Verifiers must guarantee that the device's capability register correctly indicates feature support, that the control register is configured with the proper value, and that the feature is not enabled before the system is ready. Users can take advantage of VIP's error messages to identify Spec's violations more efficiently.

Verifying the PTM dialog can be really challenging. The PCIe specification defines the exact gathering point for the timestamp values. But at the same time, the devices may hold a small to moderate delay for processing incoming data, which may compromise the timestamp gathering value. The PTM dialog verification requires precise timing analysis.

Please refer to the VIP PCIe User Guide for more information on VIP PTM implementation and configuration.

Learn More

For more information on how Cadence PCIe Verification IP and TripleCheck VIP enable users to confidently verify IDE, 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 more feedback or need more information, reach out to us at talk_to_vip_expert@cadence.com.