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

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.

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.