How FPGAs work, and why you'll buy one (2013) • Hacker News Board

Re: How FPGAs work, and why you'll buy one (2013)

#41

Post by Matumio » Thu, Apr 16, 2015, 6:14 PM UTC

nulldozer wrote: post #15

Igglyboo wrote: post #7

The trouble I had with FPGAs is how radically different languages like Verilog and VHDL are when compared to languages like Java, Python, or C++. Writing code that is concurrent by default is a massive paradigm shift when all I had been exposed to at that point were procedural languages.

That's because hardware description languages are not programming languages. This point was constantly emphasized in my digital systems courses. You do not describe a sequence of instructions using an HDL, you describe the layout of a circuit with registers, wires, and logic blocks. You have to consider the physics of the device to avoid violating timing constraints or driving a signal from two different sources, etc…

They are programming language, but you don't program the FPGA device with them. Your program a generator that runs on your CPU and creates the physical layout for the FPGA device as its output.

Re: How FPGAs work, and why you'll buy one (2013)

#42

Post by tjradcliffe » Thu, Apr 16, 2015, 6:23 PM UTC

jychang wrote: post #13

I am currently just another college student, but I have some experience in this field, as I had interned at Xilinx (which is the largest FPGA maker right now, iirc, although Altera may have taken the crown). I don't think your typical college CS student, and by extension, the average programmer, would be interested in using FPGAs right now. This isn't an issue of performance, or costs, or lack of use cases- FPGAs are…

There have been periodic bursts of FPGA hype over the past several decades, and they have all fizzled out for precisely the reasons you cite.

"FPGAs: they're the technology of the future, and always will be!"

Re: How FPGAs work, and why you'll buy one (2013)

#43

Post by kyboren » Thu, Apr 16, 2015, 6:24 PM UTC

TuringTest wrote: post #3

Is there a possibility to use just-in-time compilers to port software to FPGAs? I can see how that could be used to accelerate applications written on bytecode languages (i.e. mostly everything in your mobile phone) to near-assembly speeds.

What jbangert said is the crux of the JITing problem: "compilation" for FPGAs is not really at all like compiling software, and can be hugely computationally expensive. On top of that, pretty much the entire synthesis, mapping, and place and route flow is usually proprietary.

That said, there have been some efforts in this direction. Search the literature for "warp processing".

Re: How FPGAs work, and why you'll buy one (2013)

#44

Post by frozenport » Thu, Apr 16, 2015, 6:25 PM UTC

lmeyerov wrote: post #16

Our experience with GPU cloud computing at Graphistry should be pretty representative. We spend a lot of effort getting subsecond interactivity in funny C dialects (OpenCL/CUDA). To get those down further, we can put together a few GPUs and reuse most of the code. Eventually, however, data communication costs get too high, so FPGAs would be the next step. That is certainly doable: OpenCL -> FPGA compilers are a thing…

>>Eventually, however, data communication costs get too high

Looks like the program is spending too much time in 'MPI_RECV'? Clearly the same time would be spent by any other hardware device, and raw compute power wont fix this. You need a faster interconnect. Indeed, among the few fixes for this problem are complicated changes to the algorithm, such a maintaining some kind of network routing scheme, which often involves complicated logic difficult to implement on anything but a CPU.

Re: How FPGAs work, and why you'll buy one (2013)

#45

Post by anigbrowl » Thu, Apr 16, 2015, 6:28 PM UTC

jonaldomo wrote: post #11

I think FPGAs are an untapped technology. I would love a book by Manning or Pragmatic called "FPGAs in Action" or "101 FPGA Projects". I have no idea what to do with it besides try to make a bitcoin miner.

I have several FPGA-based devices, in hybrid digital-analog synthesizers. FPGAs allow rapid reconfiguration of signal routing between analog components, which latter deliver much nicer sound quality than DSPs for many requirements, especially filtering. There are also Field Programmable Analog Arrays but I don't have any of those, yet.

Re: How FPGAs work, and why you'll buy one (2013)

#46

Post by Matumio » Thu, Apr 16, 2015, 6:29 PM UTC

sklogic wrote: post #37

[deleted] wrote: post #35

Earlier quoted context omitted.

[deleted]

And why setting up LUTs and interconnect is not a programming?

(Apologies for deletion. I moved my comment to parent. Won't try that again.)

It is, but on a different level. I think the analogy would be that in VHDL/Verliog you are dealing with a template or macro language (which is executed to generate code) as opposed to a low-level language (which translates almost directly to machine instructions).

Re: How FPGAs work, and why you'll buy one (2013)

#47

Post by tel » Thu, Apr 16, 2015, 6:29 PM UTC

elihu wrote: post #26

nulldozer wrote: post #15

Earlier quoted context omitted.

That's because hardware description languages are not programming languages. This point was constantly emphasized in my digital systems courses. You do not describe a sequence of instructions using an HDL, you describe the layout of a circuit with registers, wires, and logic blocks. You have to consider the physics of the device to avoid violating timing constraints or driving a signal from two different sources, etc…

Hardware description languages are not imperative programming languages (even if they might superficially resemble them). That doesn't mean they aren't programming languages at all -- they just belong to a different category of language. (I suspect that there's a connection between hardware design and functional programming, but I don't have enough hardware design experience to know how closely the two are related.)

Conal Elliott, Haskeller of FRP fame, was recently working for a company where he was developing a compiler of functional programming into categorical semantics which is actually quite neatly similar to the layout of a circuit. The company went under, unfortunately, so I'm not sure of the status of his research, but some remarks are available on his blog [0] [1] [2].

Further, there is a notion of a Generalized Arrow [3] which is a useful, advanced functional programming technique which is quite nice for implementing FRP. These are somewhat obviously "wiring diagrams" but are shown to be in correspondence with a more normal "lambda calculus"-like syntax.

[0] http://conal.net/blog/posts/haskell-to-hardware-via-cccs

[1] http://conal.net/blog/posts/overloading-lambda

[2] http://conal.net/blog/posts/optimizing-cccs

[3] http://www.megacz.com/berkeley/garrows/

Re: How FPGAs work, and why you'll buy one (2013)

#48

Post by skaevola » Thu, Apr 16, 2015, 6:31 PM UTC

solve wrote: post #25

_yosefk wrote: post #22

Earlier quoted context omitted.

Author here. I didn't write the follow-up yet because it requires a lot of research and I'm busy :-) If you ask me, GPUs are anything but "the new FPGA". GPUs are the least efficient hardware accelerator out there, but also the most accessible to the largest number of programmers. FPGAs are much more efficient than GPUs on DSP workloads and GPUs are useless for I/O while FPGAs are a godsend. On the other hand, FPGAs…

But are they the most efficient in cost-per-computation? For all the major data crunchers I'm familiar with, doing either finance or scientific calculations, that's the only metric they cared about. Only place I can see the cost-per-computation metric not mattering is in space satellites. Am I way off?

For any sort of mobile device energy-usage per computation is an important metric. Hence you have chips with multiple low power modes which can trade off different amounts of computational power with different amounts of power efficiency.

Re: How FPGAs work, and why you'll buy one (2013)

#49

Post by tel » Thu, Apr 16, 2015, 6:32 PM UTC

jonaldomo wrote: post #11

I think FPGAs are an untapped technology. I would love a book by Manning or Pragmatic called "FPGAs in Action" or "101 FPGA Projects". I have no idea what to do with it besides try to make a bitcoin miner.

If you're into hardware, robotics, automation then there's a HUGE space for this stuff. National Instruments has made there name here for some time.

Re: How FPGAs work, and why you'll buy one (2013)

#50

Post by vkjv » Thu, Apr 16, 2015, 6:32 PM UTC

viccuad wrote: post #18

I think a lot of people posting here don't realize that programming an FPGA means programming how the gates are set up on the FPGA, not software programming. VHDL/Verilog etc are descriptive languages, not software languages ala C/Python/Java/etc. You should have enough hardware design knowledge (at RT level) to be able to sketch your HW design in a piece of paper, and then, you are apt for writting VHDL/Verilog and…

While, I do have an EE degree, I play with FPGAs fairly frequently and rarely think about the hardware that I'm laying out.

In my experience, unless you are building something either very large and need to worry about your gate count, or something very time sensitive and need to work about component distance, you can just program and enjoy real concurrency. :)