How do dont_touch cells, fixed cells, and boundary cells differ in how remove_clock_trees treats them?

Short Answer

All three are preserved by remove_clock_trees, but for different underlying reasons: a dont_touch cell is preserved because optimization is explicitly excluded from touching it; a fixed cell is preserved because its placement is locked, independent of dont_touch; a boundary cell is preserved specifically because it protects a hierarchical timing contract, and additionally cannot be moved or resized even outside the context of tree removal.

Technical Explanation

• A dont_touch cell is preserved by remove_clock_trees because optimization is explicitly excluded from touching it -- a general-purpose protection, not clock-tree-specific.
• A fixed cell is preserved because its placement is locked -- a different mechanism from dont_touch, though both result in preservation during tree removal.
• A boundary cell is preserved specifically because it protects a hierarchical timing contract at a block boundary, and it carries an additional, stronger constraint: it cannot be moved or resized even outside the context of remove_clock_trees.
• The distinction matters for debugging: three different reasons can each explain why a cell survived a rebuild, and they call for three different fixes if you actually need to change one.

Follow-up Question & Model Response

"If you needed to actually modify a boundary cell for a legitimate reason, what would that require beyond just clearing dont_touch?"

Candidate Model Response: It would require first establishing that the modification doesn't break the hierarchical timing contract the boundary cell protects -- likely re-characterizing the block's boundary timing and re-validating every sibling block that depends on it, not just clearing an attribute.