Smallfix for findActivity

[stanminlee]

Pins specified by the user using set_power_activity are not queried in findActivity because they appear in user_activity_map. This is not good because some pins can't be propagated through in some cases (flops or macro outputs)

This leads to pins being ignored and reported as having 0 activity/duty when they were actually present as they're set by the user. Before we say an activity origin is unknown, query this map and return the value

[greptile-apps]

Greptile Summary

This PR fixes findActivity in Power.cc so that pins explicitly annotated via set_power_activity are returned even when propagation through the design fails (e.g. for flop outputs or macro outputs that block propagation through activity_map_). Previously these pins fell through to the "unknown/zero activity" return despite having a valid user-set value in user_activity_map_.

• Adds a two-line fallback that checks user_activity_map_ before returning the zero-activity unknown sentinel, correctly surfacing user annotations that propagation could not carry forward.
• The fix does not cover the global_activity_.isSet() early-return path, meaning per-pin user annotations are still shadowed by a global activity setting when one is present.

Confidence Score: 4/5

Safe to merge for the primary fix; the change correctly recovers user-set pin activities that propagation cannot forward.

The two-line change is minimal and well-targeted: it fixes the described case where flop and macro output pins silently reported zero activity despite having a user annotation. One related gap remains — the global_activity_ early-return still shadows per-pin user annotations — but that is pre-existing behavior not introduced here.

The global_activity_.isSet() early-return branch in power/Power.cc around line 1448 warrants a follow-up to confirm whether per-pin user annotations should take precedence over a global activity setting.

Important Files Changed

Filename

Overview

power/Power.cc

Adds a fallback lookup of user_activity_map_ in findActivity before returning an unknown activity, so pins explicitly set via set_power_activity (e.g. flop outputs, macro outputs that block propagation) are no longer silently reported as zero-activity/unknown. The fix is logically sound for the described propagation-failure case, but global_activity_ still short-circuits before the new check, so per-pin user annotations remain shadowed when a global activity is set.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[findActivity called for pin] --> B{Pin is constant?}
    B -- Yes --> C[Return 0.0/0.0 constant]
    B -- No --> D{Pin is clock?}
    D -- Yes --> E{activity_map_ has non-unknown entry?}
    E -- Yes --> F[Return activity_map_ entry]
    E -- No --> G[Return clock-computed activity]
    D -- No --> H{global_activity_ is set?}
    H -- Yes --> I[Return global_activity_ - user_activity_map_ never reached]
    H -- No --> J{activity_map_ has non-unknown entry?}
    J -- Yes --> K[Return activity_map_ entry]
    J -- No --> L{user_activity_map_ has entry? NEW fallback added by this PR}
    L -- Yes --> M[Return user_activity_map_ entry]
    L -- No --> N[Return 0.0/0.0 unknown]

Loading

Comments Outside Diff (1)

1. power/Power.cc, line 1448-1458 (link)

   global_activity_ still silently shadows user-set pin activities

   The new user_activity_map_ lookup is only reachable when global_activity_ is not set. If a user calls set_power_activity_global and set_power_activity on the same pin, the per-pin activity is ignored and the function returns the global value — the exact problem this PR is fixing for the propagation path. Worth confirming whether global activity is intended to override all per-pin user annotations or whether user pin annotations should take precedence.

_{Reviews (1): Last reviewed commit: "update" | Re-trigger Greptile}

[greptile-apps]

Missing comment for new fallback logic

Per the team's convention of commenting complex code blocks, this new fallback should have a brief comment explaining why user_activity_map_ is consulted here — specifically that some pins (flop outputs, macro outputs) cannot be propagated through, so their user-set activities never reach activity_map_, making this check the last resort before returning unknown. Without the comment, it's non-obvious why this check appears after the activity_map_ lookup rather than before it.

Rule Used: Always add comments to explain the purpose of comp... (source)

Learned From
Silimate/preqorsor-vscode#33

Note: If this suggestion doesn't match your team's coding style, reply to this and let me know. I'll remember it for next time!