Why record a manifest and file checksums?
From PDVerse PnR Interview Handbook, part of the pdVerse Mentor Guide
Short Answer
A manifest is the packing list that comes with every design handoff — it tells the receiving engineer exactly what revision, corner, mode, and producer each input file represents, so nobody has to guess. Without it, "the netlist" or "the SDC" is ambiguous — there could be five versions floating around a project, and the wrong one silently loaded gives you a run that looks fine but is quietly analyzing the wrong design.
Technical Explanation
- The checksum is the tamper seal on that packing list: if a file's checksum doesn't match what the manifest recorded, you know immediately that the file changed after the manifest was written — whether by an honest edit, a bad copy, or something worse.
- "
- This matters most at handoff boundaries — synthesis to PD, PD to signoff — where a single stale or substituted file can invalidate an entire run's conclusions without anyone noticing until timing numbers stop making sense.
- Practically: keep the manifest alongside the run directory, and treat a checksum mismatch as a hard stop, not a warning to investigate later.
Visual Verification
Cryptographic SHA-256 checksums in the handoff manifest guarantee that netlists, constraints, and UPF files are authentic, untampered, and match the exact verified synthesis release.
What To Check
- Warning sign: A rerun produces different counts because a same-named file changed silently.
- Inspect: Start with one named object in the report and trace it to the netlist, library, or SDC statement that created it.
- Correct: Freeze the approved inputs, record checksums outside ICC2, and restart from the documented bundle.
Command Checks & Actions
- current_block: confirms the active design block
- report_ref_libs: shows the reference libraries used for linking
Run the commands in order. Each line answers a separate part of the check.
Healthy, Suspicious & Hard-stop Results
- Expected: A manifest connects every loaded file to a revision, producer, timestamp, mode, corner, and checksum so the run can be reproduced.
- Stop before floorplanning when required logic or timing coverage is missing or unexplained.
Common Mistake
The Trap: Do not assume the check passed just because ICC2 continued. Fix or narrowly justify the named objects, then rerun the same command.
What The Interviewer Is Testing
Be ready to explain why this matters before floorplanning.
Physical Design & Planning Handbook
Master ASIC Physical Design Planning & Floorplanning
Dive into 14 comprehensive chapters covering netlist sanity, FinFET grids, macro placement, power grids, CTS, and timing budgeting.
Offline PDF Bundle
Want all 1109 questions offline?
Get the complete 4-book PDF bundle (PnR, STA, MMMC, Low Power) with a clickable table of contents - no ads, no internet needed.
Continue practising