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 jan_ch
Visitor
349 Views
Registered: ‎05-17-2019

Inter-clock path constraints problem

Hi, i am trying to learn how to constrain with my Zynq-7000 Video design. Accordingly, to Xilinx tutorials for Timing Constraint Wizard I firstly create the design, and set only input/output pin locations, synthesized it, opened, and start to constraint clocks with the Wizard (the input and output delays are waiting for me, but I started from clocks).

I have two clocks. Zynq Fabric clock (FCLK0 - 100MHz), for whole design, and input differential 100Mhz clock which is an input for the Clocking Wizard and using the mmcm output 74.250MHz clock is generated. The generated 74.250MHz clock is used as a output hdmi clock for ADV7513, and as vid_io_out_clk for the AXI Stream to Video out. 

So, in my understanding those clocks (the generated 74,250MHz, and the FCLK0) are not related, and should not be analyzed in relaton to each other. After report timing summary i am receiving two very big  timing problems in the Inter-Clock Paths section.

First is :

From Clock : clk_out1_design_1_clk_wiz_0_0 which - i am guessing - is the output of the clocking wizard (My external clock from clocking wizard is named hdmi_clk)

To Clock : ...processing_system7_0/inst/FCLK_CLK_unbuffered[0]

The total Violation on setup is  -33,8 ns and Hold -624ns

And the second is :

From: ...processing_system7_0/inst/FCLK_CLK_unbuffered[0]

To: clk_out1_design_1_clk_wiz_0_0 

Total Violation on setup i -871 ns and on Hold is 0

 

What should I do with this? Any advices?

0 Kudos
1 Reply
Guide avrumw
Guide
329 Views
Registered: ‎01-23-2009

Re: Inter-clock path constraints problem

If there are failures between the clock domains (inter-clock failures), then you have paths that cross between the clock domains.

When data needs to be moved between asynchronous clock domains, a proper clock domain crossing circuit (CDCC) is required. The type of CDCC depends on the width of the data, the amount of the data being moved between domains, the coding of the data (if it is a bus) and a number of other things.

One aspect of a CDCC is a timing exception on the paths between the clocks. This can be a set_false_path, or set_max_delay -datapath_only depending on the type of CDCC and the system requirements.

But there is no "one size fits all" CDCC - you need to figure out what paths are crossing between the domains, determining if they are supposed to be there, determine the characteristics of the data crossing the domain, and then implement the appropriate CDCC along with its exceptions.

Some may advise you to simply do a "set_clock_groups -asynchronous" constraint between the domains. This will disable all timing analysis between the domains and hence make the violations disappear, but will (usually) not result in a working (or reliable) system when downloaded to the FPGA.

Avrum

0 Kudos