Find where false_path was set.

[OrF]

Hi,

I have a design where there is a physical path between two flip-flops (FF). However, when I try to generate a timing report, the Timing Analyzer shows “nothing to report.” I assume this might be due to a false path or the setting of asynchronous clock groups. Are there any other possibilities?

Is there a way to identify where the false path or asynchronous clock groups were set? maybe , in which SDC file and line?

Thanks.

[sstrell]

Run "Report SDC" from the Timing Analyzer or run the timing exceptions report.

[OrF]

I am aware of these reports; however, they seems to be the exact the false_path or clock group within the SDC. This is equivalent to manually searching (using "grep") through my SDC files to determine why the report indicates "nothing to report." For instance, if there is a use of the wildcard character "*", it becomes challenging to ascertain whether this was the underlying reason for including the false path in the path I am examining.

[sstrell]

report_sdc expands wildcards to list every path in the design and then references the .sdc file and line number where the constraint came from.  So you can generate the report and search in the report for the path in question.  Then the report will point you to the applied constraint(s).

If you're still not finding the path, then something else is going on.

[OrF]

Hi 

can you point me to the report that expand the wildcard.

since I used the next command (gui or to file) 

>report_sdc -file report_sdc.txt

and I still see the wild cards 

+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
; Set False Path ;
+----------------+-------+------------+------------------------+---------+----------+-------------------------------------------------------+----------------------------+----------+
; SDC Command ; Flags ; From Flags ; From ; Through ; To Flags ; To ; Location ; Comments ;
+----------------+-------+------------+------------------------+---------+----------+-------------------------------------------------------+----------------------------+----------+
; set_false_path ; ; -from ; [get_clocks {rx_*}] ; ; -to ; [get_clocks {pll_*}] ; scf_manual_addition.scf:65 ; ;
+----------------+-------+------------+------------------------+---------+----------+-------------------------------------------------------+----------------------------+----------+

[sstrell]

I'm not sure why this is referring to a .scf file (which I had to look up what that was, a simulator channel file?), but maybe that's why there are issues.  This should be in a .sdc file.

[OrF]

The .scf extension is what I used to apply my constraints. The constraints are in place, but I can change the file name or its extension if needed (see below). I created a test case, but it doesn’t seem to be expanding the wildcard, even after changing the file name.

+-----------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
; Set False Path ;
+----------------+-------+------------+------------------------+---------+----------+-------------------------------------------------------+----------------------------+----------+
; SDC Command ; Flags ; From Flags ; From ; Through ; To Flags ; To ; Location ; Comments ;
+----------------+-------+------------+------------------------+---------+----------+-------------------------------------------------------+----------------------------+----------+
; set_false_path ; ; -from ; [get_clocks {rx_*}] ; ; -to ; [get_clocks {pll_*}] ; new.sdc:2 ; ;
+----------------+-------+------------+------------------------+---------+----------+-------------------------------------------------------+----------------------------+----------+

[RichardTanSY_Intel]

Try removing the .sdc file reported in the Report SDC (Set False Path) from the project directory and check if the timing path is reported between the flip-flops.

The asterisk (*) is likely not expanding because the SDC constraints were initially written in that format.

Regards,

Richard Tan

[RichardTanSY_Intel]

Hi,

Just dropping a note to check if my last reply was helpful to you.

Do you need any further assistance from my side?

Regards,

Richard Tan

[OrF]

I didn't check it , hopefully I will do it today , anyway I will update here if it was helpful or not .

Thanks

Or. 

[OrF]

Hi,

Unfortunately, it didn’t help.

I’m not sure if I removed the .sdc file you asked me to remove. I removed these two files:

The output of the command  the file  report_sdc.txt

'report_sdc -file report_sdc.txt'

The .sdc file of the project, but then I couldn’t regenerate the timing report because it looks for the .sdc file in its initial steps.
So, I removed the .sdc file before issuing the command:

'report_sdc -file report_sdc.txt'
Bottom line, neither approach helped.

maybe I don't understand where to remove it .

Or.

[sstrell]

If you want to expand all wildcards to a separate file, the correct command is

write_sdc -expand "<sdc file name>"

[OrF]

Hi,

I tried the additional step you suggested, but it still doesn’t resolve the issue. I used the command write_sdc -expand "expanded_sdc.sdc", but the output still includes lines like the following on the false path, and I don’t see it expanding the output delay constraints:

set_false_path -from [get_clocks {rx_*}] -to [get_clocks {pll_*}]
set_output_delay -add_delay -max -clock [get_clocks {tx_clk}] 47.000 [get_ports {DIE0_dib_pad_0_*_*[*]}]
set_output_delay -add_delay -min -clock [get_clocks {tx_clk}] 0.000 [get_ports {DIE0_dib_pad_0_*_*[*]}]

Any further suggestions?

Or.

[RichardTanSY_Intel]

Could you please share your design by archiving the project (Project > Archive Project) so I can investigate it further?

Also, kindly provide the timing path that isn't being captured in the Timing Analyzer.

Regards,

Richard Tan

[OrF]

Hi,

I’ve attached the QAR file. I’m not sure what files are inside the QAR, but the timing constraints I would like to expand are as follows:

set_false_path -from [get_clocks {rx_*}] -to [get_clocks {pll_*}]
set_output_delay -add_delay -max -clock [get_clocks {tx_clk}] 47.000 [get_ports {DIE0_dib_pad_0_*_*[*]}]
set_output_delay -add_delay -min -clock [get_clocks {tx_clk}] 0.000 [get_ports {DIE0_dib_pad_0_*_*[*]}]

In my project, these constraints are located in the file scf_manual_addition.scf.

I’m not sure what the QAR will generate, but my expectation is that the * will be expanded in any of the three cases.

Thanks,
Or

[RichardTanSY_Intel]

The timing analyzer does not expand the wildcards(*) list unfortunately, but you can right-click and View Matching, to examine the collections in the wildcards that you specified.

Alternatively, you can go to the Timing Analyzer GUI, View > Name Finder to check and experiment with collections using the wildcards.

Regards,

Richard Tan

[RichardTanSY_Intel]

Hi,

Do you have further question in regards to this case?

Regards,

Richard Tan

[RichardTanSY_Intel]

We noticed that we haven't received a response from you regarding the latest previous question/reply/answer, and will now transitioning your inquiry to our community support. We apologize for any inconvenience this may cause and we appreciate your understanding.

If you have any further questions or concerns, please don't hesitate to reach out. Please login to ‘https://supporttickets.intel.com’, view details of the desire request, and post a feed/response within the next 15 days to allow me to continue to support you. After 15 days, this thread will be transitioned to community support.

The community users will be able to help you on your follow-up questions.

Thank you for reaching out to us!

Best Regards,

Richard Tan