Is there a developer-recommended way of turning off all hold timing fixes?

[tdene]

Prompt

I am not an expert with OpenROAD's code-base, and I would like to seek advice.

I am experimenting with the procedural generation of up to 10^64 variants of the same sub-design.
This sub-design is not meant to be a full design (no clock for example), and is not even meant to represent a complete timing path in a realistic setting. It would only be part of some longer paths.

The OpenLane flow offers a very convenient way to characterize a large amount of variants of such a sub-design in parallel.
It is straight-forward to turn off some of the here-unnecessary steps that just add variance to the final results. There's flags to turn off CTS and diode-insertion, it is straight-forward to customize the power-grid, it is easy to define pin layers and locations. These all work well.

I also want to turn off hold-fixing entirely, as it introduces noise into my data while offering no realistic benefit.

Question

Is there a developer-recommended way of turning off all passes meant to fix hold timing?

I have found the ECO_ENABLE flag, which can be used to enable / disable final hold timing fixes, post-OpenROAD. This is certainly one step of the answer.

However, the normal routing passes also call upon OpenROAD to perform hold time fixing here and here.

There are flags that allow for the tweaking of this process: HOLD_SLACK_MARGIN and HOLD_MAX_BUFFER_PERCENT.

It seems to me that a definitive way of turning off all hold-fixing passes would be to set the following flags:

• ECO_ENABLE = 0
• PL_RESIZER_SETUP_MAX_BUFFER_PERCENT = 0
• PL_RESIZER_HOLD_SLACK_MARGIN = -1
• GLB_RESIZER_SETUP_MAX_BUFFER_PERCENT = 0
• GLB_RESIZER_HOLD_SLACK_MARGIN = -1

To those that are more familiar with the code-base than I am, does this seem like the solution that I am searching for?

[vijayank88]

@tdene As far as I know and considering automated flow, its all added based on user requirement. Already you found where -hold arguments passing. Maybe you can add your own set ::env(HOLD_FIX_ENABLE) 1 (Default set to 1 will not affect existing flow and in your case make it 0 to disable) This way you can avoid -hold argument passing.

@donn Is that work?

[tdene]

Maybe you can add your own set ::env(HOLD_FIX_ENABLE) 1

This is part of the reason I came here with this question. If there is interest, I can certainly make a PR enabling that extra configuration variable.

[donn]

Set all of PL_RESIZER_DESIGN_OPTIMIZATIONS, PL_RESIZER_TIMING_OPTIMIZATIONS and GLB_RESIZER_TIMING_OPTIMIZATIONS to 0. That said, I do acknowledge these names are horrendous and I will take a look at them.

[tdene]

Thanks @donn.

I'd argue this is not a "bug" label, but rather an "enhancement" label :)

Would you like a PR like the one @vijayank88 suggested, introducing a new HOLD_FIX_ENABLE configuration variable? I can spin one up in my downtime. But at the same time I'm not sure if adding yet another configuration variable is a good thing, given that this functionality can already be enabled with the current set of config vars.

It's a design philosophy question more than anything.

[donn]

Let me rename the variables then I'll see how it goes

[maliberty]

If you have no clock then you can't have any hold violations to fix. Something is odd in the description of the problem.

[tdene]

That is a very fair point @maliberty .

I'll have to jump back into those runs and dig out some data. I most definitely had dlygates inserted into my clock-less design back in March. It could be any of:

• User error on my part
• The design had no clock pin, but was not unconstrained. Setup timing was analyzed, so hold timing may have been as well.
• Some tool along the toolchain decided to pick a dlygate cell to do fan-out decoupling with.

I'll update in a few days, when I go back and try to replicate.

[kareefardi]

Variables are renamed in OpenLane 2