OpenCL Host Channel or Host Pipes

The replies in those threads were made by me (in the old Altera forum). I generally use the terms "pipe" and "channel" interchangeably but I am not sure if Altera/Intel agrees with this. 😅

Either way, the example you posted seems to include everything required to use host channels (or pipes 😜). No low-level DMA access is required; you just need to define the host channel as an argument in the kernel and then write data to it in the host code and read it in the kernel code (or vise versa) using the specific notation used in that example. I believe there is also fine-grained stalling mechanism in-place (similar to on-chip channels), that will block the host if the channel is full or block the kernel if it is empty. There is also an example in "Intel FPGA SDK for OpenCL Pro Edition, Section 5.5.6.4. Example Use of the cl_intel_fpga_host_pipe Extension".

Thanks for the response @HRZ​ . Too bad someone from Intel won't weigh in on host channel vs host pipe convention!!

I assumed they must be the same, and was able to compile and use the example targeting the host_ch BSP on the A10 GX eval card. I was also able to make some modifications to the example and use the one-at-a-time clWritePipeIntelFPGA and clReadPipeIntelFPGA calls. I had not used the clGetExtensionFunctionAddress call or have much experience with function pointers, but seems to work.

Out of curiosity since so few people are using these features - have you tested the throughput you can achieve using the host pipes? I'm considering creating a multi-threaded host application that writes/reads to a device kernel doing some simple data manipulation. I assume any bottleneck would be in the host application or host pipe logic in the BSP - not in the kernel or PCIe interfaces. I'm hoping to move ~1GB/sec

Well, the unfortunate reality is that most people are still stuck in getting basic stuff to work on their boards and won't get to such advanced features any time soon; apart from that, many people (including me) use third-party boards which rarely get BSP updates and hence, in many cases they cannot use new features like this due to lack of compatible BSP. I am personally very interested in trying host channels/pipes but my board manufacturer is yet to release a BSP with this feature included.

With respect to the performance of host pipes/channels, I can point you to Intel's own paper (which is unfortunately behind a paywall):

https://dl.acm.org/citation.cfm?id=3078182

I am in the same situation with regards to slow BSP updates on a 3rd party board, but the host pipe/channel features is compelling enough that I'm now working with the Intel A10 GX board that has a BSP claiming host channel support. But that board doesn't support built in IO channels to the network interfaces like 3rd party boards - which leads me down the path of creating a custom BSP for the Intel board.

A paper by Intel engineers about about a feature for Intel FPGAs is behind a paywall.... interesting. I can't even find their emails to contact them directly and request a copy.

I see. I think Intel themselves probably have non-public BSPs for the reference boards with support for different components. Though, I am not sure how they could be requested now that they don't accept service requests from public anymore.

Regarding the paper, they published it at a scientific conference, hence it is behind the paywall of the publisher. If you search "Peter Yiannacouras" in google, you can find his Linkedin profile and his personal page on University of Toronto's website with his old email address; if that didn't work, you can try reaching out to him on Linkedin.

P.S. Have you successfully used the network I/O channels provided by your third-party board? From what I know, the "free" network I/O channels you get with such boards only allow communication at physical layer and you will have to perform framing and handle all the control signals yourself (in OpenCL). Furthermore, there is no flow control. There is another network I/O channel that also provides the MAC layer protocol and significantly simplifies usage but that requires Intel's ultra-expensive low-latency MAC license. But still, there is no flow control.

I have successfully used network I/O channels on 3rd party boards that include the 10GigE MAC as part of the BSP - but you're correct that requires the ultra-expensive low-latency MAC license. But I have not tried to use flow control. I have been able to create kernels attached to the I/O channels that process data at the IP and transport layers at line rate.

You should be able to find all the information you need about host pipes at this link.

https://www.intel.com/content/www/us/en/programmable/documentation/mwh1391807965224.html#ewa1425651091639

The document is for version 18.1, but the information should still apply to 17.1.

Current Pipes/Channels Restrictions

*Channels can have multiple read call sites, but only a single write call site

*Pipes can have only a single read and a single write call site

*Loop containing pipes or channel writes cannot be unrolled

*Kernels with channels can’t be vectorized (num_simd_work_items)

*Kernels CU with channels likely cannot be replicated (num_compute_unit)

– Unless max_global_work_dim(0) applied

*Dynamic indexing into arrays of channel IDs not supported

–Only static indexing supported

–AOC needs to know how to connect to HW at compile time

Pipes vs. Channels

*Most cases they are the same

–Usage and Performance

*Use Pipes

–For host pipes

–Partially conformant to OpenCL™ standards

–Needs modification from OpenCL 2.0 Pipes

*Use Channels

–With autorun kernels

–Use model more aligned with FPGA implementation

–Pipe usage more verbose, especially on the host side

@SSFyTMT​ I see, thank you.

@DPrin​ That information is related to on-cip channels/pipes, not host channels/pipes.