News for hackers. Stuff that matters.

A comment on Open Source Needs FPGAs; FPGAs Need an On-Ramp. Parent comment

Re:Open Source Needs FPGAs; FPGAs Need an On-Ramp by PhaseLockk on Friday March 31, 2017 @06:10PM (#14008787)
FPGAs are a useful means of accelerating any algorithm where you want more performance than you would get from executing it on a CPU, but can't afford to create your own ASIC because the volume is relatively low. For example, it may be used in DSP applications for things like radar. This use as a reprogrammable accelerator is also why Amazon has introduced instances with on-board FPGAs to AWS.
[ Parent | on HN ]
Re:Open Source Needs FPGAs; FPGAs Need an On-Ramp by pdelbarba on Friday March 31, 2017 @06:17PM (#14008840)
Also worth noting that for real time control you can't beat the speed. Essentially, everything you do on an FPGA happens at the same time. You could see a 1000 line Verilog file that completes a huge operation in a handful of cycles.
[ Parent | on HN ]
Re:Open Source Needs FPGAs; FPGAs Need an On-Ramp by 0xcde4c3db on Friday March 31, 2017 @06:49PM (#14009079)
Also note that "speed" includes latency, and not just low latency but also deterministic. You can do things like adjust a timestamp or tweak a control equation knowing that a sample has been delayed through an N-stage pipeline/filter that advances at M hertz.
[ Parent | on HN ]
Re:Open Source Needs FPGAs; FPGAs Need an On-Ramp by pdelbarba on Friday March 31, 2017 @07:10PM (#14009231)
Yea, I misspoke there. %s/speed/latency/

Certain industries (esp nuclear) really like them because they can "prove" the set of attainable states in the FPGA.

[ Parent | on HN ]
Re:Open Source Needs FPGAs; FPGAs Need an On-Ramp by thesz on Friday March 31, 2017 @07:13PM (#14009250)
Exactly.

There is an algorithm for detecting bursts of unusual activity which is extremely well suited for FPGAs: http://www.cs.nyu.edu/cs/faculty/shasha/papers/burst.d/burst...

Basically it is a tree of registers with checks. It can compute burst position and duration in the O(log(window size)) time (clocks). You look here at 2.5..5ns (200MHz..400MHz) multiplied by log2(window size) - 25..50 ns for window with 1024 samples. You just cannot get that kind of connectivity with CPU/GPU. Processing these samples in CPU will get you into several hundreds of ns, if not more.

[ Parent | on HN ]