AMBA C2C Extends Chiplet Connectivity Across AXI and CHI

AMBA C2C is being developed to give chiplet designs a shared connectivity foundation across AXI and CHI. Its central engineering choice is to scale features through defined protocol subsets, while keeping AMBA packetization separate from the underlying die-to-die transport. That could let designers reuse the same broad architecture across simpler I/O links and more complex coherent systems.

One architecture for different chiplet needs

Chiplet applications span memory expansion, I/O and accelerator attachment, and heterogeneous compute systems. Those jobs don't all need the same capabilities. A link for non-coherent I/O may call for less functionality and implementation work than a connection between components in a fully coherent system.

AMBA CHI C2C already addresses variation in implementation complexity through property negotiation. Implementations can support the capabilities they need while retaining interoperability across chiplet types, vendors and generations. Arm says this mechanism includes backward and forward compatibility.

Even with that scaling mechanism, some chiplets need a simpler route to chip-to-chip connectivity. This is especially relevant to the installed base of AXI designs, which could benefit from being composed into chiplet systems without requiring the full feature set used by advanced coherent compute. Arm says partner feedback has reinforced the need for a common approach that covers both AXI and CHI, rather than separate connectivity solutions for each protocol.

AMBA CHI C2C has gained momentum for chiplet connectivity in fully coherent, heterogeneous compute systems and superchips. AMBA C2C is intended to build on that work and extend the architecture to a broader set of applications. Arm first discussed extending C2C connectivity to simpler, often AXI-based use cases in 2023.

Subsets set the feature and complexity level

Protocol subsetting is the core mechanism proposed for AMBA C2C. Defined subsets would set which protocol features are carried for a given class of use. A device or accelerator attachment could use a subset aligned with simpler AXI-based I/O and non-coherent traffic. More advanced subsets could provide the richer functions needed by coherent and heterogeneous systems.

The subsets connect the on-chip protocol to the chip-to-chip link in two steps: AMBA defines which protocol behavior is in scope, then specifies how that behavior is packetized for transport between dies. Packetization can be tailored to a subset while following a shared approach for AXI- and CHI-class traffic. The intended result is room to match implementation effort to the use case without abandoning a common architecture.

That distinction matters for AXI because AXI defines interface behavior rather than a native packet format. Its configuration and supported capabilities can also differ between implementations. Carrying AXI over a C2C link therefore requires a defined account of which AXI semantics cross the link and how they are represented in packets. Arm says that definition needs to evolve with AXI itself.

Protocol and transport remain separate

AMBA C2C follows a layered model: AMBA defines protocol behavior and packetization, while a transport such as UCIe supplies the underlying die-to-die connection. That boundary is intended to let the AMBA protocols and transport technologies develop on their own schedules while still working together.

This division has precedents in the chiplet ecosystem. AMBA CHI C2C uses UCIe Streaming, as described in a UCIe discussion and the UCIe 1.1 specification announcement. PCIe and CXL can also be transported over UCIe. UALink has adopted a related layered structure, defining packetization alongside protocol functions while separating those elements from the data-link and physical layers.

Fig. 1: Transporting AMBA protocols over UCIe with AMBA C2C.

For designers, separating protocol from transport creates a clear architectural boundary. AMBA C2C is intended to work with a range of die-to-die and chip-to-chip transports, rather than being tied to one physical implementation. The practical value will depend on the specification defining packetization and supported protocol behavior clearly enough for different implementations to interoperate.

What the proposal means for designers

AMBA C2C is still under development, in collaboration with industry partners. Arm says the specification will be freely available, royalty-free and architecture-neutral, following the development and licensing model used across the AMBA ecosystem. These terms describe the planned specification model; the source provides no release date or implementation availability details.

If the specification delivers on its stated approach, teams could have a shared way to connect designs ranging from AXI-based I/O to fully coherent CHI systems. The key details to watch are the defined subsets, the packetization rules for each, and how property negotiation handles implementations with differing capabilities. Those choices will determine how much design reuse the common foundation enables in practice.