xor bug?

[taylor-bsg]

https://github.com/The-OpenROAD-Project/OpenSTA/blob/12022edc37acf0370f3686eb4ce05c3490b4a7ce/search/Power.cc#L451

Should activity factor actually be:

           1.0-activity1.activity()*activity2.activity()-(1.0-activity1.activity())*(1.0-activity2.activity()),

Because an XOR gate does not switch if both its inputs switch or if neither of its inputs switch? And if only one of its input switches every cycle, then the output switches every cycle?

[taylor-bsg]

replacing example1.v with this:

module top (in1, in2, clk1, clk2, clk3, out, out2);
  input in1, in2, clk1, clk2, clk3;
  output out,out2;
  wire r1q, r2q, u1z, u2z;

  DFF_X1 r1 (.D(in1), .CK(clk1), .Q(r1q));
  DFF_X1 r2 (.D(in2), .CK(clk2), .Q(r2q));
  BUF_X1 u1 (.A(r2q), .Z(u1z));
  AND2_X1 u2 (.A1(r1q), .A2(u1z), .ZN(u2z));
  DFF_X1 r3 (.D(u2z), .CK(clk3), .Q(out));
  XOR2_X1 r4 (.A(r1q),.B(r2q),.Z(out2));

endmodule // top

source example1.tcl
% set_power_activity -pins r4/B -activity 0 -duty 0.5
% set_power_activity -pins r4/A -activity 1 -duty 0.5
% puts [get_property -object_type pin r4/B activity]
0.00000e+00 0.500 user
%  puts [get_property -object_type pin r4/A activity]    
1.00000e+08 0.500 user
%  puts [get_property -object_type pin r4/Z activity]
2.50000e+07 0.500 propagated <--- should match r4/A activity

[jjcherry56]

fixed by bb50746 issue 107 xor activity