On Terasic DE10-Nano I've created an OpenCL BSP based on one originally modified from de10_nano_sharedonly. It works fine for programs like hello_world, 'aocl diagnose'. However, for vector_add, it runs successfully for only ONCE. The 2nd call to vector_add will hang on clWaitForEvents().
Using clGetEventInfo() I found that the status of a command sent to command queue by clEnqueueReadBuffer() freezes on CL_QUEUED and never changes. On contract, in the first call to vector_add, that status will become CL_COMPLETE immediately.
I'm wondering if there is any way I can debug why this command queue is stalled? For example, maybe I can probe some signal/bus inside the circuit, or call some API to know the status of the command queue?
OK. In the attached vector_add.tgz you can find
- the opencl kernel source: vector_add/device/vecor_add.cl
- the host application source: vector_add/host/src/main.cpp
I got them as part of the OpenCL BSP of DE10-Nano from Terasic.
I guess its original source is the v17.1 Arm32 Linux package (.tar.gz) from:
Please kindly understand that you won't duplicate this symptom on the official DE10-Nano OpenCL BSP from Terasic.
It only happens on the BSP I created.
Anyway, as I said in my original post, the symptom is: the host application will stop on the call to clWaitForEvents() (Line 361) in the second run of this host application.
My OpenCL BSP is based on this one: https://github.com/thinkoco/c5soc_opencl, which is originally modified from de10_nano_sharedonly from Terasic.
I modified the Quartus project, the u-boot spl, u-boot, kernel, etc to enable 1920*1080 HDMI output.
Yes, I know how to use SignalTap. Any signal/bus inside the circuit you could kindly suggest me to probe?
Actually I've contacted the author of c5soc_opencl for this issue, but he has no idea about how to debug this issue, even he had solved many of my issues before.
OK, I'll try to debug in the way you suggest.
Thanks for your kind help. I wish you a wonderful day!