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: 
Highlighted
Visitor rickyalbert
Visitor
11,033 Views
Registered: ‎02-15-2016

Vivado HLS and timing requirements in Vivado

Jump to solution

Hi everybody, I have synthesized in Vivado HLS a module that uses a lot of resources and after a lot of work I have managed to make it meet a timing requirement of 10 ns with II = 4.

After the implementation in Vivado I found out that the timing requirements are not met and there are some critical paths that need 12/13 ns. I have also tried to use a simplified version of my module and try different frequencies but I'm not able to fulfill the requirements in Vivado implementation.

 

Do you know why a fully synthesized module in HLS causes these kind of errors in Vivado? How can I solve this problem?

 

Thank you very much

Riccardo

0 Kudos
1 Solution

Accepted Solutions
Scholar jprice
Scholar
20,260 Views
Registered: ‎01-28-2014

Re: Vivado HLS and timing requirements in Vivado

Jump to solution

In general I've found the Synthsis estimates of HLS should be ignored both for timing and resource utilization, they are next to meaningless. I've seen it predict claim reasonable timing closure when in reality it can't even come close. I've also seen the opposite where it claims it can't possibly make timing but easily does. Resources estimates in Synthesis tend to be wildly incorrect for designs of any sufficent complexity. However the real problem is that HLS is absolutely awful at control logic, it produces large unwieldy state machines. They do way to much work in a single clock cycle regardless of target clock frequency. For example if you have a conditional with an adds and comparisons on multiple 64 bit quantities it will do all comparisons and the add in a single cycle. This will drive some enormous state machine for whatever function called it. I have to intentionally force registers on these comparisons in order for this not to happen. Worse the state machines of each function don't have register isolation from one another so you can end up with some of the FSM control having both dozens of levels of logic and ridiclously high fanout. The clock enables are the biggest problem, they are derived from multiple levels of FSM logic before driving some fixed site primitives like block RAMs and DSP48s. You can use the latency option on the resource directive to pipeline the address, data, etc. but it won't do anything for the clock enable. Reducing the usage of those resources if possible can help make timing for that reason. Unfortunately you need to have a solid understanding of timing closure in FPGAs and the HDL HLS produces. This will allow you to work around timing issues. I recognize the goal is to not have to worry about those issues as much but ithe tool is just not there yet. I also run the Explore directive with both place and route, and AggressiveExplore on phys_opt multiple times post place. This may be enough to help you acheieve timing.  Xilinx is aware of these issues though and will hopefully be addressing them in the near future.

0 Kudos
9 Replies
Teacher muzaffer
Teacher
10,988 Views
Registered: ‎03-31-2012

Re: Vivado HLS and timing requirements in Vivado

Jump to solution
I am starting to think it's because HLS is broken. It generates faulty code which doesn't pass cosim, the generated RTL fails timing by a significantly large margin than what's estimated. I think Xilinx should put a lot more resources in getting HLS to be a robust tool.
- 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.
Scholar u4223374
Scholar
10,958 Views
Registered: ‎04-26-2015

Re: Vivado HLS and timing requirements in Vivado

Jump to solution

HLS definitely does do some odd things with timing. I've got a design which won't manage 10ns in HLS 2015.4. If I put a latency pragma at a critical point then I can get it under 10ns. If I build the design in HLS 2015.2 (with no pragma) it gets under 10ns (and works fine, results are bit-for-bit identical). If I tell HLS 2015.4 that actually I want 5ns (again with no pragma), then it manages about 7ns, although this does use far more hardware.

 

It'd be sort of nice if HLS could actually go through the whole synthesis-implementation-place-route process and tell you whether or not that block can pass timing on the selected FPGA. It's no guarantee (obviously if your other blocks occupy a lot of resources then when you add the HLS block to those it might fail timing) but it'd be a definite bonus.

Visitor rickyalbert
Visitor
10,945 Views
Registered: ‎02-15-2016

Re: Vivado HLS and timing requirements in Vivado

Jump to solution

I have been able to synthesize my IP increasing the clock uncertainty from 12.5% to 35% and the use of resources is not changed. I don't know if this is the smartest thing to do, but I've made quite a frustrating research to find a correct clock uncertainty that brings to an implementable IP in Vivado.

0 Kudos
Teacher muzaffer
Teacher
10,942 Views
Registered: ‎03-31-2012

Re: Vivado HLS and timing requirements in Vivado

Jump to solution

@u4223374 actually you can use the -evaluate option of export_design to do get hls to run p&r and tell you timing/area.

- 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 u4223374
Scholar
10,939 Views
Registered: ‎04-26-2015

Re: Vivado HLS and timing requirements in Vivado

Jump to solution

@muzaffer

 

Good to know. I must not have paid enough attention to the text; I thought that the "evaluate" option just ran it through synthesis (not implementation and P&R). Every time I've ticked that box I've ended up with significantly nicer numbers than HLS gives after its normal (high-level) synthesis - lower resource utilisation, higher clock speed.

0 Kudos
Scholar jprice
Scholar
20,261 Views
Registered: ‎01-28-2014

Re: Vivado HLS and timing requirements in Vivado

Jump to solution

In general I've found the Synthsis estimates of HLS should be ignored both for timing and resource utilization, they are next to meaningless. I've seen it predict claim reasonable timing closure when in reality it can't even come close. I've also seen the opposite where it claims it can't possibly make timing but easily does. Resources estimates in Synthesis tend to be wildly incorrect for designs of any sufficent complexity. However the real problem is that HLS is absolutely awful at control logic, it produces large unwieldy state machines. They do way to much work in a single clock cycle regardless of target clock frequency. For example if you have a conditional with an adds and comparisons on multiple 64 bit quantities it will do all comparisons and the add in a single cycle. This will drive some enormous state machine for whatever function called it. I have to intentionally force registers on these comparisons in order for this not to happen. Worse the state machines of each function don't have register isolation from one another so you can end up with some of the FSM control having both dozens of levels of logic and ridiclously high fanout. The clock enables are the biggest problem, they are derived from multiple levels of FSM logic before driving some fixed site primitives like block RAMs and DSP48s. You can use the latency option on the resource directive to pipeline the address, data, etc. but it won't do anything for the clock enable. Reducing the usage of those resources if possible can help make timing for that reason. Unfortunately you need to have a solid understanding of timing closure in FPGAs and the HDL HLS produces. This will allow you to work around timing issues. I recognize the goal is to not have to worry about those issues as much but ithe tool is just not there yet. I also run the Explore directive with both place and route, and AggressiveExplore on phys_opt multiple times post place. This may be enough to help you acheieve timing.  Xilinx is aware of these issues though and will hopefully be addressing them in the near future.

0 Kudos
Teacher muzaffer
Teacher
10,856 Views
Registered: ‎03-31-2012

Re: Vivado HLS and timing requirements in Vivado

Jump to solution

For me it would be a  good start if they produced working code ie. if cosim terminated with passing results. Most of my designs either have non-terminating cosim or the cosim fails to match csim results. I wish I knew what I am doing wronng.

 

- 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
Scholar
10,844 Views
Registered: ‎01-28-2014

Re: Vivado HLS and timing requirements in Vivado

Jump to solution

That's a fair complaint as well. Sadly there's no way to actually do a C Testbench for most of my designs since they communicate to external interfaces. For example reading from an ap_vld interface, there's no meaningful way to provide it data. As a result I always just build my own VHDL testbench and use global values from the HLS code to produce "debug ports" to debug the C. Certain isolated functions that don't communicate externally I still test in a C Testbench but I've never had much use for the cosim feature.

0 Kudos
Teacher muzaffer
Teacher
10,835 Views
Registered: ‎03-31-2012

Re: Vivado HLS and timing requirements in Vivado

Jump to solution
luckily I am working with axi stream and axi master interfaces (ie camera outputs and ddr read/writes) so I can still use cosim. If it weren't for cosim promise I am not sure if Xilinx would ever support me. It would be always the testbench which is at fault.
- 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