What problem does split_fanout actually solve during a timing ECO, and how do you tell it what to split on?

Short Answer

split_fanout optimizes net fanout during a timing ECO by inserting buffers to break up a high-fanout net -- specified either by -net/-driver plus -max_fanout (a numeric limit) or -load (an explicit list of pins/ports, optionally -hierarchy-aware). -on_route adds the buffers on the existing route topology (like ABOR); -max_distance_for_incomplete_route handles splitting fanout of a net that isn't fully routed, within a max distance, and errors if 0 or more than 1 routed segment is found in that distance.

Technical Explanation

• split_fanout optimizes net fanout during a timing ECO by inserting buffers to break up a high-fanout net into smaller, more manageable groups.
• Specify what to split on either by -max_fanout <n> (a numeric fanout limit) or -load {pins/ports} (an explicit list, optionally -hierarchy-aware).
• -on_route adds the new buffers on the existing route topology, similar in spirit to add_buffer_on_route -- minimizing routing disturbance.
• -max_distance_for_incomplete_route specifically handles splitting fanout of a net that isn't fully routed yet, within a stated max distance -- and it ERRORS if 0 or more than 1 routed segment is found within that distance, since the operation is ambiguous in either case.

Follow-up Question & Model Response

"Why would the command error out (rather than guess) when it finds more than one routed segment within the distance for -max_distance_for_incomplete_route?"

Candidate Model Response: Because with more than one candidate routed segment, there's genuine ambiguity about which one the fanout split should actually attach to -- guessing wrong could silently create an incorrect topology, so the command requires explicit disambiguation instead of picking one arbitrarily.