Hold time violations of asap7/swerv

[Blueonics]

Hi,

I am running the asap7/swerv design with ORFS, based on the reports that were generated, there was zero hold violations at CTS and global routing stage, but then we have few hundreds of hold violations after detailed routing.

I also came across this discussion hold time violation on nangate45/swerv and I then found:

"finish__timing__drv__hold_violation_count": 605,

from metadata-base-ok.json, so the design run would generate some hold time violations by default.

Then, I went through the ORFS variables and wanted to tweak some variables. Looking at HOLD_SLACK_MARGIN, I understand that the inaccuracies are caused by pre-CTS and post-CTS timing calculations as we are assuming an ideal clock pre-CTS, and that we can avoid over repair by setting a lower slack margin, my question would still be what can I do in the flow to fix the hold timing more aggressively? Should I switch OpenROAD instead of using the flow script to have more control over the hold fixing process?

An additional question is that does AutoTuner support sweeping of HOLD_SLACK_MARGIN?

Any suggestions would be appreciated.
Thanks in advance.

[maliberty]

I don't think AT supports HOLD_SLACK_MARGIN but it wouldn't be hard to add.

The limit is just out of date. In the latest run the actual value is

"finish__timing__drv__hold_violation_count": 0,

[Blueonics]

Thanks for the information.

I did a fresh run with just default config.mk variables, ended up having 161 hold violations as indicated, and this is my OR version: v2.0-23557-g6ff4ea2d3f incorporated with newest updates, I will investigate a bit more.

I also inspected global_route.tcl and detail_route.tcl, and repair_timing is being used in the former but not the latter, it seems that post-drt timing fixes are not supported yet?

If that's the case, on a higher level, is there a recommended strategy to iterate on hold fixes post-drt?

[maliberty]

In https://jenkins.openroad.tools/job/OpenROAD-flow-scripts-Nightly-Public/5899/ with ORFS 9d1bc71 and OR d957ce88f246b5fdfc084069ff4696fe76413557 it finished with 0 violations. Please try with those commits and see if you still have an issue.

I don't think there is a need to go into further workarounds when there is no detectable problem in the nightly CI.

[Blueonics]

Thanks for providing the specific commits. I've verified that I have both repositories at the exact commits you mentioned:

    ORFS: 9d1bc717
    OpenROAD: d957ce88f246b5fdfc084069ff4696fe76413557

However, I'm still seeing violations in my local environment. I've:

Cleanly checked out both commits
Built the complete toolchain using ./build_openroad.sh --local
The OpenROAD binary shows this version: `v2.0-23600-gd957ce88f2`

I also checked out the report final_report_swerv_wrapper_asap7_base_2025-08-19_09-30.tar.gz from #5899, and noticed there are 161 hold violations shown in 6_finish.rpt, maybe it is a reporting issue rather than the build itself?

Thanks.