I read the only relevant question on this topic here and the issue seems to be unresolved. I did post on that thread the exact same comment as well.
I am noticing a have a very similar problem to the above linked question with only slightly different target device, and am sharing the specific failure. Just thought I'd provide a few more data points and analyses so you can perhaps advise on a fix/ work-around?
Tool: Vivado 2016.4
hdl branch: 2016_r2
h/w target: Zynq (zedboard) + FMCOMMS1
I simply copied the FMCOMMS1 files from the master branch and used all the newer files(2016_r2) for the IP library build(is this alright to do?)
I instantitate only a subset of HDL fmcomms1 reference design: ad9122 (dac core and dmac), ad9643(adc core and dmac) and the associated cpack,upack and write fifo and the IIC going to the FMC header. My design requires only these IP blocks
Clocks: CLK0: 50 MHz and CLK1: 100 MHz. I reduced these clocks from 100 and 200MHz as I was attempting to correct those timing violations and the analysis I am including here is with the lower 50 and 100 MHz clocks.
Some background info: Implementing the reference design with ONLY the ad9122 signal chain IPs throws up NO violations, which is consistent with your statement that when multiple IPs are using the same constraint file Vivado seems to be doing something funky.
However I have noticed that even without the dmac workaround that you mentioned, using 2 dmac IPs (1 for ad9122 and another for ad9643) , their own timing constraints (located in the IP home directories) seem to be preserved. One can confirm this in the 'timing_constraints' window in Vivado post synth or implementation.
Problems and analysis:
Synthesis: Vivado DRC check post synthesis, tells me that I should buffer the CLK1 (100 MHz from zynq PS) using a utility buffer before it is sent to the 'delay_clk' pin of the ad9643.
So I did this and the worst neg. slack for the pulse width reduced but was still negative even in this static timing analysis post-synthesis.
Implementation: So after adding a utility_buffer between the FCLK1 from PS and the 'delay_clk' pin of ad9643 I still went ahead and ran the implementation.
Implementation threw up setup, hold and pulse width timing violations. So I investigated this further to find that some direct signals in the ad9122 core were taking unusually long routes. So I pblock-ed the ad9122 core with an empty location on the fpga floor and this solved the set up and hold timing violations.
However the pulse width violation is quite persistent and is only found to occur with the ad9643 core and the violating cells are tabulated below from my timing log. (this is for CLK1 of 100 MHz). For a higher clock the negative slack is still present (didn't save the numbers on that one but can run my design again to do this)
Note: this timing log is AFTER I buffered the CLK1 into the ad9643 delay clock.
Now when I look for ad9643 timing constraints there are none to be found even though I can see that the IP should have been created with the constraints from the ad_ip_constraints.XDC
The dmac constraints for both instances seem to have been preserved.
1. Can you elaborate on why exactly the ad_ip_constraints are setting all those paths to false for the DAC and ADC cores?
2. Also there don't seem to be any input/output delays associated with the reference design builds. Won't this cause the placement tool to place the interface IP cores for the dac and adc possibly far from the I/O pads of the fabric?
Rejeesh suggested using the dev branch, can i still do this for fmcomms1?
If i run the scripts as is, by only commenting out the unnecessary IP and connections and PS configurations and leaving everything else the same I observe the following:
Global generate (generate targets for global) run: -0.429 ns of worst negative slack (WNS) in the setup path
to the PS7 wstrb High performance AXI slave port.
I then attempted to manually floorplan the 9643 IP block chain to an empty part on the fabric to see if this works, I then forced the synthesis to update but re-ran implementation from the Vivado gui. But the route design took for ever and ended up worsening and adding setup and hold slack violations in multiple other routes.
Now it's worst negative setup (WNS) of -8.101 ns and is in other paths connecting internal ad9122 modules. sigh.. quite frustrating.
- I suspect it's dropped the IP constraints again and hence fails, because after floor planning I synth+implement from the Vivado gui.
I do not remember this being a problem at all when compiling from the 2014_r1 branch on VIvado 2014.2
OOC generated targets: This leads to the dmac *.XDC constraints not being read correctly and similar timing violations to the above gui implemented design
Using the dev branch: This seems to fix the problem of dropped constraints and clearly seems to have to do with the IP tcl now including constraints for all separate submodules in the file list? Now I can edit in Vivado GUI and the constraints are still preserved (haven't explored this extensively but the couple of runs I did, I think it works)
Update 2: I attempted a few iterations
1. The most recent iteration was:
branch hdl_2016_r2 (Using IP libraries from this branch but the fmcomms1 project from the master branch), using the Makefile and reducing CLK0 and CLK1 frequency to 50 and 100 MHz (i.e. Half of that in the reference design.). I did not make any other change and was able to meet timing after implementation
Same as above but with CLK0 and CLK1 frequency left at the default 100 and 200 MHz (CLK0 and CLK1 respectively). This time the timing requirements failed for both branches (2016_r2 and dev) for the following paths
2.1 CLK1 as source and destination clock
|Name||Slack||Levels||High Fanout||From||To||Total Delay||Logic Delay||Net Delay||Requirement||Source Clock||Destination Clock||Exception|
|Path 41||-0.22||5||8||i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg_replica/C||i_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB||4.30||1.36||2.94||5.00||clk_fpga_1||clk_fpga_1|| |
|Path 42||-0.19||5||8||i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg_replica/C||i_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB||4.27||1.36||2.91||5.00||clk_fpga_1||clk_fpga_1|| |
|Path 43||-0.14||5||8||i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg_replica/C||i_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB||4.22||1.36||2.85||5.00||clk_fpga_1||clk_fpga_1|| |
|Path 44||-0.11||5||8||i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg_replica/C||i_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB||4.19||1.36||2.83||5.00||clk_fpga_1||clk_fpga_1|| |
|Path 45||-0.11||5||8||i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg_replica/C||i_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB||4.19||1.36||2.83||5.00||clk_fpga_1||clk_fpga_1|| |
|Path 46||-0.10||5||8||i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg_replica/C||i_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB||4.18||1.36||2.81||5.00||clk_fpga_1||clk_fpga_1|| |