A team hears that OpenCL is write-once, run-anywhere, points its existing GPU kernel at an FPGA board, kicks off a build, and waits. Two hours later the bitstream lands, runs correctly, and delivers roughly the throughput of the CPU baseline they were trying to beat. Nobody made a mistake in the code. The mistake was in the assumption: that OpenCL’s portability of source implies portability of performance. It does not. On an FPGA, the same kernel text that ran fine on a GPU describes a completely different physical machine — one you have to design, not just dispatch to. That gap is the whole story of OpenCL on FPGA. The language is genuinely portable. The compute model underneath is not. Understanding the difference is what separates a project that shaves real milliseconds and watts off a fixed inference workload from one that spends weeks compiling bitstreams to arrive back where it started. What should you know about OpenCL on FPGA in practice? On a GPU, an OpenCL kernel is scheduled onto a fixed array of execution units. The silicon already exists; your kernel is a program the hardware runs. On an FPGA there is no fixed array waiting for work. The device is a fabric of configurable logic blocks, DSP slices, and on-chip memory (BRAM) that gets wired into a circuit specific to your kernel before anything runs. The OpenCL C you write is not executed — it is synthesized into a spatial pipeline that data flows through. This is why the vendor toolchains — Intel’s oneAPI/FPGA flow (formerly the Intel FPGA SDK for OpenCL) and AMD’s Vitis (formerly Xilinx SDAccel) — sit on top of a high-level synthesis (HLS) engine. HLS translates the kernel into register-transfer-level logic, then place-and-route maps that logic onto the physical fabric of the target board. The output is a bitstream: a configuration file that reprograms the FPGA into the circuit your kernel describes. The practical consequence is that “the same OpenCL” behaves nothing like it does on a GPU. A loop that a GPU runs as thousands of parallel threads becomes, on an FPGA, a pipeline you want the compiler to unroll and pipeline so a new input enters every clock cycle. Get the pipelining right and throughput is enormous for a fixed dataflow. Get it wrong and the circuit stalls, waiting on memory or serializing a dependency you never noticed on the GPU. The compute model — spatial dataflow versus temporal thread scheduling — is the thing you are actually porting, and OpenCL only carries you across the syntax, not the model. We cover the same divergence from the language side in what CUDA and OpenCL each mean in practice when porting AI workloads. How is an OpenCL kernel turned into an FPGA bitstream, and why do compile times run into hours? A GPU OpenCL kernel compiles in seconds because it targets an existing instruction set. An FPGA build is a physical design problem. The flow runs, roughly, through four stages, and each one is expensive: Stage What happens Why it is slow High-level synthesis OpenCL C → RTL (register-transfer logic) Scheduling and resource allocation of every operation Logic synthesis RTL → gate-level netlist Optimizing a large boolean circuit Place-and-route Netlist → physical fabric mapping NP-hard placement + timing closure across the die Bitstream generation Placed design → configuration file Final packaging, verification Place-and-route dominates. It is solving a spatial optimization problem across millions of routing resources while trying to meet timing at a target clock frequency. For a non-trivial inference kernel, full builds commonly run on the order of an hour or more, and complex designs can stretch across a working day (build times are board- and design-dependent; treat any figure as an observed-pattern range, not a benchmark). This is not a tuning knob you can turn off — it is intrinsic to configuring hardware rather than dispatching to it. The immediate design implication: your iteration loop is broken compared to a GPU. On CUDA or GPU OpenCL you edit, recompile, and re-profile in a minute. On FPGA every change to memory layout, unroll factor, or pipeline structure can cost an hour before you learn whether it helped. Fast-iteration workloads — research code, models still changing weekly — are structurally a poor fit. FPGA OpenCL rewards a stable model where the compile cost is paid once and amortized across a long deployment. What latency, throughput, and power can an FPGA OpenCL path deliver versus a CPU or GPU baseline? This is the question that justifies the whole exercise, and the honest answer is: it depends entirely on the workload, and you must measure it. There is no universal “FPGAs are N times faster” claim that survives contact with a real deployment. What FPGAs offer structurally is deterministic low latency and strong power efficiency for a fixed dataflow, because the circuit does exactly your computation with no instruction-fetch overhead and no scheduling jitter. Where they lose is peak batch throughput on large, well-parallelized models — a modern GPU with high HBM bandwidth and tensor cores will typically win on raw images-per-second for a big convolutional or transformer model. Where they win is a small, latency-critical model that must respond in a bounded time with a tight power budget, the kind of constraint you see in embedded vision, signal processing, or always-on edge inference. A fit assessment should produce four numbers against a named baseline: Per-inference latency — and, crucially, its variance. FPGAs shine when the p99 must be near the p50. Sustained throughput under the real request pattern, not a synthetic burst. Power-per-inference (watts per inference, or inferences per joule) — often the number that actually decides it. See FLOPS per watt and how to use it in port decisions for how to read energy efficiency without being misled by peak figures. Resource utilization — DSP, BRAM, and LUT usage as a percentage of the device, which tells you both whether the design fits and how much headroom remains. Every one of these is an operational measurement on your kernel and your board. Treat vendor peak-efficiency figures as ceilings you will not reach, not as forecasts. When does an FPGA path fit an inference workload better than native GPU/CUDA acceleration? Use this rubric before committing a single hour of build time. The FPGA path earns its place when several of these hold together — not because any one is true in isolation. FPGA fit checklist The model is stable — architecture and weights are not changing weekly. The binding constraint is latency determinism or power, not peak throughput. There is a fixed low-latency or watts-per-inference target you must hit, ideally in an embedded or edge envelope. The deployment volume is large enough to amortize the toolchain and tuning cost. You have — or can build — the HLS expertise to tune pipelines and memory layout; naive ports rarely beat the baseline. A GPU is overkill on power or thermals for the physical deployment. If most of those are false — the model is still evolving, you care about batch throughput, iteration speed matters, or the deployment is a handful of servers in a datacenter with power to spare — a GPU almost certainly wins, and the FPGA build cost is wasted. The decision is a branch in a broader port assessment, the same pass that weighs a WASM path or native C++/CUDA acceleration against each other; our [inference-cost-cut pack](Inference Cost-Cut Pack) treats the FPGA branch as one option among several rather than a foregone conclusion. Does OpenCL portability actually transfer performance across CPU, GPU, and FPGA? No. OpenCL portability is functional portability — the same kernel source compiles and produces correct results on a CPU, a GPU, and an FPGA. That is a real and useful property. It means you are not rewriting in a proprietary hardware description language, and it keeps the door open to multiple accelerators from one codebase. But performance is not portable, because the optimal kernel structure differs by target. A GPU wants coalesced memory access and thousands of lightweight threads. An FPGA wants deep pipelines, on-chip buffering, and loop transformations that make the synthesized circuit deterministic. A kernel written for one is frequently pessimal for the other. In practice, an FPGA-tuned OpenCL kernel carries board-specific attributes and pragmas — unroll factors, pipeline directives, memory-bank assignments — that mean nothing on a GPU and everything on the fabric. This is the same lesson SIMD portability teaches on CPUs: as we discuss in what SIMD width buys a ported inference path, portable source and portable peak performance are different guarantees. The safe mental model is that OpenCL portability protects your investment in the algorithm, not your performance on a new target. How do we profile a synthesized kernel against a fixed latency and power target before committing? Profile before you commit, not after. The whole point of the fit assessment is to spend one or two build cycles learning whether the FPGA path can hit the target, rather than committing the toolchain and discovering the answer in month three. A workable sequence: Establish the baseline first. Measure per-inference latency, sustained throughput, and power-per-inference on the CPU or GPU you would otherwise ship. Without this number, no FPGA result means anything. Build a representative kernel, not the full model — a slice that exercises the dominant compute and memory pattern. This bounds the first long build. Read the HLS report the toolchain emits before place-and-route. It estimates resource utilization (DSP/BRAM/LUT), the achievable clock, and the initiation interval of your pipeline. If the report says your loop can’t pipeline to one-per-cycle, you learn that in minutes, not hours. Run the synthesized kernel on the board and measure real latency and watts under the actual request pattern — not a synthetic loop. Compare against the baseline and the target, and record a documented go/no-go. If the FPGA can’t beat the baseline on the constraint that matters, that is a valid — and cheap — answer. The output is a decision, not a deployment. A clear “no, the GPU path wins on this workload” that cost two build cycles is a good outcome, because it was reached before the toolchain investment. Release-readiness for an FPGA path adds its own gates — bitstream provenance, resource-headroom margins, and compile-to-deploy cadence all become part of the readiness conversation once you do commit. FAQ What does working with OpenCL on FPGA involve in practice? OpenCL C targeting an FPGA is not executed on a fixed processor — it is compiled through high-level synthesis into a spatial dataflow circuit that reconfigures the FPGA’s logic fabric. In practice this means the compute model is fundamentally different from a GPU’s thread scheduling: you are designing a pipeline that data flows through, and the same source that ran on a GPU describes a physically different machine. How is an OpenCL kernel turned into an FPGA bitstream, and why do compile times run into hours? The kernel passes through high-level synthesis to RTL, logic synthesis to a gate-level netlist, place-and-route onto the physical fabric, and finally bitstream generation. Place-and-route dominates the time because it solves an NP-hard spatial placement and timing-closure problem across millions of routing resources. Full builds commonly run on the order of an hour or more (an observed-pattern range, not a benchmark), which breaks the fast edit-recompile loop you get on a GPU. What actual latency, throughput, and power-per-inference can an FPGA OpenCL path deliver versus a CPU or GPU baseline? It depends entirely on the workload and must be measured — there is no universal speedup figure. FPGAs structurally offer deterministic low latency and strong power efficiency for a fixed dataflow, while a high-bandwidth GPU typically wins on peak batch throughput for large models. The fit assessment produces four operational measurements: per-inference latency and its variance, sustained throughput, power-per-inference, and DSP/BRAM/LUT utilization against a named baseline. When does an FPGA path fit an inference workload better than native GPU/CUDA acceleration? When the model is stable, the binding constraint is latency determinism or power rather than peak throughput, there is a fixed low-latency or watts-per-inference target, deployment volume is large enough to amortize toolchain cost, and HLS tuning expertise is available. If the model is still evolving or batch throughput matters, a GPU almost always wins and the FPGA build cost is wasted. Does OpenCL portability actually transfer performance across CPU, GPU, and FPGA, or only source code? Only source code. OpenCL gives functional portability — the same kernel compiles and produces correct results across targets — but the optimal kernel structure differs by hardware, so performance does not transfer. A GPU-tuned kernel with coalesced access and many threads is frequently pessimal on an FPGA, which wants deep pipelines, on-chip buffering, and board-specific pragmas. How do we profile a synthesized FPGA kernel against a fixed latency and power target before committing to the toolchain? Establish the CPU/GPU baseline first, build a representative kernel slice rather than the full model, then read the HLS report before place-and-route to check resource utilization and pipeline initiation interval in minutes. Run the synthesized kernel on the board under the real request pattern, measure latency and watts, and record a documented go/no-go against the target. A cheap, clear “the GPU wins here” is a valid outcome reached before the toolchain investment. The question worth carrying into the port decision is not “can OpenCL run on this FPGA” — it almost always can — but “does the deployment constraint actually reward a spatial dataflow circuit over a scheduled processor?” That is a precision-versus-target trade-off you resolve with two build cycles and a baseline, not with a portability promise. For the compute-model mechanics in more depth, our companion piece on how the OpenCL FPGA compute model actually works for inference picks up where the fit assessment leaves off.
