A PD engineer sees worse congestion and setup slack in a second DCPeripheral implementation snapshot. An assistant can organize the differences quickly, but it may turn two moving numbers into a causal explanation. Start by asking which inputs changed, where each metric was measured, and whether its definition stayed constant. A physical report describes a particular database and analysis stage, so provenance belongs beside every metric.
Synthetic snapshot | P-A | P-B |
|---|---|---|
Netlist / constraints / library | N1 / C1 / L1 | N1 / C1 / L1 |
Stage / timing corner | Global route estimate / synthetic_slow | Global route estimate / synthetic_slow |
Placement seed / density target | 11 / 0.60 | 29 / 0.65 |
Estimated global-route overflow, track units | 20 | 45 |
Worst setup slack, ns | -0.04 | -0.12 |
Worst-path identity / local route details | Not supplied | Not supplied |
These hand-authored rows are normalized teaching fields, not literal tool output. For this exercise, overflow means the sum of positive demand-minus-capacity over the report's routing edges, using the same grid and reporting definition in both snapshots. The comparison says overflow increased by 25 track units and worst setup slack decreased by 0.08 ns. It does not establish that the worst paths are identical or that congestion caused the slack change. Seed and density both changed, and neither table contains the local timing paths.
PROMPT:
Compare P-A and P-B as read-only reports.
Return metric differences with units, provenance gaps, and hypotheses.
For each hypothesis request evidence that could support or weaken it.
Do not attribute cause from correlation or propose database edits as facts.A useful synthetic answer might hypothesize that higher density increased routing pressure and net delay. It should request congestion maps, the affected nets, path identities, and per-path cell/net delay comparisons. If the worst endpoint changes, a WNS comparison alone cannot tell you what happened to either original path. Other plausible explanations include different buffering or placement of critical cells caused by the seed. Label these as alternatives rather than listing them as discovered defects.
Write a three-sentence comparison note, then propose a future investigation that changes one controlled input. Keep the seed fixed while varying density, hold netlist, constraints, library, route settings, and analysis stage constant, and compare the same endpoint paths. Explain what you would record if overflow improves but the original critical path gets worse. The goal is to learn which evidence would discriminate explanations, not to promise a successful optimization.
Observed: overflow rises from 20 to 45 track units and WNS changes from -0.04 to -0.12 ns. Both seed and density differ, and path identities are missing. A congestion-related delay hypothesis needs local path and routing evidence. In a controlled comparison, improved overflow with worse path slack weakens a simple global-overflow explanation; retain both observations and inspect the local path rather than discarding the inconvenient metric.
One controlled pair can narrow a hypothesis but may still depend on the fixed seed. A later seed sweep can examine sensitivity once the first comparison is understood. Keep that as a planned experiment with named inputs and expected measurements. Also distinguish placement density targets from measured utilization: the two labels are not interchangeable without the reporting definitions and area denominators.
Global-route estimates do not establish detailed-route legality, extracted signoff timing, power integrity, or manufacturability. A clean congestion summary cannot stand in for those reports. OpenROAD global placement documentation describes timing-driven and routability-driven placement concepts; the rolling page was accessed 2026-10-18. Actual option names, metrics, and behavior require the installed tool revision. No tool command or implementation run has been performed in this case.