01-18-2018 09:15 AM
Hello,
I've developed a small HLS module that is doing a simple math computation. Basically it has an accumulator and an output that is the accumulator division by another number. Both input and output are AXI-S interfaces. An ap_ctrl interface is created (inferred) and I can successfully start it, send data, read output and wait for ap_done and start the process all over again.
My problem is if I increase the frequency of operations (i.e. setting ap_start, send data, read output, wait for ap_done), the HLS module stalls.... not rising ap_done anymore. I took care of that the number of operations per second (frequency of operations) doesn't violate the estimated module max latency (37 clock cycles) and max interval (38 clock cycles).
So, I'm about to test resetting the entire module when it hangs. My question is: how many clock cycles ap_rst_n should be asserted to completely propagate reset in the HLS module? Is there a minimum clock cycles? Or is there any way to discover this number?
regards
01-23-2018 11:15 AM
I got the problem fixed by creating an 'command' port that, as a predefined 'command' is written to, clears all internal variables. So the core itself isn't being reset (by asserting ap_rst_n), but internal registers are being cleared.
01-18-2018 10:59 AM
@brasilino Each HLS component is synthesized for a given frequency, Which is set in Solution Settings/ Synthesis/ Period . If You increase your design frequency in Vivado without adjusting in HLS again you will have a timing violation.
01-19-2018 01:50 AM
thanks for your reply. Maybe I wasn't clear, but the frequency of operations I mentioned isn't the clock frequency, but the number of operations done by the HLS module in a given time.
An operation, in this context, would be setting ap_start, send data, read output, wait for ap_done (written in parenthesis in my previous post). Each operation takes many hundred of clock cycles to complete.
But, anyway, the problem is that after around 250 operations the module stalls, not rising ap_done anymore.
regards
01-23-2018 11:15 AM
I got the problem fixed by creating an 'command' port that, as a predefined 'command' is written to, clears all internal variables. So the core itself isn't being reset (by asserting ap_rst_n), but internal registers are being cleared.
01-23-2018 11:32 AM
01-23-2018 11:41 AM
Yes... pretty easy. Create a 'cmd' (command) input port that when a certain "opcode" is written to it, you
zero all internal (static) variables on your design. It worked for me.