Verification

From UPLI Poison to TL Message Type 0x20: Carrying Corrupted Data Through UALink

Nikshit — Tue, 27 Oct 2026 07:23:00 GMT

The Problem Nobody Wants to Talk About

Every high-speed link has a quiet fear: what happens when a piece of data is already bad before it even reaches the wire?

A soft error flips a bit in an SRAM. A parity check fails inside a switch. A read response arrives at an accelerator with a damaged payload. The data is corrupt, but the protocol around it, the addresses, the tags, the credits, is perfectly healthy.

You have three choices:

Drop the transaction. Now, a requester waits forever for a response that will never come.
Stop the link. One bad beat takes down traffic for everyone sharing that fabric.
Deliver the data, but label it as bad. The transaction completes, the fabric keeps flowing, and the one chip that finally consumes the data knows not to trust it.

UALink picks option three. That label is called poison, and the way it travels from the Protocol Level Interface (UPLI) down into the Transaction Layer (TL) and back up again is one of the most elegant, and most easily misverified, mechanisms in the specification.

This blog focuses on a key aspect of data integrity in UALink: ensuring that corrupted data is never silently trusted. Through its poisoned data mechanism, UALink identifies, propagates, and contains data corruption, allowing downstream components to detect and respond to errors appropriately.

Poisoned Data: In-Band Error Signaling

When data corruption is detected, UALink propagates the error in-band with the affected data rather than relying on retransmission, acknowledgements, or additional buffering. The specification requires the corruption indication to remain coincided with the corrupted data half-flit, avoiding protocol feedback loops and complex buffering requirements. At the TL, the affected data half-flit is replaced with a poisoned data message (message type 0x20), preserving data ordering and allowing the corruption status to be propagated transparently to the final consumer of the data.

Step 1: Where Poison Is Born at the UPLI

Poison starts as a single bit on a UPLI data channel.

Read data (RdRspDataError): This is a data "poison" indicator. It is asserted at any UALink protocol level interface on a switch or accelerator that detects a parity error on the RdRsp data beat, or by the switch core when it detects an error on read response data (data only, not control signals) according to the switch soft-error detection scheme. The key phrase: it is asserted individually for each beat, according to the error state of that beat.

Write data (OrigDataError): The mirror image on the originator side. It is set at any interface that detects a parity error on the originator data, or by the switch detecting an error on data, and note the careful exclusion: data only, not control signals, including byte enables. This signal is one bit wide and, when asserted, indicates the current data beat contains a data error. OrigData itself is 512 bits, so one OrigDataError bit covers one 64-byte beat.

Two things to hold on to for the rest of this blog:

Poison is per beat, not per transaction. A four-beat write can have beat one poisoned and the others perfectly clean.
Poison covers payload, never control information or byte enables.

Poison Is Not the Same as an Error Status

It is tempting to confuse poison with a failed read. They are different tools:

Aspect	RdRspStatus Error	RdRspDataError/OrigDataError
What it indicates	🚫 The operation failed (TARGET ABORT, DECODE ERROR, PROTECTION VIOLATION, CMPTO)	⚠️ The operation completed, but a specific data beat is corrupt
Granularity	One 4-bit status per response	One error bit per data beat
Data on the wire	Completer sends all requested beats with RdRspLast and manufactured data (typically all 1s / 0xFF)	Actual data is transmitted, but the affected beat is marked untrustworthy
Cache behavior	❌ Returned data shall not be cached; cache state remains unchanged	☣️ Accelerator may cache the line while marking the data as poisoned
Impact	Entire transaction is considered unsuccessful	Only the affected beat(s) are suspect
Recovery action	Retry, software handling, or protocol-level recovery	Consumer decides whether to use, retry, or discard poisoned data

Same fabric, two different failure stories. A good testbench checks both, and checks that they never get mixed up.

Step 2: The Hard Part, Moving From a Wire to a Flit

Inside a UPLI interface, poison is trivial: a sideband bit sitting right next to its data beat. But UALink traffic doesn't stay on UPLI. It is packed into TL flits for the trip across the fabric, and a TL flit has no DataError wire.

Here is how a TL flit is built:

A TL flit is two 32-byte Half-Flits. Each half-flit carries a one-bit message indicator (M1 for the upper half, M0 for the lower).
When the indicator is 1, the half-flit is a TL message half-flit: the low-order byte is the MsgType (256 possible message types) and the remaining 31 bytes are message-specific payload.

Normal TL message half-flits are inserted into the stream and shift subsequent half-flits to maintain ordering. The poisoned data TL message half-flit (0x20) is the only exception, replacing the affected data half-flit(s) in place rather than being inserted, thereby preserving the existing TL sequence. Along with NOP (0x00) and initial credit release complete (0x01), it is one of the three legal TL message half-flit types.

Poisoned Data Handling Requirements

In-place substitution: A corrupted data payload is indicated by replacing the corresponding TL data half-flit with a poisoned data TL message half-flit (MsgType = 0x20). No additional TL message half-flit is inserted into the stream.
Undefined payload content: For a poisoned data TL message half-flit, only the MsgType field is defined. The remaining bytes are undefined and carry no protocol significance.
Restricted usage: Poisoned data replacement is valid only in half-flits that would otherwise contain data payloads or atomic operands. It shall not be used in half-flits carrying byte enables.
64B-to-32B mapping requirement: Since 64-byte UPLI data beat maps to two 32-byte TL data half-flits, poisoning a UPLI beat requires both associated TL data half-flits to be replaced with poisoned data message half-flits.
Authentication precedence: When authentication is enabled, a poisoned data TL message half-flit shall not replace an AuthTags half-flit. Authentication-related half-flits retain priority over poison substitution.

A Worked Example

A 256-byte write is four 64-byte UPLI beats, which is eight 32-byte data half-flits. Because the second beat is the bad one, its two half-flits, Req0.Data.2 and Req0.Data.3, are replaced by poisoned data message half-flits. Every other half-flit travels as normal data.

When this data finally reaches the accelerator that consumes it, the receiver sees the two 0x20 messages and drives OrigDataError for the second UPLI beat, restoring the very same per-beat bit that existed on the sending side. The loop closes.

How Far Does Poison Travel?

The corrupt-data indication shall be carried through the various subsequent TL interfaces and UPLI interfaces, via RdRspDataError or OrigDataError, until the data reaches the accelerator ultimately receiving the data. Every switch in between is a courier, not a judge. And that final accelerator is free to mark the data as poisoned in its caches or take whatever action it needs.

What Poison Is Not For

An error detected on the TL Rx interface itself, by an implementation-specific detection scheme, is uncorrectable and fatal. It cannot be fixed by poisoning data. The Rx TL interface on which it occurred stops forwarding all received TL flits. Errors on the TL Tx interface are handled by UALink DL. Poison is a mechanism for known-bad payload on a healthy link, not a way to paper over a broken one.

The Verification Iceberg: 6 Things That Must All Be Right

The visible tip is "when the data is bad, send a 0x20." Below the waterline:

Faithful mapping, per beat. Every poisoned UPLI beat must become a poisoned data pair, and every clean beat must stay real data. Poison one beat of four and exactly two half-flits change.
Pairing. One poisoned half-flit with a clean partner is a protocol violation. Both halves of a beat must agree.
Position. Poisoned data must never appear on a byte enable half-flit, and it cannot be the start of a new command. It only replaces data or atomic operand half-flits.
Round-trip fidelity. The OrigDataError or RdRspDataError pattern recovered at the far UPLI must equal the pattern injected at the near one, beat for beat.
No collateral damage. Poisoning a beat must not shift, delay, or corrupt neighbouring half-flits, since in-place replacement is the whole point.
Both directions, both paths. Writes (OrigDataError) and reads (RdRspDataError) take different channels and different code paths. Verifying one tells you nothing about the other.

Why Hand-Written Tests Fall Short

A directed test usually poisons "beat 0 of a write" and calls it a day. But poison position, beat count, transaction type (write, read, atomic), port, and traffic around it all interact. The bugs live in the corners: the last beat of a burst, two adjacent poisoned beats, poison on a read response that follows a write. Only constrained-random injection with continuous checking reaches them.

The Verification Hit List: 5 Scenarios Every Plan Should Include

Random beat poison on writes. Inject OrigDataError on a random subset of beats of a multi-beat write, and confirm the receive-side OrigDataError mask equals the transmitted one, beat for beat.
Random beat poison on read responses. The same for RdRspDataError on multi-beat read responses, checked end-to-end at the originator.
Pairing violation. Deliberately poison only one half of a beat's half-flit pair, and confirm the checker flags it.
Position violation. Place Poisoned Data on a Byte Enable half-flit, and as the first message of a new command, and confirm both are flagged.
Poison versus status. Check that a read response carrying an error RdRspStatus (Manufactured Data, no caching) behaves differently from one carrying poisoned data beats, and that neither is confusing for each other.

How Modern Verification IP Tackles This

Cadence's Simulation VIP for UALink turns each of these rules into something you can run and measure:

Built-in protocol checkers. Dedicated receive-side validation checks ensure that poisoned data is used only in the locations permitted by the protocol. These checks verify that poisoning is applied consistently across paired half-flits and is not carried on byte-enable or control half-flits where it is not allowed. The checks are automatically applied to all received flits and require no additional test-specific set-up.
Granular control of the poison stimulus. A verification environment should be able to select exactly which data beats of a transaction are poisoned, on both writes (OrigDataError) and read responses (RdRspDataError). A single beat, adjacent beats, or a random subset can be targeted while the remaining beats stay unaffected. This makes it possible to reach corner cases such as the last beat of a burst or two neighbouring poisoned beats.
End-to-end checking of the poison pattern. The pattern injected at the originating UPLI is compared, beat for beat, with the pattern recovered at the far-end UPLI. The comparison runs on every transaction, on both channels and in both directions, and the same checking flags patterns the specification does not allow, such as poison on only one half of a beat's pair or poisoned data in a non-permitted position.
How Cadence VIP addresses this. Cadence's Simulation VIP for UALink already covers both areas, from poison stimulus to end-to-end checking. Verification teams can therefore focus on defining meaningful scenarios and analysing coverage, rather than building and maintaining the injection and checking infrastructure themselves.

Conclusion: The Label That Keeps the Fabric Honest

Credit flow is invisible when it works, because data flows at line rate. Poison is the opposite: it is the mechanism you want to be visible exactly once, at the one chip that finally consumes the bad data.

The path is short to describe and long to verify. A single bit on a UPLI beat becomes two 32-byte message half-flits tagged 0x20, travels unchanged through every hop, and re-emerges as the same single bit at the far UPLI. At every step, there are rules about pairing, position, and what must not be poisoned.

A poison bug does not crash your design. It does something much worse: it lets corrupt data look clean, in a cache, in a training run, at scale. Verify it now, while it is just a simulation log.

To integrate this end-to-end validation capability into your environment, contact Cadence Support, visit the Simulation VIP for UALink product page, or explore the wider range of Cadence Simulation VIP solutions. For technical assistance, reach out at talk_to_vip_expert@cadence.com.

From Transactions to Flits: The Journey Through UALink Transaction Layer

Nirav Toliya — Mon, 26 Oct 2026 09:23:00 GMT

AI accelerators are getting faster, but their performance increasingly depends on how quickly they can exchange data. In a multi-accelerator system, one device may finish computing a tensor, gradient block, or intermediate result while another device is already waiting for it. When communication cannot keep pace with computation, expensive accelerator cycles are lost.

UALink is designed to remove that bottleneck inside the scale-up system. It gives accelerators a direct, high-bandwidth, low-latency path to peer memory using read, write, and atomic operations. Instead of treating communication as a separate networking task, UALink makes peer-memory access part of the accelerator’s memory-oriented transaction flow.

Consider one such transaction. A 256-byte result leaves accelerator A as one WriteFull request and four data beats. At accelerator B, the same request and data beats emerge. In between, however, the transaction is split, packed, routed, repacked, and reconstructed. The layer responsible for preserving its meaning throughout that journey is the UALink Transaction Layer (TL).

UALink TL transforms, transports, and reconstructs a 256-byte WriteFull.

TL Receives One Transaction

UPLI presents a WriteFull request and four associated 64-byte data beats on the originator data channel. TL must preserve the command, destination accelerator ID, transaction tag, and association between the request and all four data beats.

TL Builds the Flit Sequence

Tx TL places the WriteFull request in a control field and splits the 256-byte payload into eight 32-byte data half-flits. The control field tells Rx TL what transaction is coming and how much data belongs to it. Because WriteFull marks every byte as valid, no separate byte-enable half-flit is needed.

One possible mapping of a 256-byte WriteFull into TL control and data half-flits.

Flow Control — Is the Receiver Ready?

Before sending the WriteFull, Tx TL must have enough credits for both the request and its payload. A 256-byte WriteFull consumes one request CMD credit and four request data credits, with each data credit representing one 64-byte receive buffer. Each link maintains an independent credit loop, with credits returned as receive-buffer capacity becomes available.

Compression — Can the Request Be Smaller?

When the optional Tx and Rx address caches are implemented, an uncompressed request can load a corresponding entry in the receiver’s address cache. If a later WriteFull hits that entry and satisfies the compression rules, Tx TL can encode the request in two sectors instead of four. Only the control encoding becomes smaller; the 256-byte payload still uses eight 32-byte data half-flits.

TL Preserves the Transaction Across the Fabric

At the switch, the ingress TL reconstructs the WriteFull request and its associated data beats. The switch core uses the destination accelerator ID to select the outgoing port, and the switch egress TL builds a new flit sequence for the next link. Flit packing may change, but the request and its associated data must remain correctly sequenced and associated.

Rx TL Reconstructs the Original UPLI Transaction

Rx TL decodes the WriteFull control field, knows that eight data half-flits belong to the transaction, and collects them in sequence. It then recreates the corresponding UPLI WriteFull request and four 64-byte data beats for accelerator B’s completer.

TL Carries Completion and Error Meaning

Completion: After completing the write, accelerator B returns a write response containing the completion status and original transaction tag. Accelerator B’s Tx TL encodes the write response, and accelerator A’s Rx TL reconstructs it so the originator can retire the correct request.

Corruption: If a 64-byte data beat is marked corrupted, its two corresponding 32-byte data half-flits are replaced with poisoned data TL message half-flits using message type 0x20. Rx TL then reconstructs the corresponding UPLI beat with OrigDataError asserted. The data is not trusted, but the transaction sequence remains intact.

Why TL Verification Gets Interesting

At the UPLI boundary, a WriteFull transaction appears simple: one request and four data beats. Within the transaction layer, however, the request may be compressed, its payload is divided into eight data half-flits, credits determine when it can advance, and switches may reconstruct and repack it for the next link.

Any of these steps can fail without stopping the protocol. The flit stream may remain valid while the reconstructed transaction is incorrect. This is what makes TL verification challenging, particularly in areas such as:

Credit-controlled progress. Command and data credits must be consumed and returned correctly on every link. When a transaction stalls, it can be difficult to tell expected backpressure from a credit-accounting error.

Compression and reconstruction. A request compressed to two sectors depends on a matching entry in the receiver’s address cache. If the Tx and Rx address caches fall out of sync, the reconstructed WriteFull can silently differ from the original.

Transaction association. Each data half-flit must remain associated with the correct request, including after switch repacking, and each completion must be matched to the correct outstanding request. With many transactions in flight, a broken association can still look like valid traffic.

Error propagation. A data beat marked corrupted must be reconstructed with OrigDataError asserted on the corresponding UPLI beat, without disrupting the transaction sequence. The poison indication must reach the correct beat, not just the correct transaction.

WriteFull is only one example; reads and atomics follow the same principle. A transaction may change form many times on its journey, but its meaning must not.

Cadence UALink VIP helps verify that this meaning is preserved. Built-in protocol checkers flag violations, while transaction-aware visibility across the UPLI and TL interfaces connects flit-level activity to transaction-level behavior, shortening the path from a valid-looking flit stream to the root cause of an incorrect transaction.

More information on Cadence UALink VIP is available at the Simulation VIP for UALink. You can also explore Cadence Simulation VIP solutions for other protocols. If you have any queries, feel free to contact us at talk_to_vip_expert@cadence.com

Demystifying NOP Debug Flits in PCIe Flit Mode

sabnams — Mon, 12 Oct 2026 22:35:00 GMT

Introduction

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

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

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

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

NOP Debug Flit Layout and Details of Fields

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

Figure 1: NOP.Debug flit debug chunk

Figure 2: NOP.Debug flit debug chunk fields

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

Table 1: PCI-SIG-defined debug chunk Opcodes

Advantages of Debug Flits

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

This improves:

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

Debug Flits Verification

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

For this, some crucial negative scenarios must include:

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

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

2. Flit Replays Caused by CRC/FEC Error Injection

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

3. Handling Corrupted Debug Flit Headers

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

4. Buffer Occupancy Reporting

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

Conclusion

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

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

More Information

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

Why Protocol Compliance Is Not Enough: Performance Verification with ATP

PratikKumarGupta — Mon, 12 Oct 2026 22:00:00 GMT

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

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

What Adaptive Traffic Profiles Describe

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

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

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

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

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

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

What the Model Demands of an Implementation

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

How Cadence Verification IP Delivers the Model

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

Coverage across the AMBA family

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

The full pattern vocabulary

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

Timing fidelity beyond the rate

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

Protocol legality guaranteed

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

Measurement built in

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

Repeatable, trace-driven traffic

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

Seeing the Result

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

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

Learn More

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

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

AY20250725603 — Fri, 09 Oct 2026 00:00:00 GMT

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

UCIe 3.0: Faster Links Are Only Half the Story

Mannan — Thu, 08 Oct 2026 08:52:00 GMT

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

More Than Just Higher Bandwidth

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

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

Enabling Continuous Transmission Workloads

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

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

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

Reliability Becomes a First-Class Requirement

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

The Verification Challenge

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

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

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

Why Advanced VIP Matters

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

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

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

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

Looking Ahead

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

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

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

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

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

LeoHendrawan — Sun, 04 Oct 2026 10:31:00 GMT

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

Real Software Stack?

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

Virtual Board and Real Web Browser?

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

Building the Software Example “As Is”

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

Debugging the First Blocker

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

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

Bridging the Model Gap

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

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

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

Connecting the Virtual Ethernet Network

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

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

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

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

From L4 Simulation to a Complete Virtual ECU

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

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

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

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

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

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

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

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

Outcome:

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

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

Python API and App Store Development with Verisium Debug

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

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

Why This Course Matters

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

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

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

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

What You’ll Learn

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

1. Python API Foundations

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

2. Design and Value Analysis

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

3. Database Handling

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

4. GUI Automation and Customization

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

5. Batch Mode Automation

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

6. App Store Development

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

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

Key Benefits of Taking This Course

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

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

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

Earn Recognition Through the Badge Exam

Learning doesn't stop when the course videos end.

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

The badge exam enables learners to:

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

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

Start Building the Future of Debug Automation

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

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

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

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

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

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

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

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

Overview of CXS Interleaving

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

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

Why CXS Needs Stream-Aware Interleaving

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

CXS Interleaving Protocol Architecture

Protocol-Aware Stream Identification with CXSPRCLTYPE

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

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

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

Legal Insertion Boundaries with CXSLAST

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

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

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

Continuous Delivery with CXSCONTINUOUSDATA

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

Multi-Node Stream Identity in CXS Issue D

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

CXS stream identity = {CXSPRCLTYPE, CXSSRCID, CXSTGTID}

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

Key Protocol Features

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

Practical Use Cases for CXS Interleaving

Multi-Protocol Controller Connectivity

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

Multi-Node and Modular Subsystem Fabrics

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

Mixed-Latency and Variable-Length Traffic

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

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

Functional Verification Challenges

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

Stream Identity Integrity

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

Insertion-Boundary Correctness

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

Ordering and Packet Reconstruction

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

Credit and Delivery Continuity

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

Verification Strategy

Protocol and Flit-Level Checking

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

Stream-Aware Scoreboarding

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

Credit and Continuity Stress

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

Coverage and Negative Testing

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

Cadence CXS VIP Solution

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

Concurrent generation of multi-protocol and multi-node streams

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

Stream-aware packet reconstruction and ordering validation

Credit-pressure and continuous-delivery stress scenarios

Functional coverage across stream identities and insertion boundaries

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

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

Conclusion

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

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

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

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

Why LLMs Are the Best Thing to Happen to Chip Design

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

By Kartik Hegde, Sr. Engineering Group Director

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

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

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

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

Custom Silicon: Two-Year Minimum, 100+ Engineers

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

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

Historical Perspective: Shifting Bottlenecks

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

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

Key Stages of Chip Design

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

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

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

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

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

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

To summarize:

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

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

2000s and Beyond: Increasing Complexity of Functional Verification

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

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

Design Hierarchy

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

Methodology

Simulation
Formal verification
Emulation
Gate-level simulation

Abstraction Level

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

Verification Intent

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

Environment

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

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

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

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

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

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

How LLMs Are Changing the Chip Design Game

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

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

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

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

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

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

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

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

The Road Ahead: Rise of New Abstractions for Chip Design

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

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

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

Learn more about the Cadence ChipStack AI Super Agent.

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

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

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

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

GDDR7-Based System Architecture

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

Device Feature Overview

Channel Operation

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

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

Data Interface, PAM3 Encoding, and Signaling

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

PAM3 Mode

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

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

Command, Clock, and Configuration Model

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

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

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

Data Integrity, Electrical Limits, Package, and Implementation Guidance

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

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

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

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

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

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

The Ethernet PHY We Knew, The UALink PHY We Needed

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

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

The Myth We All Quietly Believe

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

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

Follow One Flit, and the Difference Appears

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

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

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

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

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

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

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

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

RS generates a 'Start Flit Code Sequence'

PCS recognizes that sequence

PCS overwrites specific 257-bit blocks with Ethernet alignment markers

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

RS uses that sequence to recover DL flit phase

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

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

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

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

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

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

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

Coming Back Is Harder

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

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

Then Latency Enters the Story

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

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

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

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

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

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

The Problem Ethernet Gets for Free

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

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

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

Back-to-Back Does Not Mean Boundary-Free

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

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

What UALink Refused to Reinvent

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

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

One Last Thing

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

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

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

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

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

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

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

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

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

When a Power Saving Feature Becomes a Protocol Puzzle

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

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

Inside the Link Management DLLP

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

The key semantic fields are:

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

Same DLLP Encoding, Different Protocol Universe

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

The Request-Response Contract

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

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

Ack, Nak, or Abandon: The Clock Keeps Running

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

Small on the Wire, Big in Verification

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

More Information

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

Not Every Byte in a UALink DL Flit Is a Payload

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

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

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

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

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