physical design
Partitioning a Coherent Mesh
2026 · 8 min read
When a coherent mesh outgrows one physical partition, teams reach for the RTL hierarchy and start cutting. That's usually the wrong knife. RTL hierarchy, physical partition boundaries, and clock domains are three independent decisions — and most partitioning failures come from treating them as one.
A CPU chiplet built around a coherent mesh interconnect eventually faces the same wall: the mesh is physically large, it runs at a frequency where wire delay is a first-class citizen, and the place-and-route flow wants it in pieces. So the team partitions. And almost immediately, the conversation collapses three separate questions into one:
- RTL hierarchy — how the modules nest in the source,
- physical partitions — what place-and-route treats as independently optimized blocks,
- clock domains — where the synchronous boundaries actually sit.
None of these implies another. Four physical partitions can share one clock. One RTL hierarchy can hide five clock domains. A partition boundary can sit in the middle of a synchronous region with no functional consequence at all. Until a team says these three things out loud as separate decisions, every partitioning debate is three debates happening at once, each participant arguing about a different one.
The synchronous temptation
The default instinct is to keep the mesh synchronous: one clock domain across the whole interconnect, CPU clusters doing their own DVFS on the other side of a well-defined interface. It's the option with the least architectural surgery — no new CDC structures, no protocol-level questions about ordering across an asynchronous seam, no re-verification of the coherency logic.
What it buys in RTL simplicity, it pays for in physical implementation. A synchronous mesh at GHz-class frequencies means:
- clock insertion delay and skew across the full mesh extent,
- a clock tree whose power is no longer a rounding error,
- long XP-to-XP paths that won't close in one cycle,
- hold fixing across distances the tool would rather not think about.
The honest comparison is never "sync means no RTL change." Sync means less architectural change, more physical cost — clock tree buffers, routing resource, and register slices on every path that outgrew its cycle. Async means the opposite: cheap clock distribution, expensive protocol surgery. Neither option is free; they just bill different teams.
What an async boundary really costs on a coherent fabric
The async option gets mispriced constantly, because people price it as a data-path CDC. A coherent interconnect is not a data path. Insert an asynchronous boundary between crosspoints and you now have to answer, with evidence:
- how CHI transaction ordering is preserved across the crossing,
- how credit and flow control behave when the far side's clock stalls,
- how backpressure propagates without deadlock,
- what the crossing latency does to snoop round trips — and therefore to every cache miss in the system.
None of that is a bridge cell. All of it is protocol correctness, and all of it lands on whoever owns the interconnect's functional model. This is exactly the kind of change that looks like two weeks on a Gantt chart and is a quarter of verification in practice.
Register slices don't insert themselves
Here is the part that surprises architecture teams on every program: the pipeline stages that save the synchronous option are manual. No synthesis tool looks at a 4 mm wire, sighs, and adds a register slice. Someone has to:
- measure the physical distance of each long connection from a real floorplan,
- decide, jointly with physical design, where a slice can go without breaking a protocol assumption,
- edit the RTL and the interconnect configuration to match,
- re-run correlation, because every slice is a cycle of latency on some path.
That last point is why this is a modeling conversation and not just an implementation one. A register slice is invisible to a functional model and fatal to a performance model that ignored it. Cache-miss latency, snoop round trips, sustained bandwidth under congestion — all of them move when slices go in, and the only way to know which way they moved before silicon is a model that represents the pipeline structure honestly.
Flatten what, keep what
The other quiet decision is which hierarchies survive into physical implementation. The reference tile — CPU clusters, home nodes, a crosspoint, wrapped in a tidy top level — is a logical construct. Physical teams routinely flatten the interconnect logic: keep the CPU clusters as hard partitions with disciplined aspect ratios, and let the mesh logic — crosspoints, home nodes, pipeline slices — get placed and optimized as one region.
The trade is real. Preserved hierarchy gives you repetition, symmetry, and a floorplan that tiles. Flattening gives placement freedom, better timing on the paths that cross the would-be boundaries, and a clock tree that doesn't have to respect artificial walls. What you almost never get is both, and the choice interacts with everything above: a flattened mesh region makes a synchronous clock domain easier to balance; preserved tile boundaries make per-tile clocking — and per-tile DVFS — more natural.
Don't size partitions from someone else's floorplan
One more failure mode, because it recurs on every program: partition sizing taken from a reference design's cell counts and area numbers. Reference floorplans are useful for topology and relative placement. They are dangerous as area evidence — different cache configurations, different technology libraries, different synthesis flows, and different feature cuts make the numbers incomparable more often than not. When a reference says a subsystem is half the size your own data says it is, believe your own data. You will be the one living with the floorplan.
What the model owes this decision
Partitioning a coherent mesh is decided at the intersection of architecture and physical design, which is precisely where most teams have the least shared evidence. The architect has a functional model that passes protocol tests. The physical designer has a floorplan and a timing report. Neither artifact answers the question both of them are being asked: if we partition this way, what does the system's performance actually become?
That's the question a performance model exists to answer — with the clock structure, the pipeline slices, the partition-induced latencies, and the DVFS boundaries represented as first-class structure, not afterthoughts. Build it before the partition decision, and the decision gets made on evidence. Build it after, and the model spends its life explaining surprises.