Max achievable frequency in HLS code

Question

I am looking for the maximum frequency (smallest clock period) at which I could run the test code that I attach, targetted for Zynq (ZC702). It is the design of a very simple IP block with hls::stream input and output , with an s_axilite control.
It simply computes two multiplications and the expf function, all in single-precision floating point and inside a pipelined for loop with an initiation interval II=1.
1) If the solution is set with a clock period of 10.0ns, then synthesis and implementation (export) will meet the timing (I am using Vivado HLS 2014.3). But if I lower it to 5.0ns (as an example), then synthesis expects 4.36ns (uncertainty 0.62ns), but implementation will report 6.011ns and fail. (I am aware that synthesis only estimates the timing).
2) I have also read the post in the HLS forum regarding "registered stages" and the suggestion of trying "reg(...)" available in #include <hls/utils/x_hls_utils.h>. If I apply this idea, then synthesis estimates 5.29ns (uncertainty 0.62ns), but implementation reports 5.681ns.
2a) If I only compute the reg( expf (...) );  inside the for loop, then implementation will just achieve 4.990 ns.
Based on this behaviour, I cannot find a procedure to find out the minimum clock period (max clock frequency) at which the IP block will work. (I cannot keep running implementation (RTL export) for every idea I come up with)
QUESTION 1: Could you please provide guidance on this regard?
QUESTION 2: just because the depth of the pipelined for loop increases should not mean that the minimum clock period increases, am I right? (I would expect the tool to automatically register intermediate results accordingly in order to achieve the targetted clock period). Is there an alternative to reg(...), or any other approach I could follow?
Thanks in advance,
Javier
 

Answer 1

hello
In your code if you think that the FSM is the issue, then you should remove the for loop!
I'm not joking.. when you remove it, then your IP will have an II of 1 and a latency N; but from your integration perspective, this is almost the same: you still need AXIS IPs to push data to the VHLS IP.
The fact that your VHLS IP read an unknown number of samples and then stops and has to be restarted in SW doesn't help you. It's a bit of overhead actually.
If you remove the loop you should find that it goes faster.
Last point, I don't know what is the F max achievable in the ZC702 's programmable logic but I think that 200 MHz should already be plenty!?
What is the rest of the design going?