The-OpenROAD-Project / The-OpenROAD-Project/OpenROAD
GPL: Strange behavior when enabling repair_timing during timing-driven
Open
Nobody has claimed this yet.
gpl
rsz
Stale
- Dominant language
- Verilog
- Stars
- 3.1k
- Forks
- 1k
- Avg merge
- 2d 23h
- Merged PRs (30d)
- 136
Description
In this example, the worst endpoint slack is -0.028 ns after running repair_timing.
Just after that, the measured WNS is -0.270 ns. And after the final GPL steps, the measured WNS is -0.110 ns.
Something seems wrong here. I don't know if we are incorrectly estimating timing here.
If the -0.028 slack is correct, then we are just degrading the placement in the final steps.
Contributor guide
First steps
- Read the whole issue, then the project's contributing guide.
- Comment on the issue to say you are picking it up — it saves two people doing the same work.
- Fork the repository and make your change on a branch.
- Open a pull request that references the issue number.
Assessment
This issue has not been assessed yet.