Physical Design Interview Questions: Read Reports and Defend Your Next Fix

Physical design interview questions test whether you can connect an implementation report to a defensible next experiment. Identify the flow stage, clock and parasitic models, then compare a proposed fix against both its target and its regressions. A setup violation needs path and physical evidence before it justifies resizing, spreading placement or changing the clock tree.

This article uses an original, explicitly fictional report packet spanning placement, clock-tree synthesis and routed analysis. OpenROAD documentation supplies tool facts; a local Python check verifies the packet’s arithmetic and decision rules. No OpenROAD flow, parasitic extraction or silicon measurement was executed for this article. These are worked teaching exercises, not candidate-reported employer questions.

Use PracHub’s timing and testability question to rehearse the timing vocabulary. Here, the main task is deciding what evidence from several physical-design stages supports the next change.

Physical-design reports are compared across placement, clock-tree synthesis and routing before choosing a controlled experiment

Which report are you actually reading?

Official flow fact: OpenROAD Flow Scripts separates stages and saves logs, design databases and reports. Its tutorial distinguishes placement, clock-tree synthesis, global routing and detailed routing, rather than treating every timing number as a final result. OpenROAD flow tutorial

Before interpreting a number, record the checkpoint, netlist revision, constraints, timing corner, units and parasitic source. Ask whether clocks are ideal or propagated. Confirm which endpoints and path groups the report covers. If any of these differ between runs, explain the difference before attributing the change to your proposed fix.

For this exercise, a fictional block has a fixed netlist, clock target and analysis corner. The baseline contains three snapshots:

Fictional snapshot	Setup worst slack	Hold worst slack	Analysis description
Placement	`+0.04 ns`	Not supplied	Placement-based wire estimate; ideal clock
After CTS	`−0.06 ns`	`−0.02 ns`	Placement estimate; propagated clock
Routed	`−0.20 ns`	`−0.04 ns`	Routed parasitics; propagated clock

Do not treat the first row as final timing closure. Hold was not supplied, and the analysis model changes afterward. Keep the unsupplied hold result marked unknown; substituting zero would imply a check this packet does not contain. The CTS-to-routed setup change is −0.14 ns, but the aggregate numbers alone do not identify its cause.

Does low average utilization rule out congestion?

Our fictional baseline has 6,000 µm² of cell area in a 10,000 µm² core: 60% average utilization. Its global-routing overflow summary is nevertheless 18 in the exercise’s stated counting convention. That is not contradictory. Average area occupancy does not describe where routing demand meets unavailable or contested resources.

Reasoned diagnosis: inspect the spatial pattern before changing the whole core. For the original scenario, assume a dense group of connected cells beside a macro channel. A local demand hotspot, pin access or blocked routing resources are hypotheses to investigate; none is established by the number 18 alone.

Request the congestion by layer, the macro-channel geometry and pin locations, and the nets crossing that channel. Distinguish a channel problem from broadly dense placement. A larger floorplan can provide space, but it may also lengthen important connections. Reducing a density target without checking the new routes is an experiment, not a guaranteed solution.

Official tool fact: OpenROAD’s global router can produce a congestion report and can be instructed to continue with remaining congestion. A completed command under that option does not establish a congestion-free design. Global routing reference

What changed after clock-tree synthesis?

Official CTS fact: OpenROAD’s report_cts reports quantities including inserted buffers, clock roots, subnets and sinks. These are useful implementation observations, but buffer count alone is not a timing-quality verdict. Clock-tree synthesis reference

The fictional transition from positive placement setup slack to negative CTS slack prompts a question, not an automatic clock-tree accusation. Compare clock arrivals, skew, insertion latency, transition and the data path under the relevant models. Check whether optimization also changed data cells or placement between checkpoints.

A proposed “reduce skew” answer needs the affected launch and capture relationships. A global skew summary can hide which endpoints are failing, and changing a clock branch can affect more than one check. State which clock paths you would inspect and what result would support your hypothesis.

The PracHub static-timing article covers setup/hold arithmetic and constraint exceptions. For this case, keep the focus on stage comparison and physical consequences; changing a functional timing exception merely to remove a violation is outside the proposed fixes.

Why can routed timing differ from placement estimates?

Official tool boundary: OpenROAD’s resizer documentation warns that placement-based parasitics cannot accurately predict routed parasitics. Its extraction documentation describes extracting parasitics from a routed design. These are different evidence states. Resizer guidance, parasitics extraction

For the fictional −0.14 ns CTS-to-routed regression, request the same endpoint’s path details at both stages. The worst endpoint may have changed, so subtracting two worst-slack values does not necessarily measure one path’s deterioration. Compare cell and net contributions, the route, loads and the analysis settings.

A longer detour around a blocked channel is one possible explanation. Another is a changed clock path or a different critical path. Check the evidence that separates these alternatives before recommending more buffering. A lower estimated wirelength is also insufficient if the relevant electrical conditions or final routed path become worse.

Compare two interventions without selecting the prettiest number

The following numbers are original fictional observations, not OpenROAD output or predictions from a physical simulator. Both variants are compared at the same routed analysis stage and fictional corner. Variant A spreads placement by enlarging the core; variant B increases selected cell sizes while retaining core area.

Routed metric	Baseline	A: spread placement	B: selected upsizing
Core area, `µm²`	10,000	12,100	10,000
Cell area, `µm²`	6,000	6,000	6,600
Wirelength, `µm`	10,000	11,000	9,800
Setup worst slack, `ns`	−0.20	−0.08	+0.01
Hold worst slack, `ns`	−0.04	−0.06	−0.05
Global-route overflow count	18	0	12
Detailed-route DRC count	7	0	3

A reduces the supplied overflow and DRC counts to zero and improves setup by 0.12 ns. However, core area rises 21%, wirelength rises 10%, and hold becomes more negative. Its utilization is about 49.59%, calculated from cell area divided by core area. Calling A “closed” would ignore both negative timing checks.

B improves setup by 0.21 ns and reaches positive setup slack at this one corner. Its cell area rises 10%, yielding 66% utilization. Hold remains negative, and the packet still contains routing overflow and three DRC violations. B’s setup result does not make it an acceptable final implementation.

The table does not establish that spreading always harms hold or upsizing always leaves DRC. Those are outcomes assigned to this exercise. In a real experiment, retain the logs and changed objects that could explain the observed trade-off.

Variant A still fails timing; variant B passes setup at one corner but retains hold and routing failures

What is your acceptance record?

For this exercise, the stated acceptance subset requires nonnegative setup and hold slack, zero supplied overflow and DRC counts, cell area no greater than 6,600 µm², and core area no greater than 12,100 µm². Neither variant passes it. These thresholds belong to the teaching case; they are not foundry rules or universal sign-off criteria.

The original Python component check passed 13 arithmetic and classification checks. It verified the area and wirelength percentages, utilization, setup changes, the stage-level regression and rejection of both variants. It also checked that a hypothetical corrected A passes this limited rule and that exceeding the core-area boundary is rejected.

The execution checks the supplied exercise’s internal consistency. It does not validate a route, cell library, RC model, clock tree or silicon behavior. Keep the report data and the tool that checked its arithmetic separate from an actual EDA execution record.

A real acceptance record must add the project’s applicable corners, modes, electrical limits, connectivity, power and physical-verification requirements. “Zero DRC” also needs a named checker and rule scope. A detailed router’s reported count cannot, by itself, establish complete foundry sign-off.

Defend the next experiment and its rollback

A defensible answer can be: “Neither variant is acceptable. A’s routing evidence is more promising, but it still fails setup and hold. I would preserve A as a checkpoint and investigate a localized data-path repair, then rerun the affected implementation stages and all required timing checks.” This selects a next experiment without declaring an unsupported winner.

Name the failing endpoints, proposed changed cells or nets, expected mechanism, and stopping rule. If the repair introduces new congestion or exceeds the area budget, restore the checkpoint and investigate another intervention. Do not combine density, clock constraints and cell sizing changes in one unexplained run; you would lose the comparison needed to explain the result.

Official command context: OpenROAD documents repair_timing after CTS with propagated clocks and explains its setup-before-hold repair ordering. That is relevant context for choosing a valid stage, not a promise that one command resolves this case. The flow’s loaded libraries, constraints and physical state remain prerequisites. Timing repair reference

How would you collect real evidence with OpenROAD?

Start from an officially supported flow and a known design configuration. Record tool revisions, platform/library files, SDC, RTL or netlist identity and run settings. Preserve separate output directories or named variants so a later run cannot silently overwrite the baseline.

The official flow tutorial provides a complete starting example and identifies the resulting stage files. Use its commands for the installed release. Capture placement, CTS and routed checkpoints, then compare the same metrics with their analysis models attached. The tutorial also cautions that outputs can vary across releases; its sample figures are not measurements of your own run.

Change one intervention at a time. Keep the unchanged inputs and the exact configuration difference, then retain detailed paths and physical reports alongside the summary. If a run stops before extraction, label extracted timing unavailable. Do not fill its final-report cells with placement estimates or another variant’s results.

This article supplies the interpretation exercise and the arithmetic check. It does not distribute an executed OpenROAD flow or measured intervention benchmark. The official installation guide explains the supported prebuilt setup for readers who want to produce their own implementation evidence.

Practise the boundaries of a physical-design answer

The verified PracHub bank did not provide a dedicated placement-and-routing question set for this article. These five adjacent records support hardware reasoning, input correctness and explainable decisions; their scope is stated individually.

PracHub question	Useful connection and boundary
Explain timing and testability concepts	Timing terminology; not a measured PnR exercise
Improve chip performance without process advances	Performance alternatives; distinguish architecture from physical implementation
Describe common RTL lint warnings and errors	Input-quality reasoning; lint does not establish physical closure
ASIC Verification Fundamentals Across SystemVerilog UVM CDC and Architecture	Verification scope; functional checks and physical checks differ
Explain a Difficult Technical Decision	Compare alternatives and regressions; general decision practice

Begin with Explain timing and testability concepts, then return to the fictional packet and defend one next experiment. State the checkpoint, target, regression, acceptance rule and missing evidence. Use those five items to make your proposed experiment reviewable before changing the design.

Sources and Further Reading

Documentation checked October 11, 2026. All report values are fictional teaching inputs. Actual local execution checked arithmetic and decision rules only.