A Look at Altera's OpenCL SDK for FPGAs(anandtech.com)
anandtech.com
A Look at Altera's OpenCL SDK for FPGAs
http://www.anandtech.com/show/7334/a-look-at-alteras-opencl-sdk-for-fpgas
3 comments
Was there something preventing you from using a GPGPU? Embarrassing memory bandwidth is one of their strengths, and of course they run OpenCL.
How efficiently OpenCl used the FPGA ?
And BTW, i remember reading some paper that compared CPU/GPU/FPGA. The conclusion was - GPU's win on compute/$, FPGA's win on compute/watt. Hard to find the paper now, though.
And BTW, i remember reading some paper that compared CPU/GPU/FPGA. The conclusion was - GPU's win on compute/$, FPGA's win on compute/watt. Hard to find the paper now, though.
>How efficiently OpenCl used the FPGA ?
There will always be some inefficiencies introduced when comparing OpenCL to Verilog. Hopefully, this will decrease in the future versions of OpenCL. Notice that the development time decreased by over 80%...
There will always be some inefficiencies introduced when comparing OpenCL to Verilog. Hopefully, this will decrease in the future versions of OpenCL. Notice that the development time decreased by over 80%...
Interesting. Is there any reference, or tutorial, for a fellow FPGA developer who are interested in studying OpenCL for FPGA?
Also, is there a link for your thesis? What kind of data processing was needed? I mostly work with signal processing for RF signals, pipelining data from ADCs.
Also, is there a link for your thesis? What kind of data processing was needed? I mostly work with signal processing for RF signals, pipelining data from ADCs.
So I'd say just pickup OpenCL in general, and then follow altera's best practices until you feel comftable.
No link for my thesis, can send you a pdf if you want. In terms of what was needed, my kernel was the simulation inner-most loop that would take in 4 values(2 floats, a const int and a double) per neuron and use them to update the neurons state. The simulation ran at a resolution of 1ms, with values between 1k and 100k neurons.
In essense it was high repetition, low complexity, high memory calculations.
Infact, what I experienced was that a) the biggest overhead is actually setting up the kernel and b) you have to take into account the memory requirements.
Biggest upgrades in performance came from transitioning the data transfers from synchronous to asynchronous, (to alleviate memory bottlenecks as much as possible), and from increasing the number of neurons.
Most interesting bit was that due to the simulation characteristics (Izhikevich model of a SNN), the firing rate dropped aroud 20-30k neurons. With a low firing rate, I could simulate in real-time (ie 1ms of simulation in 1ms of real time) 18k neurons, and 80k neurons due to disparities in firing rates
No link for my thesis, can send you a pdf if you want. In terms of what was needed, my kernel was the simulation inner-most loop that would take in 4 values(2 floats, a const int and a double) per neuron and use them to update the neurons state. The simulation ran at a resolution of 1ms, with values between 1k and 100k neurons.
In essense it was high repetition, low complexity, high memory calculations.
Infact, what I experienced was that a) the biggest overhead is actually setting up the kernel and b) you have to take into account the memory requirements.
Biggest upgrades in performance came from transitioning the data transfers from synchronous to asynchronous, (to alleviate memory bottlenecks as much as possible), and from increasing the number of neurons.
Most interesting bit was that due to the simulation characteristics (Izhikevich model of a SNN), the firing rate dropped aroud 20-30k neurons. With a low firing rate, I could simulate in real-time (ie 1ms of simulation in 1ms of real time) 18k neurons, and 80k neurons due to disparities in firing rates
Would you please send me a pdf of your thesis?
Care to mention in what field you did your bachelors and masters? You got into FPGAs though CS or through EE? I'm always curious about FPGA engineers.
Heya, did my undegrads as EE, changed it halfway from a 4 year MENG course to a 3 year bachelors because I was bored of the power distribution related stuff. Went on to do a masters in Advanced Microelectronics Design. I had contact with FPGA's in both my undergrad and my masters. I selected my BENG thesis on an ARM M0 soft implementation on an FPGA that implemented an expanded instruction set with increased performance on the SHA-1 algorithm.
Lots of interest about FPGA in HN lately. I wonder what caused this spark.
IMO: FPGAs are an interesting beast because they've been inaccessible to a lot of people thanks to the poor and/or expensive tooling and development boards.
That's starting to change slowly and people are getting interested in trying something new.
That's starting to change slowly and people are getting interested in trying something new.
Well, good development boards are cheaper nowadays, Vivado is slightly better than ISE, but pro tools are still very expensive and, of course, terrible.
Actually, most discussions here in HN are about how bad FPGA tools are.
Actually, most discussions here in HN are about how bad FPGA tools are.
I'm a CS major switching to EE and it's a logical intersection of the two fields, but hasn't recieved the same amount of attention and hype as the rest of the IoT movement.
Why are you switching to EE? The most interesting questions EE can address are in the CS domain. EE is the past, CS is the future. CS is to EE as Architecture is to knowing how to use a hammer, nails, and a saw. And I say this as an MSEE.
Intel is buying Xilinx, the largest FPGA manufacturer... Why is everyone going DEEP?!:( I thought I could just run my javascript code in a java based browser running in a java VM running inside a VM written in Python. :(
WE NEED MORE HIGH LEVEL STUFF. Not VHDL and whatnot. Coz the hardware will always be 'fast enough', right?
WE NEED MORE HIGH LEVEL STUFF. Not VHDL and whatnot. Coz the hardware will always be 'fast enough', right?
Seriously, I am using it to create an open-source quantum mechanics software, supports both GPU and FPGA acceleration.
Report back here when you do, please.
Having OpenCl certainly reduced dev time by around 85% id say. And that's from someone fluent with verilog, who didn't know openCL before doing this.