Why must current_block be checked before every sanity run?

Short Answer

Think of current_block as the "you are here" pointer in ICC2 — almost every command [PrimeTime: get_cells, report_timing, place_opt, you name it] silently operates on whatever block is currently active, not the block whose name you typed in your last open_block. If you have several blocks open in the same session (a hierarchical flow, a sub-block plus the top level, or two design revisions loaded for comparison), a query can run cleanly against the wrong block and return a perfectly formatted, completely irrelevant answer.

Technical Explanation

• There's no error message for this — the syntax is valid, the collection isn't empty, the report prints. The only way to catch it is to check current_block (or print it in your log) before trusting the result.
• This is the PD equivalent of double-checking which file is open before you hit save: cheap to check, expensive to debug after the fact once ten more commands have run on the wrong context.
• Good practice: start every sanity/debug script with current_block, and have your reports echo the block name in their header so a stale log is immediately recognizable.

What To Check

• Warning sign: Counts or scenarios unexpectedly match another checkpoint.
• Inspect: Start with one named object in the report and trace it to the netlist, library, or SDC statement that created it.
• Correct: Select the intended block explicitly and repeat the baseline reports before any mutation.

Healthy, Suspicious & Hard-stop Results

• Expected: Most ICC2 queries and reports operate on the current block, so correct syntax in the wrong context gives a polished but wrong answer.
• Stop before floorplanning when required logic or timing coverage is missing or unexplained.

What The Interviewer Is Testing

Be ready to explain why this matters before floorplanning.