Forum Discussion

anonimcs's avatar
anonimcs
Icon for Contributor rankContributor
1 year ago
Solved

Clock groups ignored by Timing analyzer

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 b...
Timing
  • anonimcs's avatar
    anonimcs
    1 year ago

    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.

sstrell's avatar
sstrell
Icon for Super Contributor rankSuper Contributor
1 year ago

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's avatar
    anonimcs
    Icon for Contributor rankContributor
    1 year ago

    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's avatar
      sstrell
      Icon for Super Contributor rankSuper Contributor
      1 year ago

      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's avatar
        anonimcs
        Icon for Contributor rankContributor
        1 year ago

        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)