Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
11 years ago

Mixing OpenCL kernel with VHDL Netlists

Hi,

Is it possible for the output of an OpenCL kernel to reside in the same FPGA as a VHDL netlist? For example, could I implement an algorithm in OpenCL and a display driver in VHDL? The intention here is to display the output from a parallel algorithm, locally, using a VGA driver implemented on the FPGA fabric not used by the OpenCL kernel.

14 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Hi,

    I have a related question. Is it possible to have a channel communicate with OpenCL directly. What i am looking at is to have a channel defined in the BSP which i can write to from a C/C++ host application and have the OpenCL kernel read from the channel as an I/O channel. It seems related to what popoolab wanted to do, but the difference is that i want the host-program to talk via a channel instead of a Verilog component.

    Any pointers would be appreciated.

    Thanks!
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    If you maintained the communication between the channel and the host outside of the OpenCL infrastructure that should be possible. As long as the channel is exposed in the BSP as a Avalon-ST interface then the kernel should be able to communicate with it but that means it's up to you to take care of the other side of the channel yourself. This could get very messy though if that side band information needs to stay synchronized with kernel invocations so before going too far down that road I would try to determine if you really need to do this.

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    Thanks BadOmen. The problem that i am trying to solve is to have some high-bandwidth/low-latency communication between the CPU (C++) and the FPGA (OpenCL) on a SoC. What would you recommend as the best approach to the solution. Currently, i copy the data in a circular buffer as well as the endpoints (start/end) to SDRAM, and have the CPU poll over the endpoints to check for data produced by the FPGA. This, as expected is quite slow. I have two approaches in mind to speed it up -

    1) Relying on physical addresses mapped in the FPGA-2-HPS and HPS-2-FPGA bridges. I am not sure if there is a region of the physical address space that is mapped to a buffer that i can use for data exchange. As far as i have read, there are specific addresses for IO devices, but nothing for data exchange.

    2) Relying on the coherency mechanism (ACP) to communicate the endpoints and use the SDRam for communicating the actual data.

    As you might have guessed, i don't have much experience in FPGAs, so any help will be appreciated. I am looking for something that works well with relatively medium effort.

    Thanks,
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    If I understood correctly what you need to do it hand off data from the accelerator to the HPS while the accelerator is still operating? Before I end up sending in the wrong direction I'll need to know more about the data flow of this system. For example if you wanted to send small amounts of information to the HPS while the kernel is still operating you could put a FIFO in your design that the kernel accesses as a channel that the HPS could pop the information out of. Typically circular buffers are how OpenCL developers manage this sort of thing because it allows you to overlap operations if you use the appropriate runtime calls to keep everything synchronized. By the sounds of it you are looking for a way to funnel information back to the HPS outside of the runtime managed portion which can be tricky if you allow the runtime to queue up operations. For example lets say you queue up the kernel to run twice in a row on different buffers but you have a backdoor way for the kernels to communicate with the HPS, now you need some sort of way to ensure the data sent through the alternative means has some sort of context so that you can tell the data apart.