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

91–100 of 110 posts

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

#91

Post by sitkack »

davexunit wrote: post #53

The major issue with FPGAs today is that there is no free toolchain for compiling the bitstreams that run on them. The only project I know of to make any real progress on fixing this is fpgatools. [0] It supports a single model of the Xilinx Spartan-6 series, the XC6SLX9. I know almost nothing about FPGAs, but seeing as how almost no one is working on this problem, I figured I'd try to add support for the XC6SLX45, t…

Just implement an FPGA in Verilog, then use that FPGA as your target. It has the added bonus of making your bitstream portable across Altera, Xilinx, Lattice, etc. One could use genetic algorithm to map the search space so that the virtual fpga compiles cleanly using available resources of the hardware.

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

#92

Post by sitkack »

charlesnw wrote: post #19
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.

I've recently purchased the parallela board: http://www.parallella.org/ It's got USB/ethernet/arm cpu , and has been incorporated into numerous other projects. It's ~$100.00 USD.

I second the parallella, not only does it have an FPGA, an arm core and a massively parallel cpu. So much to play with and still running Linux so the workflow is super smooth.

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

#93

Post by diamondman »

kyboren wrote: post #43
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".

As kyboren says fpga compiling is crazy intensive. This is because we are mapping physical resources and things have to physically fit instead of just being able to arbitrarily jump somewhere else in the program. It becomes a huge constraint satisfaction problem, there is no 'correct' answer, and many times FPGA compilers will produce different results when run multiple times because they often use randomness to start the process if there are too many options.

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

#94

Post by nkurz »

diamondman wrote: post #84
diamondman wrote: post #82

Earlier quoted context omitted.

PART 1/3 The lack of open tools is a huge problem. My friends on IRC are working on reverse engineering multiple chips enough that full compilation tool chains can work. My part of the project is working to make a highly generic method of loading the compiled files onto the actual chips no matter the programmer or chip used. I will expand on the steps of compiling for an FPGA, loading a program onto an FPGA, the diff…

PART 3/3 MY PROJECT: I want to pave the way for FPGAs to be usable in everything from laptop/desktop computers to phones (if the static power consumption gets better). I have some very interesting ideas of what an average user could do with in system FPGAs that can be reconfigured at runtime. My main target is fixing the huge tangled JTAG mess. I mentioned earlier that even though the JTAG standard is pretty solid, e…

Brilliant writeup, thanks! Please publish this somewhere more permanent and resubmit so it gets more attention (and hopefully discussion).

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

#95

Post by _yosefk »

solve wrote: post #88
_yosefk wrote: post #81

Earlier quoted context omitted.

Do you get more throughput per dollar with FPGA relative to GPUs? Most certainly, except for floating point stuff, especially double precision. (Finance would care much less than scientific computing and I think FPGAs are way more prominent there.)

You sure? The ones I'm personally familiar with are investment banks that have hundreds of thousands of computers doing machine learning modeling. They ran the costs, and found GPUs to be far more cost effective.

Machine learning software will tend to use floating point, hence the result IMO. In HFT for instance I'd expect things to be the opposite.

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

#96

Post by _yosefk »

solve wrote: post #77
skaevola wrote: post #48

Earlier quoted context omitted.

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.

But ASIC is 100x better than FPGA for energy per computation. Know of any mobile devices that have FPGAs on them now?

It's not fair to compare a programmable circuit with a fixed-function circuit though, because programmability is often a requirement.

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

#97

Post by sklogic »

sitkack wrote: post #91
davexunit wrote: post #53

The major issue with FPGAs today is that there is no free toolchain for compiling the bitstreams that run on them. The only project I know of to make any real progress on fixing this is fpgatools. [0] It supports a single model of the Xilinx Spartan-6 series, the XC6SLX9. I know almost nothing about FPGAs, but seeing as how almost no one is working on this problem, I figured I'd try to add support for the XC6SLX45, t…

Just implement an FPGA in Verilog, then use that FPGA as your target. It has the added bonus of making your bitstream portable across Altera, Xilinx, Lattice, etc. One could use genetic algorithm to map the search space so that the virtual fpga compiles cleanly using available resources of the hardware.

I did it (while playing with reconfigurable dataflow CPUs), and timings (expectably) were awful.

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

#98

Post by anewhnaccount »

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…

Another way to think of a register transfer level hardware description languages is as a type of dataflow programming language.

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

#99

Post by TuringTest »

kyboren wrote: post #43
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".

Back in the day I learned about using VHDL to design circuits, is that the kind of compilation also used for FPGAs?

That language paradigm is close to modern dataflow oriented programming languages. It should be theoretically possible to compile an application program written in that style and have the logical circuits in the FPGA be a direct mapping of the business logic in the application.

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

#100

Post by skaevola »

solve wrote: post #77
skaevola wrote: post #48

Earlier quoted context omitted.

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.

But ASIC is 100x better than FPGA for energy per computation. Know of any mobile devices that have FPGAs on them now?

Sure: http://www.eejournal.com/archives/articles/20131118-lattice/

But you're right - when programmability isn't important you'd rather have an ASIC.

Post reply on HN