The industry assumption is that AI inference is a throughput problem you solve by stacking FLOPs. The Cadence white paper "Designing Physical AI Systems Under Real-World Constraints" reframes the question: the system must close a sensing-inference-response cycle inside a bounded window, and every element in that path—memory, interconnect, I/O, synchronization—sits inside the control loop.

The binding constraint is worst-case latency from sensor capture to actuator command, not peak compute. The paper names the subsystems that carry that latency: memory interfaces, die-to-die links, I/O blocks, and interconnect fabric. A delay in any one of them changes the relevance of the incoming data. Response-time variability, the document notes, makes the system harder to control—a different failure mode than a throughput miss.

The edge environment layers a second constraint set on top of the timing budget. Thermal variation, vibration, motion, shock, and humidity are listed as operating conditions the silicon must survive. The paper names these as design inputs but attaches no wattage, no temperature range, no vibration spectrum to any of them. The buyer sources those numbers from the application spec, not from this document.

Beyond a single die, the paper describes architectures spanning edge, industrial, vehicle, and cloud boundaries. Data must be exchanged and coordinated across those boundaries, and the same data-movement and synchronization constraints that govern the local loop extend outward. No specific interconnect standard or bandwidth figure is named for the cross-boundary link.

Die Brief's read: the document identifies the constraint set but does not quantify it—no latency budget, no power envelope, no memory-bandwidth target, no thermal ceiling appears anywhere in the paper. The designer is told what must be balanced but not what the numbers are for any named application. The real constraint for the buyer is that the control-loop deadline is set by the slowest element in the path, and this paper does not tell you which element that will be. For the fab, memory-interface, die-to-die, and I/O decisions must be made before the application timing budget is pinned down, because the paper treats those blocks as the implementation vehicle for the constraints.

What remains unmeasured: the actual timing budget for any specific sensor-actuator pair, the power envelope at the edge, a reliability metric (the paper invokes safety but gives no failure-rate target), and the memory bandwidth required to close the loop. The document is a framework, not a spec. Watch for a companion application note that maps a concrete workload to a latency and power budget, or for the next revision to attach numbers to the constraint set.

The document names the constraint set but attaches no numbers to it; the buyer cannot size the control-loop deadline from this paper alone. The fab must commit to memory-interface and die-to-die topology before the application timing budget is known.

The white paper is a constraint taxonomy, not a design spec. It tells the architect which blocks sit in the critical path (memory, interconnect, I/O, sync) but provides no latency figure, no wattage, no bandwidth target. The buyer's risk is committing to a die-to-die or memory-interface topology before the application timing budget is fixed, because the paper positions those silicon-level decisions as the implementation vehicle for constraints it never quantifies.