Building a UCIe-based chiplet system involves more than selecting a die-to-die interconnect. Engineering teams also need to determine how the existing protocol architecture inside each chiplet connects to that UCIe link.

This creates an important distinction between UCIe Controller IP and UCIe Bridge IP.

The two are closely related, but they do not perform the same function. The UCIe controller implements the UCIe protocol stack and manages the die-to-die connection, while protocol-specific bridge IP connects that UCIe infrastructure to interfaces such as AXI, CHI, CXL, PCIe, and CXS.

Functionally, the controller and bridge solve different parts of the architecture. In practice, a commercial UCIe controller configuration may integrate one or more protocol bridges as part of the overall IP, so the distinction described in this article refers to functional roles within the data path rather than a requirement that every implementation license two physically separate blocks.

Understanding that difference helps SoC teams determine which IP components are required for a particular chiplet architecture and where each component fits within the overall data path.

SmartDV’s UCIe IP for Next-Generation Chiplet Designs portfolio brings these components together with UCIe Controller IP, multiple protocol-specific Bridge IP options, and UCIe Verification IP.

What Does UCIe Controller IP Do?

UCIe Controller IP provides the core logic required to implement the Universal Chiplet Interconnect Express protocol within a chiplet or multi-die system.

The controller manages the UCIe-specific portions of the connection, including protocol-layer operation, die-to-die adapter behavior, Flit handling, retry mechanisms, CRC and parity functions, sideband communication, link management, packaging configurations, and other requirements defined by the supported UCIe specification.

SmartDV currently provides both UCIe 2.x Controller IP and UCIe 3.x Controller IP.

The UCIe 2.x Controller IP supports UCIe v2.0 and earlier revisions with operation through 32 GT/s, while the UCIe 3.x Controller IP supports UCIe v3.0 and operation through 64 GT/s. Both controller products support multiple protocol domains through dedicated bridge interfaces, including PCIe, CXL, AXI, CXS, and CHI.

The controller therefore establishes the UCIe die-to-die foundation, but that does not necessarily mean the surrounding subsystem communicates using UCIe directly.

What Does UCIe Bridge IP Do?

UCIe Bridge IP connects an existing SoC protocol domain to the UCIe controller and die-to-die path.

A chiplet may contain processors, accelerators, memory-facing logic, coherent fabrics, or I/O subsystems that already communicate using an established protocol. Rather than redesigning those subsystems around a different interface, bridge IP allows the existing protocol traffic to be carried across the UCIe connection.

For a more detailed look at the individual protocol options and where each fits, see UCIe Bridge IP Explained: Connecting AXI, CHI, CXL, PCIe, and CXS Across Chiplets.

SmartDV provides dedicated bridge solutions for:

• 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

Each bridge addresses the behavior of its corresponding protocol while providing connectivity into the UCIe architecture.

How the Controller and Bridge Work Together

A simplified, logical view of the UCIe chiplet data path can be thought of as:

Protocol Fabric → Protocol Bridge → UCIe Controller → UCIe PHY / Die-to-Die Link

On the receiving side, that path can continue through another UCIe controller and into the protocol environment used by the destination chiplet.

The exact topology depends on the design. A system may use the same protocol on both sides of the link, or different chiplets may connect into a larger architecture through different subsystem interfaces.

For example, an AXI-based accelerator subsystem may use AXI to UCIe Bridge IP to connect into the UCIe controller. A coherent processor subsystem may instead require CHI to UCIe Bridge IP. A memory or accelerator architecture using CXL may require CXL to UCIe Bridge IP.

This separation between the controller and bridge allows the UCIe link to serve as a common die-to-die foundation while the surrounding chiplets retain the protocol architecture appropriate to their function.

Why a Chiplet Design May Need More Than One Bridge

Advanced chiplet architectures may contain multiple protocol domains.

An AI or HPC device, for example, may combine processor-facing coherent traffic, accelerator data paths, memory connectivity, and external I/O within the same multi-die system. Those functions may not all use the same protocol.

One part of the system may use AXI, another may rely on CHI, while another communicates using CXL or PCIe.

In that type of architecture, a single bridge may not represent every interface required by the system. Different chiplets or subsystems can require different bridges even though they share the same UCIe-based die-to-die infrastructure.

This is one reason a modular IP strategy can be useful. Engineering teams can select the controller and protocol connectivity required by the architecture rather than treating every UCIe implementation as a fixed, monolithic stack.

See Building a Modular UCIe IP Stack for AI and HPC Chiplet Architectures for a closer look at how UCIe Controller IP, protocol-specific Bridge IP, and Verification IP can be combined across heterogeneous multi-die systems.

How the Protocol Determines the Bridge

AXI-Based SoC and Accelerator Subsystems

For systems using AMBA AXI internally, AXI to UCIe Bridge IP provides a path between AXI traffic and the UCIe link.

SmartDV’s current AXI to UCIe Bridge IP supports AMBA AXI5 with backward compatibility for AXI4 and AXI3, multiple AXI data widths, and UCIe operation through 64 GT/s.

Coherent CHI Architectures

Systems using AMBA CHI require additional coherency-related behavior across the bridge boundary.

SmartDV’s CHI to UCIe Bridge IP supports Request, Home, and Slave node types along with CHI Protocol, Network, and Link layer behavior for coherent chiplet communication.

CXL-Based Memory and Accelerator Connectivity

CXL architectures may use CXL.io, CXL.cache, CXL.mem, or combinations of those protocols depending on the device type and implementation.

SmartDV’s CXL to UCIe Bridge IP carries these CXL protocol functions across the UCIe connection, making it relevant to coherent accelerator, memory expansion, and other CXL-based chiplet architectures.

PCIe-Based Subsystems

PCI Express remains widely used for high-speed I/O, accelerators, networking, and storage connectivity.

The PCIe to UCIe Bridge IP connects PCIe Root Complex and Endpoint functionality to UCIe and currently supports UCIe 3.0 and PCIe 6.0.

CXS Streaming Interfaces

AMBA CXS supports high-bandwidth streaming communication between components and interconnects.

SmartDV’s CXS to UCIe Bridge IP carries CXS streaming traffic across UCIe while supporting credit exchange, link activation, packet control, error handling, and other CXS-related behavior.

Key Technical Challenges When Combining Controller and Bridge IP

The division between controller and bridge creates a clear architecture, but it also creates an important integration boundary.

Teams need to consider how transactions move from the originating protocol through the bridge and into the UCIe stack, and then how that behavior is reconstructed or consumed at the destination.

Important considerations can include:

• Transaction ordering and completion behavior
• Credit and flow-control mechanisms
• Protocol-specific coherency requirements
• Flit formatting and packet handling
• Lane and data-width configuration
• Link initialization and training
• Sideband communication
• Reset and recovery sequences
• Error detection and retry behavior
• Power-management behavior

The requirements on the AXI, CHI, CXL, PCIe, or CXS side do not disappear when traffic reaches the UCIe boundary. The complete architecture needs to preserve the behavior required by both protocol domains.

How Verification Teams Should Approach Controller and Bridge Integration

Verification should follow the complete data path rather than treating the controller and bridge as unrelated blocks.

A bridge may behave correctly when tested independently, and the UCIe controller may also pass interface-level verification, while system-level problems still appear when transactions cross the complete path.

Verification teams should therefore exercise:

• Source-protocol transactions entering the bridge
• Translation or adaptation through the bridge
• UCIe packet and Flit behavior
• Link initialization and sideband operation
• Flow control and backpressure
• Reset, retry, and recovery scenarios
• Error injection on both sides of the interface
• End-to-end transaction integrity
• Stress traffic and corner-case combinations

SmartDV’s UCIe VIP provides protocol-aware verification support for UCIe implementations through UCIe 3.0, including mapped protocol support, Flit-format coverage, link training, retry and recovery behavior, error injection, and functional coverage.

The existing article Why UCIe Verification Is Critical for Chiplet-Based SoC Design provides a deeper discussion of the verification challenges created by die-to-die links and bridge integration.

SmartDV’s FAQ Why Does Chiplet-Based Design Require Specialized Verification? also explains why chiplet verification needs to account for bridge logic, protocol boundaries, initialization, traffic behavior, interoperability, and system-level debug.

Related SmartDV UCIe Products and Resources

SmartDV provides complementary UCIe Design IP and Verification IP for building and validating chiplet-based systems.

• UCIe 2.x Controller IP
• UCIe 3.x Controller IP
• 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 Verification IP

For teams evaluating a modular IP strategy more broadly, Flexible IP Licensing and Customizable IP: What SoC Teams Should Consider discusses how configurable Design IP and Verification IP can be aligned with project-specific architecture and reuse requirements.

Article Summary

UCIe Controller IP and UCIe Bridge IP solve different but complementary parts of the chiplet interconnect problem.

The UCIe controller implements and manages the UCIe die-to-die protocol stack. The protocol bridge connects that UCIe infrastructure to the AXI, CHI, CXL, PCIe, CXS, or other protocol environment used by the surrounding subsystem.

A simplified, logical view of the architecture therefore looks like:

Protocol Fabric → UCIe Bridge IP → UCIe Controller IP → UCIe PHY / Die-to-Die Link

The correct combination depends on the chiplet architecture. Some designs may require one protocol bridge, while larger heterogeneous systems may use several bridge types across different chiplets.

Verification should extend across the complete path so teams can confirm not only that the UCIe link operates correctly, but also that transactions maintain the required protocol behavior as they move between the originating subsystem, bridge logic, UCIe controller, and destination chiplet.

Frequently Asked Questions

What is the difference between UCIe Controller IP and UCIe Bridge IP?
UCIe Controller IP implements the UCIe die-to-die protocol stack and manages the UCIe connection. UCIe Bridge IP connects the controller to an existing protocol domain such as AXI, CHI, CXL, PCIe, or CXS.

Does every UCIe design require Bridge IP?
The required architecture depends on how the subsystem connects to UCIe. When an existing protocol domain such as AXI, CHI, CXL, PCIe, or CXS needs to communicate across the UCIe link, a corresponding bridge provides the connection between that protocol and the UCIe infrastructure.

Can one UCIe system use multiple Bridge IPs?
Yes. A heterogeneous multi-die system may contain several protocol domains. Different chiplets or subsystems can therefore use different bridge types while sharing UCIe as the standardized die-to-die interconnect.

What protocols can SmartDV connect to UCIe?
SmartDV currently provides dedicated UCIe Bridge IP for AXI, CHI, CXL, PCIe, and CXS.

How are UCIe Controller IP and Bridge IP verified together?
Verification should exercise the complete protocol path, including source-protocol transactions, bridge behavior, UCIe Flit and link operation, flow control, reset, sideband communication, errors, retries, recovery, and end-to-end transaction integrity.

Build the UCIe Stack Your Chiplet Architecture Requires

SmartDV provides UCIe Controller IP, protocol-specific Bridge IP, and UCIe Verification IP so engineering teams can build a die-to-die interconnect strategy around the interfaces and capabilities their architecture actually requires.

Explore SmartDV UCIe IP for Next-Generation Chiplet Designs to review controller, bridge, and verification solutions for AI, HPC, networking, data center, and other multi-die SoC architectures.