--- Quote Start ---
Yes, I did something similar. I inserted an END_OF_FLAG in the data stream. So I can use the END_OF_FLAG to decide if it is end of the processing.
It works when the array size is small. it stalls when the array size is larger than a number around 300000~40000 on both simulation and implementation.
I will double check today and post the code next time. Maybe I missed something critical.
--- Quote End ---
Did you use blocking channel operations or non-blocking? If it was blocking, the behavior is expected since channels have a specific depth and hence, even if you are reading less than you are writing, your program will execute correctly for small streams, but will eventually deadlock for large ones. Since you are also observing the deadlock in simulation, you certainly have a balancing problem; i.e. you are reading less or more than you are writing to the same channel. This will not be hard to debug in the emulator by counting the amount of data that is read or written. This should not happen with a correctly-implemented design using non-blocking channels.
--- Quote Start ---
By the way, are you referring to the basic examples in this link?
https://www.altera.com/products/design-software/embedded-software-developers/opencl/developer-zone.html --- Quote End ---
No, I was talking about the Intel FPGA SDK for OpenCL Programming Guide. You can find some basic code examples in Sections 5.4.5.2.1 and 5.4.5.3.1 for non-blocking channel operations. I don't think any of Altera's OpenCL example designs use non-blocking channels.
Honored Contributor
