AR# 67332


LogiCORE DisplayPort v7.0 (Rev. 1) - If the same clock is connnected for the axi_clk and vid_clk, a lot of unconstrained paths appear under the intra clock timing report for paths outside of the DisplayPort IP which are driven by this clock


I am using a common clock for the axi_clk and the vid_clk, which is also used to drive the logic outside of the DisplayPort IP.

A large number of unconstrained paths appear under the intra clock timing report for this common clock.


Sharing the axi_clk and vid_clk (the clock for native video interface) is not a proper use case, because the video clock will change on the fly for resolution changes.

The recommended usage is to use a 25 to 135 Mhz clock for AXI interface and a 150Mhz or higher frequency clock to the RX video clock. 

The DisplayPort RX IP always considers the axi_clk and vid_clk to be unrelated clocks. 

The following max_delay constraints will be generated in the _clocks.xdc file. 

They are used for crossing clocking domains between the axi_clk and the vid_clk.

set_max_delay -datapath_only 40 -from [ get_clocks -of_objects [get_ports s_axi_aclk] ] -to  $rd_vid_clock set_max_delay -datapath_only 40 -from $rd_vid_clock -to  [ get_clocks -of_objects [get_ports s_axi_aclk] 

If you have a common clock for both the axi_clk and the vid_clk, the period constraint for this common clock is over written by the max_delay constraint inside the core. 

All of the paths driven by this common clock are considered as false paths, and as a result they are reported as unconstraint paths in the timing report.

If the design is short of clocking resource, you can work around the problem by commenting out the set_max_delay manually.

This is beyond the scope of Xilinx Support. It is the user's own responsibility to validate the functionality of such use cases.

AR# 67332
日期 04/30/2018
状态 Archive
Type 综合文章
People Also Viewed