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: 
Explorer
Explorer
767 Views
Registered: ‎02-08-2018

Failed timing after Vivado HLS block is added to the design

Jump to solution

Vivado implementation shows failed timing in my design when I add this Vivado HLS block, which is an image filtering block.  The Vivado HLS block meets timing requirements in Vivado HLS synthesis. However, when I use a different Vivado HLS image processing block, I do not get the failed timing.  I believe the reason could be that this other image processing block uses much less computation (it only converts a color image to grayscale) and so it uses close to 0% of the resources.  The image filtering block that leads to failed timing uses much more resources, which includes 37% of BRAM, 16% of LUT and 4% FF.

The failed timing is only in implementation setup, and seems to only take place at the MMCM that sends signals to the image filtering Vivado HLS block. Below are the statistics on the failed timing for implementation setup:

*****************************************

Worst Negative Slack = -0.579

Total Negative Slack = -6.856 ns

# Failing endpoints = 37 out of a total of 159600

*****************************************

I used the following command for timing constraints:

set_property CLOCK_DEDICATED_ROUTE BACKBONE [get_nets sys_clk_p]

The Microblaze operates at 200 MHz, but the Vivado HLS block operates at 100 MHz, so I use an additional clock in the Microblaze.  Now I am looking into the set_clock_groups command

Any suggestions?

0 Kudos
1 Solution

Accepted Solutions
Explorer
Explorer
560 Views
Registered: ‎02-08-2018

Re: Failed timing after Vivado HLS block is added to the design

Jump to solution

I got rid of the timing error by returning to the Vivado HLS program and reducing the input image size from 640X480 to 320X240.  This change reduced the memory usage by the Vivado HLS block to 9% for BRAM_18k, 3% for DSP48E, 4% for FF and 16% for LUT.  The timing per clock cycle was still 8.75 ns +/- 1.25 ns, with a target time of 10 ns. 

In addition, I reconstructed the Microblaze block diagram from scratch using guidelines from https://lancesimms.com/Xilinx/VC707_Microblaze_UART_to_LED_Example_Part3.html

When the new RTL was exported and placed into the reconstructed Microblaze block diagram, there were no more timing errors.  I am not sure if this is because the modified Vivado HLS block occupied less memory space or because of the reduced timing-related warnings in the Microblaze design.

4 Replies
Teacher xilinxacct
Teacher
759 Views
Registered: ‎10-23-2018

Re: Failed timing after Vivado HLS block is added to the design

Jump to solution

Had you already applied any timing constraint on design with the old IP block in place? If so, you may want to try removing the old constraints and let the synthesizer get a fresh view of the world.

Additionally, more resources can take an impact on being able to successfully route. That can be compounded when a design is highly dense (meaning using most of the resources available). Some otherwise valid designs will not meet timing in a crowded environment.

0 Kudos
Explorer
Explorer
737 Views
Registered: ‎02-08-2018

Re: Failed timing after Vivado HLS block is added to the design

Jump to solution

@xilinxacct

I did remove the two timing constraints, and while there is still failed timing, BUT the degree of negative slack has decreased as well as the number of failing endpoints.  Below are the new statistics:

Worst Negative Slack = -0.041 ns

Total Negative Slack = -0.041 ns

# Failing endpoints = 1 out of 152637

I tried adding PACKAGE_PIN constraints to sys_clk_p and sys_clk_n, but this constraint did not make much difference.

The Vivado HLS block does not seem to take up that much resources.  Below is an image of overall resource consumption, and the MMCM path that fails:

temp.png

0 Kudos
Teacher xilinxacct
Teacher
730 Views
Registered: ‎10-23-2018

Re: Failed timing after Vivado HLS block is added to the design

Jump to solution

@agailey

Glad to hear that improved the situation... And it looks like you are almost there... If you haven't already, now strategically add a constraint on the critical path... I find it helpful to not be greedy and ask for the entire amount of the slack... just ask for a ns better than what it is. That sometimes resolves everything (and gives you more than what you asked for).

0 Kudos
Explorer
Explorer
561 Views
Registered: ‎02-08-2018

Re: Failed timing after Vivado HLS block is added to the design

Jump to solution

I got rid of the timing error by returning to the Vivado HLS program and reducing the input image size from 640X480 to 320X240.  This change reduced the memory usage by the Vivado HLS block to 9% for BRAM_18k, 3% for DSP48E, 4% for FF and 16% for LUT.  The timing per clock cycle was still 8.75 ns +/- 1.25 ns, with a target time of 10 ns. 

In addition, I reconstructed the Microblaze block diagram from scratch using guidelines from https://lancesimms.com/Xilinx/VC707_Microblaze_UART_to_LED_Example_Part3.html

When the new RTL was exported and placed into the reconstructed Microblaze block diagram, there were no more timing errors.  I am not sure if this is because the modified Vivado HLS block occupied less memory space or because of the reduced timing-related warnings in the Microblaze design.