Defaulted activity on non-functional pins

[stanminlee]

Added boolean to check whether a pin was annotated during visit function on the Activity propagator.

If it was not annotated (by either branch) we will default the activity to the defaults calculated by library/setting from user

[greptile-apps]

Greptile Summary

This PR introduces an annotated boolean flag inside PropActivityVisitor::visit to detect when a driver pin's activity was not set by either the functional-expression path or the clock-gate path, and falls back to the library/user-configured inputActivity() with origin defaulted. A companion inputActivity() accessor is added to Power to expose the private input_activity_ member.

• Power.cc: The annotated flag correctly guards both the evalActivity(func) path and the clock-gate path; when neither sets an activity, inputActivity() is applied to the pin with origin PwrActivityOrigin::defaulted.
• Power.hh: A minimal const accessor returning input_activity_ by value is added to the public interface.
• The new code has inconsistent indentation (spaces vs. tabs), lacks an explanatory comment on the fallback block (violating the project's commenting convention), and silently skips the default for pins with a null liberty port — all worth addressing before merge.

Confidence Score: 4/5

The change is safe to merge as-is; the fallback logic is correct for the cases it handles, and the new public accessor in Power.hh is straightforward.

The core logic is sound and the fallback is correct for the cases it handles. The mixed indentation and missing comment reduce readability but do not affect correctness. The null-port exclusion is a design gap worth confirming as intentional.

power/Power.cc deserves a second look: the indentation should be normalized to tabs, a comment should be added to the fallback block, and the null-port exclusion should be confirmed as intentional.

Important Files Changed

Filename	Overview
power/Power.cc	Adds annotated boolean to PropActivityVisitor::visit to fall back to inputActivity() for driver pins with a liberty port but no functional expression and no clock-gate formula; new code mixes tabs/spaces, lacks an explanatory comment, and silently skips the default for null-liberty-port pins.
power/Power.hh	Exposes inputActivity() as a const accessor returning input_activity_ by value; minimal, correct change with no issues.

Flowchart

%%{init: {'theme': 'neutral'}}%%
flowchart TD
    A[visit vertex] --> B{hasUserActivity?}
    B -->|yes| C[setActivityCheck userActivity]
    B -->|no| D{isLoad pin?}
    D -->|yes| E{Has incoming wire edge?}
    E -->|yes| F[setActivityCheck propagated activity]
    E -->|no| G[No activity set]
    D -->|no| H{isDriver pin?}
    H -->|yes| I{port not null?}
    I -->|no| J[No activity set]
    I -->|yes| K[annotated = false]
    K --> L{func not null?}
    L -->|yes| M[evalActivity from func, setActivityCheck pin, annotated = true]
    L -->|no| N{isClockGateOut?}
    M --> N
    N -->|yes| O{enable and clk and gclk found?}
    O -->|yes| P[setActivityCheck gclk with gate formula, annotated = true]
    O -->|no| Q{annotated?}
    P --> Q
    N -->|no| Q
    Q -->|no| R[setActivityCheck pin with inputActivity defaulted]
    Q -->|yes| S[Done]

Loading

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

[greptile-apps]

Inconsistent indentation mixes tabs and spaces

The new lines (bool annotated = false;, annotated = true; inside the func block, and the entire if (!annotated) block) use spaces, while the surrounding code consistently uses tabs. This will render incorrectly in any tab-width-aware viewer and conflicts with the project's existing style. All new lines should use tabs at the same nesting depth as their enclosing block.

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!

[stanminlee]

followed what is reflected in the code

[akashlevy]

Yeah this is fine, we will refactor this when we update to OpenSTA 3.0 (which @donn is working on)

[greptile-apps]

Default fallback only applies when port is non-null

annotated is declared and the if (!annotated) default is evaluated only inside the if (port) block. Driver pins for which network_->libertyPort(pin) returns null (no liberty port at all) receive neither a computed activity nor the inputActivity() default — the same as before this PR. If the goal is to ensure all unresolved driver pins get a default, the null-port case is silently excluded. If the exclusion is intentional (e.g., non-liberty pins are handled elsewhere), a comment stating that would help.

[stanminlee]

shouldnt be this case

[akashlevy]

Seems fine for now

[akashlevy]

Yeah this is fine, we will refactor this when we update to OpenSTA 3.0 (which @donn is working on)

[akashlevy]

Seems fine for now