@Duane: OpenCL, like CUDA, is based on writing a "kernel" of code in a specialized dialect of C. You write C for the main "application", then call the "kernel" to execute, then wait for the results. The "application" runs on the host (eg, Intel CPU) while the "kernel" runs on an accelerator (GPU card or FPGA card). When programming the kernel, you take on a specialized viewpoint -- you write code for the kernel as if it is doing a tiny amount of work on, say, a single element in a matrix. When the kernel is executed from C, you are saying "here is a big matrix of data, run the kernel on every element". Inside the kernel, you can use special identifiers to determine which element you are, and to find your neighbouring elements if you want them.
One downside of OpenCL is that it generates Verilog which must fit inside the FPGA. This means (1) you must wait for place and route to finish each time you change your OpenCL code, and (2) while writing OpenCL, you don't know if your FPGA chip is big enough. If the chip is too small, you may have to rearchitect the code significantly, and possibly take a huge performance penalty.
Another way of using FPGAs is to use a processor-based programming model. The embedded ARM processors are pretty fast, and they have NEON accelerators to give you another 2-3x boost when needed. This has the advantages of rapid compile time (no place and route), rapid debugging, and ability to support dynamic structures (memory allocation, function pointers, etc) that cannot be supported with OpenCL or other C-to-gates technologies.
If you need higher performance than NEON, or if ARM isn't available, there is an alternative. The VectorBlox MXP processor is a purely C-programmable vector engine that attaches to Nios, MicroBlaze or ARM. It doesn't require changing the bitstream every time the C program is changed, so recompilation is fast and debug is easy. Furthermore, it is scalable, so it can be as small as a single ALU, or as large as the entire FPGA fabric. It also achieves significant speedups on the order of 100-1000x over Nios or MicroBlaze alone. (Disclaimer: I co-founded VectorBlox; sorry if this appears to be spam.)
Languages like OpenCL can also be compiled to run on vector processors, but we aren't there yet.
@Duane: OpenCL evolved from Graphics Processing Units used for image processing. It is an attempt to generalize usage for non-image vector algorithms.
Basically pass a portion of a vector array(or whatever the correct name is) as a unit of work to be done. If that is not your application, it is useless. There are lots of applications, but OpenCL is not a general purpose language such as assembly, C C++, Python, etc
How many years have we heard that programmers are going to "program" FPGAs? And just write it in C the magical C to hardware tools will do the rest. . . . .
Remember Brian Durwood's blogs on APP? H certainly found that doing accellerators is a daunting task. Minly because place and route has to be done BEFORE loading the bit stream to the chip.
Also application specific processors and reconfigurable computing are pretty much pipe dreams. I am sure someone will say that is what an FPGA is. NO, an FPGA is a logic device analogous to an ASIC, with a shorter design cycle.
It's a little unclear as to exactly what OpenCL is and how to go about using it. I hunted around a bit and found that a lot of big names seem to support it, but it looks like they do so with APIs and SDKs. Does that mean OpenCL can be grafted onto other langauges?
It is great to learn that OpenCL could be the one language for all programmable devices from microcontroller to DSPs to FPGAs. As the CPUs & FPGAs are getting merged in a common fabric in the form of SoCs and the trend would continue, this kind of common language would solve the issue of sticking to vendor specific development tools (but there shall still be some dependencies right?) and more over the need to have expertise in several languages. It is also great to learn that OpenCL can handle parallelism like VHDL, Verilog. I understand it would be very easy for the firmware engineers, who are experts in C, to pick up OpenCL What about the engineers who were using VHDL? Will it be easy for them to pick this up fairly quickly if they have basic knowledge about C?
A Book For All Reasons Bernard Cole1 Comment Robert Oshana's recent book "Software Engineering for Embedded Systems (Newnes/Elsevier)," written and edited with Mark Kraeling, is a 'book for all reasons.' At almost 1,200 pages, it ...