Clock groups ignored by Timing analyzer

[anonimcs]

Hi all,

I have a design with multiple clock domains. I want to ignore the timing checks for the paths where CDC happens. For this purpose, I have set clock groups in my sdc file, code can be found below. What I noticed after compiling the design on Quartus Pro 21.3 is that the compiler still checks for the timing between the clock domains, therefore I'm getting setup violations. I attached a snippet where I can see that the path between these clocks are not set as false paths. Do you guys know what I'm doing wrong here ?

set_clock_groups \
    -group [get_clocks { clk_25mhz_fpga }] \
    -group [get_clocks { sg_clk }] \
    -group [get_clocks { blk_clk_n_rst.i_pll_sys|iopll_0|outclk0 }] \
    -group [get_clocks { i_max|ddr4|ddr4_phy_clk_0 \
                         i_max|ddr4|ddr4_phy_clk_l_0 \
                         i_max|ddr4|ddr4_wf_clk_0 \
                         i_max|ddr4|ddr4_wf_clk_1 \
                         i_max|ddr4|ddr4_wf_clk_2 }] \
    -group [get_clocks { i_max|ddr4|ddr4_phy_clk_1 \
                         i_max|ddr4|ddr4_phy_clk_l_1 \
                         i_max|ddr4|ddr4_wf_clk_3 \
                         i_max|ddr4|ddr4_wf_clk_4 \
                         i_max|ddr4|ddr4_wf_clk_5 \
                         i_max|ddr4|ddr4_wf_clk_6 }] \
    -group [get_clocks { i_max|fpga_emif_ddr4|fpga_emif_ddr4_phy_clk_0 \
                         i_max|fpga_emif_ddr4|fpga_emif_ddr4_phy_clk_l_0 \
                         i_max|fpga_emif_ddr4|fpga_emif_ddr4_wf_clk_0 \
                         i_max|fpga_emif_ddr4|fpga_emif_ddr4_wf_clk_1 \
                         i_max|fpga_emif_ddr4|fpga_emif_ddr4_wf_clk_2 \
                         i_max|fpga_emif_ddr4|fpga_emif_ddr4_wf_clk_6 \
                         i_max|fpga_emif_ddr4|fpga_emif_ddr4_core_usr_clk \
                         i_max|fpga_emif_ddr4|fpga_emif_ddr4_phy_clk_1 \
                         i_max|fpga_emif_ddr4|fpga_emif_ddr4_phy_clk_l_1 \
                         i_max|fpga_emif_ddr4|fpga_emif_ddr4_wf_clk_3 \
                         i_max|fpga_emif_ddr4|fpga_emif_ddr4_wf_clk_4 \
                         i_max|fpga_emif_ddr4|fpga_emif_ddr4_wf_clk_5 }] \
    -group [get_clocks { i_max|rx_phy_0|rx_phy_0|rx_clkout \
                         i_max|rx_phy_1|rx_phy_1|rx_clkout \
                         i_max|rx_phy_2|rx_phy_2|rx_clkout \
                         i_max|rx_phy_3|rx_phy_3|rx_clkout \
                         i_max|rx_phy_4|rx_phy_4|rx_clkout \
                         i_max|rx_phy_5|rx_phy_5|rx_clkout }] \
    -group [get_clocks { clk_xcvr_1f \
                         i_teng_io_pll|iopll_0|outclk0 \
                         i_teng_io_pll|iopll_0|outclk1 }] \
    -asynchronous

[sstrell]

You should not be creating timing constraints for IP like EMIF.  The IP creates the .sdc for you when generated.  Chances are, the constraints for the IP are overriding what you have put here in your .sdc.  Check the timing analyzer's ignored constraints report and the timing exceptions reports to see how your clock groups constraints have (or have not) been applied.

[anonimcs]

Hi @sstrell ,

I just checked the Ignored SDC report on Timing Analyzer (under Constraint Diagnostics) and I see that my constraints are not ignored (at least not here). But I also checked the .sta.rpt file and I saw that there has been no exception between the two domains that I set by introducing the clock groups in my entry above. Here's one of the many entries I saw in that report:

Path #1: Setup slack is -9.497 (VIOLATED)
===============================================================================
+-----------------------------------------------------------------------------------------------------------------+
; Path Summary                                                                                                    ;
+---------------------------------+-------------------------------------------------------------------------------+
; Property                        ; Value                                                                         ;
+---------------------------------+-------------------------------------------------------------------------------+
; From Node                       ; i_max|rx_link_layer_1|rx_link_layer_1|cfg_output_switch                       ;
; To Node                         ; i_max|rx_link_layer_4|rx_link_layer_4|link_layer_fifo_showahead|s_p1_data[15] ;
; Launch Clock                    ; blk_clk_n_rst.i_pll_sys|iopll_0|outclk0                                       ;
; Latch Clock                     ; i_max|fpga_emif_ddr4|fpga_emif_ddr4_core_usr_clk                              ;
; SDC Exception                   ; No SDC Exception on Path                                                      ;
; Data Arrival Time               ; 4060.638                                                                      ;
; Data Required Time              ; 4051.141                                                                      ;
; Slack                           ; -9.497 (VIOLATED)                                                             ;
; Worst-Case Operating Conditions ; Slow 900mV 100C Model                                                         ;

So somehow my clock groups were ignored and the tool considers the timing between two domains. I also tried splitting the `set_clock_groups` command above in multiple `set_clock_groups` command where each command has only 2 different groups as it's stated by Intel here that the Set Clock Groups dialog box only permits two clock groups. However, it made no impact at all, I have the exact same issues at the end..

---

[sstrell]

Try taking get_clocks out of each group.  It's not needed if the clocks have already been defined in other constraints and you are naming the clocks correctly in each group.  I don't know if it will do anything, but I don't normally put that in the targets for this command.

But it doesn't make sense that these don't appear in the ignored constraints report and that they are not being applied.  It has to be one or the other.  Run "report sdc" to see what constraints *are* being applied to the design.  Maybe that will provide a clue.

Also, obviously, make sure this .sdc file is being read by Quartus in the timing analyzer settings.

[anonimcs]

I haven't defined those clocks in other constraints, that's why I've used `get_clocks`. I double-checked this by trying to set clock groups in the Timing Analyzer GUI and that one provides the equivalent code for .sdc files. And that one had `get_clocks` as well.

I've run the Report SDC and I can see that only 3 `create_clock` commands are used from my .sdc file. The other commands that I have (listed below) are simply 'ignored', but weirdly not shown when I run Report Ignored SDC...

derive_pll_clocks
derive_clock_uncertainty

#JTAG Signal Constraints
#constrain the TDI TMS and TDO ports 
set_input_delay  -clock {altera_reserved_tck} 5 [get_ports altera_reserved_tdi]
set_input_delay  -clock {altera_reserved_tck} 5 [get_ports altera_reserved_tms]
set_input_delay  -clock {altera_reserved_tck} 5 [get_ports altera_reserved_ntrst]
set_output_delay -clock {altera_reserved_tck} 5 [get_ports altera_reserved_tdo]

set_false_path -from [get_ports {rotenc_a rotenc_b rotenc_z}] -to *
set_false_path -from [get_pins {\blk_clk_n_rst:sb_rst|q}] -to *

set_clock_groups -asynchronous -group [get_clocks {blk_clk_n_rst.i_pll_sys|iopll_0|outclk0}] -group [get_clocks { clk_xcvr_1f i_teng_io_pll|iopll_0|outclk0 i_teng_io_pll|iopll_0|outclk1 }]

There are many more commands like the ones above, just added those to show the type of commands which are 'ignored'.

And yes, I've already added the .sdc file into the project on Quartus (and I tried removing/re-adding it back, didn't help)

[sstrell]

Can you show your create_clock constraints?  Something is not making sense here.  What is your target device and Quartus version?

[anonimcs]

The target device is Arria 10 and I'm using the Quartus version 21.3 Pro. I attached my .sdc file here so that you can have a better sight on my constraints.

[TingJiangT_Intel]

Could you please provide your project (.qar) for investigation. You can remove all RTL files for confidentiality.

Thanks a lot.

[anonimcs]

Could you specify the archive settings that you want ? I don't want to provide 'too less' files to you, but checking all boxes here generates gigabytes of data...

[TingJiangT_Intel]

Just make sure that after restoring the timing analyzer can be opened without going through the synthesis process.

You can open the QAR file after archiving the project to verify this. Thanks.

[anonimcs]

@TingJiangT_Intel  Could you send me a link via email so that I can upload the archived project ? I tried all the options above and any option is greater than 71 MBytes, which is the limit I'm allowed to attach files here.

[ZachDrew]

Hi,

Ensure your SDC file is correctly loaded and check for typos in clock names. Verify the timing analyzer respects the constraints. You can also define false paths explicitly, like:

set_false_path -from [get_clocks { clk_25mhz_fpga }] -to [get_clocks { sg_clk }]

Generate a detailed timing report to pinpoint the issue. Make sure no incremental compilation settings are causing this problem. Lastly, check for any known issues with Quartus Pro 21.3.

Hope this helps!

[anonimcs]

Hi,

My .sdc is correctly loaded into the project and there is no typos whatsoever, I directly copy-pasted the names from the Timing Analyzer. I tried defining false paths with the syntax you suggested, but the result is the same. No ignored constraints and no applied constraints for the false paths... And yes, I still get the timing violations at the clock domain crossings.

Not sure what you meant by "a detailed timing report", these should be the details I need to look for, right ?

I applied both "Superior performance with synthesis optimizations" and "Balanced" flows, the results are the same.

Thanks for the suggestions anyways !

[anonimcs · Accepted solution]

The issue was that the .sdc file was read before all the other .ip files are read in the .qsf file. When I moved the line to read the .sdc file after reading the .ip files, the issue is gone, and I can see false paths set in the report for clock transfers. This issue was also mentioned in this article here. In case the link becomes broken in the future, I attach a screenshot of the link content below.

[TingJiangT_Intel]

I’m glad that your question has been addressed, I now transition this thread to community support. If you have a new question, 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.