rsz: Convert buffering to fixed-point delays

[openroad-ci]

This is to address

[ERROR RSZ-0501] buffering pin gen_tiles\[0\].i_tile.i_tile/gen_cores\[1\].gen_mempool_cc.riscv_core.i_snitch/_10200_/ZN failed: area recovery cannot reproduce solution

and errors of this form

Also integrate Rebuffer2 into repair_timing. We can retire the former content of Rebuffer.cc and move Rebuffer2.cc into its place.

[github-actions]

clang-tidy made some suggestions

[povik]

Secure CI came back green but on public CI this raised a few repair failures similar to The-OpenROAD-Project/OpenROAD-flow-scripts#3245. With @eder-matheus we have taken a look at one instance of this failure and we think we understand the cause due to a bug in GRT.

I think we should wait on the GRT fix before merging this change.

[github-actions]

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

[povik]

I think we should wait on the GRT fix before merging this change.

The prospective fix: #7650

[github-actions]

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

[povik]

Public CI on designs is down to a fixable EQY failure, this is ready to merge pending review

[maliberty]

Are you fixing the "fixable EQY failure"?

[povik]

Yes, I'll open a PR on the ORFS side

[maliberty]

Please explain how this conversion fixes the issue you mentioned. Its is helpful to give more explanation for a larger PR.

[povik]

I think this PR is easier to review going per commits. The main change is in the first commit, and the changes to Rebuffer.cc from the first commit can be ignored since the file gets replaced with Rebuffer2.cc later in the commit sequence. I can rewrite the git history to get rid of these extra changes and to make it more readable if requested.

Please explain how this conversion fixes the issue you mentioned.

The issue is caused by rounding errors putting the algorithm in an inconsistent state. By using fixed-point delay and slack values this is mostly avoided. Inconsistencies might still be introduced by way of the gate delay calculator but it's unclear it's an issue in practice and there are ways we could fix it.

More elaborate explanation: Area recovery is tasked with building up a buffer tree which is no worse in timing than the current candidate tree. To that effect it assigns timing thresholds to each node of a Steiner tree, and then it enumerates buffer tree options requiring the local thresholds to have been met. Since the thresholds were assigned based on an existing candidate tree (with some relaxation applied) we are in principle guaranteed at least one viable solution. Due to rounding errors the enumeration process can fail coming up with no viable solution. The slacks and delays can be one or two orders of magnitude apart, this makes it challenging to come up with a good tolerance scheme to prevent failures due to rounding errors.

[povik]

@maliberty I have introduced strong typing for the fixed-point delays and rewrote the git history to aid review

[github-actions]

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