AnsweredAssumed Answered

AD9122 + AD9643 reference design timing violation in Vivado

Question asked by oppradhan on Apr 12, 2017
Latest reply on Apr 13, 2017 by larsc

CsomIlarsc rejeesh

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)

 

Max Periodn/aIDELAYCTRL/REFCLKn/a5.2610.00-4.74IDELAYCTRL_X1Y1i_system_wrapper/system_i/axi_ad9643/inst/i_if/i_adc_or/i_delay_ctrl/REFCLK
Max Periodn/aIDELAYCTRL/REFCLKn/a5.2610.00-4.74IDELAYCTRL_X1Y2i_system_wrapper/system_i/axi_ad9643/inst/i_if/i_adc_or/i_delay_ctrl_REPLICATED_0/REFCLK

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.

 

 

Questions:

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?  

 

Update 1:

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

from /ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg

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

 

2. Then:

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

 

 

Header 1
NameSlackLevelsHigh FanoutFromToTotal DelayLogic DelayNet DelayRequirementSource ClockDestination ClockException
Path 41-0.2258i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg[1]_replica/Ci_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB[5]4.301.362.945.00clk_fpga_1clk_fpga_1 
Path 42-0.1958i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg[1]_replica/Ci_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB[3]4.271.362.915.00clk_fpga_1clk_fpga_1 
Path 43-0.1458i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg[1]_replica/Ci_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB[4]4.221.362.855.00clk_fpga_1clk_fpga_1 
Path 44-0.1158i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg[1]_replica/Ci_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB[6]4.191.362.835.00clk_fpga_1clk_fpga_1 
Path 45-0.1158i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg[1]_replica/Ci_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB[1]4.191.362.835.00clk_fpga_1clk_fpga_1 
Path 46-0.1058i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/i_dest_dma_mm/i_data_mover/id_reg[1]_replica/Ci_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB[2]4.181.362.815.00clk_fpga_1clk_fpga_1 
2.2 CLK0 as source and CLK1 as destination clock
Header 1
NameSlackLevelsHigh FanoutFromToTotal DelayLogic DelayNet DelayRequirementSource ClockDestination ClockException
Path 99-0.2058i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/eot_mem_reg[7]/Ci_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB[5]4.471.433.045.00clk_fpga_0clk_fpga_1MaxDelay Path 5.000ns -datapath_only
Path 100-0.1758i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/eot_mem_reg[7]/Ci_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB[3]4.441.433.015.00clk_fpga_0clk_fpga_1MaxDelay Path 5.000ns -datapath_only
Path 101-0.1158i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/eot_mem_reg[7]/Ci_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB[4]4.391.432.955.00clk_fpga_0clk_fpga_1MaxDelay Path 5.000ns -datapath_only
Path 102-0.0958i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/eot_mem_reg[7]/Ci_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB[6]4.361.432.935.00clk_fpga_0clk_fpga_1MaxDelay Path 5.000ns -datapath_only
Path 103-0.0858i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/eot_mem_reg[7]/Ci_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB[1]4.361.432.925.00clk_fpga_0clk_fpga_1MaxDelay Path 5.000ns -datapath_only
Path 104-0.0758i_system_wrapper/system_i/axi_ad9643_dma/inst/i_request_arb/eot_mem_reg[7]/Ci_system_wrapper/system_i/sys_ps7/inst/PS7_i/SAXIHP0WSTRB[2]4.351.432.915.00clk_fpga_0clk_fpga_1MaxDelay Path 5.000ns -datapath_only
Clearly this means the dmac constraint that sets these path delays as the fifo_wr_clk seems to be failing but only for the ad9643 dmac. Any thoughts on why this might be?
3. Once again using the 2016_r2 branch  I explored the routing and placement that Vivado was doing for the above implementation and tried to place the ad9643 dmac closer to the PS-PL boundary and this improved the setup slack considerably, even though the worst negative slack (WNS) was still negative so design still did not meet timing requirements. So now the WNS is -0.044 for the same paths as listed above. 
However I had to save the floorplanning derived constraints in a seperate .XDC include this with the list of constraints in the tcl system.tcl and then re-run the script (through the makefile). This was the only way to ensure that the final implementation was able to account for all the individual IP constraints.
I can't floor plan the problematic dmac core any more and so the only way to get the design to pass timing seems to be to modify the dmac *.XDC file, isn't this so?
Anyway so the timing failure for me atleast is irrespective of whether I run all the way from a script or modify in Vivado gui (for the dev branch). 

Outcomes