A block-level ECO in a hierarchical design: what changes at the top, and what must be regenerated?

Short Answer

A block ECO changes the block interface timing the top sees, so every abstraction of that block used at the top is now out of date. Regenerate the block model, whether an extracted timing model from extract_model (PT) or a HyperScale block model, and rerun top-level timing. If the top changes as a result, regenerate the block context with characterize_context (PT) and write_context (PT) so the block is fixed against the real environment.

Technical Explanation

• The block is fixed against a context: the clocks, input delays, output loads and exceptions it sees from the top. With context characterization, it comes from characterize_context -block blkA (PT), update_timing (PT) and write_context (PT) in a top-level session; characterize_context (PT) only marks the block, and the context is computed at the next timing update. In a HyperScale flow, the top session writes the detailed block context with write_hier_data (PT) and the block session reads it with read_context (PT).
• An ECO inside the block changes internal paths, but also the boundary: input pin loads, output drive and the delay from ports to the first or last register. Those feed the top.
• An extracted timing model abstracts the block interface as timing arcs with delay tables. After the ECO, the old ETM describes a block that no longer exists, so run extract_model (PT) again from the post-ECO block.
• In a HyperScale flow, the block model written with write_hier_data (PT) must also be regenerated, and the top session must read the new one before its results mean anything.
• At the top, rerun timing with the new model. Paths that cross the block boundary can move in either direction; a stronger output driver helps the top, a larger input load slows the top-level driver.
• If the top changes, for example the top also takes an ECO on a boundary path, the block context is stale. Regenerate it and rerun the block, repeating until the block and top agree.
• Multiply instantiated blocks share one implementation. An ECO for one instance must be valid for all of them, or the block has to be split into separate implementations.

What To Check

• Boundary pins whose load, drive or port-to-register delay changed in the ECO.
• Date and source netlist of each block model used at the top.
• Top-level paths through the block before and after the new model.
• Block context version used for the block ECO against the current top.

Healthy, Suspicious & Hard-stop Results

• Healthy (illustrative): New model regenerated from the post-ECO netlist, top paths through the block within 5 ps of the block-level numbers.
• Suspicious (illustrative): Top uses the new model but block context is two ECO rounds old; boundary slack disagrees by 15 ps.
• Hard stop: Top signoff run on the pre-ECO model. The top results say nothing about the chip being built.

What The Interviewer Is Testing

• Knowing which abstractions depend on the block implementation.
• Can you describe the block/top loop and when it must repeat?
• Awareness of what a multiply instantiated block does to a block ECO.

Follow-up Question & Model Response

"What would you check first if top-level timing through the block changes a lot after the ECO?"

Candidate Model Response: I compare the boundary timing in the old and new models: input capacitance on the block pins, output drive and the port-to-register delays. A large change there usually means the ECO touched boundary cells, for example a resized input buffer. Then I check whether the block was fixed with a current context, because a stale context can make a block ECO optimise for boundary conditions the top no longer has.