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.