Chiplet-based design changes more than how functionality is divided across silicon. It also changes how the different pieces of a system communicate.

Universal Chiplet Interconnect Express, or UCIe, provides a standardized die-to-die interconnect for connecting chiplets within a package. But the logic inside those chiplets may already communicate using established interfaces and protocols such as AXI, CHI, CXL, PCIe, or CXS.

That creates an important architectural question: how does traffic from an existing SoC fabric or protocol domain move onto a UCIe die-to-die link?

This is where UCIe Bridge IP becomes important.

Rather than requiring every chiplet subsystem to be redesigned around a single interface, bridge IP provides the connection between an existing protocol environment and the UCIe interconnect. Depending on the IP architecture, that bridge functionality may be delivered as a dedicated bridge block or integrated as part of a broader UCIe controller configuration. SmartDV’s UCIe portfolio includes dedicated bridge solutions for AXI, CHI, CXL, PCIe, and CXS, allowing engineering teams to select the protocol interfaces required by their particular chiplet architecture.

This modular approach is part of SmartDV’s broader UCIe IP for next-generation chiplet designs strategy, combining controller, bridge, and verification technologies rather than forcing every design into the same fixed implementation.

Why UCIe Bridge IP Matters in Chiplet Architectures

A chiplet interconnect does not operate in isolation. Data originates somewhere in the system and ultimately needs to reach a processor, accelerator, memory subsystem, I/O device, or another functional block.

Inside the chiplet, that communication may already be based on AXI, CHI, CXL, PCIe, CXS, or another established protocol. UCIe provides the die-to-die path, but the architecture still needs a mechanism for carrying the appropriate protocol traffic across that path.

UCIe natively maps PCIe and CXL protocol traffic as part of the base specification. Other protocols, including AXI, CHI, and CXS, are typically carried using the streaming and raw-mode transport mappings the UCIe Consortium expanded through the 1.1 and 3.0 revisions. The result for the surrounding subsystem is similar either way: a protocol-aware connection across the die-to-die link, but the underlying UCIe-level mapping can differ by protocol.

Bridge IP fills that role.

For example, an AXI-based subsystem may need to communicate with logic on another die without changing the internal AXI architecture. A coherent processor subsystem using CHI may need to extend communication across a chiplet boundary. A CXL-connected accelerator or memory device may need CXL traffic carried across the UCIe interface. PCIe-connected components present another set of protocol requirements.

The bridge selected therefore depends on the architecture surrounding the UCIe connection. The goal is not to select one universal bridge for every chiplet. It is to preserve the protocol behavior the system requires while using UCIe as the standardized die-to-die connection.

That becomes especially useful in modular platforms where different chiplets may have different interface requirements.

Connecting Different Protocol Domains to UCIe

AXI to UCIe Bridge IP

AXI is widely used for communication inside SoCs, including processor, accelerator, memory-facing, peripheral, and other subsystem connections.

SmartDV’s AXI to UCIe Bridge IP connects AXI protocol traffic to a UCIe die-to-die link. The current product supports AMBA AXI5 while maintaining backward compatibility with AXI4 and AXI3, configurable data widths, and UCIe 3.0 operation across multiple lane configurations.

For chiplet systems, this provides a way for an AXI-based subsystem to communicate across a die boundary without requiring the internal subsystem to be redesigned around another host-side interface.

CHI to UCIe Bridge IP

AMBA CHI addresses coherent communication in processor and high-performance SoC architectures. When coherent subsystems are divided across chiplets, maintaining the required transaction and coherency behavior becomes a key part of the die-to-die architecture.

SmartDV’s CHI to UCIe Bridge IP supports AMBA 5 CHI communication across UCIe links, including Request, Home, and Slave node types and the associated Protocol, Network, and Link layer behavior.

This makes CHI-to-UCIe bridging particularly relevant to multi-die systems where coherent processor, cache, or accelerator subsystems need to communicate across a package boundary while retaining the CHI architecture used inside the system.

CXL to UCIe Bridge IP

CXL provides coherent connectivity for processors, accelerators, and memory devices and is an important protocol in AI, HPC, and data center systems.

SmartDV’s CXL to UCIe Bridge IP supports CXL.io, CXL.cache, and CXL.mem traffic over UCIe. This allows a chiplet architecture to combine CXL protocol behavior with a standardized UCIe die-to-die connection.

This is especially relevant where memory expansion, coherent acceleration, or other CXL-based functionality needs to span chiplets within a package.

PCIe to UCIe Bridge IP

PCI Express remains foundational to accelerator, storage, networking, and general-purpose high-speed I/O architectures.

SmartDV’s PCIe to UCIe Bridge IP connects PCIe Root Complex and Endpoint functionality with UCIe die-to-die connectivity. The current implementation supports UCIe 3.0 and PCIe 6.0, allowing PCIe protocol traffic to traverse the chiplet interconnect.

This can be useful when functionality that would traditionally communicate through PCIe needs to be incorporated into a multi-die package while preserving the expected PCIe protocol environment.

CXS to UCIe Bridge IP

AMBA CXS provides a high-bandwidth streaming interface designed for communication between components and interconnect structures.

SmartDV’s CXS to UCIe Bridge IP carries CXS streaming protocol traffic across UCIe and includes credit exchange, link activation and deactivation, configurable credit control, packet handling, error detection, and UCIe sideband functionality.

This gives systems using CXS a direct path into a UCIe-based chiplet architecture without requiring the CXS-facing subsystem to adopt an unrelated protocol at the chiplet boundary.

Key Technical Challenges in UCIe Bridge Integration

Connecting two interfaces involves more than moving data from one side of the bridge to the other. The surrounding protocols have their own transaction models, ordering requirements, credit mechanisms, error behavior, reset sequences, and system-level expectations.

One of the most important design challenges is therefore maintaining correct behavior across the protocol boundary.

For coherent protocol domains such as CHI and applicable CXL.cache/CXL.mem use cases, the bridge must preserve the coherency and ordering behavior required by the originating architecture as traffic crosses the die-to-die interface. For AXI, transaction handling, outstanding requests, read/write behavior, and data widths may affect the implementation. CXS relies heavily on streaming and credit behavior. PCIe introduces its own transaction, link, and recovery requirements.

At the UCIe side, the implementation must also account for the appropriate Flit formats, lane configuration, sideband communication, retry mechanisms, CRC behavior, link management, and supported packaging configuration.

The bridge effectively sits where two different sets of requirements meet. That makes the interface boundary an important architectural and verification focus rather than simply a transport connection.

Choosing the Appropriate UCIe Bridge

The correct bridge depends primarily on the protocol architecture of the subsystem being connected.

An AXI-based accelerator or SoC subsystem naturally points toward AXI-to-UCIe connectivity. A coherent AMBA system may require CHI. CXL-based memory or accelerator architectures require CXL protocol support. PCIe-based devices or subsystems need to maintain their PCIe behavior. Designs built around CXS streaming interfaces require the corresponding CXS bridge.

More complex multi-die systems may contain several of these protocol domains at the same time.

SmartDV’s current UCIe Controller IP reflects that possibility by supporting PCIe, CXL, AXI, CXS, and CHI protocol connectivity through dedicated bridge interfaces. The UCIe 2.x Controller IP and UCIe 3.x Controller IP are therefore closely related to the bridge portfolio rather than independent of it.

For a closer look at how these components work together, see UCIe Controller IP vs. UCIe Bridge IP: What Does a Chiplet Design Need?

This also supports the modular positioning of the current campaign: engineering teams can build around the controller and protocol connections their architecture actually requires rather than treating every chiplet implementation as the same fixed stack.

For a broader look at how controller, bridge, and verification technologies can be combined around different system requirements, see Building a Modular UCIe IP Stack for AI and HPC Chiplet Architectures.

How Verification Teams Should Approach UCIe Bridge Integration

Bridge verification needs to consider both sides of the connection.

It is not enough to confirm that the UCIe link can move data. Verification also needs to establish that transactions entering through the source protocol emerge correctly across the UCIe path while maintaining the required ordering, flow-control, error, and recovery behavior.

A practical verification plan should cover:

• Protocol traffic under normal and stressed conditions
• Transaction and packet integrity across the bridge
• Initialization and reset sequences
• Credits and flow control where applicable
• Link training and sideband behavior
• Retries and recovery
• Error injection and error handling
• Interactions between the bridge and the surrounding subsystem

That system-level perspective is important because a failure observed across a chiplet connection may originate in the source protocol domain, bridge logic, UCIe link, destination subsystem, or configuration between them.

SmartDV’s existing FAQ Why Does Chiplet-Based Design Require Specialized Verification? discusses this problem in more detail and specifically addresses verification across UCIe bridge boundaries.

For a deeper discussion focused specifically on UCIe verification, read Why UCIe Verification Is Critical for Chiplet-Based SoC Design, which covers link initialization, traffic behavior, recovery, system-level interactions, and bridge integration.

Related SmartDV UCIe Products and Resources

SmartDV’s UCIe portfolio brings together the Design IP and Verification IP required to build and validate chiplet interconnects.

• AXI to UCIe Bridge IP
• CHI to UCIe Bridge IP
• CXL to UCIe Bridge IP
• PCIe to UCIe Bridge IP
• CXS to UCIe Bridge IP
• UCIe 2.x Controller IP
• UCIe 3.x Controller IP
• UCIe Verification IP

SmartDV’s UCIe VIP supports verification of UCIe implementations through UCIe 3.0, including mapped protocol support, Flit formats, link training, error recovery, error injection, and functional coverage.

For a broader view of how these components fit together, visit SmartDV UCIe IP for Next-Generation Chiplet Designs.

Article Summary

UCIe provides a standardized die-to-die interconnect for chiplet-based systems, but chiplets still need to communicate with the protocol fabrics and subsystem interfaces already used throughout the architecture.

UCIe Bridge IP provides the connection between those protocol domains and the UCIe link.

AXI to UCIe Bridge IP supports AXI-based SoC and accelerator subsystems. CHI to UCIe Bridge IP addresses coherent AMBA architectures. CXL to UCIe Bridge IP carries CXL.io, CXL.cache, and CXL.mem traffic. PCIe to UCIe Bridge IP connects PCI Express functionality into the chiplet interconnect. CXS to UCIe Bridge IP supports high-bandwidth CXS streaming communication.

Selecting the appropriate bridge is therefore an architectural decision based on the protocol environment surrounding each chiplet.

Verification must then extend across that entire path. Teams need confidence not only that the UCIe interface operates correctly, but that protocol behavior remains correct as transactions move between the original SoC fabric, the bridge, the UCIe link, and the destination chiplet.

Frequently Asked Questions

What is UCIe Bridge IP?
UCIe Bridge IP connects an existing protocol or SoC interface to a Universal Chiplet Interconnect Express die-to-die link. It allows protocol traffic such as AXI, CHI, CXL, PCIe, or CXS to participate in a UCIe-based chiplet architecture without requiring the surrounding subsystem to be redesigned around a different interface.

Why is Bridge IP needed if a design already has UCIe Controller IP?
UCIe Controller IP provides the core UCIe interconnect functionality, while protocol-specific bridge IP connects that UCIe infrastructure to the protocol domain used by the surrounding subsystem. The required combination depends on the architecture and the interfaces that need to communicate across the chiplet boundary.

Which UCIe Bridge IP products does SmartDV provide?
SmartDV currently provides AXI to UCIe Bridge IP, CHI to UCIe Bridge IP, CXL to UCIe Bridge IP, CXS to UCIe Bridge IP, and PCIe to UCIe Bridge IP.

How should UCIe Bridge IP be verified?
Verification should cover both the UCIe side and the adjacent protocol domain. Teams should validate transaction behavior, ordering, flow control, data integrity, initialization, reset, error handling, retries, recovery, sideband operation, and end-to-end behavior across the bridge.

Is UCIe Bridge IP only relevant to AI and HPC designs?
AI and HPC are important use cases because they increasingly rely on modular, high-bandwidth chiplet architectures, but the same UCIe bridge concepts can apply to other multi-die SoC and system designs where established protocol domains need to communicate over UCIe.

Build a Modular UCIe Architecture with SmartDV

SmartDV provides UCIe Controller IP, protocol-specific Bridge IP, and Verification IP to support chiplet architectures from implementation through verification.

Explore SmartDV UCIe IP for Next-Generation Chiplet Designs to learn how AXI, CHI, CXL, PCIe, and CXS Bridge IP can be combined with UCIe Controller and Verification IP to meet the specific requirements of your multi-die architecture.