Cadence Community

Welcome Ulkasemi VLSI Training Institute to the Cadence CCTP Program

prabhab — Thu, 05 Nov 2026 07:32:00 GMT

The semiconductor industry requires a highly skilled workforce and necessitates recent engineering graduates to swiftly bridge the gap between academia and practical application. This is where the Cadence Training Partner Certification Program comes ...(read more)

Meet Cadence’s ChipStack AI Super Agent

Vinod Khera — Thu, 05 Nov 2026 07:20:00 GMT

Cadence ChipStack AI Super Agent shifts AI in EDA from helping with individual tasks to coordinating a connected, evidence-driven design-and-verification workflow, with engineers remaining accountable for the final engineering decision. Every stage ...(read more)

Agentic AI for Analog and Custom IC Design

Reela Samuel — Wed, 04 Nov 2026 14:30:00 GMT

Analog IC design and custom IC design remain difficult to automate because circuit behavior depends on interactions among device characteristics, circuit topology, simulation results, and physical layout. Design intent is not always captured fully i...(read more)

Big Millennium News Is Coming to SC'26: Visit Us at Booth 6310

Corporate — Tue, 03 Nov 2026 18:15:00 GMT

Accelerating engineering from semiconductors to AI factories AI is transforming engineering. From advanced semiconductors and high-speed interconnects to AI factories and digital twins, design complexity, simulation scale, and performance demands ha...(read more)

Cadence Expands Sovereign AI in Europe: From Chips to AI Factories

Corporate — Tue, 03 Nov 2026 14:00:00 GMT

European engineering teams are advancing increasingly complex chip and system design while building the infrastructure to run AI at scale. Both depend on substantial computing resources. Both involve sensitive intellectual property. And both require...(read more)

Why Testing Automated Driving Is Harder Than It Looks

PMM Michael — Tue, 03 Nov 2026 14:00:00 GMT

Most people assume the hardest part of automated driving is building the technology itself. After all, enabling a vehicle to recognize traffic signs, detect pedestrians, stay within its lane, and react to complex traffic situations sounds like an ex...(read more)

PCI Express Security and TEE Integration, Part 2 - Protecting PCIe Traffic

RajeshPamujula — Tue, 03 Nov 2026 12:37:00 GMT

Protecting PCIe Traffic: Understanding Link IDE and Selective IDE

Part 1 of this series examined how Data Object Exchange (DOE), Security Protocol and Data Model (SPDM), and Component Measurement and Authentication (CMA) establish the control-plane trust required to authenticate PCI Express® (PCIe) devices and validate their security state. Once that trust has been established, the next requirement is to protect data in motion. This blog examines how Integrity and Data Encryption (IDE) secures PCIe traffic, including the roles of link IDE and selective IDE in direct-attached and switched topologies.

IDE: Protecting PCIe Traffic

Once trust has been established between the communicating IDE terminals, the next requirement is to protect the data in motion. This is the role of IDE.

PCI-SIG defines IDE as a mechanism that provides confidentiality, integrity protection, and replay protection for PCIe transaction layer packets (TLPs). The IDE security model specifically addresses attacks involving physical probes, malicious interposers, compromised switches, extension devices, and traffic manipulation.

IDE introduces a cryptographic processing layer between the PCIe transaction layer and the data link layer. The technology uses Advanced Encryption Standard Galois Counter Mode (AES-GCM), which provides both encryption and authentication of PCIe traffic. PCI-SIG® standardized the use of 256-bit AES-GCM keys for IDE.

Example: Why IDE Matters

Imagine an AI server connected to an external accelerator through a PCIe switch.

Without IDE:

Model weights travel in plaintext
Intermediate AI results can be observed
A malicious interposer could alter transactions
Packets could potentially be replayed or reordered

With IDE enabled:

Traffic is encrypted
Tampering is detected
Replay attacks are prevented
The communication channel remains protected even if an attacker gains physical access to the interconnect

Understanding IDE Streams

IDE organizes protected traffic into streams. A stream represents a cryptographically protected communication channel. Each stream contains three substreams:

Posted requests
Non-posted requests
Completions

PCIe uses different ordering rules for these transaction classes, so PCI-SIG created separate cryptographic substreams to preserve protocol ordering while maintaining strong security guarantees. Each sub-stream maintains an independent cryptographic state.

Link IDE vs. Selective IDE

The IDE architecture supports two complementary protection models: link IDE and selective IDE. While both use the same cryptographic foundation and provide confidentiality, integrity protection, and replay protection, they operate at different points in the PCIe hierarchy and address different security requirements.

Link IDE

Link IDE provides protection between two directly connected PCIe ports. The cryptographic relationship exists only across a single PCIe link, and protection terminates at the adjacent port.

Each side of the link contains an IDE engine that encrypts outbound TLPs and validates inbound traffic. The protected traffic is decrypted when it reaches the opposite port. If the packet subsequently traverses another PCIe link, a different IDE relationship must be established for that next hop.

From an implementation perspective, link IDE behaves similarly to other link-level protection schemes used in networking. The security boundary is the physical link itself rather than the complete end-to-end transaction path.

This model is particularly attractive when:

The device is directly attached to the host
Traffic does not need to traverse switches
All traffic on the link requires the same security policy
Hardware simplicity and minimum management overhead are priorities

For example, a directly attached SSD or SmartNIC may use link IDE to ensure that data cannot be observed or modified through a malicious probe attached to the PCIe connection.

Why Link Protection Is Not Sufficient

As PCIe fabrics become larger and more disaggregated, the trust boundary often extends beyond a single link.

Consider a rack-scale AI server, connecting a CPU ⟺ Switch ⟺ GPU. If link IDE protects only the CPU-to-switch link: CPU ⟸ Encrypted traffic ⟹ Switch ⟺ GPU, traffic is protected while crossing the first link. However, it must be decrypted inside the switch before being forwarded to the GPU. In this case, the switch becomes part of the trusted boundary.

For many traditional deployments, this may be acceptable. However, confidential computing environments increasingly require security that extends through the switch fabric itself. PCI-SIG specifically calls out the need to address threats involving compromised or malicious switches and manipulation of switch routing mechanisms. This requirement led to the introduction of selective IDE.

Selective IDE

Selective IDE protects specific PCIe traffic flows associated with an IDE stream. Unlike Link IDE, which secures an entire PCIe link, selective IDE can protect selected traffic between directly connected ports or across one or more intervening switches.

If Root Complex⟺ Switch⟺ GPU are covered by selective IDE, the cryptographic relationship exists between the Root Complex and the GPU endpoint even though the traffic traverses a switch. PCI-SIG describes selective IDE as traffic that can pass through switches while maintaining cryptographic protection between the terminal ports.

This distinction becomes increasingly important where resources may exist several PCIe hops away from the host processor, such as in:

AI clusters
Composable infrastructure
PCIe-attached accelerator pools
Disaggregated memory systems
Confidential computing deployments

IDE Streams and Traffic Selection

Unlike Link IDE, which generally protects all applicable traffic crossing a link, selective IDE operates on explicitly defined criteria to select the traffic that needs to be protected. An IDE stream can be viewed as a cryptographically protected communication context.

Traffic is associated with a particular stream using stream-identification information carried within the IDE architecture. The receiving endpoint uses the stream identifier and associated cryptographic information to validate and decrypt the transaction. This allows multiple security policies to coexist on the same PCIe fabric.

This flexibility is one of the primary reasons selective IDE is so important for cloud and multi-tenant infrastructure.

Streams, Substreams, and Ordering

PCIe uses different ordering rules for each flow class. Rather than applying a single encryption context to all traffic, IDE maintains separate cryptographic state for each substream. PCI-SIG notes that each substream maintains its own key and invocation counter. TLPs within a substream are processed in order, preserving PCIe's transaction semantics while supporting AES-GCM encryption.

This design is particularly important for selective IDE because traffic may traverse switched topologies where ordering behavior becomes more complex.

Figure 2: Link IDE vs selective IDE (image generated by Microsoft Copilot)

Link IDE and Selective IDE in Confidential Computing

A useful way to think about the two mechanisms is:

Feature	Link IDE	Selective IDE
Security boundary	Single PCIe link	End-to-end PCIe path
Traverses switches	No	Yes
Protection scope	Adjacent ports	Adjacent and non-adjacent ports
Typical use	Direct-attached devices	Disaggregated resources
Confidential computing relevance	Basic protection	Preferred for TDISP-based trusted device assignment across PCIe fabrics

In practice, modern confidential computing deployments increasingly rely on selective IDE because trusted device assignment often involves accelerators, SmartNICs, or storage devices located behind switches. Link IDE remains valuable for directly attached devices and simpler system topologies. Together, the two modes provide PCIe architects with the flexibility to align security boundaries with system-level trust requirements.

PCIe 6.x Security Enhancements

PCIe 6.0 introduced FLIT Mode.

A flow control unit (FLIT) is a fixed 256-byte packet format that supports PAM4 signaling and FEC. Unlike previous generations, PCIe 6.x transports traffic using fixed-size FLITs rather than variable-sized packets.

To support emerging security requirements, PCI-SIG has continued enhancing IDE. One important enhancement is partial header encryption (PHE). PHE allows portions of PCIe transaction headers to be encrypted while leaving sufficient information exposed to support routing and protocol operation. This improves confidentiality without breaking interoperability. PCI-SIG identifies PHE and enhanced downstream-link security as key additions to newer IDE implementations.

From Protected Traffic to Trusted Device Assignment

IDE protects PCIe traffic against observation, tampering, and replay, whether across a directly connected link or an end-to-end path through a switched fabric. However, protecting the communication channel does not determine whether a device can be trusted by a confidential workload.

Part 3 of this series will examine how the TEE Device Interface Security Protocol (TDISP) builds on DOE, SPDM, CMA, and IDE to enable trusted device assignment and extend the chain of trust into PCIe-attached devices.

Learn more about Cadence’s controller and PHY IP for PCIe on the PCIe and CXL landing page.

Accelerating RTL Development with the Cadence RTL Generation Agent

ErinGrant — Tue, 03 Nov 2026 12:30:00 GMT

Digital design teams face increasing pressure to deliver production-quality RTL faster, while still meeting aggressive power, performance, area, and verification goals. The Cadence RTL Generation Agent brings generative and agentic AI capabilities i...(read more)

The Memory Challenge of Physical AI

Joe C — Tue, 03 Nov 2026 04:54:00 GMT

Most AI hardware conversations start with compute, which is understandable since accelerators are visible, easy to compare, and often tied to headline performance metrics. Physical AI broadens that conversation by placing greater emphasis on how compute, memory, and data movement work together under real-world operating constraints. For intelligent systems that must see, interpret, decide, and act in the physical world in real time, it’s critical that the right data reaches the right engine at the right time.

As a result, data movement has become an increasingly important consideration when architecting physical AI systems. A physical AI device may simultaneously handle sensor streams, model weights, activations, temporary buffers, control loops, and safety functions. If memory access becomes unpredictable, compute engines can stall. Power consumption rises when data is moved too often, and poorly planned buffering can cause latency accumulation that is hard to recover from later.

As physical AI workloads become more complex, architects must now consider how predictably the complete system performs when multiple real-world workloads are active simultaneously.

Avoid Unnecessary Data Movement

Physical AI systems rely on a memory hierarchy that coordinates on-chip memory with larger-capacity external memory. LPDDR or GDDR may hold model weights, sensor data, activations, and other working data, while on-chip SRAM and cache keep the portions currently needed by the NPU, CPU, DSP, ISP, or other processing engines close to compute.

As workloads move through the processing pipeline, required data is transferred from external memory into on-chip memory, where it can be accessed and reused with lower latency and energy. The more effectively the architecture reuses that local data, the fewer times it must retrieve the same information from external memory. However, because SRAM and cache consume silicon area, their capacity is limited. Data that does not fit on-chip, or is used less frequently, remains in LPDDR or GDDR until it is needed.

This coordination is important because every unnecessary transfer across the memory hierarchy consumes energy, adds latency, and uses external-memory bandwidth. Physical AI systems are also constrained by device size, package complexity, power delivery, and thermal headroom. The goal is therefore not to eliminate external memory access, but to keep the right data close to compute for as long as it is useful and avoid moving it more often than necessary.

A well-planned dataflow coordinates compute engines, on-chip SRAM and cache, external LPDDR or GDDR, buffering, and interconnect around the workload. This helps keep compute resources productive while using external-memory capacity and bandwidth efficiently.

Real-World Applications Clarify the Tradeoffs

Humanoid robots, drones, autonomous vehicles, smart cameras, inspection robots, industrial robots, and autonomous mobile robots may all run local intelligence, yet each stresses memory and interfaces differently. Their architectures must determine which data should remain close to compute for immediate access and which should reside in higher-capacity external memory.

Humanoids may combine cameras, depth sensing, audio, inertial data, balance control, object recognition, path planning, and actuator feedback within a limited power and thermal envelope. If perception data arrives late, control decisions may be delayed. In addition, sustained performance drops and power rises if model weights and intermediate data are reloaded too often. In this kind of system, memory efficiency affects how smoothly the robot can perceive, decide, and move, all of which are key to successful real-time operation.

A drone or autonomous mobile robot has a different set of constraints. It may need visual navigation, obstacle avoidance, stabilization, object tracking, wireless communication, and video processing, all while staying within a limited power and thermal budget. Unnecessary external memory accesses reduce operating time, add heat, or introduce latency into the control loop. For these physical AI systems, bandwidth per watt is as important as raw bandwidth.

Autonomous vehicles and advanced driver assistance systems (ADAS) present an even greater challenge. With cameras, radar, lidar, ultrasonic sensors, vehicle telemetry, map data, and control functions, competition for memory access is fierce. Some data streams need continuous throughput, while others need fusion across sensor domains. Retaining relevant data long enough to support planning and decision-making is also an important consideration. In this environment, memory behavior affects both throughput and response predictability.

Memory Choices Must Follow the Workload

When building a memory architecture, architects should begin with the behavior of the physical AI workload itself. The objective is not simply to select the fastest external memory technology or provision the greatest possible bandwidth. It is to right-size the complete memory hierarchy, including local storage, external memory capacity, bandwidth, power, buffering, and integration, around the device’s data streams, reuse patterns, latency requirements, and operating constraints.

LPDDR and GDDR address different architectural priorities. LPDDR is often a strong fit when bandwidth per watt and memory capacity are needed to sustain local inference performance. When continuous image or sensor-stream bandwidth is the primary requirement, GDDR may be a viable option because its high bandwidth can meet those performance needs with fewer DRAM devices.

Available solutions give architects considerable flexibility in making this tradeoff. For example, Cadence offers

LPDDR6/LPDDR5X PHY and Controller IP supporting data rates up to 14.4Gbps, as well as GDDR7 PHY IP supporting data rates up to 36Gbps for high-bandwidth applications. These options allow the external memory interface to be aligned with the workload rather than treated as a one-size-fits-all design choice.

A humanoid robot may prioritize power-efficient access to model weights, perception data, and control information. A smart camera or autonomous-vehicle perception processor may place greater pressure on sustained vision-stream bandwidth. In each case, the architecture should keep frequently reused and latency-sensitive data close to compute while selecting an external memory interface sized for the remaining capacity and bandwidth requirements. This helps avoid both memory bottlenecks and unnecessary over-provisioning.

Device context	Examples	Primary pressure	Likely memory fit
Mobile physical AI devices	Humanoids, drones, autonomous mobile robots, robotic modules	Sustained local inference under size, capacity, bandwidth, and latency limits	LPDDR for bandwidth-per-watt and high DRAM capacity design; GDDR selectively for heavy vision streams
Vision-heavy physical AI devices	Autonomous vehicles, smart cameras, inspection robots, industrial vision systems	Continuous image or sensor streams with predictable response	LPDDR where memory capacity matters; GDDR when stream bandwidth dominates

Five Memory Architecture Decisions

Before selecting an external memory interface, architects should evaluate how the device’s dataflow and operating constraints affect five key areas:

Data locality: Which data should remain close to compute to meet latency, reuse, and energy-efficiency requirements, and which data should reside in external memory?
Traffic contention: Where will sensor, inference, software, safety, and control traffic contend for memory access?
External memory fit: Which external memory option best matches the device’s bandwidth, power, and integration needs?
Buffering strategy: How much local storage and buffering are needed to reuse data effectively and avoid unnecessary off-chip movement?
Latency predictability: Can the device keep latency bounded when multiple workloads are active?

A balanced memory architecture aligns data locality, traffic management, external memory selection, buffering, and latency predictability with the device workload. Together, these decisions help reduce unnecessary data movement, keep compute resources productive, and maintain predictable performance when multiple workloads operate concurrently.

Conclusion

Physical AI places intelligence inside devices that operate continuously, interact with real-world signals, and respond under power, thermal, latency, and reliability constraints. Meeting these demands requires compute, memory, and data movement to function as a coordinated system. Predictable data movement is crucial for physical AI devices to operate effectively under real-world conditions, making memory architecture an important part of the overall design. Selecting the right memory requires a careful balance of latency, power efficiency, bandwidth, buffering, and workload requirements. Architects must keep frequently used data close to the engines that need it, use external bandwidth efficiently, keep compute resources productive, and maintain predictable system behavior as workloads operate concurrently.

Learn more about how to architect physical AI systems with design IP in Cadence’s “Designing Physical AI Systems Under Real-World Constraints” white paper.

EuMW2026: Cadence Debuts GPU-Accelerated Clarity 3D Solver Solution

MSATeam — Mon, 02 Nov 2026 06:58:00 GMT

AI-enhanced Cadence technologies excited attendees at European Microwave Week 2026 (EuMW 2026) in London, UK, in October. Key highlights and demonstrations across multiple domains were:

AWR Design Environment: RF analysis and agentic AI capabilities
Virtuoso Heterogeneous Integration (VHI) and ViraStack: newest integration of Agentic AI into custom, analog, and mixed-signal integrated circuit (IC) design
System Design and Analysis (SDA): Multiphysics and signal/power integrity (Si/PI) solutions including Clarity 3D Solver, Allegro X, Sigrity X, and Celsius Thermal Solver
Workflow focus: Solutions enabled engineering teams to design, analyze, optimize, and signoff advanced RF-ICs, monolithic microwave integrated circuits (MMICs), modules, packages, and complete systems

Clarity Solver with GPU-Accelerated 3D Electromagnetics

The latest release of Clarity 3D Solver featuring graphical processing unit (GPU) acceleration debuted at EuMW. When used in combination with Cadence’s Millennium supercomputer, Clarity 3D Solver with GPU features the industry’s first FEM GPU solution, which is equivalent to 1000+ CPU cores with Millennium, 100+ CPUs similar performance per GPU, and up to 75% energy efficiency vs. CPU hardware.

Microwave Journal Interview

Gary Lytle, product management director at Cadence, sat down with Tim Rainier of Microwave Journal to discuss the company’s activities at the show. He commented that Cadence products are now being enabled with AI technology to support compressed design cycles that allow customers to make better products faster, reduce their time to market, and uncover unique designs. AI technology is helping designers look at a broader scope by adding its intelligence to make their existing designs better and faster.

Being introduced at the show is Clarity 3D Solver with GPU acceleration, the first-to-market solution with GPU-accelerated FEM technology that is delivering a 10-15X reduction in Cadence’s already fast simulation times. It is putting our customers in the engineering cockpit, making decisions in real time and being able to update their designs as they go through the process. Watch the video interview here.

Agentic AI for Design Verification and Debug

Vinod Khera — Thu, 29 Oct 2026 05:00:00 GMT

Each new generation in chip design makes chip verification more complex. Today, verification consumes 60-70% of the total engineering hours in chip design. Better methodologies, more automation, and additional compute have helped. Even with tho...(read more)

L&T Achieves 2–10X Faster Data Center Design with Reality Digital Twin Platform

Veena Parthan — Thu, 29 Oct 2026 03:30:00 GMT

Every data center design starts with a deceptively simple question: will the facility keep critical systems within safe thermal limits when conditions change? For hyperscale data centers and AI factories, the answer now carries much higher stakes. Hi...(read more)

Pre-Silicon Edge AI Verification: Skymizer and Palladium Z3 System Studio

HSV Marketing — Wed, 28 Oct 2026 19:00:00 GMT

As large language model (LLM) inference expands beyond hyperscale data centers into power-, memory-, and thermally constrained edge devices and enterprise-controlled on-premises systems, silicon complexity and verification workloads are increasing rapidly. Designing a complex architecture is only part of the challenge; validating the tightly coupled software stack—including compilers, runtime kernels, device drivers, high-speed interfaces, and memory subsystems—well before first silicon returns from the foundry is equally important.

Waiting for physical chips to begin system-software bring-up introduces significant program risk and can delay time to market.

Skymizer addressed this challenge by using Cadence Palladium Z3 System Studio to accelerate verification of its Language Processing Unit (LPU) and begin software bring-up months earlier.

Breaking Through the Simulation Wall

Skymizer develops LPU IP and silicon for on-device, edge, and on-premises LLM inference, supported by advanced compiler toolchains. Its architecture targets predictable latency and energy-efficient inference across constrained devices and enterprise systems.

Validating this next-generation architecture introduced three critical engineering hurdles:

Workload scale: Representative LLM verification workloads can require billions of clock cycles across transformer layers, memory traffic, and host-device interactions.
Hardware-software integration: Validating pure RTL in isolation is no longer sufficient. AI compilers, kernel runtimes, operating system drivers, PCIe Gen5 interfaces, and high-bandwidth LPDDR subsystems all must be validated together.
Simulation performance: Traditional RTL simulators take too long, often requiring days or even months to fully execute comprehensive AI workloads.

FPGA prototyping is valuable for high-speed software validation once a design is sufficiently stable. During earlier, iterative RTL bring-up, hardware emulation provides faster compile-debug turnaround, cycle-accurate execution, and deeper hardware-software visibility.

Shifting Software Validation Left

Skymizer deployed its pre-silicon LPU RTL model on the Palladium Z3 platform and connected it to an Ubuntu host through a PCIe Gen5 SpeedBridge and Emulation Development Kit (EDK).

This environment allowed real workloads, compilers, and drivers to interact with a cycle-accurate representation of the LPU before physical silicon was available.

For this design, the Palladium platform reduced compilation turnaround to approximately 10 minutes, enabling hardware and software teams to modify, compile, debug, and test multiple iterations within a working day.

Demonstrating Significant Acceleration

Skymizer recorded substantial performance gains when running AI workloads on Palladium Z3:

Workload	RTL simulation	Palladium Z3	Acceleration
TinyStories 260K	13.5 minutes	3 minutes	4.5X
Llama 3.2, 1B parameters	5.2 days	20 minutes	374.4X
Llama 3.1, 8B parameters	77 days, projected	36 minutes	3,080X

In these tests, acceleration increased with workload scale. For Llama 3.1 8B, the equivalent RTL-simulation runtime was projected at 77 days, while Palladium Z3 System Studio completed the same verification workload in 36 minutes—a 3,080X wall-clock acceleration. Acceleration figures compare the wall-clock execution time for equivalent pre-silicon verification workloads; they do not represent production inference throughput.

This acceleration allowed Skymizer to execute realistic workloads earlier, validate interfaces sooner, and complete more hardware-software iterations during development.

Accelerating Debug and Root-Cause Analysis

Speed alone is not enough. Engineers also need visibility into hardware behavior when software encounters an unexpected condition.

Using Palladium FullVision and the Software Debug Link, Skymizer could correlate software execution with cycle-by-cycle RTL activity at emulation speed. Engineers could investigate issues without recompiling the design solely to add debug instrumentation.

This brought hardware and software teams into a common verification environment, enabling integration issues to be identified and resolved earlier.

Reducing Verification Time by More than 90%

By adopting hardware-assisted verification, Skymizer:

Reduced end-to-end verification time by more than 90%
Shortened LPU and PCIe verification cycles from weeks to days
Started software bring-up months earlier
Improved software readiness before first silicon

Skymizer’s results demonstrate that market velocity increasingly depends on pre-silicon hardware-software validation.

In the fast-moving advanced AI SoC landscape, hardware design and software enablement cannot be sequential. Skymizer's experience shows how validating the complete system stack before first silicon helps engineering teams reduce program risk, protect schedules, and improve software readiness for edge and on-premises deployment.

Listen to the complete Skymizer story

Unraveling Streamlined Virtual Channel Extended Capability (SVC)

Igor Krause — Wed, 28 Oct 2026 00:30:00 GMT

Introduction

The Streamlined Virtual Channel Extended Capability (SVC) was introduced on Specification 6.1 to address limitations of the traditional PCIe ordering model in modern multi-host fabrics. While earlier mechanisms such as Relaxed Ordering (RO) and ID-Based Ordering (IDO) provided partial solutions, they did not fully solve the challenges associated with multiple traffic paths and fabric-wide traffic management. The traditional PCIe ordering mechanisms solve ordering at the transaction level, but they don't provide a mechanism for coordinating TC-to-VC assignments when multiple hosts and paths share switching resources. SVC introduces a standardized approach for TC-to-VC assignment across a PCIe fabric, allowing a Fabric Manager to establish consistent traffic policies and avoid conflicts that can occur when multiple hosts share the same switching infrastructure. This blog provides an overview of SVC features.

Feature Compatibility

A Port may implement the SVC Extended Capability alongside traditional Virtual Channel (VC) or Multi-Function Virtual Channel (MFVC) capabilities. However, UIO support is exclusively tied to the SVC architecture and cannot be provided through the legacy VC or MFVC mechanisms.

Although UIO operation is supported only in Flit Mode, the SVC capability itself is not limited to Flit Mode operation. In Non-Flit Mode, the SVC structure may still be used to support TC-to-VC mappings for non-UIO traffic.

Initialization and Software Control

To maintain backward compatibility with existing PCIe software, when a Link is brought up, VC0 is automatically initialized in each VC and MFVC capabilities, while VC0 within the SVC capability remains disabled. This allows software that is not aware of SVC to continue operating using the traditional VC architecture without any changes.

Although a Port may implement both SVC and VC/MFVC capabilities, the two mechanisms are mutually exclusive from an operational perspective. Hardware guarantees that SVC and VC/MFVC capabilities cannot be enabled simultaneously on the same Port.

For Ports that support both architectures, it is the responsibility of SVC-aware software to determine which mechanism should be used. Before operating with the legacy VC/MFVC architecture, software clears the Use VC/MFVC bit in the SVC Port Status register. This action immediately disables all VC resources associated with the VC/MFVC capabilities and enables VC0 in the SVC capability. Once cleared, the Use VC/MFVC bit remains in that state until the next Conventional Reset, ensuring a consistent operating model and reducing both hardware and software complexity.

In ports that implement only the SVC capability, the Use VC/MFVC bit is hardwired to 0b. As a result, VC0 within the SVC capability is automatically initialized during Link training, allowing the Port to operate directly using the SVC.

The number of available SVC Virtual Channels (besides VC0) is reported through the SVC Extended VC Count field located in the SVC Port VC Capability Register 1. Software uses this field to determine the number of extended SVC Resource registers.

Streamlined Virtual Channel Extended Capability Structure

The Streamlined Virtual Channel (SVC) Extended Capability is an optional PCIe Extended Capability structure that must be implemented by Ports supporting features that depend on it, including Unordered I/O (UIO).

The location of the SVC Extended Capability within a PCIe component depends on the Port type:

For an Upstream Port (USP), the SVC Extended Capability may be implemented only in Function 0. When present, that single instance applies to all Functions associated with the Port.
For a Downstream Port (DSP), the capability may be implemented directly within the Port.
The capability may also be implemented within a RCRB.

Additional implementation requirements apply to switches. If an SVC Extended Capability is implemented in a Switch Upstream Port containing one or more Switch USP Functions, the capability must also be implemented in all associated Switch Downstream Port Functions. This ensures consistent SVC behavior throughout the switch hierarchy.

For Root Complexes, implementation is flexible. A system may choose to implement the SVC Extended Capability on some Root Ports while omitting it from others, depending on the requirements of the platform.

Enabling UIO Traffic in SVC

Not all Virtual Channels (VCs) support Unordered I/O (UIO) traffic. The supported protocols for each VC can be determined by examining the SVC VC Protocols Supported field (bits [11:8]) of the SVC Resource Capability Register. A value of 0010b or 0011b indicates that the VC is capable of carrying UIO traffic.

SVC Resource Capability Register

Before enabling UIO, the legacy VC/MFVC mechanism must be disabled. This is accomplished by clearing the Use VC/MFVC bit (bit 0) in the SVC Port Status Register (Offset 10h). Since this field is defined as Write-to-Clear, writing a value of 1 clears the bit and transitions the Port to SVC-based operation.

SVC Port Status Register (Offset 10h)

Once SVC is active, UIO can be enabled on a Virtual Channel by programming the SVC VC Protocol Selected field (bits [11:8]) in the SVC Resource Control Register to 0010b and setting the SVC VC Enable bit in the same register. This configures the selected VC to carry UIO traffic.

Traffic Classes associated with the Virtual Channel are configured through the SVC TC/VC Map field (bits [7:0]) of the SVC Resource Control Register. This field defines which Traffic Classes are mapped to the VC, allowing UIO and non-UIO traffic to be routed according to the desired fabric policy.

SVC Resource Control Register

This configuration process enables software to establish the Virtual Channels that will carry UIO traffic while maintaining explicit control over TC-to-VC mappings across the PCIe fabric.

Verification Challenges and Solutions

While the Streamlined Virtual Channel Extended Capability simplifies the deployment and management of Traffic Class to Virtual Channel mappings within a PCIe fabric, it introduces several new verification considerations. Verification environments must ensure that SVC initialization and enablement behavior strictly follows the specification requirements, particularly in implementations that support both SVC and traditional VC/MFVC capabilities. Since these mechanisms are mutually exclusive, validating the transitions between operational modes and guaranteeing that conflicting configurations cannot exist simultaneously becomes an important aspect of compliance testing.

The SVC capability introduces new configuration registers, status fields, and control mechanisms that software relies on to determine available Virtual Channel resources and control fabric behavior. Any mismatch between the implemented hardware behavior and software expectations can lead to interoperability issues that may not be immediately visible during basic functional testing.

Additional challenges arise when validating UIO support. Because UIO is exclusively associated with the SVC architecture and is limited to Flit Mode operation, verification environments must ensure that UIO traffic is correctly associated with the required Virtual Channels and that unsupported configurations are properly handled. At the same time, SVC behavior in Non-Flit Mode must also be validated, as the capability remains available for TC-to-VC mapping even when UIO functionality is not present.

The importance of SVC becomes more apparent in multi-host and fabric-based deployments. In these environments, traffic originating from multiple hosts may traverse shared Links and switching resources, making consistent TC-to-VC assignments critical for predictable system behavior. Verification must therefore extend beyond individual Port functionality and evaluate end-to-end fabric operation, ensuring that traffic classifications, Virtual Channel assignments, and routing behaviors remain consistent throughout the fabric.

Learn More

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

PCI Express Security and TEE Integration, Part 1 - Establishing Trust

RajeshPamujula — Wed, 28 Oct 2026 00:00:00 GMT

Security Foundations for PCIe: Establishing Trust Beyond the CPU

As AI infrastructure evolves toward multi-GPU servers, rack-scale architectures, composable infrastructure, and disaggregated data centers, PCI Express® (PCIe®) has become far more than a peripheral interconnect. Today, PCIe serves as the primary connectivity fabric between CPUs, GPUs, AI accelerators, SmartNICs, storage controllers, memory expanders, and chiplets. Sensitive data, proprietary models, cryptographic keys, and confidential workloads increasingly traverse PCIe links.

This evolution fundamentally changes the security requirements of PCIe-based systems. Historically, most PCIe traffic remained within a trusted server chassis. Physical access to the interconnect was difficult, and the operating system or hypervisor was generally assumed to be trustworthy. Those assumptions no longer hold. Modern deployments may involve confidential computing workloads that explicitly do not trust the hypervisor. PCIe traffic may travel across switches, retimers, cable connections, composable infrastructure fabrics, and accelerator modules that reside outside the traditional trust boundary.

As a result, protecting processor memory alone is no longer sufficient. The entire I/O path must become part of the trusted computing architecture.

To address this challenge, PCI-SIG® has developed a suite of complementary security technologies, including Data Object Exchange (DOE), Component Measurement and Authentication (CMA), Integrity and Data Encryption (IDE), and the TEE Device Interface Security Protocol (TDISP). Together, these technologies extend security beyond the CPU and memory subsystem to encompass PCIe-attached devices and the communication paths between them.

Understanding Trusted Execution Environments

Before discussing PCIe security mechanisms, it is important to understand the concept of a trusted execution environment (TEE).

A TEE is a hardware-protected execution domain that isolates sensitive applications and their data from the rest of the system. Intel TDX and AMD SEV-SNP are examples of TEE technologies. Arm Confidential Compute Architecture (CCA) uses the Realm Management Extension (RME) to support isolated execution environments called Realms. TEEs allow sensitive workloads to execute without trusting the operating system, hypervisor, or other software outside the workload's trusted computing base (TCB).

While TEEs provide strong protection for CPU execution and memory, they create a new challenge: how can a trusted workload safely communicate with external devices?

Consider a confidential AI training workload running inside a TEE. The workload may need direct access to GPUs, DPUs, storage devices, or network adapters. Simply assigning a PCIe device to the workload is insufficient because neither the communication path nor the device itself may be trusted. PCIe security technologies bridge this gap.

The Security Foundation: DOE, SPDM, and CMA

Before devices can exchange encrypted traffic, trust must first be established. Therefore, PCIe security begins with three foundational technologies.

DOE

Data Object Exchange (DOE) provides a standardized mechanism for exchanging management and security messages between PCIe components. Think of DOE as a mailbox built into the PCIe fabric through which security protocols communicate.

Rather than defining security itself, DOE provides the transport mechanism used by higher-level protocols. PCI-SIG describes DOE as the mechanism for transporting security-related data objects between hosts and PCIe devices.

SPDM

Security Protocol and Data Model (SPDM) is a security protocol developed by the Distributed Management Task Force (DMTF).

SPDM enables:

Device authentication
Firmware measurement collection
Secure session establishment
Key exchange
Attestation

In practical terms, SPDM allows a host platform to verify that a PCIe device is genuine, running approved firmware, and operating in an expected security state before trusting it.

CMA

Component Measurement and Authentication (CMA) is the PCI-SIG architecture that applies SPDM specifically to PCIe systems.

CMA establishes how PCIe components perform authentication, collect measurements, and exchange attestation information. Together, DOE, SPDM, and CMA form the control-plane foundation used by higher-level PCIe security protocols.

A useful analogy is transport layer security (TLS) on a secure website. Before encrypted communication begins, both parties must establish identity and exchange cryptographic information. CMA and SPDM serve a similar purpose for PCIe devices.

From Trust Establishment to Trusted Communications

DOE, SPDM, and CMA establish the control-plane trust needed before a PCIe device can exchange protected traffic or be assigned to a confidential workload. Once a device has been authenticated and its security state validated, IDE protects data moving across the PCIe fabric while TDISP enables secure assignment of the device to a TEE.

Together, these technologies extend the chain of trust beyond processor execution and memory, allowing confidential workloads to communicate securely with PCIe-attached accelerators, storage devices, and network interfaces. Figure 1 illustrates how these capabilities build upon one another within the PCIe confidential computing architecture.

Figure 1: PCIe Confidential Computing Security Architecture (image generated by Microsoft Copilot)

Establishing the Foundation for Protected PCIe Communications

DOE, SPDM, and CMA establish the control-plane trust required to authenticate devices and validate their security state. Once trust is established, the next step is to protect transaction data as it moves between components.

Part 2 of this series will examine how IDE provides confidentiality, integrity protection, and replay protection across PCIe links and fabrics.

For more information on Cadence's controller and PHY IP solutions for PCIe, visit the PCIe and CXL landing page.

Who Signs the Tapeout? Ziyad Hanna on AI Chip Design – Wearing Flip-Flops

Corporate — Tue, 27 Oct 2026 18:00:00 GMT

An AI agent writes the RTL, builds the testbench, runs the regressions, and closes coverage. Then an engineer signs the tapeout. What exactly is that engineer signing? Ziyad Hanna, Corporate Vice President of R&D and Strategic Head of AI at Cade...(read more)

fJscaler, GF, and Cadence Collaborate to Scale Optical Interconnects for AI

Corporate — Tue, 27 Oct 2026 17:00:00 GMT

Unified EIC/PIC Co-Design and Strategic Foundry Collaboration Helps fJscaler Develop Advanced Optical Engines for AI Infrastructure fJscaler is named after a unit of energy so small that it takes a quadrillion of them to make a single joule. That is ...(read more)

Agentic AI for RF Design: A Practical Path to Faster Execution

StandingWaves — Tue, 27 Oct 2026 15:30:00 GMT

How Cadence AI supports greater engineering productivity In RF design, the most useful AI is not a generic assistant detached from an engineering context. It is AI that helps designers move faster through the work that consumes real product developme...(read more)

Why Every Modern Vehicle Is Becoming a Software Problem

PMM Michael — Tue, 27 Oct 2026 14:00:00 GMT

For more than a century, automotive innovation was measured in horsepower, fuel efficiency, mechanical reliability, and manufacturing precision. Today, a new battleground is emerging. Increasingly, the most important innovations in a vehicle are not...(read more)

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.

Romax 2026.2: A First Look at the Next Chapter in Drivetrain Simulation

Pankaj Pawar — Tue, 27 Oct 2026 07:20:00 GMT

Larger Models. Faster Insight. More Confident Decisions. Engineering teams are being asked to do more and to do it faster. Electrification, increasing competition, and new market entrants are raising the pressure to deliver innovative products quick...(read more)

Generating High-Quality Data for Turbomachinery Machine Learning

Veena Parthan — Tue, 27 Oct 2026 03:30:00 GMT

Inverse design and high-fidelity CFD enable ML predictors that accelerate optimization and design-space exploration with smaller datasets.(read more)

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

在云中运行 Clarity 3D Solver，对复杂系统进行电磁分析

SDA China — Fri, 23 Oct 2026 01:00:00 GMT

核心结论：Cadence Clarity 3D Solver Cloud 通过与 Amazon Web Services（AWS）的安全连接，将 3D 有限元法（FEM）电磁仿真容量从 32 个 CPU 内核扩展至数千。在 PCB 测试用例中，仿真速度提升 6 倍至 20 倍，内存使用减少 50% 至 75%；在 IC 封装测试用例中，平均性能提高 10 倍。一、为什么复杂系统的 3D 电磁仿真需要云？超大规模计算、航空航天、工业物联网（IIoT）和汽车等领域对智能系统的需求不断增加，设计...(read more)

Cadence OrCAD X and Allegro X 26.1 Is Now Available

AllegroReleaseTeam — Thu, 22 Oct 2026 20:47:00 GMT

The Cadence OrCAD X and Allegro X 26.1 release is now available from Cadence Downloads, delivering significant enhancements across PCB design, package design, system-level design, simulation, and analysis workflows. Here is a summary of the key updates.

Allegro X PCB Editor and Allegro X APD

IPC-compliant footprint generation from an extensive library of standard templates, with support for automatic footprint regeneration.
Dynamic shape editing through the new Dynamic mode, enabling real-time shape updates and visual feedback during editing.
Component-level Design for Assembly (DFA) checks directly within the layout environment.
Enhancements to X AI routing technologies and new X AI Power/Ground Generator, improving routing productivity.
ECAD-MCAD co-design workflow enhancements that streamline collaboration workflows.
System-level design exploration in 3DX Canvas, with support for multiple boards and system connectivity in a unified 3D environment.
Simplified daisy-chain creation and editing for package designs.
SPICE-compatible RLGC models for advanced analysis workflows.
Parameterized structure creation and reuse for evaluating high-speed design alternatives.

Allegro X System Capture

System-level design enhancements, including support for 3D system exports and MCM board integration.
Integrated analysis enhancements in Layout Mode, including RLGC model extraction and LayoutLink-based reflection analysis workflows.
Reusable reliability parameter libraries for consistent application of validated reliability data across projects.
Preservation of Pulse custom variables in project archives to support design handoff and collaboration workflows.
Productivity improvements through schematic Minimap navigation and workspace window stacking.
Enhanced differential pair creation using Constraint Manager capabilities.
Improved pin delay import workflows with automatic data detection, validation, and pre-import review capabilities.

Enhanced module support and streamlined module management workflows for more efficient selection, management, and reuse of module instances.
Enhanced measurement capabilities for more accurate point-to-point and multi-segment distance measurements.
Customizable Heads-Up Display (HUD) and cursor settings that improve visibility, readability, and navigation.
Flexible pin renumbering capabilities that accelerate footprint creation and updates through support for multiple numbering patterns, numbering formats, and direct pin editing.
Net Override and Rule Set views that simplify constraint management by making it easier to identify overrides, enforce constraint inheritance, and manage net-specific design rules.
Improved visibility controls, streamlined layer navigation, and faster access to display views that enhance design productivity.

PSpice and PSpice Advanced Analysis

Persona-based simulation configuration for faster simulation setup and improved consistency across projects.
Additional component libraries from Murata and TAIYO YUDEN, expanding available simulation content.
Intelligent, condition-based model and subcircuit selection for more flexible and adaptable simulation workflows
Ambient temperature-based resistor derating for enhanced stress (smoke) analysis workflows.
Enhanced high-frequency resistor thermal noise modeling with quantum-corrected calculations.
Generic MATLAB and Tcl measurement functions for advanced custom analysis and verification workflows.

Sigrity X Aurora and Topology Workbench

Signal behavior and analysis improved across multiple connected PCB and package designs.
Multi-design reflection analysis enhanced with reusable System Configuration and LayoutLink files.
DDR measurement reporting optimized for next-generation memory technologies through support for LPDDR6 and HBM4.
Serial-link validation accelerated with multi-channel analysis, comprehensive channel characterization, and PCI Express® Gen 7 compliance support.
Waveform review and debug enhanced with advanced measurements, curve filtering, CSV export, enhanced result management, and the new Grid Curve Viewer for side-by-side waveform analysis.
Circuit simulation and analysis streamlined with direct generation of SPICE-compatible RLGC circuit models from layout structures in the IME workflow.
Complex system modeling simplified with support for IBIS-Electrical Module Description (EMD) models, linear buffer models, and automatic Broadband SPICE model extraction.
Signal and memory-interface validation streamlined with transient circuit simulation directly within Serial Link Analysis and support for simultaneous read/write cycle simulations.

For complete details, refer to the What's New documentation for release 26.1 and the accompanying README_CCR.txt file on the Cadence Downloads site.

If you have questions or feedback, send them to pcbbloggers@cadence.com.

To receive release announcements and related information directly in your mailbox, subscribe to the PCB Design blog.

Allegro Release Team