<@U018LA3KZCJ> I'm running report_checks on `sta` ...
# openroad
@User I'm running report_checks on
and I'm confuse about this results. It seems I'm not getting all the violations results I thought I would get in the first case, but if I specify a
parameter like in the second case I get some extra results:
Copy code
report_checks -path_delay min -format summary  -group_count 1000000  -slack_max 0

Startpoint                           Endpoint                               Slack
mprj/wrapped_quad_pwm_fet_drivers_5/_3974_/Q (sky130_fd_sc_hd__dfxtp_1) soc/core/_34944_/D (sky130_fd_sc_hd__dfxtp_1)   -1.09
mprj/wrapped_quad_pwm_fet_drivers_5/_3962_/Q (sky130_fd_sc_hd__dfxtp_2) soc/core/_34942_/D (sky130_fd_sc_hd__dfxtp_2)   -0.96
mprj/wrapped_quad_pwm_fet_drivers_5/_3950_/Q (sky130_fd_sc_hd__dfxtp_1) soc/core/_34940_/D (sky130_fd_sc_hd__dfxtp_1)   -0.90

report_checks -path_delay min -format summary  -group_count 1000000  -slack_max 0 -through mprj/wrapper_fibonacci_3

Startpoint                           Endpoint                               Slack
mprj/wrapper_fibonacci_3/_3283_/Q (sky130_fd_sc_hd__dfxtp_2) soc/core/_34942_/D (sky130_fd_sc_hd__dfxtp_2)   -1.25
mprj/wrapper_fibonacci_3/_3282_/Q (sky130_fd_sc_hd__dfxtp_1) soc/core/_34944_/D (sky130_fd_sc_hd__dfxtp_1)   -1.21
mprj/wrapper_fibonacci_3/_3284_/Q (sky130_fd_sc_hd__dfxtp_1) soc/core/_34940_/D (sky130_fd_sc_hd__dfxtp_1)   -1.21
Is there something I might by missing about how report_checks works?
I'm using
@User would you comment on this sta concern.
@User Did you got any info on why
showing additional result?
Not yet
I suggest you open an issue with a testcase
@User Ok. I wanted to be sure that there wasn't something I wasn't getting about how that functions works. I'll create and issue with the test case
I looked a little bit more into this issue. One important thing I noticed is that the SPEF for that macro (wrapper_fibonacci_3) didn't exactly match the verilog version. So that's something that can definitely cause issues I guess. The other thing I realized is that the endpoint for those paths is the same, so I think that might cause the report to show only one of them. It should be the worst slack, and doesn't look like it from those results, but when I checked, it was: for some reason, when I used the
parameter, the report didn't remove the
clock reconvergence pessimism
, making the slack worst So now I'm digging a little bit about that clock reconvergence pessimism issue to see if I understand why that might happen
@User I would need to see the full timing report especially the header showing the path group and the end showing the slack. In the case of -through is the path specified is unconstrained while the default path is constrained there could be a difference.
@User it seems that if I use the path of the macro (ej:
) in
the report doesn't calculate the CRP, but if don't use the param or if I set it to one of the leaf cells of the macro (
) it does. Is that ok? Note: this sta script loads a hierarchical design (caravel + user project) with many verilog files and
read_spef -path
to assign spef files to their instances
If you look at the source flop and destination flop clock paths, do you see a common root? If yes there should be crpr, if no, there should not be. It is easy to see in the full clock expanded report.
In those reports I attached the paths are exactly the same in the 3 cases, but depending on how I called report_checks the crpr is 0 or -0.69 (which seems the correct value)
That looks like a bug then. If you can file an issue it would be great. If the path and the transitions are identical the crpr should be identical.
👍 1
@User filed the issue with a test case. Creating the test case I discover that running
-through somemacro
the first time calculates the cprp, but if I then call
--through somemacro/child_cell_on_path
and then I call
-though somemacro
again this time the cprp is 0.
@User I have another doubt about report_checks -through parameter and these hierarchical designs: Should the call with -through
include the results from the call with -through
? Here
are defined in separate verilogs and have their own .spef files
Normally sta users specify a through pin versus a through instance. If you get the same path with different crpr and you see the same common clock root in the expanded clock somethings is wrong.