SoC and IP

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

2026-11-03T12:37:00Z

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.

The Memory Challenge of Physical AI

2026-11-03T04:54:00Z

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.

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

2026-10-28T00:00:00Z

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.

Data Movement Enabling Physical AI

2026-10-22T16:00:00Z

Most discussions around physical AI center on the models and compute that enable robots, vehicles, drones, and other autonomous machines to see, reason, and act in the physical world. Both matter, but these machines are more than the models and compute inside them. Each relies on a chain of sensors, compute, and actuators connected by a series of links. Data has to move through that chain on time and without errors for the machine to act correctly.

Physical AI must operate locally without depending on a connection to the data center. But the AI factory remains essential for simulation, model training, testing, and retraining before updated models are deployed back to the machine.

This post examines the three networks involved across this lifecycle. Each has its own challenges, and only one operates inside the data center.

Inside the machine: Sensors capture the surrounding environment, onboard compute interprets the data and makes decisions, and actuators turn those decisions into physical action. This see-reason-act loop runs continuously under strict timing, reliability, and safety constraints.
Between the machine and the data center: Outside the real-time control loop, deployed machines selectively send operational data back for analysis, simulation, and model improvement, while tested and approved model updates are delivered securely to the machines.
Inside the data center: AI factories use collected and synthetic data to train, test, and refine the models that will ultimately run on the machine. This work distributes demanding simulation and AI workloads across large numbers of interconnected accelerators.

Figure 1: Physical AI runs on three networks

The rest of this post examines each network.

Inside the Machine: Latency, Reliability, and Safety

Inside a physical AI machine, data crosses several different interfaces between the moment a sensor captures something and the moment an actuator responds. Each hop uses the interface built for it, and each hop has a deadline.

Figure 2: Inside the machine, every hop is a different interface with a deadline

Cameras, radar, and lidar connect to compute over sensor interfaces such as MIPI CSI-2 and automotive SerDes, or over automotive Ethernet where sensors are aggregated by a zone controller. Inside the compute module, the NPU, CPU, and memory talk over an on-chip interconnect and memory interfaces such as LPDDR. Traditionally, the CPU, NPU, and other processing elements have been integrated into a monolithic SoC, but we are seeing more designs move toward chiplet-based architectures connected over UCIe.

Storage and additional accelerators attach over PCI Express® (PCIe®) and Compute Express Link (CXL). Commands go out to motors, brakes, and joints over deterministic networks: Time-Sensitive Networking (TSN) Ethernet in vehicles, EtherCAT in robots, and controller area network (CAN) for simpler nodes. Humanoid platforms coordinate 30 to 40 servo axes this way with sub-millisecond synchronization.

While the interfaces differ, the requirements do not, and three of them govern every hop:

Worst-case latency

A control loop does not care about average delay. It cares whether the slowest transfer still arrives on time. On the sensor side, that means a frame has to be in memory before the model needs it. On the actuator side, it means a command has to reach the motor before the next control cycle. Deterministic networking exists for this: TSN on Ethernet aligns every node to a common clock and reserves slots for control traffic, so a brake command is never queued behind a camera frame. The same idea, a bounded and predictable delay rather than a fast average, has to hold on PCIe, on the memory interface, and on the die-to-die link once chiplets arrive, or the deadline is missed somewhere else in the chain.

Reliable delivery

In a data center, a dropped packet can often be retransmitted without affecting physical safety. Inside a machine, a lost brake command or joint update may not be recoverable within the control deadline. A retry that completes inside the link, in nanoseconds, is acceptable. A retry that reaches software is not, which is why error correction, link-level replay, redundancy, and fault detection are built into the interface itself rather than handled above it.

Safety and security

The interfaces have to support functional safety through fault detection and diagnostic coverage, enabling the system to meet ISO 26262 and applicable Automotive Safety Integrity Level (ASIL) requirements in vehicles, or IEC 61508 and applicable Safety Integrity Level (SIL) requirements in industrial and robotic systems. And every link has to be secured at line rate. A spoofed sensor frame in a data center is a data breach. In a vehicle, it is a collision.

The interfaces inside the machine are part of the control system, not data pipes.

Between the Machine and the Data Center: Volume, Selection, and Secure Updates

The link between a deployed machine and the data center gets the least engineering attention because no single packet on it is time-critical. Nothing crashes if an upload is late. But this is the link that determines whether the model on the machine improves over time, and it has its own three problems.

Figure 3: Between the machine and the data center, a little data goes up, and one model comes down

Volume

A deployed autonomous vehicle is commonly estimated to generate several terabytes of sensor data per day, with some operators citing 4 – 5 TB per hour of raw data. A fleet of a few thousand machines produces more raw data in a day than it can practically upload, and far more than a data center can usefully label. The raw stream has to stay on the machine. The fraction that leaves is compressed and batched, sent opportunistically when the machine is on Wi-Fi at a depot or charger, or pulled over a wired service port such as USB4, rather than in real time over cellular. The in-machine network has a role here that is easy to miss: the same in-machine backbone that feeds the compute module also has to feed on-board storage and the telematics unit without stealing bandwidth from the control loop.

Selection

Choosing that fraction of data that goes back is a design decision that shapes the next model. The useful data is the data the current model handled badly: scenarios where its confidence was low, it disagreed with a human driver or operator, a safety intervention fired, or a newer model running in shadow mode would have chosen differently. That triage runs on the machine, on the same compute that runs inference, which means part of the edge compute budget is spent deciding what the data center should learn from. Right-sized inference includes providing enough compute to run the model and select useful data without exceeding the machine's power, thermal, and size limits. The better the selection, the smaller the upload and the faster the model improves.

Secure updates

The retrained model comes back over the air, and this is where the link becomes safety-critical after all. An update changes how the machine behaves. Every deployed machine has to verify that the update was signed by the right authority, has not been altered in transit, and is the version intended for that hardware. Rollouts are staged, beginning with a subset of deployed machines and retaining a path to rollback if the new model behaves unexpectedly. Secure model delivery is one part of trusted execution, which protects data, models, and devices across the full lifecycle. Vehicle regulation now requires this: UN Regulation No. 156 mandates a software update management system for type approval, and ISO 24089 defines the engineering process behind it. Robotics fleets do not yet face the same rules, but the operators running them face the same risk.

This exchange supports continuous model improvement after deployment. Although the machine operates independently in real time, the cadence of data collection, retraining, validation, and secure deployment determines how quickly its models can improve.

Inside the Data Center: Synchronization, Utilization, and Lossless Scale

The AI factory supports the model lifecycle of a physical AI machine, from simulation and training through testing, validation, and retraining. Its data center fabric connects the accelerators performing this work at scale

The model layer has moved from task-specific networks to foundation models. Vision-language-action models take camera input and language instructions and generate actions end to end. World foundation models create physically plausible video so that policies can train on synthetic scenarios before they interact with real objects. Simulation generates much of the training data, and model training consumes it at AI factory scale. Before deployment, the trained model's inference performance, accuracy, and reliability are tested in the data center. Once validated, the model is deployed to the machine, where inference runs locally.

Figure 4: Inside the data center, scale-up and scale-out as one execution path

The infrastructure that trains a robot policy is also the infrastructure that trains a language model. Thousands of accelerators exchange parameters, activations, and gradients across a scale-up fabric inside the pod and a scale-out fabric across pods.

Training and testing these models place the same fundamental demands on AI infrastructure as other large-scale AI workloads: synchronization, high utilization, and lossless operation at scale.

Synchronization

Collective operations have to be completed before the workload advances. If one accelerator is waiting on a slow link, every accelerator in the group waits with it.

Utilization

Installed bandwidth is not delivered bandwidth. Retransmissions, congestion, and header overhead all reduce how much of the fabric actually carries model state. Link-level retry, credit-based flow control, and compact headers exist to close that gap.

Lossless operation at scale

A fabric of thousands of endpoints must remain lossless under load, across multiple paths, without head-of-line blocking. UALink for scale-up, Ultra Ethernet for scale-out, and Ethernet for Scale-Up Networking (ESUN) are standards being defined to do exactly that.

One Connectivity Strategy Across the Physical AI System

Inside a physical AI machine, sensor interfaces, memory links, interconnect fabrics, and in-machine networks form the real-time path from sensing to action. Separately, connectivity between the machine and the AI factory supports data collection, model training, testing, and secure deployment, but the machine does not depend on that connection to operate.

In practice, these networks may be sourced from different vendors and designed by different teams. A sensor interface may come from one supplier, a PCIe controller from another, and the Ethernet MAC from a third, while the training cluster is designed by a separate team. Each handoff can introduce differences in verification methodology, safety support, driver models, and definitions of silicon-proven IP. Connectivity IP must interoperate across these boundaries, making it a key point of integration risk.

Optimizing each network in isolation does not address integration across the broader physical AI system. Inside the machine, latency, determinism, reliability, and security directly affect real-time operation. Between the machine and the AI factory, secure and efficient data movement supports model improvement and deployment. These networks have different requirements, but they should be considered as part of one connectivity strategy.

Cadence Connectivity IP for Physical AI

Cadence provides connectivity IP for both physical AI machines and the AI infrastructure used to develop their models. Inside the machine, the portfolio includes MIPI sensor interfaces, LPDDR memory interfaces, PCIe and CXL controllers and PHYs, automotive Ethernet controllers with TSN support, USB interface IP, and UCIe controller and PHY IP for chiplet-based architectures. Cadence also provides verification IP for interface integration and verification.

Inside the AI factory, the Cadence portfolio includes High-Speed Ethernet controller IP up to 1.6T, scale-up and scale-out SerDes PHYs, ESUN-ready controller IP with link-level retry and credit-based flow control, and UALink 200G controller and PHY IP running in 3nm silicon.

For teams moving physical AI compute to chiplet-based architectures, Cadence offers the Physical AI Chiplet Platform and the Chiplet Spec-to-Packaged Parts ecosystem. These solutions bring system, CPU, accelerator, and connectivity chiplets together in a pre-verified multi-die platform.

As physical AI moves from prototypes to widespread deployment, performance will depend not only on the compute inside each machine, but also on how reliably and predictably data moves through the see, reason, act loop.

To learn more, explore the Cadence white papers "Designing Physical AI Systems Under Real-World Constraints" and "Building AI Factories With IP Solutions".

How a Multi-Protocol PHY Simplifies Physical AI Connectivity

2026-10-21T23:28:00Z

Physical AI systems must move large amounts of data across two very different connectivity domains. Accelerators and local storage need high-bandwidth, low-latency links close to the compute SoC, while sensors and control modules require reliable connectivity across the larger platform. Supporting both domains with separate high-speed PHYs can increase silicon area and integration complexity.

Consider an autonomous mobile robot moving through a warehouse. Cameras and lidar continuously capture its surroundings, and an AI accelerator processes those inputs for object detection, localization, and path planning. Control modules send commands to motors and actuators, while selected sensor and inference data are written to local storage. All of this happens at once, so both connectivity domains must stay active while the robot operates.

PCIe 5.0 and Ethernet map naturally onto these two domains. PCIe 5.0 provides the local connection to accelerators and storage. Ethernet carries traffic across the larger platform, and this article focuses on 25G Ethernet. The demonstration shown above uses 25GBASE-KR, the 25G Ethernet interface defined for electrical backplane-style channels.

Instead of implementing a dedicated PHY for each protocol, designers can use a multi-protocol PHY: a single high-speed PHY whose lanes can be configured for different interface standards. Multi-protocol PHYs can support additional standards as well, but the PCIe 5.0 and 25G Ethernet pairing offers a clear example of how the approach works. Separate lanes are assigned to each protocol, allowing both to operate concurrently without duplicating the PHY.

PCIe 5.0 and 25G Ethernet operation within a multi-protocol PHY for physical AI connectivity

Assigning Traffic and Lanes

PCIe 5.0 is suited to traffic that stays close to the compute SoC. In the warehouse robot, it can connect the SoC to an NPU, GPU, NIC, or NVMe SSD, carrying sensor data, model data, intermediate results, and inference output between high-performance components.

25G Ethernet serves the rest of the platform. It can link camera and sensor modules, distributed compute, and control subsystems located elsewhere in the robot, so physically separated modules can exchange data without routing everything through the local PCIe fabric.

The two paths are separate but closely linked. Sensor data arrives over 25G Ethernet and moves to the AI accelerator over PCIe 5.0. The resulting inference output then drives a control decision while selected information is written to storage. Because these activities overlap during normal operation, both links must carry traffic at the same time.

A multi-protocol PHY meets this requirement by dividing its lanes between the two protocols. One lane group operates as PCIe 5.0, while another operates as 25G Ethernet. Each lane is configured for a single protocol, so no individual lane carries PCIe and Ethernet traffic simultaneously. Concurrency comes from running both lane groups in parallel within the same PHY.

Simultaneous PCIe 5.0 and 25G Ethernet (25GBASE-KR) operation over separate lanes of a multi-protocol PHY

Reducing PHY Duplication

Without a multi-protocol PHY, the design needs one PHY for PCIe and another for Ethernet. Each brings its own high-speed analog circuitry, clocking resources, lane planning, physical integration work, and verification effort.

Robots, drones, smart cameras, and other autonomous machines operate within practical limits on silicon area, package size, power, thermal capacity, and cost. A second PHY consumes resources that could otherwise go to compute, memory, control functions, or other product features. Consolidating PCIe 5.0 and 25G Ethernet onto one multi-protocol PHY avoids that duplication.

The savings apply at the PHY level. PCIe and Ethernet still require their own digital functions: a PCIe controller, an Ethernet MAC/PCS, and the associated integration logic. The multi-protocol PHY provides the physical lanes for both protocols; it does not combine or replace those digital subsystems.

Adapting the Lane Plan to the Product

The balance between PCIe and Ethernet varies by application. A robot with several local accelerators may need more PCIe bandwidth, while a platform with many cameras, sensor modules, or control units may need more 25G Ethernet links. Autonomous mobile robots, humanoids, drones, and industrial machines often share similar compute and sensing functions, yet the number and placement of their accelerators, sensors, storage devices, and control modules can differ considerably.

A configurable multi-protocol PHY lets the lane allocation follow those requirements. Designers can start from a common PHY architecture and assign lanes to PCIe 5.0 or 25G Ethernet for each product. Across a product family, one variant can dedicate more lanes to accelerator traffic while another reserves more for platform connectivity, without redesigning the PHY each time, provided it supports the required configuration.

Planning the Configuration Early

Concurrent operation must be planned from the start of the design. It should not be assumed simply because a PHY supports both protocol standards.

The intended configuration must account for the number of lanes assigned to each protocol, PCIe link width, Ethernet port configuration, PLL resources, reference clocks, firmware support, and compliance requirements. Clocking deserves particular attention because PCIe and Ethernet may use different reference clock assumptions. Some mixed-protocol arrangements may also raise compliance considerations when PCIe links operate at lower generations, so the full set of operating modes should be reviewed, not only the maximum data rates.

Defining the protocol mix, lane allocation, and clocking strategy early gives the design team time to select the right PHY configuration and verify that every intended operating mode is supported.

Conclusion

Physical AI systems need both high-bandwidth local links and reliable connectivity across the platform. A multi-protocol PHY addresses both domains with a single PHY, running PCIe 5.0 and 25G Ethernet concurrently on separate lanes. The result is less PHY duplication, more efficient use of silicon area and integration resources, and the flexibility to rebalance lanes as product requirements change.

To learn more about Cadence's multi-protocol PHY solutions for Physical AI, visit cadence.com or watch the video, "Cadence Multi-Protocol PHY Demo: Simultaneous PCIe 5.0 and 25G Ethernet Over a Unified Interface".

When AI Moves the World: Building a Chiplet Standard for Physical AI

2026-10-16T13:00:00Z

Introducing a new OCP FCSA sub-project workstream for real-time, safety-critical physical AI systems

Most AI systems return an answer. Physical AI systems must return a motion: a steering correction, a robotic arm trajectory, or an emergency stop. The output is not a prediction on a screen. It is a force applied to the world, on a deadline, often with people nearby.

That difference changes what the silicon underneath must guarantee. If that silicon is no longer one monolithic die but a package of potentially independently sourced chiplets, those guarantees stop being any single supplier's problem to solve.

To address this, a new physical AI sub-project workstream is being introduced under the Open Compute Project's Foundation Chiplet System Architecture (OCP FCSA). Its purpose is to extend the data center, cloud, and server-centric FCSA baseline with the specification requirements to satisfy real-time, safety-critical physical systems, while retaining everything FCSA already defines.

What Makes Physical AI Different

A physical AI system must perceive, reason, and act safely within real-world boundary conditions to address the determinism and criticality required in physical world interaction. Because decisions directly affect physical behavior, six constraints apply to every design.

Perceiving and Reacting

Sensor fusion: One-time-valid view of the environment from camera, radar, and lidar
Deterministic timing: Bounded, repeatable latency from sensing to action, worst case. and not just average

Acting Safely

Reliability and safety: Detect faults, report them, and reach a safe state within the deadline
Security and trust: No untrusted actor can command physical motion or alter safety behavior

Across the Whole Platform

Power and thermal efficiency: Sustain performance inside a fixed power envelope
Multi-chiplet scalability: One architecture that grows across product tiers and suppliers

Figure 1. Physical AI constraints

Why Chiplets Matter, and What They Complicate

Chiplets are compelling for physical AI for four reasons: scalable composition of compute (Including CPU and AI scaling), sensor, memory, safety, security, and I/O across product tiers; function partitioning, where sensor, AI, memory, safety, and actuator functions can span several dies; independent sourcing from different suppliers on different update schedules; and reuse, letting one architecture scale from entry-level to high-end products.

That flexibility is genuinely needed. Physical AI platforms do not share a single architectural profile. Preliminary comparison across representative categories, including vehicles, robots, drones, and other autonomous machines, suggests very different centers of gravity: high AI throughput and sensor ingress in one case, deterministic control and industrial connectivity in another, compact perception under strict size, weight, and power limits in a third.

The same functional partitioning that enables this introduces five new concerns.

Latency and jitter uncertainty: No longer fixed by a single design
Distributed trust boundaries: The security perimeter now spans chiplets and suppliers
Cross-chiplet fault propagation: One die can disturb another die's control path
Lifecycle and configuration complexity: Discovery, update, and configuration go package-wide
Observability and evidence gaps: No single die can evidence the whole package

Each of these crosses a chiplet boundary, which makes them a standardization concern.

A Physical AI Profile for OCP FCSA

The workstream is proposed as a sub-project under OCP FCSA rather than as a standalone effort, for four reasons. FCSA already owns the chiplet system architecture baseline that physical AI builds on. Real-time and safety-critical concerns go beyond that baseline's current scope. OCP FCSA is the right place to standardize externally visible chiplet behavior. Finally, OCP FCSA delivers a concrete starting point to work from.

OCP FCSA rules will be retained, and requirement rules specific to physical AI, such as real-time, secure, reliable, and safety-critical physical systems are added. In practice, that means following the OCP FCSA chapter structure wherever possible, adopting the same rules-based writing model, and applying a strict anti-duplication discipline, especially where an OCP FCSA rule already satisfies a physical AI requirement, reference it rather than restate it. Where a proposed requirement conflicts with the baseline, the conflict is named explicitly and resolved through the OCP FCSA working group.

Each candidate is then classified by interoperability impact: baseline OCP FCSA reuse, required physical AI profile, optional profile, or architecture-specific guidance. Classifying candidates this way lets the group standardize what must interoperate across chiplets and leave the rest as guidance.

Figure 2. Driving standardization via OCP FCSA

From Constraints to Architecture

An initial six constraints describe what a physical AI platform must guarantee.

Figure 3. The initial six physical AI platform constraints, starting point of the new profile

However, these initial six constraints are not directly specifiable. The bridging step maps each one to an architecture requirement area that can actually hold rules.

Physical AI constraint	Architecture areas it drives
Deterministic timing	Closed-loop control; deterministic execution; real-time interconnect
Security and trust	Security for physical action
Power and thermal efficiency	Energy efficiency and power management; heterogeneous compute
Reliability and safety	Functional safety; safety management and observability
Sensor fusion	Sensor fusion and perception data
Multi-chiplet scalability	Multi-chiplet scalability

These initial six constraints, ten areas, and every candidate requirement trace back to a constraint. That traceability is what keeps the supplement from accumulating interface features with no system-level justification.

A Worked Example: Functional Safety

Failures can occur in sensor interfaces, compute chiplets, die-to-die links, memory, safety controllers, or actuator paths. Because they reach physical behavior, faults must be detected, isolated, and recovered within bounded safety response times.

Functional safety therefore, goes beyond the individual chiplet. The platform must provide fault detection and containment, deterministic safety signaling, coordinated safe-state control, degraded-mode operation, and evidence that the sensor-to-action path stays within its safety goals. That single architecture requirement decomposes into six specification mechanisms: platform safety control and recovery coordination; traffic classes and QoS semantics; telemetry, debug, and trace control; safety-critical data protection; reliability, degradation, and link-health reporting; and verification, compliance, and safety-case evidence.

Three of those six are shared mechanisms that also serve other constraints. That overlap is the argument for doing this work once, in a common baseline, rather than repeatedly across vendor stacks.

Figure 4. Functional safety example

Scope, and Just as Importantly, What Is Out of Scope

Ensuring the new working group stays focused, boundaries are created for what is defined as in and out of scope. For example:

In Scope

Externally visible chiplet behavior required by real-time, safety-critical physical AI
Classification of candidate requirements into baseline, optional profile, or guidance
Overlap resolution with baseline OCP FCSA and UCIe
Compliance profiles and the evidence needed to support safety claims

Out of Scope

Chiplet microarchitecture and implementation choices
Die-to-die physical and link layers already owned by UCIe and BOW
AI model, algorithm, and training behavior
Product certification and vendor-specific software stacks

The exclusions do most of the work here. By ceding the physical and link layers to UCIe and BOW, staying out of microarchitecture, and declining to touch models or certification, the group reserves one territory for itself: the observable contract between chiplets, and the evidence that the contract holds. Everything a supplier competes with remains a supplier decision.

Why Cadence Is Leading this with Co-Chair imec

The two organizations bring complementary solution expertise to the table.

Cadence contributes the system and design perspective: chiplet architecture, interface implementation, system analysis, and verification. That matters disproportionately here, because a significant share of the candidate requirements are not about moving data at all. They are about proving things. Verification, compliance, and safety-case evidence is itself a candidate requirement, calling for capability declarations, compliance-profile declarations, test results, counters, logs, timestamped event records, trace snapshots, fault-injection results, timing measurements, and security-attestation records. A specification that defines behavior but not how to evidence it delivers interoperability on paper only.

Imec contributes cutting-edge research and expertise in autonomous-edge systems, workload partitioning, chiplet architectures, and advanced integration technologies, helping identify and validate critical requirements before they become formal specifications. This contribution is already reflected in the industry working record and the Autonomous Edge Chiplet Program (AECP), where imec has helped bring together leading ecosystem players to shape the future of chiplet-based autonomous-edge platforms. Through active technical leadership, imec has driven discussions from high-level concepts toward concrete, implementable requirements. Key contributions include defining the scope of system-level interfaces, sideband communication, reset and boot mechanisms, and championing capability discovery as a foundation for interoperability. Imec has also advocated a system-centric management approach, ensuring that power and operational states are managed coherently across the entire chiplet system rather than at the individual die level.

Finally, the leadership posture suits OCP. Neither company is arriving with a finished specification to ratify. What is on the table is a baseline choice, a structure proposal, and a candidate requirement list explicitly described as an input for discussion rather than a finalized requirement set.

What’s Next

The next step is to turn this proposed framework into a community-developed specification. Cadence and imec will work through the OCP FCSA community to refine the architecture requirements, identify where existing standards can be reused, define interoperable profiles and supporting evidence, and validate the approach against representative physical AI platforms. Broad participation from chiplet suppliers, system developers, integrators, and safety and security experts will be essential to ensure the resulting standard is practical, testable, and ready to support trusted physical AI systems at scale.

Building AI Infrastructure for Greater Choice and Flexibility

2026-10-14T06:00:00Z

AI infrastructure is changing fast. Training and inference are putting different demands on compute, memory, connectivity, and networking, and there is no single architecture that fits every workload.

For system architects, this opens up an important question: How much flexibility can be built into the system from the start?

The answer increasingly involves giving designers more choices across memory, compute, connectivity, and packaging, while making sure those technologies work together.

Different Workloads, Different Requirements

AI training and inference may run on much of the same underlying infrastructure, but they don't behave the same way.

Training places heavy demands on memory and communication between accelerators. Inference has a different mix of requirements, including memory capacity, latency, throughput, and efficiency.

Those differences matter when choosing an architecture. A memory technology that's right for one workload may not be right for another. The same applies to interconnects and networking.

This is why AI infrastructure is becoming more heterogeneous. Architects are combining different technologies based on what they need the system to do, rather than trying to force every workload into the same design.

Figure 1: Heterogeneous applications demand distinct solutions for optimized implementations

More Choice Through Open Standards

Open standards give designers more options for how they put those systems together.

UCIe is one example. The standard provides a common approach to die-to-die connectivity and is aimed at supporting an open chiplet ecosystem. It gives the industry a standardized way to connect dies within a package rather than tying the architecture to a single implementation.

System architects are also working across a wider range of process technologies, packaging approaches, and functions. A chiplet-based approach provides another way to partition those functions, allowing compute, I/O, memory interfaces, and other functions to be integrated within the same package.

UCIe provides a standardized die-to-die connection for that environment. This gives designers a common interface as they evaluate how different functions should be partitioned and integrated.

For designers, the value is choice. Different functions can be brought together in a package while using a common interface between them.

That freedom becomes particularly useful when architects are balancing performance, power, cost, packaging, and process technology.

Interoperability Matters

Open standards provide a common foundation for bringing technologies from different suppliers and foundries into the same system. Interoperability helps designers understand how those different implementations will work together.

Verification plays an important role here, particularly as systems incorporate more functions, interfaces, and technologies.

The Same Thinking Applies Across the AI Factory

The need for choice doesn't stop at the package.

An AI system can include several kinds of connectivity, each serving a different role. PCIe, CXL, UCIe, UALink, and Ethernet-based technologies address different parts of the architecture. Memory brings another set of decisions.

Figure 2: Different connectivity, different scope, same goal: economical, rapid data transfer

The requirements also change depending on where data is moving. HBM4E and LPDDR6 address different memory needs, while PCIe supports high-speed host and device connectivity. UALink addresses accelerator-to-accelerator communication, 224G high-speed SerDes provides the underlying high-speed signaling needed for demanding connectivity applications, and UCIe connects dies within packages.

Designers need to consider what they are connecting, how much data needs to move, and the requirements of the workload. Looking at those decisions together provides a more complete view of the system than treating each interface independently.

That perspective changes the design conversation. Rather than optimizing individual pieces independently, architects can look at how memory, compute, and connectivity fit together across the system.

Designing with Room to Evolve

AI infrastructure will continue to change as workloads, memory technologies, accelerators, and interconnects advance. Building flexibility into the architecture gives designers more options as those requirements change.

Open interfaces and interoperability are an important part of that flexibility, allowing designers to choose technologies based on the needs of the system rather than a single approach.

For a deeper look at the memory, compute, and connectivity technologies shaping these systems, read our "Building AI Factories with IP Solutions" white paper.

How Cadence DSPs Put In-Cabin AI Audio On-Chip in SemiDrive's X10

2026-10-08T16:00:00Z

SemiDrive, an automotive semiconductor company building SoCs and MCUs for the software-defined vehicle, has licensed and integrated Cadence Tensilica HiFi 5s DSPs into its X10 next-generation AI cockpit SoC, where they form the audio and voice subsys...(read more)

Accelerating Physical AI Through Cadence Silicon Solutions and Arm Total Design

2026-09-22T13:00:00Z

Physical AI is shifting artificial intelligence from centralized data centers into intelligent systems that must perceive, reason, and act in the real world. Autonomous vehicles, robots, drones, industrial systems, and other autonomous machines all require local intelligence that can process sensor-rich workloads in real time while meeting strict requirements for power, performance, functional safety, cybersecurity, and lifecycle reliability.

Figure 1: Physical AI applications

That shift places new demands on silicon. Physical AI is a systems challenge, requiring a complete foundation that connects AI models to trusted silicon and ultimately to deployable technology. Cadence addresses these current industry challenges through an integrated physical AI solution built around four core pillars: right-sized inference, trusted execution across the lifecycle, standards-based modularity, and one partner from spec to silicon to system.

Arm Total Design for Physical AI reflects the same ecosystem imperative. By bringing together compute platforms, silicon IP, implementation technologies, software, services, and ecosystem partners, Arm Total Design for physical AI creates a collaborative model for building the next generation of AI-enabled systems. For customers, that collaboration matters because physical AI is not solved by a single component. It requires coordinated progress across architecture, software, security, verification, packaging, and silicon realization.

Cadence already plays a pivotal role in the physical AI ecosystem by helping customers move from early architecture exploration to production-ready silicon. Cadence combines AI-driven design, system analysis, verification, digital implementation, multiphysics optimization, IP, advanced packaging, and chiplet realization technologies into a comprehensive development platform. The result is a more complete path for customers that need to accelerate silicon design for physical AI while reducing the integration risk, schedule pressure, and execution complexity of a multi-vendor stack.

A Physical AI Collaboration with Arm Built for Scalable Platforms

Cadence previously announced a comprehensive collaboration with Arm around Arm® Zena™ Compute Subsystems (CSS), helping to address one of the most demanding areas of silicon innovation: scalable, AI-enabled systems that must operate reliably in the physical world. Arm Total Design for Physical AI enhances this collaboration by extending the Cadence solution into a broader ecosystem model that brings together compute platforms, silicon IP, software, virtual platforms, tools, services, sensors, and deployment expertise to reduce integration complexity and accelerate development. As intelligent platforms evolve into software-defined, sensor-rich systems, semiconductor teams must support perception, sensor fusion, planning, control, connectivity, security, and lifecycle management in increasingly complex SoCs and chiplet-based architectures. Cadence’s physical AI silicon solutions, advanced implementation flows, IP, chiplet platform, and system-level expertise, paired with Arm’s ecosystem approach, gives customers a more coordinated path to building, validating, and scaling physical AI systems. This is especially important for systems that require real-time inference, deterministic performance, functional safety, lifecycle trust, and deployment readiness from silicon through system integration.

Right-sized inference for physical AI is critical. Intelligent physical systems do not have a one-size-fits-all compute profile. Some workloads require always-on, low-power inference. Others require higher-performance multimodal processing across cameras, radar, lidar, audio, environmental sensors, and system-state data. By combining Arm’s scalable compute foundation with Cadence technologies for architecture exploration, system analysis, IP integration, and silicon implementation, customers can better tune their designs for the performance, power, area, and latency targets required by their specific applications.

Figure 2: Right-sized inference

These new physical AI systems must have trusted execution across the lifecycle. Physical AI systems operate in mission-critical and safety-sensitive environments and must protect data, software, models, firmware, configuration assets, and device identity from manufacturing through field deployment. In software-defined physical AI systems, this becomes especially important because connected platforms depend on secure boot, authenticated updates, attestation, lifecycle management, and system-level trust. Cadence’s broader physical AI solution, including security capabilities such as Securyzr, provides a foundation for protecting AI workloads, chiplet-based platforms, and connected edge systems throughout their operational life.

Figure 3: Trusted execution

Physical AI demands are increasing faster than traditional monolithic SoC approaches can comfortably absorb. Chiplet-based architectures offer a scalable path by enabling compute, AI acceleration, memory, I/O, security, and domain-specific functions to be integrated through reusable, interoperable building blocks. Cadence’s physical AI chiplet platform and design expertise, UCIe-based integration capabilities, standards-aligned IP, EDA flows, and multi-die implementation technologies help customers pursue modular architectures that can scale across platforms and product generations while preserving flexibility and reuse. The Cadence physical AI chiplet platform aligns with the OCP Foundational Chiplet System Architecture specification, enabling interoperable chiplets.

Figure 4: Standards-based modularity

Cadence can help customers translate high-level physical AI requirements into executable silicon specifications, integrate Arm-based compute subsystems with the required IP and system infrastructure, validate software earlier through virtual and hybrid development environments, implement the design, and support the path toward silicon realization. For customers, that means fewer handoff points, less multi-vendor integration risk, and a more direct route from concept to production.

Together, Cadence and Arm are helping customers address the system-level realities of physical AI. The collaboration is not simply about connecting a compute subsystem to an implementation flow, it is about giving silicon innovators a more integrated foundation for building AI-defined systems: scalable compute, trusted execution, standards-based chiplet pathways, early software enablement, and silicon realization expertise in one coordinated ecosystem.

Why This Matters for the Physical AI Era

Physical AI changes the center of gravity for semiconductor design. Customers are no longer optimizing isolated IP blocks or single-purpose SoCs. They are building intelligent systems that must see, reason, and act in real time, often under strict power, safety, cost, and reliability constraints. That requires a systems mindset.

The Cadence physical AI solution addresses the needs of this shift clearly: AI accelerated, secure by design, standards-based, and scalable. This collaboration with Arm reinforces each part. Arm provides a scalable compute foundation for Physical AI systems. Cadence helps customers realize that foundation through software enablement, IP integration, verification, implementation, advanced packaging, chiplet design, and silicon realization services.

Supporting the needs of physical AI applications, Cadence offers a physical AI chiplet platform, which is a configurable, standards-based multi-die solution that accelerates development of scalable physical AI systems by combining pre-verified reference chiplets, UCIe die-to-die connectivity, advanced packaging flows, and a broad Cadence IP portfolio. It integrates system, AI acceleration, and CPU cluster chiplets, anchored by Cadence Neo NPU inference, Arm-based compute, memory, I/O, security, debug, and system-management capabilities, to support demanding workloads across autonomous vehicles, robotics, drones, industrial systems, and other autonomous machines. The platform reduces cost, schedule, and integration risk while enabling package-level scalability, interoperability, and rapid customization for application-specific physical AI silicon.

Figure 5: Cadence physical AI chiplet platform

For the market, the value is straightforward. Customers can move faster from model to trusted silicon. They can reduce the risk associated with complex heterogeneous integration. They can explore modular chiplet-based architectures when scale demands it. And they can rely on a coordinated ecosystem rather than stitching together disconnected technologies across the development lifecycle.

As physical AI expands across robotics, drones, industrial systems, intelligent edge platforms, and other real-world AI applications, this model of collaboration will become increasingly important. The next generation of intelligent machines will depend on silicon platforms that combine compute performance, software readiness, lifecycle trust, modular scalability, and production discipline. Cadence is positioned to help customers build those platforms faster, with lower risk, and with a complete path from specification to silicon to system.

What Is Physical AI? Why It Demands a New Class of Silicon

2026-09-02T14:00:00Z

Artificial intelligence is moving out of just the data center and into the physical world. Cars now steer themselves through traffic. Robots pick, sort, and assemble on factory floors and dance! Drones inspect infrastructure without a pilot. These ma...(read more)

DDR5 MRDIMM Gen2: The Missing Link in Scaling AI Infrastructure

2026-09-01T05:45:00Z

AI systems continue to grow exponentially in size and complexity. Today, most attention is focused on GPUs and high-bandwidth memory (HBM). Yet many AI deployments are becoming constrained by a less visible bottleneck in the memory subsystem attached to the host CPU. To address this, the industry is moving away from fixed, server-centric designs toward more flexible AI factory scale-up and scale-out topologies and disaggregated architectures. This is where GPUs and TPUs, together with HBM and LPDDR, dominate AI training and inference accelerators. CPUs remain the infrastructure managers of large-scale AI systems. They load datasets, preprocess inputs, manage model checkpoints, coordinate communications across accelerators, and stream data to GPUs.

Memory bandwidth across the entire data center infrastructure has become critical for achieving optimal performance. MRDIMM is the next-generation DRAM module that enables ever-expanding large-scale AI models. AI accelerators require continuous access to data to deliver peak performance, but CPU memory bandwidth often becomes the bottleneck during data preparation and scheduling. MRDIMM helps maintain efficient and steady data from storage to the AI accelerator by increasing memory throughput, which significantly improves AI efficiency.

Today, DDR5 RDIMM is the most prolific memory used in enterprise computing and the data center. MRDIMM has emerged as the next-generation server memory designed to fit into a standard RDIMM socket. MRDIMM enables a significantly higher memory bandwidth and capacity per server slot without changes in the platform form factor. It achieves this by using a multiplexed architecture that effectively doubles the data rate of the underlying DRAM. DDR5 MRDIMM Gen1 supports speeds up to 9.2 GT/s, while MRDIMM Gen2 supports up to 12.8 GT/s, significantly boosting memory performance.

Cadence leads the market with its DDR5 MRDIMM 12.8 Gbps Gen2, TSMC N3P IP system solution, establishing a new benchmark for industry-leading PPA. Key industry leaders have already adopted this solution, which is now also available in the TSMC N2P and N5/N4P process nodes.

The Cadence memory system solution pairs a fully featured, enterprise-class controller with a highly optimized DDR5 MRDIMM Gen2 PHY, targeting complex, demanding multichannel applications.

The controller supports UDIMM, RDIMM, and MRDIMM configurations through a common enterprise architecture, and delivers advanced capabilities across four dimensions:

Enterprise-class reliability, availability, and serviceability (RAS)
Security
Enterprise-class performance
PPA-optimized configurations and floorplans

For more information on our industry-leading DDR5 RDIMM and MRDIMM, LPDDR6/5X, HBM4E, and GDDR7 solutions, contact Cadence.

Learn More

Building AI Factories with IP Solutions by Arif Khan

Cadence Advances AI in the Cloud with Industry-First DDR5 12.8Gbps MRDIMM Gen2 Memory IP System Solution

Data Movement Shapes AI System Performance

2026-08-19T20:00:00Z

For much of the last decade, AI performance has been discussed primarily through the lens of compute. More GPUs, larger clusters, and higher peak throughput were treated as the main path to better performance. That worked when workloads could scale across loosely connected systems and when coordination overhead was not the dominant constraint.

As AI systems have scaled, the challenge has become less about deploying additional compute and more about keeping that compute productively utilized.

Modern AI workloads distribute models across large numbers of accelerators that must continuously exchange data and synchronize execution. Under these conditions, memory throughput, interconnect efficiency, and communication overhead all have a direct impact on overall system performance.

The result is a different set of architectural priorities. System performance depends not only on available compute resources, but also on how efficiently data moves through the machine. All of these factors determine the cost of each token as it is produced.

AI Factories Scale Through Coordination

AI workloads divide models across accelerators using tensor, pipeline, and data parallelism. Each step requires parameters, activations, gradients, and optimizer state to move between devices. These exchanges are not occasional. They are structured, repeated, and synchronized at every stage of execution.

That creates a very different performance model from traditional computing environments. The system cannot simply continue because compute resources are available. It must complete the required communication steps before moving to the next stage. Every accelerator participating in the workload must receive the required data, complete its work, and reach synchronization points with the rest of the system.

This dependency chain has ripple effects across the AI factory. Delays in communication do not remain isolated to a single accelerator. They propagate through the workload and affect overall execution efficiency.

Memory Throughput Gates Compute Utilization

Nearly every compute step in tight AI loops depends on the continuous movement of model state through the memory subsystem. Parameters must be read. Activations must be generated and stored. Gradients must be accumulated. Updated weights must be written back. These operations repeat throughout execution and create sustained demand for memory throughput.

When memory supplies data at the required rate, compute pipelines remain active. When it does not, execution stalls at the point of dependency. The accelerator may be available, but it cannot proceed until the data arrives. The workload is constantly moving between compute and data access. As models grow and systems scale, that relationship becomes more important, not less. Memory throughput therefore, plays a direct role in determining how much of the available compute can actually be used. Higher compute capacity only improves delivered performance if the memory subsystem can keep pace with the workload.

Interconnect Becomes an Extension of the Memory System

Model partitioning forces data to move across accelerators. Activations generated on one device become inputs for another. Gradients must be aggregated across devices, and parameter updates must be distributed across the system. At AI factory scale, these exchanges extend well beyond the local memory attached to a single accelerator and depend directly on interconnect performance.

From a system perspective, interconnect increasingly becomes an extension of the memory system. It moves data between distributed regions of model state and directly affects how quickly those regions can be accessed, updated, and synchronized.

The dominant communication patterns are collective operations. Reductions, broadcasts, and exchanges must be completed across groups of accelerators before the workload can advance. If interconnect performance varies, or if communication cannot sustain the required pattern, execution time increases even when compute resources are available. The issue is not that the accelerator lacks capability. The issue is that the system cannot deliver the data and synchronization needed to keep execution moving.

This is why interconnect should not be treated as a separate infrastructure layer. In an AI factory, it is part of the execution path.

Synchronization and System Efficiency

Each training step includes local computation, data exchange across devices, completion of collective operations, and synchronization before the next step begins. All participating accelerators must complete these stages together.

That creates a system-level straggler problem. If one device is delayed by data arrival, communication latency, or contention, the rest of the group cannot simply continue. They wait at the synchronization point until the operation completes.

As accelerator counts increase, sensitivity to synchronization overhead increases as well.

Scale-Up and Scale-Out Must Work as One System

Scale-up communication connects accelerators within a tightly coupled domain. It supports frequent data exchange and low-variation synchronization inside a local group of devices. Many collective operations depend on this communication, completing quickly and consistently.

Scale-out communication extends workloads across nodes and clusters, allowing model partitions and execution to span the broader AI factory.

These domains serve different purposes, but they are not independent. Inefficiency in either introduces delay into the same execution flow. A workload distributed across multiple accelerators still relies on communication and synchronization to progress, regardless of where the communication occurs.

Separating scale-up from scale-out does not isolate the performance challenge. It only changes where communication overhead appears in the system.

Scaling Requires Architectural Alignment

Memory, interconnect, networking, and packaging form a continuous path through which model state moves. A constraint at any point in that path affects the execution of the workload.

Optimizing individual components in isolation does not guarantee efficient system behavior. Bandwidth, latency, consistency, and synchronization characteristics all influence how data moves between accelerators and through the broader system.

As AI factories scale, these dependencies become more tightly coupled, requiring architectural decisions to be evaluated at the system level rather than within individual subsystems.

The Next Phase of AI Performance

FLOPS are easy to quantify and easy to compare.

At AI factory scale, however, delivered performance depends on more than the compute installed in the rack. It also depends on how efficiently data moves through memory systems, across interconnect fabrics, and between synchronized groups of accelerators.

As systems scale, the relationship between computation and communication becomes increasingly important. Every layer involved in moving, storing, and exchanging model state contributes to overall execution efficiency. Looking forward, the systems that advance the next generation of AI will not necessarily be those with the most compute, but the ones that can make the most effective use of it across memory and interconnected fabrics.

For a deeper look at AI infrastructure and networking, read the "Building AI Factories With IP Solutions" white paper.

Scale-Up Ethernet Ecosystem Ramps Up: Cadence ESUN Controller IP Available

2026-07-31T00:00:00Z

AI Infrastructure Networking Demands

The AI Infrastructure industry is investing hundreds of billions of dollars to build AI factories. Purpose-built for AI workloads, these systems are designed to convert capital, power, and silicon into model training throughput and inference tokens at massive scale.

As accelerator counts grow from hundreds to thousands per deployment, the efficiency of data movement inside these systems increasingly determines overall factory productivity. Every nanosecond of latency, every retransmission, and every underutilized link translate directly into idle accelerators, lower utilization, and reduced return on infrastructure investment.

This shift is driving a renewed focus on scale-up networking. While advances in compute continue to expand accelerator performance, next-generation AI factories also require fabrics capable of moving data between XPUs with predictable latency, efficient bandwidth utilization, and lossless operation.

The Need for Scale-up Networking

Operators building scale-up domains want AI-fabric performance and efficiency while continuing to leverage the Ethernet ecosystem they already use. That's the goal of Ethernet for Scale-up Networking (ESUN), an open OCP (Open Compute Project) workstream led by major AI infrastructure operators, accelerator providers, and networking technology vendors. The group published its first Network Operator Requirements specification in early 2026.

ESUN keeps what has made Ethernet successful for more than four decades: ecosystem, economics, and interoperability, while addressing the demands of scale-up AI workloads. Like the broader Ultra Ethernet (UEC) effort, ESUN incorporates AI-focused networking enhancements designed to improve efficiency and resiliency. These enhancements include:

Link-Level Retry (LLR) to recover errors locally in nanoseconds rather than escalating them to end-to-end retransmissions

Credit-Based Flow Control (CBFC) for managing traffic at the virtual-channel level to maintain lossless operation without head-of-line blocking

Header optimization: Standard Ethernet carries 28 to 48 bytes of IP-related header overhead per packet; ESUN replaces that with a compact 4-byte ESUN header while preserving traffic prioritization, congestion signaling, and load balancing

For workloads dominated by small, frequent, latency-critical transfers, these changes translate directly into higher effective bandwidth and more predictable latency.

Cadence ESUN Controller IP

Building on its High-Speed Ethernet controller IP family, Cadence provides ESUN-ready controller IP for next-generation AI scale-up networking.

Key ESUN controller features:

Flexible multi-rate architecture supporting Ethernet speeds from 100G to 1.6T

ESUN link layer:
- Per-port Priority Flow Control (PFC), LLR with configurable replay buffer size for lossless Ethernet, and CBFC supporting from 2 to 32 Virtual Channels
- Compact ESUN and UFH Header framing supported

1.6T multi-rate Ethernet MAC: Up to four independent 400G channels configurable for 1×1.6T, 2×800G, 4×400G, and 4×200G modes over 224G SerDes; up to four additional 200G channels may be added to the base configuration

Integrated RS-FEC:
- Integrated RS-FEC options including Low Latency FEC/RS(272, 257+1)
- Software selectable interleaving for minimum latency

Controller designed for minimum silicon area

Delivered as a complete, pre-verified controller, multi-controller, or integrated PHY package, Cadence ESUN controller IP helps reduce integration complexity, minimize implementation risk, and accelerate time-to-silicon for next-generation AI infrastructure SoCs. The controller combines ESUN link-layer capabilities, multi-rate Ethernet MAC, and integrated RS-FEC in a flexible architecture optimized for high performance, low latency, and efficient silicon utilization.

Advancing AI Networking

Cadence is an active participant in the open standards shaping AI infrastructure, including OCP, the Ultra Ethernet Consortium, and the UALink Consortium. Building on decades of Ethernet IP leadership, Cadence extends its High-Speed Ethernet IP portfolio with ESUN-ready controller IP designed to address the demands of AI scale-up fabrics.

As the emergence of ESUN reflects growing industry interest in applying the economics, operational familiarity, and ecosystem scale of Ethernet to the scale-up domain, Cadence is enabling customers to engage early with this next-generation scale-up networking architecture. To accelerate your designs with Cadence ESUN Controller IP, please contact your Cadence sales representative.

For a deeper look at AI infrastructure and networking, read the "Building AI Factories With IP Solutions" white paper.

Why AI Factories Need Great Interconnect IP, Not Just More Compute

2026-07-27T16:00:00Z

AI infrastructure is often evaluated based on compute: how many accelerators, how much total performance, how fast models can train.

That works up to a point.

At scale, these systems behave fundamentally differently from traditional data center architectures. They are built for sustained, tightly coordinated workloads, where large numbers of accelerators operate as a single system rather than independent resources.

In this environment, adding compute does not guarantee higher performance.

What matters is whether that compute can be kept utilized—and that depends on how efficiently data can be delivered, exchanged, and synchronized across the system.

As AI factories have scaled, the limiting factor has shifted. Performance is no longer defined by peak compute capability, but by communication efficiency.

The constraint moves from compute to interconnect.

AI Factories Are Fundamentally Different Systems

AI factories are not just larger data centers, they operate very differently. Instead of loosely coupled workloads, they run large training jobs across tightly connected systems. Thousands of accelerators operate together, continuously exchanging data and staying synchronized over long periods.

This reflects a broader shift in data center architecture, from general-purpose infrastructure to systems built specifically for sustained AI workloads.

This fundamentally needs a new approach to interconnect, as covered in our latest white paper, "Building AI Factories with IP Solutions".

In this environment:

Compute resources are interdependent
Data exchange is continuous
Synchronization is intrinsic to the workload

Under these conditions, efficiency is determined by the weakest link in the data path. If one part of the system cannot keep up, the entire system slows down.

Compute Doesn't Define Performance

It is easy to assume that faster accelerators will improve performance. But accelerators only create value when they are fully utilized, and that depends on how efficiently data reaches them.

Bandwidth: Accelerators consume data at extremely high rates. If bandwidth is insufficient, compute stalls regardless of peak capability.
Latency: Distributed training requires frequent coordination. Latency in collective operations directly reduces throughput.
Topology: At scale, communication paths become more complex. Poor topology increases hop count, introduces contention, and amplifies latency.

As AI workloads have scaled, the industry has introduced new interconnect approaches, both within nodes and across systems, to address these pressures.

However, higher link speeds alone do not remove the constraint. Efficiency depends on how the interconnect behaves under sustained load.

These Constraints Originate in IP

Interconnect behavior is not defined at deployment. It is determined in the underlying IP.

Key characteristics are set by:

SerDes design, which determines signaling efficiency, reach, and power
Protocol implementation, which governs overhead and effective bandwidth
Interface IP, which defines buffering, flow control, and latency
Integration across chiplets, packages, and systems

These are architectural decisions made early in the design process. Once established, they constrain what the system can achieve.

As AI factories scale, the impact of these decisions becomes more visible. Tradeoffs that were previously localized begin to affect overall system behavior.

Why "Good Enough" Interconnect Fails at Scale

At smaller system sizes, an interconnect that meets basic requirements is often sufficient. That is not the case in AI factories.

As systems scale:

Small inefficiencies increase synchronization costs
Variability across links creates imbalance
Local bottlenecks propagate across the system

A design that looks acceptable in isolation can become the primary limiter of system performance. Peak metrics don't tell you much here. What matters is how the system performs under sustained workloads.

Compute, Memory, and Interconnect Must Be Co-Optimized

Compute, memory, and interconnect are tightly coupled. Improving one without the others does not improve overall performance:

More compute without enough bandwidth reduces utilization
Faster links without lower latency do not improve coordination
Local optimizations can introduce system-level inefficiencies

AI factory design requires a system-level approach, where these elements are developed together. Optimizing one dimension in isolation creates imbalance—and lost performance.

Where the Real Constraint Sits

AI factories make the limitation clear. Performance is not defined by how fast individual components are. It is defined by how efficiently the system moves and manages data. That is governed by the interconnect.

Because interconnect behavior is set at the IP level, achieving performance at scale depends on getting interconnect IP right from the start.

Scaling AI systems is not just a matter of adding more compute. It is a question of whether the system can sustain efficient data movement as it grows.

Read the "Building AI Factories With IP Solutions" white paper now.

Cadence Achieves Successful Silicon Validation of 1st IP Test Chips on Intel 18A

2026-05-28T19:00:00Z

Cadence has reached an important milestone in its collaboration with Intel Foundry with the successful completion of its first test chips on Intel 18A earlier this year. This achievement marks a meaningful step forward in enabling advanced, standards‑based interface IP on Intel 18A. More details about these test chips were recently shared in presentations at CadenceLIVE Silicon Valley and GOMACTech events.

As system architectures continue to evolve to support AI, high‑performance computing, and heterogeneous designs, early validation on silicon plays a vital role. This set of first test chips on Intel 18A reflects Cadence's continued investment in silicon‑backed IP readiness, providing customers with practical insight and reduced risk as they make IP decisions.

Advancing From Early Enablement to Silicon Validation on Intel 18A

The completion of these test chips represents a transition from early enablement activities into tangible silicon validation, using dedicated vehicles to exercise real interface behavior under representative operating conditions. The silicon-validated IP serves as a proof point for the GAA (RibbonFET) and back-side power (PowerVia) technology available on Intel 18A.

Yet rather than serving as a single proof point, each test chip supports ongoing learning across electrical performance, signal integrity, power behavior, and system integration assumptions. These insights feed directly back into model correlation and IP refinement, strengthening readiness well before customer designs move toward production.

This approach reflects a simple but critical principle: early silicon matters. It shortens learning cycles, uncovers integration considerations sooner, and helps ensure that IP entering customer SoCs is aligned with real‑world behavior on advanced nodes.

Key IP Enabled on Intel 18A

The test chips on Intel 18A technology bring together several cornerstone interface technologies from Cadence's IP portfolio, each aligned with the bandwidth, latency, and integration demands of modern systems.

High‑speed 112G PAM4 SerDes IP was exercised on Intel 18A as a foundation for bandwidth‑intensive AI, networking, and accelerator applications.

Figure 1: 112G SerDes PAM4 eye diagram

The test chips also support PCI Express^® (PCIe^®) 6.0 (64 GT/s PAM4) and PCIe 5.0 (32 GT/s NRZ) PHY IP operation, reflecting the continued evolution of high‑bandwidth I/O and coherent system architectures.

Figure 2: PCIe 6.0 Eye Plot

For the memory subsystem, LPDDR5 PHY IP was validated at high data rates on Intel 18A, supporting the power‑efficient, high‑performance memory interfaces required for advanced SoCs.

Figure 3: LPDDR5 8533 Mbps Tx/Rx Eye Diagram

Also demonstrated in the test chips was UCIe™ IP, including multi‑lane configurations and packaged implementations that align with emerging chiplet‑based system designs.

Figure 4: UCIe-AP 16G Eye Plot – 64 Lanes

Together, these protocols represent the interfaces that increasingly define system scalability—not in isolation, but in combination. Validating them on silicon helps ensure they operate cohesively across SoCs, packages, and multi‑die systems.

Reducing Risk for Advanced Designs

Early test chips play a critical role in helping customers move confidently onto new process technologies. With these test chips, Cadence can validate key interface behavior on real silicon, strengthen correlation between design models and measured results, and identify integration considerations at a stage when design flexibility is still high.

This silicon work complements Cadence's broader collaboration with Intel Foundry, including Design IP expansion, EDA tool enablement, and advanced packaging support. Taken together, these efforts are focused on a shared goal: accelerating time‑to‑value while reducing uncertainty for customers building next‑generation systems.

Continuing Momentum with Intel Foundry

Cadence remains focused on delivering IP that is not only standards‑based but backed by real silicon validation. The completion of the first test chips on Intel 18A represents an important milestone—one that reinforces Cadence's long‑term commitment to enabling customers with reliable, production‑ready IP as they move onto Intel Foundry technologies. Meanwhile, Cadence is continuing its collaboration with Intel Foundry on Intel 18A-P and Intel 14A technology nodes.

Learn more about Cadence Design IP.