Rsz buffering boost#9373
Conversation
Signed-off-by: Martin Povišer <povik@cutebit.org>
Recently repair_design received a new slew degradation model, use the same model in rebuffer. Signed-off-by: Martin Povišer <povik@cutebit.org>
r_drvr should not be scaled by the shape factor as it is derived from NLDM data as the asymptotic slew/load ratio and as such it already includes the shape factor. Signed-off-by: Martin Povišer <povik@cutebit.org>
When measuring the delay on a buffered net include the driving gate delay. Signed-off-by: Martin Povišer <povik@cutebit.org>
Signed-off-by: Martin Povišer <povik@cutebit.org>
The load passed to the gate delay calculator is exclusive of the driving port's own capacitance. Fix the formulas accordingly. Signed-off-by: Martin Povišer <povik@cutebit.org>
Signed-off-by: Martin Povišer <povik@cutebit.org>
This follows from simple charging model. Signed-off-by: Martin Povišer <povik@cutebit.org>
Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
Signed-off-by: Matt Liberty <mliberty@precisioninno.com>
![gemini-code-assist[bot]](https://avatars.githubusercontent.com/in/956858?s=60&v=4){kind=small}
There was a problem hiding this comment.
Code Review
This pull request significantly enhances the resizer's buffering capabilities by introducing a more sophisticated analytical approach for long-wire buffering, replacing the previous geometric stepping method. It also refactors and improves slew and delay modeling by using shape factors and correcting inconsistencies in load capacitance calculations. These changes should lead to better quality of results. However, I've identified a couple of potential issues in the new slew calculation formulas that need to be addressed to ensure the correctness of the new algorithm.
| const double a = wire_res * wire_cap * resizer_->slew_shape_factor_ / 2; | ||
| const double b | ||
| = (r_drvr * wire_cap) | ||
| + (wire_res * in->capacitance() * resizer_->slew_shape_factor_); | ||
| const double c = (r_drvr * in->capacitance()) - max_slew; | ||
| const double D = b * b - 4 * a * c; |
There was a problem hiding this comment.
The coefficients a, b, and c for the quadratic equation appear to be derived from an inconsistent or non-standard formula for slew. Assuming a standard Elmore-based slew approximation, the application of slew_shape_factor_ to the terms in b and c seems incorrect. For example, if the intended formula is slew = (R_d*C_total + R_wire*C_wire/2) * factor, the coefficients in the code do not match the derived quadratic equation. This is a critical part of the new buffering logic and could lead to incorrect calculation of the wire length limit. Please review and correct the formula derivation.
| const BnetPtr& bnet) | ||
| { | ||
| double wire_res, wire_cap; | ||
| estimate_parasitics_->wireSignalRC(corner_, wire_res, wire_cap); | ||
| float r_drvr = driver->driveResistance(); | ||
| float load_slew | ||
| = (r_drvr + resizer_->dbuToMeters(bnet->maxLoadWireLength()) * wire_res) | ||
| * bnet->cap() * elmore_skew_factor_; | ||
|
|
||
| return load_slew <= maxSlewMargined(bnet->maxLoadSlew()); | ||
| return r_drvr * bnet->cap() <= maxSlewMargined(bnet->maxLoadSlew()); | ||
| } |
There was a problem hiding this comment.
The slew calculation in this function has been simplified to r_drvr * bnet->cap(), which omits the wire resistance. The previous implementation included a term for wire resistance, which is a more accurate approximation of slew for nets with non-negligible wire lengths. This oversimplification could lead to underestimating slew, potentially causing incorrect driver selections in the findBestSolution function. Consider using a more accurate Elmore-based slew approximation that accounts for wire resistance.
|
clang-tidy review says "All clean, LGTM! 👍" |
3 participants
No description provided.