说到PrimePower功耗计算，你的脑海中可能浮现出不同power analysis mode的flow。假使你有input的VCD/FSDB，你的flow也是之前千锤百炼的，那power的计算结果就一定是无懈可击的吗？不一定！
PrimePower在计算cell功耗的时候是依据cell pin的Toggle Rate（TR）和Static Probability（SP），并按照cell每个power arc去estimate cell的State-Dependent-Path-Dependent（SDPD）的toggles，进而计算cell的功耗。pin的Toggle Rate（TR）是pin连接的net的Toggle Count（TC）和发生toggle这段时间（duration）的比值，即TR=TC/duration。这个TC其实是这根net所有的segment的TC的一个叠加。TC从哪来呢？当然是waveform。VCD里面记录的是每个cell的input和output pin链接的net在不同的time stamp下的状态。
比如说下面这个链接关系， Inst1和Inst2的input和output对应timestamp下的状态会被记录在VCD里面。
由于Inst1/O到Inst2/B的net的delay的不同可能会有以下两种翻转状态，对应Inst1/O和Inst2/B就有各自的timestamp下的0/1状态记录。
这两种不同的状态对应的net n的TC一样吗？不一样！因为net的TC是依据net segment叠加的，第一种情况，net delay超出了pulse width的时候，Inst1/O输出认为net翻转了，Inst2/B输入也认为net翻转了，得出的TC是4，但实际上TC应该是2。第二种net delay比较小就不会出现这样的误判断，因为1->1的signal不被认为是翻转，所以TC还是2。当我们debug cell奇怪的switch activity的时候，比如一个BUF它的input TR和output TR不一致，一种可能是FSDB merge带来的conflict，另外一种就是以上第一种的情况，这种情况是可能出现在你的design中的哦！
那如何避免工具这样的误判呢？这个功能是由power_read_unique_net_activity控制的，从PrimePower 2019.03开始，工具就自动使能这样的修正。
注意，merge FSDB之后是很可能出现activity conflict的，所以对于merge FSDB的input，这个变量并不起作用。