UPGRADE YOUR BROWSER

We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

cancel
Showing results for 
Search instead for 
Did you mean: 
Visitor yf2018
Visitor
437 Views
Registered: ‎10-13-2018

Adding MMCM causes input delay constraint to be not working, vivado treating output of MMCM as asynchronous

Jump to solution

I am interfacing a USB chip to the Artix and there are timing constraints that need to be referenced to the clock that is generated by the USB chip. I have some setup time violation (about -2.2ns setup slack), so I used the clocking wizard, and generated a MMCM instance to compensate the clock insertion delay caused by the BUFG and the clock input paths.

The following is part of the constraints that I use to constraint the output delay of usb_wr_b against the ft_clk.

 

create_clock -period 16.667 -name ft_clk -waveform {0.000 8.334} [get_ports usb_clkout]
create_clock -period 20.000 -name global_clk -waveform {0.000 10.000} [get_ports global_clk]
set_clock_groups -name async_clocks1 -asynchronous -group [get_clocks {global_clk ft_clk sys_clk}]
set_output_delay -clock [get_clocks ft_clk] -max 7.500 [get_ports usb_wr_b]
set_output_delay -clock [get_clocks ft_clk] -min 0.000 [get_ports usb_wr_b]

After added the MMCM generated from the clocking wizard, I don't see the setup time failure anymore. However, I am not convinced so I generated the timing report for the usb_wr_b, and it seems like the input of the MMCM (ft_clk) is somehow become asynchronous to the output of the MMCM (clk_out1_usb_clk_mmcm_1), and causes the slack to go infinite! See the timing report below:

 

 

Slack:                    inf
  Source:                 usb_tx_master/FSM_sequential_usb_send_ps_reg[0]/C
                            (rising edge-triggered cell FDRE clocked by clk_out1_usb_clk_mmcm_1  {rise@0.000ns fall@8.333ns period=16.667ns})
  Destination:            usb_wr_b
                            (output port clocked by ft_clk  {rise@0.000ns fall@8.334ns period=16.667ns})
  Path Group:             (none)
  Path Type:              Max at Slow Process Corner
  Data Path Delay:        9.623ns  (logic 4.156ns (43.183%)  route 5.468ns (56.817%))
  Logic Levels:           2  (LUT1=1 OBUF=1)
  Output Delay:           7.500ns
  Clock Path Skew:        0.900ns (DCD - SCD + CPR)
    Destination Clock Delay (DCD):    0.000ns
    Source Clock Delay      (SCD):    -0.900ns
    Clock Pessimism Removal (CPR):    0.000ns
  Clock Uncertainty:      0.203ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Discrete Jitter          (DJ):    0.156ns
    Phase Error              (PE):    0.118ns
  Timing Exception:       Asynchronous Clock Groups

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock clk_out1_usb_clk_mmcm_1 rise edge)
                                                      0.000     0.000 r  
    N13                                               0.000     0.000 r  usb_clkout (IN)
                         net (fo=0)                   0.000     0.000    usb_clk_mmcm_inst0/inst/clk_in1
    N13                                                               r  usb_clk_mmcm_inst0/inst/clkin1_ibufg/I
    N13                  IBUF (Prop_ibuf_I_O)         1.516     1.516 r  usb_clk_mmcm_inst0/inst/clkin1_ibufg/O
                         net (fo=1, routed)           1.233     2.749    usb_clk_mmcm_inst0/inst/clk_in1_usb_clk_mmcm
    MMCME2_ADV_X0Y0                                                   r  usb_clk_mmcm_inst0/inst/mmcm_adv_inst/CLKIN1
    MMCME2_ADV_X0Y0      MMCME2_ADV (Prop_mmcme2_adv_CLKIN1_CLKOUT0)
                                                     -6.965    -4.215 r  usb_clk_mmcm_inst0/inst/mmcm_adv_inst/CLKOUT0
                         net (fo=1, routed)           1.666    -2.549    usb_clk_mmcm_inst0/inst/clk_out1_usb_clk_mmcm
    BUFGCTRL_X0Y2                                                     r  usb_clk_mmcm_inst0/inst/clkout1_buf/I
    BUFGCTRL_X0Y2        BUFG (Prop_bufg_I_O)         0.096    -2.453 r  usb_clk_mmcm_inst0/inst/clkout1_buf/O
                         net (fo=551, routed)         1.553    -0.900    usb_tx_master/CLK
    SLICE_X45Y28         FDRE                                         r  usb_tx_master/FSM_sequential_usb_send_ps_reg[0]/C
  -------------------------------------------------------------------    -------------------
    SLICE_X45Y28         FDRE (Prop_fdre_C_Q)         0.456    -0.444 f  usb_tx_master/FSM_sequential_usb_send_ps_reg[0]/Q
                         net (fo=24, routed)          2.940     2.496    usb_tx_master/buf_active
    SLICE_X30Y27                                                      f  usb_tx_master/usb_wr_b_internal/I0
    SLICE_X30Y27         LUT1 (Prop_lut1_I0_O)        0.124     2.620 r  usb_tx_master/usb_wr_b_internal/O
                         net (fo=1, routed)           2.528     5.148    lopt
    P13                                                               r  usb_wr_b_OBUF_inst/I
    P13                  OBUF (Prop_obuf_I_O)         3.576     8.724 r  usb_wr_b_OBUF_inst/O
                         net (fo=1, unset)            0.000     8.724    usb_wr_b
    P13                                                               r  usb_wr_b (INOUT)
  -------------------------------------------------------------------    -------------------

Slack:                    inf
  Source:                 usb_tx_master/FSM_sequential_usb_send_ps_reg[0]/C
                            (rising edge-triggered cell FDRE clocked by clk_out1_usb_clk_mmcm_1  {rise@0.000ns fall@8.333ns period=16.667ns})
  Destination:            usb_wr_b
                            (output port clocked by ft_clk  {rise@0.000ns fall@8.334ns period=16.667ns})
  Path Group:             (none)
  Path Type:              Min at Fast Process Corner
  Data Path Delay:        3.459ns  (logic 1.462ns (42.272%)  route 1.997ns (57.728%))
  Logic Levels:           2  (LUT1=1 OBUF=1)
  Output Delay:           0.000ns
  Clock Path Skew:        0.570ns (DCD - SCD - CPR)
    Destination Clock Delay (DCD):    0.000ns
    Source Clock Delay      (SCD):    -0.570ns
    Clock Pessimism Removal (CPR):    -0.000ns
  Clock Uncertainty:      0.203ns  ((TSJ^2 + DJ^2)^1/2) / 2 + PE
    Total System Jitter     (TSJ):    0.071ns
    Discrete Jitter          (DJ):    0.156ns
    Phase Error              (PE):    0.118ns
  Timing Exception:       Asynchronous Clock Groups

    Location             Delay type                Incr(ns)  Path(ns)    Netlist Resource(s)
  -------------------------------------------------------------------    -------------------
                         (clock clk_out1_usb_clk_mmcm_1 rise edge)
                                                      0.000     0.000 r  
    N13                                               0.000     0.000 r  usb_clkout (IN)
                         net (fo=0)                   0.000     0.000    usb_clk_mmcm_inst0/inst/clk_in1
    N13                                                               r  usb_clk_mmcm_inst0/inst/clkin1_ibufg/I
    N13                  IBUF (Prop_ibuf_I_O)         0.284     0.284 r  usb_clk_mmcm_inst0/inst/clkin1_ibufg/O
                         net (fo=1, routed)           0.440     0.724    usb_clk_mmcm_inst0/inst/clk_in1_usb_clk_mmcm
    MMCME2_ADV_X0Y0                                                   r  usb_clk_mmcm_inst0/inst/mmcm_adv_inst/CLKIN1
    MMCME2_ADV_X0Y0      MMCME2_ADV (Prop_mmcme2_adv_CLKIN1_CLKOUT0)
                                                     -2.362    -1.638 r  usb_clk_mmcm_inst0/inst/mmcm_adv_inst/CLKOUT0
                         net (fo=1, routed)           0.489    -1.150    usb_clk_mmcm_inst0/inst/clk_out1_usb_clk_mmcm
    BUFGCTRL_X0Y2                                                     r  usb_clk_mmcm_inst0/inst/clkout1_buf/I
    BUFGCTRL_X0Y2        BUFG (Prop_bufg_I_O)         0.026    -1.124 r  usb_clk_mmcm_inst0/inst/clkout1_buf/O
                         net (fo=551, routed)         0.554    -0.570    usb_tx_master/CLK
    SLICE_X45Y28         FDRE                                         r  usb_tx_master/FSM_sequential_usb_send_ps_reg[0]/C
  -------------------------------------------------------------------    -------------------
    SLICE_X45Y28         FDRE (Prop_fdre_C_Q)         0.141    -0.429 f  usb_tx_master/FSM_sequential_usb_send_ps_reg[0]/Q
                         net (fo=24, routed)          1.200     0.771    usb_tx_master/buf_active
    SLICE_X30Y27                                                      f  usb_tx_master/usb_wr_b_internal/I0
    SLICE_X30Y27         LUT1 (Prop_lut1_I0_O)        0.045     0.816 r  usb_tx_master/usb_wr_b_internal/O
                         net (fo=1, routed)           0.797     1.613    lopt
    P13                                                               r  usb_wr_b_OBUF_inst/I
    P13                  OBUF (Prop_obuf_I_O)         1.276     2.889 r  usb_wr_b_OBUF_inst/O
                         net (fo=1, unset)            0.000     2.889    usb_wr_b
    P13                                                               r  usb_wr_b (INOUT)
  -------------------------------------------------------------------    -------------------

 

I am also seeing this warning, not sure whether this causes the problem:

 [Constraints 18-1055] Clock 'ft_clk' completely overrides clock 'usb_clkout', which is referenced by one or more other constraints. Any constraints that refer to the overridden clock will be ignored.
New: create_clock -period 16.667 -name ft_clk -waveform {0.000 8.334} [get_ports usb_clkout], [/......./constraints.xdc:137]
Previous: create_clock -period 16.667 [get_ports usb_clkout], [/....../sources_1/ip/usb_clk_mmcm/usb_clk_mmcm.xdc:56]
Resolution: Review the constraint files and remove the redundant clock definition(s). If the clock constraints are not saved in a file, you can first save the constraints to an XDC file and reload the design once the constraints have been corrected.

Do I need to add more constraints? How do I add the constraint to relate the two clocks since I don't know the actual delay of MMCM?

 

0 Kudos
1 Solution

Accepted Solutions
Historian
Historian
320 Views
Registered: ‎01-23-2009

Re: Adding MMCM causes input delay constraint to be not working, vivado treating output of MMCM as asynchronous

Jump to solution

Or I must always specify the set_clock_groups?

Just the opposite. The set_clock_groups command should only rarely be used - far rarer than it us used by designers. This command states that all paths between different groups are false paths. Furthermore, due to constraint priority, this constraint overrides any other constrain on any path that is covered by the set_clock_group command.

If two clocks are asynchronous, then moving data between the clocks required a clock domain crossing circuit (CDCC). All CDCCs need some form of timing exception on the path between domains. However only the simplest CDCC (the single bit slow changing signal CDCC) is properly constrained by a set_false_path/set_clock_groups - pretty much all other CDCCs need "less permissive" exceptions - usually a set_max_delay -datapath_only. And, as I said above, the set_clock_groups command overrides the set_max_delay -datapath_only. Therefore, if you use the set_clock_groups, these CDCCs are underconstrained and hence are potentially unreliable.

Take a look at this thread (including the comments that follow it and the links referenced within the comments) that describe constraining CDCCs.

Avrum

0 Kudos
3 Replies
Historian
Historian
393 Views
Registered: ‎01-23-2009

Re: Adding MMCM causes input delay constraint to be not working, vivado treating output of MMCM as asynchronous

Jump to solution

(I haven't looked into this carefully, but...)

Try this command instead

set_clock_groups -name async_clocks1 -asynchronous -group [get_clocks -include_generated_clocks {global_clk ft_clk sys_clk}]

Avrum

Visitor yf2018
Visitor
378 Views
Registered: ‎10-13-2018

Re: Adding MMCM causes input delay constraint to be not working, vivado treating output of MMCM as asynchronous

Jump to solution

I didn't realized that the clock group is created wrongly (it is created much earlier, using the GUI). After re-reading the user guide, it seems like the correct constraint would be the following :

set_clock_groups -name async_clk_groups -asynchronous -group [get_clocks -include_generated_clocks ft_clk] -group [get_clocks -include_generated_clocks sys_clk] -group [get_clocks -include_generated_clocks global_clk]

The 3 clocks in the original group should be asynchronous to each other.

I also tried deleting the clock group constraint and it seems to work as well (at least the constraints related to the ft_clk seems to be working correctly). My question, is it recommended to leave out the set_clock_group constraint? Or I must always specify the set_clock_groups?

 

0 Kudos
Historian
Historian
321 Views
Registered: ‎01-23-2009

Re: Adding MMCM causes input delay constraint to be not working, vivado treating output of MMCM as asynchronous

Jump to solution

Or I must always specify the set_clock_groups?

Just the opposite. The set_clock_groups command should only rarely be used - far rarer than it us used by designers. This command states that all paths between different groups are false paths. Furthermore, due to constraint priority, this constraint overrides any other constrain on any path that is covered by the set_clock_group command.

If two clocks are asynchronous, then moving data between the clocks required a clock domain crossing circuit (CDCC). All CDCCs need some form of timing exception on the path between domains. However only the simplest CDCC (the single bit slow changing signal CDCC) is properly constrained by a set_false_path/set_clock_groups - pretty much all other CDCCs need "less permissive" exceptions - usually a set_max_delay -datapath_only. And, as I said above, the set_clock_groups command overrides the set_max_delay -datapath_only. Therefore, if you use the set_clock_groups, these CDCCs are underconstrained and hence are potentially unreliable.

Take a look at this thread (including the comments that follow it and the links referenced within the comments) that describe constraining CDCCs.

Avrum

0 Kudos