If you need to rebuild a clock tree from scratch, what does remove_clock_trees actually preserve versus remove?

Short Answer

remove_clock_trees traverses root to sinks, removing buffers and inverters except dont_touch/size_only ones -- but several object types survive by design: don't-touch cells, fixed cells, generated clocks defined on a buf/inv pin, ICGs (traversal continues past them), block abstraction models, isolation cells, and level shifters. Inverters are only removed in pairs, and a three-state buffer stops traversal entirely rather than being removed.

Technical Explanation

• remove_clock_trees traverses root to sinks, removing buffers/inverters -- but NOT dont_touch or size_only cells, which survive regardless.
• Also preserved: fixed cells, generated clocks defined on a buf/inv pin (traversal continues past them), ICGs (traversal continues past), block abstraction models, isolation cells, and level shifters.
• Inverters are removed only in pairs -- a lone inverter without its pair partner is not removed.
• A three-state buffer stops traversal entirely rather than being removed -- the command doesn't try to remove past it.
• This command does NOT support clock mesh nets, and it resets CTS-related attributes on what it does touch.
• The real invocation is remove_clock_trees -clocks [get_clocks my_clk] -- the -clocks flag is what actually scopes the removal to a specific clock rather than the whole tree.

Follow-up Question & Model Response

"Why would a three-state buffer specifically stop traversal instead of just being preserved like other special cells?"

Candidate Model Response: Because a three-state buffer's output can be actively driven by more than one source depending on enable state, so removing it (or continuing traversal past it as if it were an ordinary buffer) could silently change which driver's timing the rest of the tree is analyzed against.