Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

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

yosefk.com

Post reply on HN
Print view View original

21–30 of 110 posts

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

#21

Post by penprogg »

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…

I agree, I'm a CS student taking a Digital Design course and programming VHDL is possibly the worst experience I've ever had. (I am very aware that VHDL is not a programming language but a HDL).

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

#22

Post by _yosefk »

solve wrote: post #6
nkurz wrote: post #2

A sequel is in the making, titled "Why you won't buy an FPGA" Did the followup article ever get written? I didn't find anything with a search for the proposed title on either his site or Google.

The reason is because GPUs gained more general-purpose capabilities. GPUs are the new FPGA, for all practical purposes.

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 have a ton of problems GPUs don't have. The two do not look similar to someone caring about accelerators any more than snow and ice look similar to someone living at a place where they get to see both... though the two might seem similar to people from hot places where neither is common (or perhaps if they saw one but never the other.)

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

#23

Post by kuiper83 »

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…

We used FPGAs from Xilinx to implement a MIPS processor for a course in school, and I remember one of the most frustrating things of the whole process was the toolkit/documentation. Compilation errors were very unhelpful, and debugging was a nightmare for most relatively complicated tasks.

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

#24

Post by [deleted] »

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…

[deleted]

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

#25

Post by solve »

_yosefk wrote: post #22
solve wrote: post #6

Earlier quoted context omitted.

The reason is because GPUs gained more general-purpose capabilities. GPUs are the new FPGA, for all practical purposes.

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?

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

#26

Post by elihu »

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…

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.)

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

#27

Post by sklogic »

fixxer wrote: post #17

Suppose I wanted to get started with FPGAs for purpose of computation (no interest in control or actuation of sensors/devices). What would be the best starting board for less than $300? I'm not a student, but I can probably find one if your suggestion is a student dev board.

http://valentfx.com/logi-pi/ (or logibone) is reasonably good, it's a Spartan6 LX9, easily programmable via SPI, and you can communicate with your design using the same SPI, easily clocked up to 30mbps.

For bigger designs (e.g., a full OpenRISC SoC fits, with ethernet and VGA and all that) you can use Digilent Atlys board, it's cheap for students (although communicating with it is a bit more complicated).

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

#28

Post by sklogic »

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…

Of course they are programming languages. Anything with a well-defined semantics is a programming language.

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

#29

Post by beeworker »

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 this is sort of true, this attitude contributes to the problem another commenter mentioned about how working with FPGAs is like taking a trip to the 70s. There's no reason you can't use a full-fledged programming language like Python to specify your hardware with the strict HDL subset at the RT Level, then use the full language's power to test it off-FPGA, and use all the software tooling around your full language to make the whole experience as pleasant as possible. In fact, that's the approach of MyHDL: http://www.myhdl.org/

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

#30

Post by sklogic »

TorKlingberg wrote: post #12
gchadwick wrote: post #8

I think one issue here is that to achieve the great gains in performance FPGAs can provide you do need to treat it like a proper HW design. C to RTL exists but to get the best out of it you're basically using C as a syntactic sugar for verilog/VHDL. So the overhead for programmability is higher than a DSP/GPU if you want to gain over and above them. I do wonder if there's a sweet spot in here somewhere that's basical…

As a C programmer, I don't think C is suitable for such a fundamentally parallel architecture as an FPGA. I would prefer a higher level language, maybe declarative, where it is up to the compiler to lay out the parallel operations. Unfortunately the engineering culture gap from HDL to a high level language is much wider than to C.

Actually it's easier and more natural to translate a (domain-specific) high level language into RTL than trying to fit an alien but so-called "general-purpose" C.

I'm using a language which translates into Verilog, but features native support for expressing things like FSMs, pipelines, buses, FIFOs - and something as simple as this makes HDL coding much simpler and much less error-prone than a conventional low-level RTL.

Post reply on HN