Verification

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

2026-07-31T13:30:00Z

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

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

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

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

The Debug Scene We All Know

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

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

Where Waveform Debugger Changes the Story

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

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

A UALink Example: One Transaction, Four Layers

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

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

Why the VIP Side Is the Right Place

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

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

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

The Takeaway

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

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

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

Explore UALink Debug with Cadence

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

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

AMBA AXI5 Memory Tagging Extension: Making Memory Safety Observable on the Bus

2026-07-23T12:08:00Z

Memory safety remains one of the most persistent challenges in modern computing systems. Issues such as buffer overflows, use-after-free errors, and heap corruption can lead to serious security vulnerabilities, especially in systems built using large C/C++ codebases. As Arm-based SoCs continue to grow across mobile, automotive, datacenter, and IoT applications, there is a need for a hardware-supported mechanism that can detect memory misuse with minimal runtime overhead.

Arm Memory Tagging Extension enables this by associating a small allocation tag with each memory granule and checking every pointer access against the expected tag. When a stale, out-of-bounds, or incorrect pointer is used, the mismatch can be detected before the access causes data corruption or security breach. For this mechanism to work across the full memory hierarchy, the tag information must be transported and verified through the interconnect fabric, which is where the AMBA AXI5 MTE protocol extension becomes important.

Overview of Memory Tagging Extension

Arm MTE provides hardware-enforced memory tagging by introducing dedicated tag storage, tag manipulation instructions, and automatic tag checking on memory accesses. Each 16-byte memory granule is associated with a 4-bit Allocation Tag, while the pointer carries a Logical Tag in its upper address bits. During memory access, hardware compares the Logical Tag with the stored Allocation Tag and raises a fault when they do not match.

This approach helps detect common memory safety issues such as buffer overflows and use-after-free access.

Why AXI5 Needs MTE Support

MTE tag operations such as tag reads and writes must travel through caches, interconnects, memory controllers, and DRAM without losing tag information. Without explicit AXI-level support, tag data would either need to be carried as normal data, which wastes bandwidth and affects atomicity, or it could be lost at cache boundaries.

The AXI5 MTE extension addresses this by adding dedicated signals and transaction qualifiers for tag-aware transfers. These additions allow tags to be transferred along with data, moved independently as tag-only transactions, updated selectively, and checked for correctness within the memory subsystem.

AXI5 MTE Protocol Architecture

AXI5 MTE extends the standard AXI protocol with new signals across the address, data, and response channels. AWTAGOP and ARTAGOP to identify whether a transaction is normal access, a tag-and-data transfer, or a tag-only transfer. WTAG and RTAG carry allocation tag values, while WTAGUPDATE indicates which tags must be written to memory when AWTAGOP is Update. There is 1 bit per 4 bits of tag.

The protocol also defines response and error indicators such as separate, fail, and pass responses using the BTAGMATCH signal. The waveform below provides a step-by-step view of AXI5 MTE transactions, showing how allocation tags are transferred alongside data, fetched independently through tag-only operations, and validated through tag match checking on write accesses.

Key Protocol Features

AXI5 MTE supports two important transaction types: Tag-and-Data and Tag-Only. Tag-and-Data transactions transfer application data and the corresponding allocation tags together, which is useful when memory and tag state must be initialized or fetched in a single operation. Tag-Only transactions transfer only tag information and are typically used for instructions that update or read allocation tags without modifying data memory.

The tag width depends on the AXI data bus width. Since each 16-byte granule requires a 4-bit tag, the tag bus width scales with the number of granules in each data beat. Tags are packed in address order, with the lowest bits corresponding to the lowest-addressed granule in the beat.

Detecting Real Memory Safety Issues

One of the key values of MTE is its ability to detect buffer overflow conditions before they silently corrupt adjacent memory. In the documented example, a buffer is allocated with one tag, while the neighboring allocation has a different tag. When a buggy access crosses into the neighboring granule, the Logical Tag does not match the Allocation Tag, allowing the system to detect the overflow before corruption occurs.

MTE also helps detect use-after-free errors. When memory is freed and later reallocated with a new tag, an older stale pointer still carries the previous Logical Tag. Any access using that stale pointer results in a tag mismatch, allowing the system to detect and contain the invalid access.

Functional Verification Challenges

Verifying AXI5 MTE is more complex than verifying standard AXI transactions because tag correctness becomes an additional dimension of protocol behavior. Verification must ensure not only that data transfers are correct, but also that tag transfers, tag updates, tag operation responses, and tag error reporting are legal and consistent.

At the IP level, important checks include AxTAGOP encoding legality, BTAGMATCH consistency, WTAGUPDATE behavior, Tag-Only fetch handling, separate tag response correctness, ordering rules, and interactions with exclusive accesses. These checks require protocol-aware monitors, transaction correlation, and tag state modeling.

At the SoC level, verification must cover end-to-end tag correctness across the CPU, caches, interconnect, memory controller, and DRAM. Key challenges include cache hierarchy tag coherency, tag writeback ordering, snoop tag forwarding, context-switch tag save/restore, OS tag memory management, DMA interaction with tagged memory, and security-state isolation.

Cadence AXI5 VIP Solution

Cadence AXI/ACE Verification IP provides a comprehensive solution for verifying AXI5 MTE functionality at both the IP and system levels. The solution includes a protocol-compliant BFM, monitor and protocol checker, coverage model, and built-in building block sequences for generating MTE scenarios.

Cadence AXI5 VIP helps verify all key MTE transaction types, configurable tag patterns, error injections, protocol rule enforcement, coverage closure, and complex scenarios generation using the built-in building block sequences. This allows verification teams to validate both protocol compliance and end-to-end memory tagging behavior across the SoC fabric.

Cadence AXI5 VIP accelerates MTE verification closure by providing:

Ready-to-use MTE transaction generation using the build block sequences
Protocol checks for AXI5 MTE signal legality and consistency
Tag state and error behavior validation
Coverage for MTE protocol

Conclusion

AXI AMBA5 MTE provides a practical hardware mechanism for detecting memory safety violations with low overhead. The AXI5 MTE protocol extension makes this capability visible at the bus level by transporting tag information, supporting tag-only and tag-and-data transactions, and enabling in-fabric tag error reporting.

As MTE adoption grows in Arm-based SoC designs, verifying correct tag movement, tag checking, ordering, coherency, and error reporting becomes essential. Cadence AXI5 VIP provides the protocol checks, coverage model, scenario generation, and system-level verification support needed to ensure AXI5 MTE implementations are complete, compliant, and robust.

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

For any additional clarification or technical assistance, users are encouraged to reach out through talk_to_vip_expert@cadence.com

For more information, please visit Cadence Simulation VIP Product Page

MIPI M‑PHY v6.0: Evolution of ADAPT for Ultra‑High‑Speed Interfaces

2026-07-22T23:30:00Z

MIPI M-PHY has evolved to support higher data rates with the introduction of HS-G4 and beyond. This has created signal integrity challenges such as Inter-Symbol Interference (ISI), channel loss, and noise. To ensure reliable communication over these high-speed links, the ADAPT (Adaptive Equalization Training) feature was introduced in M-PHY. ADAPT is a training mechanism that enables us to analyze channel characteristics and refine its equalization settings before high-speed data transmission begins.

ADAPT works by transmitting a known training pattern from the transmitter to the receiver. Using this pattern, the receiver can tune its equalizer to compensate for channel impairments and improve the quality of received data. This process reduces bit errors, increases signal robustness, and enhances interoperability between devices operating at high data rates.

Originally introduced in M-PHY v4.1 for HS-G4, ADAPT continues to be used in HS-G5 and HS-G6. In M-PHY v6.0, where PAM-4 signaling is used with HS-G6 having 46.7 Gbps speed per lane, ADAPT becomes even more critical to maintain reliable link performance under increasingly challenging channel conditions.

Key Enhancements in M-PHY v6.0

In earlier M-PHY versions, ADAPT was defined only for HS-G4 and HS-G5 NRZ operation. With M-PHY v6.0, the ADAPT mechanism extends to support HS-G6 PAM4 signaling, where each symbol carries two bits of information. The eye openings for PAM-4 are significantly smaller than in NRZ signaling. This increases susceptibility to channel impairments, noise, and ISI, making equalization training far more critical. The enhanced ADAPT process with different pattern sequences enables the receiver to accurately characterize channel behavior and establish optimal operating parameters before data transmission, ensuring reliable communication at speeds up to 46.7 Gbps per lane.

M-PHY v6.0 introduces Transmitter Equalization, enabling the transmitter to pre-condition the signal before transmission using techniques such as pre-emphasis and de-emphasis. It helps to compensate for frequency-dependent channel losses at the source and preserves signal quality as it propagates through the channel. During link training, optimal transmitter equalization settings can be selected based on channel characteristics, maximizing eye opening, and improving data recovery at the receiver. When combined with receiver equalization, Tx EQ provides an end-to-end signal integrity solution that enables robust and reliable operation at ultra-high PAM4 data rates.

Aspect	HS-G4/G5	HS-G6
Encoding	8b10b	PAM-4 (1b1b)
Pattern	MK0 + PRBS9 (511+1 bits)	PRBS9 + PRBS15
Total Length	650 bits (65 symbols × 10)	512 + 32768 symbols
Polynomial	X⁹ + X⁵ + 1	X⁹ + X⁵ + 1 & X¹⁵ + X¹⁴ + 1
Phases	Single phase	Two phases (L0_L3, L0_L1_L2_L3)
Levels	2 (NRZ)	4 (PAM-4)

In conclusion, ADAPT plays a critical role in enabling reliable high‑speed operation in M‑PHY by ensuring robust link establishment even over challenging channel conditions. Through well‑designed training patterns, precise timing control, and coordinated protocol mechanisms, it supports signal integrity and stability at advanced data rates like HS‑G6. At the same time, its design preserves backward compatibility, ensuring seamless operation across both legacy and newer speed grades.

With the availability of the Cadence Verification IP for M-PHY, 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 M-PHY protocol provides a complete bus functional model (BFM), integrated automatic protocol checks, and coverage model. Designed for easy integration into testbenches at IP, system-on-chip (SoC), and system levels, the VIP for M-PHY helps you reduce the time to evaluate, accelerate verification closure, and ensure end-product quality.

Learn more at Simulation VIP for MIPI M-PHY product page or reach out to Cadence's Verification IP experts.

PSS 3.1 Channels: The Game Changer for Target-Time Communication

2026-07-16T18:17:00Z

Portable Stimulus models already feature powerful language constructs to describe scenario intent. Activities, constraints, resources, buffers, streams, and states let the Perspec solver build a legal action schedule before the test runs. That is the right layer for planned action relationships: which action produces data, which action consumes it, which operations may run in parallel, and which resources must be shared or locked. Build a legal action schedule before the test runs. That is the right layer for planned action relationships: which action produces data, which action consumes it, which operations may run in parallel, and which resources must be shared or locked.

The tests generated also need to coordinate while they are running. A target-side interrupt may arrive after a device finishes work. A service loop may need to wait for requests from another running exec block. One execution context may need to send several values to another before either action completes. These situations are not just solver scheduling relationships; they are target-time communication between realization code that is already executing.

The upcoming PSS 3.1 channel addresses this gap. A channel is a component type defined inside the core library sync_pkg package; it is designed to carry typed values at the target time. It provides blocking get() and put() methods, nonblocking try_get() and try_put() methods, FIFO ordering up to the declared depth, and thread-safe behavior for concurrently running realization code. PSS 3.1 channels are a standardized feature that replaces a Perspec proprietary implementation known as ps_event.

Why Channels Are Different from Flow Objects

Buffers and streams are scenario-layer flow objects. They make dependencies visible to the solver. A buffer says the producer must finish before consumers start. A stream says producer and consumer actions are scheduled concurrently. These are powerful constructs, but they describe relationships in the solved action graph.

Channels operate inside target execution. An action can remain active, loop, compute a value from target-time state, put that value into a channel, wait for a completion value, and continue. Communication does not need to be exposed as a separate solver-visible flow object for every runtime exchange.

Use flow objects when the relationship should shape the generated scenario. Use channels when the running target code needs FIFO communication or blocking synchronization after execution has started.

Basic Example: Runtime Request and Completion

The following example models a simple client and service that exchange multiple requests and completions while both exec bodies are running. The client sends a request, waits for the matching completion, then sends the next request. The service waits for each request and returns to completion.

import std_pkg::*;
import sync_pkg::*;

const int NUM_REQUESTS = 4;

struct request_s : packed_s<> {
    bit[16] addr;
    bit[8] data;
}

struct completion_s : packed_s<> {
    bit[8] status;
    bit[8] observed_data;
}

component pss_top {
    channel_c<request_s, 2> requests;
    channel_c<completion_s, 2> completions;

    action client {
        exec body {
            repeat (i:NUM_REQUESTS) {
                request_s req;
                completion_s done;

                req.addr = (bit[16])(0x1000 + i);
                req.data = (bit[8])(0x40 + i);

                message(LOW, "client sends request addr=0x%x data=0x%x", req.addr, req.data);
                comp.requests.put(req);

                done = comp.completions.get();
                if (done.status != 0) {
                    error("request failed with status %d", done.status);
                }
                if (done.observed_data != req.data) {
                    error("completion data mismatch expected=0x%x actual=0x%x", req.data, done.observed_data);
                }
            }
        }
    }

    action service {
        exec body {
            repeat (i:NUM_REQUESTS) {
                request_s req;
                completion_s done;

                req = comp.requests.get();
                message(LOW, "service handles request addr=0x%x data=0x%x", req.addr, req.data);

                done.status = 0;
                done.observed_data = req.data;
                comp.completions.put(done);
            }
        }
    }

    action runtime_request_completion {
        activity {
            parallel {
                do client;
                do service;
            }
        }
    }
}

This is not just a producer-consumer stream. A stream would make the producer and consumer relationship part of the solved scenario. Here, the interesting behavior is the target-time request/completion loop inside the running exec bodies. The two actions stay active, exchange several values, and block only when the channel operation requires it. That is the kind of runtime coordination channels were designed to express.

This example was generated successfully with Cadence’s Perspec version 26.06.001 using the below command:

perspec generate -pss runtime_request_completion.pss -top_action pss_top::runtime_request_completion

Interrupt Modeling Is an Important Use Case

Interrupt-driven flows are a common place where channels are useful. A test may start a device operation, continue running target code, and then wait until an interrupt handler confirms that the hardware has completed the operation.

A typical structure is:

import sync_pkg::*;

extend component uart_c {
    channel_c<bit> tx_irq;
    channel_c<bit> rx_irq;

    target function void Isr() {
        uart_ctrl_ua_cisr_reg_s status;
        status = regs.ua_cisr.read();

        if (status.tempty == 1) {
            bool put_status = tx_irq.try_put(1);
            if (put_status == false) {
                message(LOW, "TX interrupt indication could not be queued");
            }
        }

        if (status.rtrig == 1) {
            bool put_status = rx_irq.try_put(1);
            if (put_status == false) {
                message(LOW, "RX interrupt indication could not be queued");
            }
        }
    }

    extend action rx_uart_data {
        exec body {
            bit[32] fifo_data;

            comp.rx_irq.get();
            fifo_data = comp.regs.ua_rfifo.read().data;
            // Check or process the received data here.
        }
    }
}

The ISR uses try_put() because interrupt handlers should avoid blocking when possible. If the channel is full, the return value makes overflow handling explicit. The waiting action uses get() because it should stop at that point until the interrupt indication is available.

This mirrors real interrupt-driven software more naturally than a purely solved dependency. The action is not merely ordered after another action. It is waiting for a runtime condition observed by the target code.

Executors and Target Execution Units

PSS already uses the term executor for a target thread or processing context that can run exec code. A generated test may also have a larger packaging boundary: a target program or image that contains one or more executors. In the current Perspec flows this packaging boundary is called an executable. In the upcoming PSS 3.1 terminology, this concept is expected to be called a target execution unit.

This distinction matters for channels because target-time communication may happen between exec blocks that are placed in different ways:

On the same executor,
On different executors in the same target execution unit,
Or on executors that belong to different target execution units.

The PSS source code should not need to change for each placement. The model says put(), get(), try_put(), or try_get() on a channel. The tool then chooses the appropriate generated implementation for the target platform.

When both sides of the channel are local to the same generated C image, the implementation can use local generated storage and a local mailbox-style synchronization mechanism. When the channel crosses target execution units, the implementation must use a communication mechanism both sides can access. In the HSI example, Perspec generated two C files:

One C file runs on the simulation side and drives the SystemVerilog environment through DPI, while another embedded C file executes on the OpenRISC RTL.

For channel communication that crosses that boundary, Perspec generated a shared memory mailbox plus a doorbell-style notification mechanism.

This is one of the main benefits of channels. The model captures the target-time communication intent once, while the tool handles whether the generated implementation is local, shared-memory based, or mapped to another platform-specific synchronization mechanism.

When to Use Channels

Use channels when:

Communication happens while exec code is running.
The producer and consumer are long-running target-side behaviors rather than single solved action endpoints.
Runtime code needs FIFO ordering with a declared depth.
Blocking or nonblocking synchronization is needed between concurrently running realization code.
An interrupt handler or callback needs to notify model code that is waiting at the target time.

Do not use channels just to replace flow objects. If the dependency should be visible to the solver, use buffers, streams, states, resources, and constraints. Channels are for target-time communication in the realization layer.

Conclusion

PSS 3.1 channels add a standard way to describe target-time communication between running realization code. They complement, rather than replace, solver scheduling and flow objects. Flow objects shape the scenario before execution; channels coordinate execution after the generated test is already running.

Interrupt modeling is one of the most common uses, but it is not the only one. Request/completion loops, service-style target code, callbacks, and communication across execution contexts all benefit from the same abstraction. Channels let the model express the intent portably while leaving the implementation details to the PSS tool and target platform. While PSS LRM 3.1 is expected to be officially published in October–November 2026, users can start leveraging channel functionality today with Perspec version 26.06.001.

Why 10BASE-T1S Automotive Ethernet SoC Verification Needs More Than Simulation?

2026-07-14T04:05:00Z

Cadence Multi-Platform Verification improves functional coverage and verification time The recent advancements in the automotive industry, such as ADAS/AV, and infotainment all depend on reliable in-vehicle communication. To keep up with the high-spe...(read more)

Understanding PCIe 6.0 Power States: L0p vs L0s vs L1

2026-07-13T06:09:00Z

PCI Express has always focused on a single goal: maximizing performance while minimizing power. However, with PCIe 6.0, maintaining this balance has become far more challenging. With PAM4 signaling in PCIe 6.0, link power is no longer a secondary concern—it is now a first-order design constraint. The PHY consumes significantly more energy, and modern workloads generate traffic patterns characterized by bursts of multiple flits rather than continuous transfers.

This is where PCIe 6.0 introduces a major shift in power-state strategy: the real battle is no longer between L0 and L1—it is between L0p, L0s, and L1.

In this blog, we explore how these states differ, why PCIe 6.0 changes the rules, and which one matters most moving forward.

Why Power States Matter More in PCIe 6.0

PCIe 6.0 doubles bandwidth compared to PCIe 5.0. While PCIe 5.0 relies on NRZ signaling, PCIe 6.0 adopts PAM4, along with Forward Error Correction (FEC) and FLIT mode to achieve higher throughput.

However, these advancements come at a cost:

Increased PHY power consumption

Higher equalization complexity

Greater idle-to-active power overhead

In this environment, remaining in L0 (fully active) during idle gaps becomes inefficient. Yet, modern workloads, especially in accelerators, AI, and storage systems consist in frequent micro-idle periods.

Therefore, PCIe 6.0 requires power states capable of responding within microseconds, without compromising throughput or latency.

PCIe Link Power-State Landscape

PCIe defines multiple link states within the LTSSM (Link Training and Status State Machine). The most relevant states for active and idle operation are:


State	Meaning	Depth	Wake Latency
L0	Fully active	None	0
L0s	Shallow standby	Light sleep	Low
L1	Deep idle	Heavy sleep	Higher
L0p	Low-power active (6.0+)	New hybrid	Near-zero

PCIe 6.0 introduces L0p because neither L0s nor L1 alone can effectively handle modern workload demands.

L0s: The Legacy “Quick Idle” State

L0s was introduced as a fast idle state for short inactivity periods.

In L0s, the transmitter may stop sending symbols, the receiver stays partially ready, and the link is still logically active.

But Why Did L0s Work in Older Generations?

Because in previous generations the PHY power was manageable, the traffic/data patterns were simpler, and the wake latency requirements were relaxed. L0s provided moderate savings without much complexity. But L0s turn out to be limited to PCIe 6.0. At PAM4 as the equalization must remain stable, the continuous readiness becomes expensive. So L0s does not reduce enough PHY power to justify its use. So, the PCIe 6.0, L0s becomes less effective.

How About L1?

Let us understand L1 now. L1 is a deeper, low-power idle state. In L1, most of the link circuitry powers down, and the exit requires a more involved wake sequence. Though it’s beneficial in terms of significant power savings and is ideal for long idle durations, it has higher exit latency and can disrupt low-latency fabrics (e.g., CXL)

The modern PCIe traffic which consists of burst transfer and micro-idle gap, If the link enters L1 too aggressively, the wake overhead will hurt performance and will cause the latency-sensitive traffic to suffer. So PCIe 6.0 needs something between L0 and L1.

Hence L0p Was Introduced

L0p (Low Power L0) is a new PCIe 6.0 link state designed to reduce power while keeping the link operational and responsive.

It is best described as: “Active mode, but PHY-optimized.” L0p sits between:

L0 (full activity)

L1 (deep sleep)

In L0p, the link remains logically active, some portions of the PHY can be powered down, lane width may be reduced dynamically, and the exit latency is near-zero compared to L1. This makes L0p ideal for short idle gaps.

L0p vs L0s vs L1: Key Comparison

Feature	L0s	L1	L0p
Introduced	Earlier PCIe gens	PCIe baseline	PCIe 6.0
Target Idle Duration	Very short	Long	Short-to-medium
Power Savings	Low- moderate	High	Moderate- high
Exit Latency	Low	High	Very low
PHY Power Reduction	Limited	Strong	Significant
Best for 6.0 PAM4?	Not really	Sometimes	Absolutely
Supports Burst Workloads	Partial	Poor	Excellent

One unique PCIE 6.0 capability is that L0p may support dynamic link width changing.

L0p supports:

x16 → x8 → x4 downsizing during idle gaps.

Maintaining at least one active lane

Restoring full width instantly when traffic returns

This is a major step toward the power aware of PCIe fabrics. So, in PCIe 6.0 systems, the emerging hierarchy is that L0 for full traffic, L0p for burst idle gaps, L1 for extended inactivity, and L0s becomes increasingly irrelevant.

PCIe 6.0 changed the power management equation. L0 is too expensive to stay in during idle gaps; L1 saves power but adds latency, and L0s is no longer sufficient for PAM4 PHY power. Hence L0p fills the critical missing middle.

L0p is not just another low-power state. As PCIe evolves toward Gen 6.0 and forward and on CXL fabrics, L0p will become foundational for more output for less power.

To learn more about Cadence solutions for PCIe and CXL verification, explore these resources:

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

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).