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!

Showing results for 
Search instead for 
Did you mean: 
Registered: ‎06-28-2008

HLS IP in top design ---- timing closure not met

Hello, everybody.

vivado 2015.4, vivado HLS 2015.4.

virtex7, 485t.


I wrote my code with vivado HLS  and packaged it to an HLS IP.

The timing report showed that it meets the timing requirement.

However, when I instantiated the HLS IP in my top design with vivado.

The timing summary showed that there are negative slack in the HLS IP----


slack:  -6.804ns
source: my_ram_interface/my_hls_ip/inst/xxx_matrix_multiply_add_tree_fu_686/exitiond2_reg_1271_reg[0]/C
destination: my_ram_interface/my_hls_ip/inst/s_din_3_im_U/xxx_s_din_0_re_ram_U/ram_reg_6/REGCEAREGCE
path group: clk_out2_clk_wiz_0
path type: setup(max at slow process corner)
requirement: 8.000ns(clk_out2_clk_wiz_0 rise@8.000ns - clk_out2_clk_wiz_0 rise@0.000ns)
data path delay: 14.461ns (logic 0.302ns (2.088%) route 14.159ns (97.912%)
logic Levels: 1 (LUT2=1)
clock path skew: -0.016ns
clock uncertainty: 0.085ns

source clock path
data path
destination clock path



1)  The data path delay is mainly route delay.

2) The negative slack is in the  IP


By the way, the clock frequency of the HLS IP is 125MHz, not very high.

( I decreased the clock frequency but still got negative slack)


In addition, my top design uses many BRAM resources with the ratio of 78% which may affect

the place and route result.


I really do NOT know how to solve the problem.

Please help me.

0 Kudos
3 Replies
Teacher muzaffer
Registered: ‎03-31-2012

Re: HLS IP in top design ---- timing closure not met

it seems the placement of the bram relative to your logic is the problem. What implementation strategy are you using?
One option might be to create a pblock for your HLS IP and include the bram and all the logic into it.

Another thing to check is the fanout of the signal which controls the CE pin of the BRAM. You can try to put a max fanout constraint on it to try to get replicated or do a physical optimization after routing to do the same if you are using a recent version of Vivado.

- Please mark the Answer as "Accept as solution" if information provided is helpful.
Give Kudos to a post which you think is helpful and reply oriented.
0 Kudos
Scholar jprice
Registered: ‎01-28-2014

Re: HLS IP in top design ---- timing closure not met

You said it yourself, you're using 78% of the BRAM in the part. My guess is you have an enormous memory somewhere. I'd look into that. 

0 Kudos
Scholar u4223374
Registered: ‎04-26-2015

Re: HLS IP in top design ---- timing closure not met

@jprice That would make sense. A single very large array accessed from one location, so Vivado has had to spread block RAMs through the whole chip but the logic accessing those block RAMs is all in one place.


I've had designs that used over 95% of both block RAM and DSPs before (and passed timing at 100MHz on the first attempt) but those were a result of having lots of small modules - so each module (logic, BRAM, DSPs) could be in one region.

0 Kudos