Static timing analysis assumes pipelined logic, whereas systolic arrays repeat data movement across a two-dimensional structure. Conventional STA fits CPUs and much control logic: balanced clock trees, predictable fanout, and timing arcs that map cleanly to the physical netlist. Systolic arrays and tensor processing units break several assumptions at once. General-purpose constraints may under-constrain important paths, or over-constrain nearly everything until closure is unattainable.
After working through enough AI accelerator tape-out programs, we know where the usual STA process can give a misleading picture. This is how we approach constraint setup for these blocks, where the conventional method falls short, and which practical alternatives we use.
Why Systolic Arrays Challenge STA
A systolic array is a 2D grid of processing elements (PEs), passing data between neighbors through a regular pipeline. Every PE performs the same operation each cycle at a regular clock rate. Fanout within each PE is low, but clock distribution has very high global fanout. A large array, such as 128x128 PEs, drives tens of thousands of flip-flops in a highly regular physical layout, so its clock tree is geometrically unlike a CPU.
For STA, this means skew across the array does not behave like the skew that CTS was tuned to handle in general-purpose logic. Clock arrival differences between neighboring PEs are usually small and consistent, which helps. The difficult skew is between the array clock domain and the control logic clock domain. Their interface consists of synchronizer flip-flops exposed to both sides of that skew budget. Constraints therefore need explicit setup and hold budgets based on the real physical separation between the array edge and the control registers, rather than only the logical clock domain crossing.
Clock Crossings in Tensor Engines
Tensor processing units commonly operate their compute array at a different frequency from the memory interfaces and host interconnect. Crossings among those regions are straightforward conceptually but sensitive numerically. A 2x frequency ratio between the systolic array clock and the DRAM interface gives one direction a setup window of half a period and the other a full period. If STA sees both sides as ordinary synchronizer flops without explicit multi-cycle path constraints, it can report false violations from fast to slow while overlooking genuine violations from slow to fast.
The familiar remedy is to apply set_multicycle_path constraints where the cycle relationship is fixed. Tensor engines complicate that approach because some crossings depend on operating mode. In batch inference mode, the relationship may be 2:1. In prefill mode for another layer type, the domains may run synchronously. An SDC file describing only the common mode can yield clean closure reports while concealing violations in the less frequently used mode.
This is primarily a constraint documentation issue, not a tool limitation. RTL designers understand the operating modes, while physical design engineers understand the timing budgets, but there is often no structured mechanism for sharing every case. We require the synthesis engineer to create a constraint coverage matrix during RTL handoff. It lists every clock domain crossing and each operating mode that changes its cycle relationship. That matrix serves as the source of truth for the SDC file.
High-Fanout Nets and Exploding Path Reports
Systolic arrays also contain control signals with extremely high fanout. A global enable that controls every PE in a 256x256 array reaches 65,536 flip-flop clock enables. STA can handle such nets in principle, but report generation can produce millions of paths. That path-count explosion makes it hard to see which reported paths are relevant to closure.
A frequent workaround is to mark high-fanout control signals as false paths and handle them as quasi-static inputs that need no tight timing closure. This is valid when a signal is set during initialization and held for the whole compute pass. It becomes wrong when that same signal toggles at each tile-computation boundary. In that case it behaves like a multi-cycle data path, so it still needs analysis, though not on a single-cycle basis.
False-path exceptions belong on signals that change only between compute kernels. Signals changing during kernel execution require timing analysis. Making that distinction calls for the microarchitecture specification to be read together with the SDC file, rather than consulting the RTL alone. Without a structured record for this context, it is easily lost as work moves from the RTL team to physical design.
Hold Timing Across Regular Arrays
Hold violations in systolic arrays commonly gather at the array and control-logic boundary, for the same underlying reason as setup violations. Within the array, repeated structure is helpful: placement is uniform, neighboring PE wires are nearly equal in length, and nearby cells receive clocks with similar skew. That regularity makes internal hold closure more manageable than hold closure in irregular logic.
At the boundary, that regular pattern ends. The interface between the edge PEs of a 7nm systolic array and the address generation unit draws cells from different floorplan regions, each with different clock arrival times. Boundary hold margin is often worse than the STA report indicates because the report uses nominal clock arrival rather than the worst-case skew combination at the interface. Applying explicit worst-case skew scenarios to the boundary cells, instead of depending only on global hold analysis, exposes violations that the standard analysis can miss.
How Constraint Automation Contributes
In accelerator blocks, the most repeatable benefit we see from automated STA analysis is checking constraint coverage rather than optimizing timing. With correct constraints, the P&R tool and STA engine generally perform their roles well. Problems arise when constraints are incomplete or disagree with the microarchitecture, and those problems are difficult to find by inspecting the SDC file alone.
An automated check can read the RTL, locate each clock domain crossing, and confirm that the SDC file includes a constraint for every one. It runs in minutes and finds gaps that might otherwise appear as timing violations three P&R iterations later. We run it in the verify agent's pre-analysis pass, before the first timing run. The check does not decide which constraint is correct. It confirms that the specified constraints are complete and internally consistent.
Automation cannot derive these constraints from first principles. Determining that a crossing is a 2:1 multicycle path in batch mode depends on the microarchitecture, which is known by the design team rather than the netlist. The automation checks that this knowledge made it into the SDC; it does not replace the knowledge itself.
A Closure Order for AI Accelerator Blocks
From work on several 7nm and 28nm AI hardware blocks, we have found fewer late surprises by following this order: first build a complete clock domain crossing inventory before P&R, then validate the SDC against it, next run high-fanout analysis to find signals needing explicit path exceptions, and finally stage hold analysis with boundary-specific worst-case skew scenarios. None of these actions is new. The difference is applying standard physical design practice systematically instead of waiting for a troubling timing report.
Timing closure for AI hardware is not inherently more difficult than closure for general-purpose logic. The key is recognizing which constraints matter and where the tools can misrepresent the design. Preparing those inputs before the first P&R run costs less than finding the same issues during ECO.