What is a boundary cell in CTS, and what are you not allowed to do to it?

Short Answer

A boundary cell is a fixed buffer inserted immediately after a block or module's boundary clock pin, to preserve the boundary conditions of that pin for hierarchical CTS. Two hard rules: a boundary cell cannot be moved or resized, and no cells may be inserted between a clock pin and its boundary cell -- both rules exist to keep the hierarchical boundary's timing contract intact.

Technical Explanation

• A boundary cell is a fixed buffer inserted immediately after a block or module's boundary clock pin, specifically to preserve the boundary conditions of that pin for hierarchical CTS.
• Rule 1: a boundary cell cannot be moved or resized -- doing so would change the boundary timing contract other blocks depend on.
• Rule 2: no cells may be inserted between a clock pin and its boundary cell -- inserting something there would insert new, uncontracted delay right at the boundary.
• Both rules exist for the same reason: hierarchical CTS depends on each block's boundary staying exactly as characterized, so other blocks' timing models stay valid.
• Identifying a boundary cell directly has no single fully-confident command name -- verify the exact attribute or reporting mechanism (likely get_attribute [get_cells <cell>] is_boundary_cell or a report_clock_qor boundary-cell listing) against the ICC2 Implementation User Guide's hierarchical CTS chapter before relying on a specific syntax.

Follow-up Question & Model Response

"What would go wrong for a sibling block if a boundary cell's delay silently changed after it was characterized?"

Candidate Model Response: The sibling block's own timing signoff -- built against the boundary's original, characterized delay -- would silently no longer match reality, potentially turning a signed-off block into one with an undetected timing violation at the boundary.