Arm FCSA and the Journey to Standardizing Open Chiplet-Based Design

I have written before about an inter-chiplet communication challenge to realizing the dream of multi-die designs built around open-market chiplets. Still a worthy dream but it’s going to take a journey to get there. Arm recently donated their Foundation Chiplet System Architecture (FCSA) to the Open Compute Project (OCP) as a step along this journey. Where CSA builds around Arm architectures, FCSA is ISA neutral, aiming to address a larger constituency of potential chiplet suppliers. Current emphasis is on automotive and infrastructure applications.

The driver for FCSA

We’re already moving on from software defined vehicles to AI-defined vehicles. According to John Kourentis (Director, Automotive Go-to-Market for EMEA at Arm) this switch is happening very quickly, most noticeably in China where he says the in-cabin experiences are already mind-blowing, with a heavy emphasis on voice-based rather than touchscreen control. Especially as auto OEMs (and Tier1s) add more semi-autonomous or autonomous capabilities, AI continues to become more central (see this for a revealing insight into Chinese automotive progress compared with Tesla).

More AI requires more complex systems built around advanced AI accelerators, signal processing pipelines, high-bandwidth memory and other features. Far too big to fit into a single die, these are only possible to construct in chiplet-based designs. There are additional benefits to that decision: such systems can scale across model families, allowing OEMs to add features for premium models and to enable update for rapidly evolving functions like AI accelerators without major redesign.

Very compelling, but how do these chiplets interact? We go to chiplets for manufacturing, maintainability and other reasons but all those chiplets and the connectivity between them still reflect an idealized monolithic logic design with bus and control connectivity between logic functions, though now partitioned into subsystems around chiplet boundaries. Chiplet subsystem design intent is still like regular SoC design but how do you deal with bus connectivity between chiplets?

My initial take

John’s view is that today chiplet designs are very much a proprietary, single vendor enterprise (though I believe HBM chiplets would be sourced externally). Connectivity between chiplets and the on-chiplet interfaces to that connectivity can be managed in-house.

This is important because bus connectivity in the monolithic design will be largely NoC-based (PCIe and DDR might be handled differently). That NoC (or NoCs) will allow on-chiplet functions to connect through standard protocol interfaces like those defined in AMBA but will translate and packetize traffic to its own internal protocol for efficiency, then translate back again at the destination.

Within a chiplet this is not a problem but crossing between chiplets these translators and NoC network functions for managing latency, bandwidth, quality of service, surely must live somewhere? In the monolithic design they would simply be added logic blocks between subsystems in the RTL. In a chiplet-based design they could in principle be implemented as active elements on the interposer, but I’m told that is an expensive option. The only place to put logic is on chiplets. Between chiplets you can only have wires.

None of this is a problem for an all-proprietary design, but what if you want to mix chiplets from different vendors who might use different NoCs with their own traffic management logic at the chiplet edge?

The FCSA approach

FCSA has an answer: the AMBA CHI C2C (chip-to-chip) protocol. Any NoC vendor can provide support for such interfaces and (with suitable compliance testing) be assured that it can communicate effectively with a similar interface on another chiplet. This is obvious for coherent connections, but also for non-coherent connections apparently. The solution to my earlier dilemma is a conversion on chiplet A from whatever internal NoC protocol is supported on A, to CHI C2C interface at the edge of A, from there connecting through a simple bundle of wires to a CHI C2C interface on chiplet B, which will convert to whatever internal NoC protocol is supported on B. (I’m skipping mention of UCIe for simplicity.)

An in-house design team starting from a monolithic design must, on partitioning, insert these CHI C2C protocol bridges between partitions. If they are building around open chiplets, they can rely on convertors on those chiplets and need only insert CHI C2C interfaces at the edge of their own chiplet design and bundles of wire to connect bridges.

For me there is still an open question around how much overhead there would be in using CHI for a non-coherent interface. Perhaps the standard already makes allowance for that usage. I cannot tell on a quick glance of either CHI or CHI C2C specs.

What about external and in-system traffic management?

This need doesn’t go away. I have earlier heard mention of system traffic management being folded into into one of the chiplets, in addition to whatever else it might do. Nice general idea but now chiplet system experts seem to be pushing for a more structured approach around IO hub chiplets. These are dedicated to traffic management, in-system and external. The CHI C2C bridges become the standard to bridge between a function-centric chiplet, such as an AI accelerator or a signal processing system, to the IO hub where sophisticated traffic management can take care of system quality of service.

Interesting – I now see the larger picture. You can read the Arm FCSA press release HERE.

Also Read:

Arm Lumex Pushes Further into Standalone GenAI on Mobile

Arm Reveals Zena Automotive Compute Subsystem

S2C: Empowering Smarter Futures with Arm-Based Solutions