What is the final gate before an ECO'd block tapes out?
From PDVerse PnR Interview Handbook · pdVerse Mentor Guide
Short Answer
After the last ECO, nothing incremental counts. The gate is a full extraction of the final layout, a full PrimeTime run in every scenario with SI and exhaustive PBA, a coverage and constraint check, equivalence checking of the final netlist, and clean physical checks. Every one must pass on the same final database, or the block does not go.
Technical Explanation
- Incremental analysis is for iteration. The PrimeTime UG notes that what-if crosstalk results can differ slightly from a full analysis, and recommends a full analysis with complete parasitic and netlist data from the physical tool for final signoff.
- Start with trust checks. The UG flow is link and resolve errors, run
check_timing(PT) and resolve them, runreport_analysis_coverage(PT) and resolve untested checks, then analyse. An ECO can add unclocked or unconstrained pins, so coverage is rerun, not copied. - Run every scenario. A scenario dropped for ECO speed or merged for iteration comes back for the gate. Report violations across all of them with
report_constraint -all_violators(PT), which also covers max transition and capacitance. - Use exhaustive PBA on anything close. Waivers are accepted only with regular exhaustive PBA evidence, never ML-PBA, and SI must be on for all of it.
- Prove function. Run Formality between the golden reference and the final netlist:
match(FM), thenverify(FM), and reviewreport_failing_points(FM) if anything fails. Every ECO, including timing-only sizing, changes the netlist. - Prove the layout. In ICC2,
check_routes(ICC2) andcheck_lvs(ICC2) must be clean on the final block. They are ICC2 checks; foundry signoff DRC and LVS in the external physical verification tool still run on the final GDS. - Tie it together. Timing, extraction, equivalence and physical checks must all refer to the same final database. A pass on a different version is not evidence.
What To Check
- All reports come from the same final netlist, layout and parasitics.
- Zero violations in every scenario, or waivers backed by exhaustive PBA.
- No new untested checks against the pre-ECO coverage report.
- Formality equivalent with no unmatched or failing points.
- Zero opens, shorts and routing DRCs in the final checks.
Command Checks & Actions
check_timingFinds constraint and clocking problems on the final netlist.
report_analysis_coverageConfirms no checks became untested.
report_constraint -all_violatorsLists every timing and DRC violation across scenarios.
report_timing -pba_mode exhaustive -nworst 1 -slack_lesser_than 0 -max_paths 1000Final PBA check, worst recalculated path to each remaining GBA violation.
check_routesRouting DRC, opens and antenna on the final block.
check_lvsShorts, opens and floating routes on the final block.
verifyEquivalence of the final netlist against the reference.
Healthy, Suspicious & Hard-stop Results
- Healthy (illustrative): All scenarios clean with SI, coverage unchanged, Formality equivalent, check_routes and check_lvs at zero, all from one database.
- Suspicious (illustrative): Three setup endpoints at -2 ps waived with exhaustive PBA in the scenarios where they fail, reviewed and signed.
- Hard stop: Any report from an earlier database, any scenario not run, or Formality not run after the last ECO. The block does not tape out.
Common Mistake
The Trap: Signing off timing on the post-ECO PrimeTime run while Formality was last run two ECOs earlier, because "the last one was only hold buffers". One of those buffers was inserted on the wrong pin of a mux, a functional change no timing report shows, and equivalence checking would have flagged it in an hour.
What The Interviewer Is Testing
- Do you list timing, function and physical checks as one gate on one database?
- Knowing why incremental results are not signoff results.
- Understanding what ICC2 physical checks cover and what is left to the physical verification tool.
Follow-up Question & Model Response
"Why must coverage be rerun after an ECO if the constraints did not change?"
Candidate Model Response: Coverage depends on the netlist as well as the constraints. An ECO can add cells with unconnected or unclocked pins, change a case-analysis path, or disable an arc through a new cell. Any of those can make a check untested without a single violation appearing. Rerunning report_analysis_coverage (PT) and comparing it with the pre-ECO report catches that.
Practical Example
Tapeout Scenario: Final gate on a block after four ECO rounds (illustrative). Full extraction, then PrimeTime in 18 scenarios with SI: 0 setup, 2 hold at -1 ps in one fast scenario, 0 transition. Exhaustive PBA clears both hold endpoints at +2 ps and they are waived with reports. Coverage shows 12 new untested checks from an ECO spare cell with a floating clock pin, tied off and re-verified. Formality reports equivalent; check_routes (ICC2) and check_lvs (ICC2) are clean. The block is released on that database.
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