A merged-mode scenario hid a violation that appears only after unmerging. How do you catch it?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
Mode merging creates a superset mode so fewer scenarios need analysis, but the merged constraints are only as good as the merge. If a clock, case value or exception from one mode masks a path that another mode checks, the merged scenario never tests it. Catch it by reviewing the merge report, comparing analysis coverage against the original modes, and running the individual modes at defined checkpoints.
Technical Explanation
- Scenario count is modes times corners, and mode merging reduces it. PrimeTime determines which input modes can be merged, merges their timing constraints, and generates superset output modes; modes that cannot be merged stay separate.
- You run it in multi-scenario mode: create scenarios with
create_scenario -mode -corner(PT), then runcreate_merged_modes(PT), and check the merged constraints and the analysis report in the merged_constraints directory. - Merging considers corners. The merged constraints are valid for a corner only if the input modes are valid for that corner. Using a merged mode on a corner one of its inputs never covered is a silent gap.
- Conflicts are where violations hide. The mode merging debug view reports clock-clock, clock-data, exception, group path, reconvergence and value conflicts. A value conflict, where one mode sets a case value and another does not, can disable arcs the other mode needs.
- Coverage exposes it.
report_analysis_coverage(PT) on the merged scenario next to the individual mode scenarios shows checks that are tested in the originals and untested in the merge. Usereport_analysis_coverage -status_details untested(PT) to see why. - A false path or clock group that belonged to one mode can end up applied more widely in a superset mode. That removes a path from analysis instead of making it pass, which no slack report shows.
- Keep a rule: the merged scenario is for iteration speed, and the individual modes run at defined points such as before each ECO sign-off and before tapeout.
What To Check
- Conflicts listed in the mode merging report and how each was resolved.
- Untested checks in the merged scenario that are tested in the original modes.
- Corners each merged mode is used in against the corners its input modes were valid for.
- Exceptions and case values that exist in only one input mode.
Command Checks & Actions
create_scenario -mode func -corner ssCreates the individual mode and corner scenarios.
create_merged_modesRuns mode merging and writes the superset modes and report.
report_analysis_coverage -status_details untestedLists untested checks and the reasons, per scenario.
report_exceptionsShows the exceptions active in the merged scenario.
report_timing -delay_type maxConfirms the suspect path in its original mode.
Healthy, Suspicious & Hard-stop Results
- Healthy (illustrative): Coverage in the merged scenario matches the union of the original modes, with no extra untested checks.
- Suspicious (illustrative): A few hundred checks untested in the merge but tested in one original mode, traced to one case value conflict.
- Hard stop: A path that violates in its original mode and is untested in the merge, with signoff planned on the merge only. Stop and run the original modes.
Common Mistake
The Trap: Treating zero violations in the merged scenario as proof of timing closure. A test-mode case value merged into the functional superset disabled a mux arc, so a functional path was never analysed. It failed by 25 ps once the functional mode ran alone, three days before tapeout.
What The Interviewer Is Testing
- Understanding what mode merging produces and when merged constraints are valid.
- Can you find missing analysis rather than only failing slack?
- A policy for when individual modes must still run.
Follow-up Question & Model Response
"Why does coverage catch this when timing reports do not?"
Candidate Model Response: A masked path does not show negative slack; it shows no slack at all, because it is not analysed. Timing reports only list paths that exist in the analysis. The coverage report counts every timing check as met, violated or untested, so a check that is tested in the original mode and untested in the merged one stands out even when both runs report no violations.
Practical Example
Tapeout Scenario: Eight functional and test modes merged into two superset modes across four corners (illustrative). The merged runs are clean. A coverage comparison shows 340 setup checks untested in merged_1 but tested in func_hs. The merge report lists a value conflict: test mode sets a mux select to 1, func_hs leaves it free. Running func_hs alone shows 3 violations of up to -25 ps through that mux. The merge is redone with the conflict resolved, and the individual modes are added to the pre-tapeout checklist.
PnR Flow Mentor Guide
Master the Physical Design Implementation Flow
Read the complete 8-chapter PnR Flow Mentor Guide free on the web — library setup through placement, clock tree synthesis, routing, chip finishing, hierarchical implementation, and ECO, all the way to stream-out.
Continue practising