CTS: fix the correct value of max fanout

[luis201420]

Some designs define the max fanout using the set_max_fanout VALUE [current_design] command (where VALUE is the defined fanout value), which adds a fanout limit to the top instance rather than a specific buffer. The CTS only checked if the selected buffer had a defined fanout limit, ignoring whether the top instance had a defined fanout limit.

This PR adds a check to consider whether the top instance has a defined fanout limit.

In the results, the following designs show a significant degradation in their metrics:

• asap7/cva6:

Metric	Old	New
finish__timing__setup__tns	-2.60392	-6.61304
finish__timing__setup__ws	-1.75515	-4.56712

-sky130hd/microwatt:

Metric	Old	New
detailedroute__antenna__violating__nets	0	1

- gf12/coyote:

Metric	Old	New
finish__timing__hold__tns	-1.12796	-16.0289
finish__timing__hold__ws	-1.12796	-4.79894

[gemini-code-assist]

Code Review

This pull request correctly adds a check for the max fanout limit set on the top-level design, which was previously ignored. While this is a good fix, I've found a critical logic issue in how the fanout limit is handled when a buffer is considered invalid. The current implementation could lead to either ignoring the top-level fanout limit or using an incorrect maximum value. I've provided a suggestion to fix this, ensuring the fanout constraints are applied correctly and consistently.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[maliberty]

Is there a metrics PR that goes with this?

[luis201420]

Is there a metrics PR that goes with this?

Yes, metric updates are needed in some designs. I created a PR with the updates.

[github-actions]

clang-tidy review says "All clean, LGTM! 👍"

[maliberty]

I assume it is The-OpenROAD-Project/OpenROAD-flow-scripts#3823