rsz: Rebuffering applies inconsistent buffer penalization
Describe the bug
Take a look at slackPenalized()
Slack RepairSetup::slackPenalized(const BufferedNetPtr& bnet,
// Only used for debug print.
int index)
{
const PathRef& req_path = bnet->requiredPath();
if (!req_path.isNull()) {
Delay drvr_delay = resizer_->gateDelay(drvr_port_,
req_path.transition(sta_),
bnet->cap(),
req_path.dcalcAnalysisPt(sta_));
Slack slack = bnet->required(sta_) - drvr_delay;
int buffer_count = bnet->bufferCount();
double buffer_penalty = buffer_count * rebuffer_buffer_penalty_;
double slack_penalized
= slack * (1.0 - (slack > 0 ? buffer_penalty : -buffer_penalty));
The buffer penalty is applied as a multiplicative factor to slack, but slack is computed as the difference between the required time and the gate delay (not the arrival).
Expected Behavior
The buffer penalty is applied in a way that does not depend on the absolute required time and is consistent across logic levels.
Environment
N/A
To Reproduce
N/A
Relevant log output
No response
Screenshots
No response
Additional Context
No response
Yes, the slack here seems to assume arrival of 0 at input. Slack penalty seems like a proxy for slew degradation with many buffers. A negative slack becomes more negative with penalty and a positive slack less positive. With 10 buffers, the penalty is 10%: -1 slack becomes -1.1 and +1 becomes +0.9. With 100 buffers, penalty becomes 100%: -1 becomes -2 and +1 becomes 0. Since the buffering happens at the load side of a driver pin, the required times at new buffer nodes need to be recomputed. Are you suggesting that bnet->required(sta_) is not sufficient?
Are you suggesting that bnet->required(sta_) is not sufficient?
No, the usage of bnet->required(sta_) should be fine here. Where I see the issue is that the behavior of the rebuffering code is not the same if we add an offset to all required and arrival times. A consistent rebuffering would only be sensitive to the relative differences of required/arrival times, never to their absolute value.
Closed by #6637?
I think so