Replies: 1 comment 1 reply
-
|
Please provide an executable test case demonstrating this. |
Beta Was this translation helpful? Give feedback.
1 reply
-
|
Thank you, I packaged a minimal running subsystem with a README file inside. |
Beta Was this translation helpful? Give feedback.
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
-
I used a test case named "gcd", and I obtained the following results ：
using the Python APIs provided by OpenROAD:
dynamic power is 0.005040252273342433,
static power is 2.3204001389665052e-05,
WNS is -4.4188694e-10,
TNS is -7.925274e-08.
However, the results I obtained through OpenROAD are as follows:
dynamic power is 0.005039...,
static power is 2.322e-05,
WNS is -0.38,
TNS is -9.60.
The power consumption on both sides is the same, but there is a significant timing difference. I believe this is the result of normalization done by OpenROAD. So, I called OpenROAD's GUI and found that the ArrivalTime value on 710/CK is 0.067 (Just like the first picture and the second picture ). At the same time, I outputted the same results using the API (without normalization, k=1e-10). However, as the signal moves (for example, from _520_A to _520_ZN), I found that they do not follow the aforementioned rule of k=1e-10. So, my question is, how should I adjust my coefficient? Or is there a better way, can I set the weight within OpenROAD GUI to 1?
Looking forward to your reply.
Sincerely
Beta Was this translation helpful? Give feedback.
All reactions