Make sure output internal power is instantiated to 0.0

[neildeo05]

Without incrementing the output internal power by 0.0 in the findOutputInternalPower function, it seems like in some cases the OutputInternalPower value was getting set to NaN

---

Important

Fixes potential NaN issue in findOutputInternalPower() in Power.cc by ensuring OutputInternalPower is incremented by 0.0 when numInternalPowerPins is zero.

• Behavior:
  • Fixes potential NaN issue in findOutputInternalPower() in Power.cc by ensuring OutputInternalPower is incremented by 0.0 when numInternalPowerPins is zero.

^{This description was created by for 4047245. You can customize this summary. It will automatically update as commits are pushed.}

[ellipsis-dev]

Important

Looks good to me! 👍

Reviewed everything up to 4047245 in 33 seconds. Click for details.

• Reviewed 13 lines of code in 1 files
• Skipped 0 files when reviewing.
• Skipped posting 1 draft comments. View those below.
• Modify your settings and rules to customize what types of comments Ellipsis leaves. And don't forget to react with 👍 or 👎 to teach Ellipsis.

1. power/Power.cc:1123

• Draft comment:
  Good addition: the explicit else branch calling result.incrOutputInternal(0.0) safely avoids division by zero and potential NaN propagation when numInternalPowerPins is zero.
• Reason this comment was not posted:
  Confidence changes required: 0% <= threshold 50% None

Workflow ID: wflow_Zh9X0PYYDR9AP7wX

^{You can customize by changing your verbosity settings, reacting with 👍 or 👎, replying to comments, or adding code review rules.}

[greptile-apps]

Greptile Summary

This PR fixes a critical bug in the findOutputInternalPower function within power/Power.cc where the output internal power value could be left uninitialized (potentially as NaN) when there are no internal power pins to process.

The change adds an else clause to explicitly initialize the output internal power to 0.0 when numInternalPowerPins equals 0. Previously, when no internal power pins were present, the result.incrOutputInternal() method was never called, leaving the power value in an undefined state. This could result in NaN values propagating through subsequent power calculations.

The fix follows standard defensive programming practices - when zero pins contribute to power consumption, the logical result should be zero power, not undefined behavior. This change integrates well with the existing power calculation framework in OpenSTA, which relies on the InternalPower classes (as seen in the context) to model and calculate power consumption based on various parameters. The modification ensures that all power calculation paths produce valid numerical results, maintaining the integrity of the overall power analysis pipeline.

Confidence score: 5/5

• This PR is safe to merge with minimal risk as it addresses a clear bug with a straightforward fix
• Score reflects the simplicity of the change and the critical nature of preventing NaN values in power calculations
• No files require special attention as this is a single-line defensive fix in a well-isolated function

_{1 file reviewed, no comments}

_{Edit Code Review Bot Settings | Greptile}