https://open-source-silicon.dev logo
Join Slack
Powered by
<@U018LA3KZCJ> I'm running report_checks on `sta` ...
# openroad
m
@User I'm running report_checks on 
sta
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 
-through
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 
sta
from 
efabless/openlane:mpw-3a
docker
m
@User would you comment on this sta concern.
d
@User Did you got any info on why 
-through
showing additional result?
m
Not yet
m
I suggest you open an issue with a testcase
m
@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 
-through
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
t
@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.
m
@User it seems that if I use the path of the macro (ej: 
mprj/wrapper_fibonacci_3
) in 
-through
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 (
mprj/wrapper_fibonacci_3/_2746_
) 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
testB_fibonacci_through_2746_.txttestB_fibonacci_through.txttestB_fibonacci.txt
t
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.
m
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)
t
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
m
@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 
mprj/wrapped_hack_soc_dffram_9
include the results from the call with -through 
mprj/wrapped_hack_soc_dffram_9/soc.spi_video_ram_1.write_fifo.dffrf
? Here 
wrapped_hack_soc_dffram_9
and 
dffrf
are defined in separate verilogs and have their own .spef files
t
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.
Open in Slack
PreviousNext
Powered by