The-OpenROAD-Project
report_checks fails to find all sources but can time missed path when given the source
In a small ASIC verilog design (with about 42K flops and quite a complete clock definition set) a report_checks report to a destination, (a ROM address bit) lists 168 sources in 388 reports when the limit is much higher:
report_checks -to $romAD -endpoint_count 2048 -format full_clock_expanded
none of those sources is "active", when this address bit is changing in simulation, and thus I traced it manually and found a "new" source: named X15195_137.
I can use the same STA database, and report_checks through that source flop's Q pin, and I then see a path to the same ADDR[0] bit.
Why doesn't the original report_checks to the $romAD include this path, which it can clearly time, if I tell it where to start? If you need the files I will have to investigate a process for sharing them with you.
I hope someone is still working on issues, this seems like a serious one.
This is based on a very recent build of sta: OpenSTA 2.4.0 7cf916ba20 Copyright (c) 2021, Parallax Software, Inc. License GPLv3: GNU GPL version 3 http://gnu.org/licenses/gpl.html
Unfortunately the openroad repo is a fork and not a mirror of the official sources so the commits are not in sync with OpenSTA.
The text description of the issue is a vague and there is no guide to the many tcl scripts.
If the missing path from X15195_137 had the smallest slack it would be a major bug. In this case it is an issue related to reporting slower paths to an endpoint (-endpoint_count), which is an entirely different search algorithm and does not indicate that the path is ignored as you may be assuming.
Sorry you find it vague, I am happy to add details. The top-level script is "run_test.tcl" which will read the lib and netlist, and constraints and then run the two report_checks scripts, creating the two report_checks output files to examine. The "general" script will have slacks ranging from $ grep "slack " report_checks.to.ROM_ADDR.AX.AY.out | head -10 -1387.26 slack (VIOLATED) -1387.26 slack (VIOLATED) -939.26 slack (VIOLATED) -939.26 slack (VIOLATED) -869.91 slack (VIOLATED) to
grep "slack " report_checks.to.ROM_ADDR.AX.AY.out | tail -5 661.09 slack (MET) 702.82 slack (MET) 702.82 slack (MET) 814.28 slack (MET) 814.28 slack (MET)
While the report through the specified source flop has these slacks:
grep slack report_checks.from.X15195_137.out -186.22 slack (VIOLATED) -186.22 slack (VIOLATED) 37.78 slack (MET) 37.78 slack (MET)
So it seems that the X15195_137 slacks are "missed" in the general report. They are not the "worst" but some are failing and not reported, although report_checks isn't looking for violators, just some number of paths.
I am wondering if there is some other counting (e.g. group_paths) that I need to also control
I am would like to re-build from the most "official" source, is that the OpenSTA link you showed above?
Rebuilding isn't really relevant. I don't think anything has changed in many years that would make the results any different.
There are issues with the liberty file that are going to cause all kinds of weirdness. The thing to notice is that the path you are hunting for from report_checks -through MI24976/MI25137/X15195_137/Q -to X23547/ADDR[0] -format full_clock_expanded -fields {input_pin}
Note that using -endpoint_count only leads to volumes of irrelevant output.
`Startpoint: MI24976/MI24335/X18946_1032/Q (clock source 'X18946_1032') Endpoint: X23547 (rising edge-triggered flip-flop clocked by X54635_64) Path Group: X54635_64 Path Type: max
Delay Time Description
672.00 672.00 clock X18946_1032 (fall edge) 0.00 672.00 v MI24976/MI24335/X18946_1032/Q (SCD_CLOOKGATING_46X4_32X3) 0.00 672.00 v MI24976/MI24335/X65376_218/A (SCD_BUF_44X8_32X6) .... 8.50 743.97 ^ MI24976/MI24335/X65378_218/Z (SCD_BUF_44X8_32X6) 0.00 743.97 ^ MI24976/MI25137/X15195_137/CP (SCD_DFC_36_32D2) <----- "register" pins 4.49 748.45 ^ MI24976/MI25137/X15195_137/Q (SCD_DFC_36_32D2). <------ 0.00 748.45 ^ MI24976/MI25137/X23894/A2 (SCD_NOR3_E54_E24) ... 0.00 1082.02 v MI24976/MI23810/X17743_6/A (SCD_BUF_E50_22X11) 0.10 1082.12 ^ MI24976/MI23810/X17743_6/Z (SCD_BUF_E50_22X11) 0.00 1082.12 ^ X23547/ADDR[0] (CORE_HIER_behav) 1082.12 data arrival time `
Notice that there the path goes from CP->Q through what looks like is a register. That should not be the case. Looking at the timing arc:
report_edges -from MI24976/MI25137/X15195_137/CP CP -> D hold ^ -> ^ 0.10:0.10 ^ -> v 0.10:0.10 CP -> D setup ^ -> ^ 0.10:0.10 ^ -> v 0.10:0.10 CP -> Q combinational v -> v 3.38:3.38 ^ -> v 3.38:3.38 ^ -> ^ 4.49:4.49 v -> ^ 4.49:4.49
The arc is non-unate and combinational, which is not correct for a register clock to Q.
The liberty for this arc is:
timing_type : rising_edge; intrinsic_rise : 0.1 ; intrinsic_fall : 0.1 ; rise_resistance : 4.6667 ; fall_resistance : 3.4875 ; related_pin : CP; ; }
Which is missing
timing_type : rising_edge;
This is not the only instance of this problem.
The SD/CD set/clear timing arcs are similarly missing timing_type attributes.
All bets are off if the register definitions are not correct because registers define paths from/to timing checks.
I can look at adding some warnings to the liberty reader or use the sequential ff definition to infer the timing_type, but right now the code isn't very forgiving for malformed liberty like this.
Another issue I noticed in the liberty is mismatched function/related_pins like this:
` cell ( SCD_BUF_44X8_32X6 ) { pin ( VS1 ) { direction : input; capacitance : 0.9733; } pin ( Z ) { direction : output; function : VS1; timing () { intrinsic_rise : 0.1 ; intrinsic_fall : 0.1 ; rise_resistance : 3.8182 ; fall_resistance : 3.4875 ; related_pin : A; ; }
}
pin ( A ) {
direction : input;
capacitance : 0.9733;
}
}
`
The timing arc for Z is missing the timing_sense attribute so OpenSTA uses the function to find the unateness. In this case the function VS1 does not contain the related_pin, A so it falls back to non-unate.
There really isn't any point in trying to debug your issues until the liberty is in better shape or the reader fills in the gaps.
James, I want to say a very gracious thank-you to you for this help. I will study your email and address all the issues that I can, I have control of the entire "mess".
I will probably then let you know how things are working!
Mark Vancura
From: James Cherry @.> Sent: Tuesday, August 22, 2023 11:49 AM To: The-OpenROAD-Project/OpenSTA @.> Cc: Mark Vancura @.>; State change @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
Rebuilding isn't really relevant. I don't think anything has changed in many years that would make the results any different.
There are issues with the liberty file that are going to cause all kinds of weirdness. The thing to notice is that the path you are hunting for from report_checks -through MI24976/MI25137/X15195_137/Q -to X23547/ADDR[0] -format full_clock_expanded -fields {input_pin}
Note that using -endpoint_count only leads to volumes of irrelevant output.
`Startpoint: MI24976/MI24335/X18946_1032/Q (clock source 'X18946_1032') Endpoint: X23547 (rising edge-triggered flip-flop clocked by X54635_64) Path Group: X54635_64 Path Type: max
Delay Time Description
672.00 672.00 clock X18946_1032 (fall edge) 0.00 672.00 v MI24976/MI24335/X18946_1032/Q (SCD_CLOOKGATING_46X4_32X3) 0.00 672.00 v MI24976/MI24335/X65376_218/A (SCD_BUF_44X8_32X6) .... 8.50 743.97 ^ MI24976/MI24335/X65378_218/Z (SCD_BUF_44X8_32X6) 0.00 743.97 ^ MI24976/MI25137/X15195_137/CP (SCD_DFC_36_32D2) <----- "register" pins 4.49 748.45 ^ MI24976/MI25137/X15195_137/Q (SCD_DFC_36_32D2). <------ 0.00 748.45 ^ MI24976/MI25137/X23894/A2 (SCD_NOR3_E54_E24) ... 0.00 1082.02 v MI24976/MI23810/X17743_6/A (SCD_BUF_E50_22X11) 0.10 1082.12 ^ MI24976/MI23810/X17743_6/Z (SCD_BUF_E50_22X11) 0.00 1082.12 ^ X23547/ADDR[0] (CORE_HIER_behav) 1082.12 data arrival time `
Notice that there the path goes from CP->Q through what looks like is a register. That should not be the case. Looking at the timing arc:
report_edges -from MI24976/MI25137/X15195_137/CP CP -> D hold ^ -> ^ 0.10:0.10 ^ -> v 0.10:0.10 CP -> D setup ^ -> ^ 0.10:0.10 ^ -> v 0.10:0.10 CP -> Q combinational v -> v 3.38:3.38 ^ -> v 3.38:3.38 ^ -> ^ 4.49:4.49 v -> ^ 4.49:4.49
The arc is non-unate and combinational, which is not correct for a register clock to Q. The liberty for this arc is: timing_type : rising_edge; intrinsic_rise : 0.1 ; intrinsic_fall : 0.1 ; rise_resistance : 4.6667 ; fall_resistance : 3.4875 ; related_pin : CP; ; }
Which is missing
timing_type : rising_edge; This is not the only instance of this problem. The SD/CD set/clear timing arcs are similarly missing timing_type attributes.
All bets are off if the register definitions are not correct because registers define paths from/to timing checks.
I can look at adding some warnings to the liberty reader or use the sequential ff definition to infer the timing_type, but right now the code isn't very forgiving for malformed liberty like this.
Another issue I noticed in the liberty is mismatched function/related_pins like this:
` cell ( SCD_BUF_44X8_32X6 ) { pin ( VS1 ) { direction : input; capacitance : 0.9733; } pin ( Z ) { direction : output; function : VS1; timing () { intrinsic_rise : 0.1 ; intrinsic_fall : 0.1 ; rise_resistance : 3.8182 ; fall_resistance : 3.4875 ; related_pin : A; ; }
}
pin ( A ) {
direction : input;
capacitance : 0.9733;
}
}
`
The timing arc for Z is missing the timing_sense attribute so OpenSTA uses the function to find the unateness. In this case the function VS1 does not contain the related_pin, A so it falls back to non-unate.
There really isn't any point in trying to debug your issues until the liberty is in better shape or the reader fills in the gaps.
— Reply to this email directly, view it on GitHubhttps://github.com/The-OpenROAD-Project/OpenSTA/issues/191#issuecomment-1688650364, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BB7RMDKEAZUJUD3XP5W6AETXWTWKZANCNFSM6AAAAAA3UWTU3I. You are receiving this because you modified the open/close state.Message ID: @.***>
You're welcome.
Here's another liberty issue: rise_resistance : inf ; fall_resistance : inf ;
Again, I'll add warnings for these.
I added a warning for the timing groups missing timing_sense that have a related_pin that is not mentioned in the output pin function. There are 26k warnings like this for the liberty file: Warning: missed_source_liberty.lib line 106, timing sense cannot be inferred because pin function does not reference related pin PIBI. Warning: missed_source_liberty.lib line 114, timing sense cannot be inferred because pin function does not reference related pin VM. Warning: missed_source_liberty.lib line 122, timing sense cannot be inferred because pin function does not reference related pin VP. Warning: missed_source_liberty.lib line 175, timing sense cannot be inferred because pin function does not reference related pin PIBI. Warning: missed_source_liberty.lib line 183, timing sense cannot be inferred because pin function does not reference related pin VM. Warning: missed_source_liberty.lib line 191, timing sense cannot be inferred because pin function does not reference related pin VP. Warning: missed_source_liberty.lib line 248, timing sense cannot be inferred because pin function does not reference related pin NVBI. Warning: missed_source_liberty.lib line 256, timing sense cannot be inferred because pin function does not reference related pin PVBI0. Warning: missed_source_liberty.lib line 264, timing sense cannot be inferred because pin function does not reference related pin PVBI1. Warning: missed_source_liberty.lib line 272, timing sense cannot be inferred because pin function does not reference related pin VP. Warning: missed_source_liberty.lib line 325, timing sense cannot be inferred because pin function does not reference related pin ENP0. Warning: missed_source_liberty.lib line 333, timing sense cannot be inferred because pin function does not reference related pin PIBI.
I pushed some changes to check the liberty that will cause thousands of warnings for your liberty file (use > to redirect them to declutter the output).
It also infers timing_type for sequential arcs when it can, which should make the results more reasonable.
Note that -endpoint_count is not going to onion peal deep enough paths to see the one you are looking for. I tried it with 20000 and it only got to about -600ns slack and the path you are looking for is -183ns.
Thanks I pulled down that source code and re-built it. I am still implementing the changes in the .lib file right now.
Mark Vancura
From: James Cherry @.> Sent: Tuesday, August 22, 2023 11:16 PM To: The-OpenROAD-Project/OpenSTA @.> Cc: Mark Vancura @.>; State change @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
I pushed some changes to check the liberty that will cause thousands of warnings for your liberty file (use > to redirect them to declutter the output).
It also infers timing_type for sequential arcs when it can, which should make the results more reasonable.
Note that -endpoint_count is not going to onion peal deep enough paths to see the one you are looking for. I tried it with 20000 and it only got to about -600ns slack and the path you are looking for is -183ns.
— Reply to this email directly, view it on GitHubhttps://github.com/The-OpenROAD-Project/OpenSTA/issues/191#issuecomment-1689294704, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BB7RMDPBEYHVTGUN6D5GTJ3XWWG4FANCNFSM6AAAAAA3UWTU3I. You are receiving this because you modified the open/close state.Message ID: @.***>
James, I have been working on the liberty issues you identified, with lots of edits, but apparently, I have a new problem that it is hard to diagnose:
$ sta ... % read_liberty missed_source_liberty.lib Memory fault(Coredump) $
Here is that missed_source_liberty.lib file, gzipped. I know it still has issues, I just don't know which one caused the coredump, sorry!
Mark Vancura
From: James Cherry @.> Sent: Tuesday, August 22, 2023 11:16 PM To: The-OpenROAD-Project/OpenSTA @.> Cc: Mark Vancura @.>; State change @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
I pushed some changes to check the liberty that will cause thousands of warnings for your liberty file (use > to redirect them to declutter the output).
It also infers timing_type for sequential arcs when it can, which should make the results more reasonable.
Note that -endpoint_count is not going to onion peal deep enough paths to see the one you are looking for. I tried it with 20000 and it only got to about -600ns slack and the path you are looking for is -183ns.
— Reply to this email directly, view it on GitHubhttps://github.com/The-OpenROAD-Project/OpenSTA/issues/191#issuecomment-1689294704, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BB7RMDPBEYHVTGUN6D5GTJ3XWWG4FANCNFSM6AAAAAA3UWTU3I. You are receiving this because you modified the open/close state.Message ID: @.***>
James, I found the coredump issue:
pin ( VS ) { pin ( VS ) { ... happened in one of my edits by mistake at line 333992
Mark Vancura
From: Mark Vancura @.> Sent: Wednesday, August 23, 2023 5:54 PM To: The-OpenROAD-Project/OpenSTA @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
James, I have been closing in on an updated liberty file, however, I currently have this issue:
$ sta ... % read_liberty missed_source_liberty.lib Memory fault(coredump) $
From: Mark Vancura @.> Sent: Wednesday, August 23, 2023 9:50 AM To: The-OpenROAD-Project/OpenSTA @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
Thanks I pulled down that source code and re-built it. I am still implementing the changes in the .lib file right now.
Mark Vancura
From: James Cherry @.> Sent: Tuesday, August 22, 2023 11:16 PM To: The-OpenROAD-Project/OpenSTA @.> Cc: Mark Vancura @.>; State change @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
I pushed some changes to check the liberty that will cause thousands of warnings for your liberty file (use > to redirect them to declutter the output).
It also infers timing_type for sequential arcs when it can, which should make the results more reasonable.
Note that -endpoint_count is not going to onion peal deep enough paths to see the one you are looking for. I tried it with 20000 and it only got to about -600ns slack and the path you are looking for is -183ns.
— Reply to this email directly, view it on GitHubhttps://github.com/The-OpenROAD-Project/OpenSTA/issues/191#issuecomment-1689294704, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BB7RMDPBEYHVTGUN6D5GTJ3XWWG4FANCNFSM6AAAAAA3UWTU3I. You are receiving this because you modified the open/close state.Message ID: @.***>
James, Thank-you, it does appear that the liberty file corrections you suggested are causing the path tracing to search from many more sources. I expect to switch to the short format, and then look at many paths to find all the source flops I am interested in. I will let you know when I achieve that Mark Vancura
From: Mark Vancura @.> Sent: Thursday, August 24, 2023 9:54 AM To: The-OpenROAD-Project/OpenSTA @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
James, I found the coredump issue:
pin ( VS ) { pin ( VS ) { ... happened in one of my edits by mistake at line 333992
Mark Vancura
From: Mark Vancura @.> Sent: Wednesday, August 23, 2023 5:54 PM To: The-OpenROAD-Project/OpenSTA @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
James, I have been closing in on an updated liberty file, however, I currently have this issue:
$ sta ... % read_liberty missed_source_liberty.lib Memory fault(coredump) $
From: Mark Vancura @.> Sent: Wednesday, August 23, 2023 9:50 AM To: The-OpenROAD-Project/OpenSTA @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
Thanks I pulled down that source code and re-built it. I am still implementing the changes in the .lib file right now.
Mark Vancura
From: James Cherry @.> Sent: Tuesday, August 22, 2023 11:16 PM To: The-OpenROAD-Project/OpenSTA @.> Cc: Mark Vancura @.>; State change @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
I pushed some changes to check the liberty that will cause thousands of warnings for your liberty file (use > to redirect them to declutter the output).
It also infers timing_type for sequential arcs when it can, which should make the results more reasonable.
Note that -endpoint_count is not going to onion peal deep enough paths to see the one you are looking for. I tried it with 20000 and it only got to about -600ns slack and the path you are looking for is -183ns.
— Reply to this email directly, view it on GitHubhttps://github.com/The-OpenROAD-Project/OpenSTA/issues/191#issuecomment-1689294704, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BB7RMDPBEYHVTGUN6D5GTJ3XWWG4FANCNFSM6AAAAAA3UWTU3I. You are receiving this because you modified the open/close state.Message ID: @.***>
James, I do see that with the "-format short" option, I get sources, which is what I am looking for, however, even when I set the endpoint_count and group_count to 2,000,000, I am still missing the one identified (and more) (and it takes a long time). The "sorting" still seems to be based on the timing violation of each path, even though the short format has no timing information in it. What I am really looking for are the register set that drives the ROM's address inputs. The ROM has 16 bits of address, that I can see changing in simulation, but the source registers identified so far do not account for many of the ROM Address changes.
I suppose I can set_disable_timing on the flops I have found so far, so that they are removed from the analysis, and then other ones will emerge. But I sure would like an analysis that I was hoping "-format short" was, which would give me "all" the source flops, just once for each, rather than thousands for each, which are all redundant.
So I will go down this path of iteratively removing the timing paths from the flops it has found, and see what other ones it can find. But if you have an insight into finding a "format short" with each source only listed once, I would love to know about it.
Thanks!
Mark Vancura
From: Mark Vancura @.> Sent: Thursday, August 24, 2023 11:39 AM To: The-OpenROAD-Project/OpenSTA @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
James, Thank-you, it does appear that the liberty file corrections you suggested are causing the path tracing to search from many more sources. I expect to switch to the short format, and then look at many paths to find all the source flops I am interested in. I will let you know when I achieve that Mark Vancura
From: Mark Vancura @.> Sent: Thursday, August 24, 2023 9:54 AM To: The-OpenROAD-Project/OpenSTA @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
James, I found the coredump issue:
pin ( VS ) { pin ( VS ) { ... happened in one of my edits by mistake at line 333992
Mark Vancura
From: Mark Vancura @.> Sent: Wednesday, August 23, 2023 5:54 PM To: The-OpenROAD-Project/OpenSTA @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
James, I have been closing in on an updated liberty file, however, I currently have this issue:
$ sta ... % read_liberty missed_source_liberty.lib Memory fault(coredump) $
From: Mark Vancura @.> Sent: Wednesday, August 23, 2023 9:50 AM To: The-OpenROAD-Project/OpenSTA @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
Thanks I pulled down that source code and re-built it. I am still implementing the changes in the .lib file right now.
Mark Vancura
From: James Cherry @.> Sent: Tuesday, August 22, 2023 11:16 PM To: The-OpenROAD-Project/OpenSTA @.> Cc: Mark Vancura @.>; State change @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
I pushed some changes to check the liberty that will cause thousands of warnings for your liberty file (use > to redirect them to declutter the output).
It also infers timing_type for sequential arcs when it can, which should make the results more reasonable.
Note that -endpoint_count is not going to onion peal deep enough paths to see the one you are looking for. I tried it with 20000 and it only got to about -600ns slack and the path you are looking for is -183ns.
— Reply to this email directly, view it on GitHubhttps://github.com/The-OpenROAD-Project/OpenSTA/issues/191#issuecomment-1689294704, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BB7RMDPBEYHVTGUN6D5GTJ3XWWG4FANCNFSM6AAAAAA3UWTU3I. You are receiving this because you modified the open/close state.Message ID: @.***>
You can find the fanin startpoints to an endpoint with report_object_full_names [get_fanin -to r3/D -startpoints_only]
or maybe you are looking for
foreach start [get_fanin -to r3/D -startpoints_only] { report_checks -from $start -to r3/D }
I can't really tell. Are you questioning the veracity of the timer or are you looking for a specific path you can't see?
I am just looking for a complete list of all the flops that can drive the ROM address pins, this is a design I am "learning", I would like to find the "address register", sadly this design has little useful hierarchy to tell things like that.
I am using this loop successfully:
proc my_find_sources { to_pin } {
set path_w_source [find_timing_paths -to [get_pins $to_pin ] -endpoint_count 1 -group_count 1 ]
while [info exists path_w_source ] {
set startpoint [get_property $path_w_source startpoint ]
set startpoint_name [get_full_name $startpoint]
puts $startpoint_name
set start_cell [get_cells -of $startpoint ]
set_disable_timing $start_cell
set path_w_source [find_timing_paths -to [get_pins $to_pin ] -endpoint_count 1 -group_count 1 ]
} puts "all startpoints reported" }
But it takes about 2.5 minutes per iteration.
Thanks for your help with this, you have helped me a lot already!
Mark Vancura
From: James Cherry @.> Sent: Thursday, August 24, 2023 5:38 PM To: The-OpenROAD-Project/OpenSTA @.> Cc: Mark Vancura @.>; State change @.> Subject: Re: [The-OpenROAD-Project/OpenSTA] report_checks fails to find all sources but can time missed path when given the source (Issue #191)
You can find the fanin startpoints to an endpoint with report_object_full_names [get_fanin -to r3/D -startpoints_only]
or maybe you are looking for
foreach start [get_fanin -to r3/D -startpoints_only] { report_checks -from $start -to r3/D }
I can't really tell. Are you questioning the veracity of the timer or are you looking for a specific path you can't see?
— Reply to this email directly, view it on GitHubhttps://github.com/The-OpenROAD-Project/OpenSTA/issues/191#issuecomment-1692548858, or unsubscribehttps://github.com/notifications/unsubscribe-auth/BB7RMDLQ3YYLINNFKSY7CRTXW7QYDANCNFSM6AAAAAA3UWTU3I. You are receiving this because you modified the open/close state.Message ID: @.***>
Issues or PRs should be filed with https://github.com/parallaxsw/OpenSTA if still relevant. This is effectively a fork (though not strictly for historical reasons).
