Reviewing a congested floorplan before timing closure

Start with the observed constraint

Imagine a hypothetical block containing several memory macros and a large amount of connecting logic. An early implementation run shows localized routing congestion. The team must decide whether to change macro placement, pin access, utilization or the logical partition. The goal is a controlled comparison, not a promise that moving one macro will deliver a particular frequency.

A useful review begins with a reproducible baseline. Keep the netlist, libraries, technology files, constraints, floorplan and tool version together. Describe whether the observation comes from placement estimation, global routing or detailed routing. Those stages provide different levels of evidence and should not be treated as interchangeable signoff results.

Read the geometry and connectivity together

A visually balanced floorplan can still create difficult routes. Review the largest connectivity bundles, macro pin locations, narrow channels and the placement of logic that communicates across the block. Check whether routing demand is concentrated around a pin edge or whether a long connection crosses several unrelated regions.

Power structures, blockages and reserved resources reduce the space available to signals. The effective routing area may therefore differ from what a simple utilization number suggests. Examine macro halos and access restrictions in the context of the actual technology and library rules. A global percentage cannot explain every local bottleneck.

Define a small comparison experiment

Change one major hypothesis at a time. For example, compare rotating a macro to improve pin access with widening an adjacent channel. Keep the timing constraints and analysis stages consistent so the results can be compared. Record any exception, such as a change in the legal placement region required by the experiment.

Select measurements before running the variants: congestion distribution, estimated wirelength, timing by path group and the number and type of physical violations at the chosen stage. Include runtime and memory when they affect project feasibility. Do not select a preferred variant solely because one headline metric improved while another critical constraint became worse.

Trace the timing consequences

Moving a macro changes the physical context of many paths. Identify affected launch and capture regions, high-fanout controls and interfaces near the boundary. Compare timing under the same modes and corners, with appropriate parasitic assumptions for the stage. A pre-route improvement can disappear after extraction, buffering and clock implementation.

Review setup and hold separately. A change that shortens a path can help setup while making hold repair harder. Changes to placement density can also alter clock-tree and power-delivery options. The experiment should therefore preserve enough downstream context to show whether the apparent improvement is likely to survive the next stage.

Use implementation gates

An early floorplan gate should ask whether the main macros fit legally, power and signal access are plausible, and the connectivity can be implemented within the agreed constraints. Later gates add routed evidence, extracted timing and physical checks. The criteria should mature with the design rather than pretending that every stage already has final data.

Keep unresolved risks visible. A congested region may be acceptable for an exploratory run but unsuitable for a release candidate. Assign an owner and a next experiment to each open issue. If the required change affects the architecture or interfaces, bring the decision back to the appropriate team before continuing implementation.

A focused comparison worksheet

Prepare a row for the baseline and each candidate floorplan. Include the hypothesis, changed geometry, fixed inputs, analysis stages and the metrics selected for comparison. Attach maps at the same scale and use consistent report definitions. A reviewer should be able to tell whether an improvement came from the intended change or from an unrelated difference in the run setup.

Consider a channel between two memory macros. One candidate widens the channel; another changes orientation to improve pin access. The first may increase travel distance elsewhere, while the second may alter the placement of connecting logic. Record those effects rather than treating the local hotspot as the entire design. If a candidate changes the power-grid strategy or clock access, explicitly expand the comparison to include that consequence.

End the experiment with a decision statement: which candidate is recommended, which evidence supports it and what must be checked next. If the candidates are inconclusive, state the missing evidence and propose the smallest next run that can distinguish them. The worksheet does not require a winning result; an honest inconclusive result can prevent the programme from committing to an untested assumption.

Package the comparison for another engineer

The illustrative deliverable is a baseline-and-variants report with scripts, constraints, maps and the rationale for a proposed direction. State exactly which stages were executed and which checks remain. Include the configuration needed to reproduce the preferred candidate and the evidence that would invalidate its selection.

This is not a report of a delivered client design, a tapeout or an achieved power, performance or area result. It shows how to make a physical-design decision reviewable. Actual acceptance depends on the project’s technology, libraries, signoff requirements and the measured results from its authorized environment.

What to bring. What to review.

Questions before you begin.