04-16-2017 09:03 AM
I am working with Vivado 2016.4 and I have a project with many IPs developed with HLS. Hardware target is Zynq 7020.
My project has an utilization of 55% LUT and 38% FF, but doesn't meet time requirements. FPGA fabric clock that I use in my IP is 100 MHz.
I already read
I am surprised to have similar issue with a device utiliztion near 50%.
Can anyone suggest me anything?
04-16-2017 02:22 PM
@begos where does timing fail? within HLS or after implementation in Vivado ? If former, especially only after synthesis, I'd say do an implementation phase and see what that says (ie export IP with implementation test). If it's latter, than the question becomes, by how much the timing is missed. If it's < 5%, you can probably fix it with a different implementation strategy. If it is > 20%, then you have to go back to HLS and constrain it more tightly and/or understand why it's generating such bad code.
04-17-2017 08:06 AM
thank you for your answer.
Timing is failing during implementation phase, in setup path requirements. Slack is near 5%, plus or minus depending by single path, how you can see in attached file.
filter_lp is an IP generated with HLS (where target clock period is 8 ns, but how you have said it is not relevant...), and there is too much delay in path. Delay is balanced about logic and net delay. dbg_2_mem_32_ch instead is an IP written in VHDL without HLS. Clock is 100 MHz.
Slack is near 5%, and probably I can choose a different strategy for implementation, but I think that the main issue is that HLS is generating "bad code" without pragma or constraints to respect basic timing requirements. In my project the only time requirements is FPGA fabric clock, that is clocking every state machine. Then I need to go in deep of understanding how HDL tool is working.
I have already anlyzed generated code and I have seen that architecture of state machine generated is not simple.
05-02-2017 10:57 AM
for clarity I have analyzed in deep my issue, and failure of time constraint is in paths between IP blocks, not inside HLS IP. Analyzing path I have seen that there is too much combinatorial logic (carry and lut blocks) in cascade, then is normal that setup time is failing. I solved the problem by inserting a flip flop.
The reason because my HLS IP blocks have four or five combinatorial blocks in cascade at the signal output is a question that need to be investigated. Probably I need to modify my C coding style to mitigate use of carry and lut logic.