Hacker News Reader

Comment by crazygringo | Hacker News Reader

So, about 15 years ago I took a college course on microprocessor design, and our final project was to implement a simple microprocessor on an FPGA.

At the time, it seemed obvious that, over the next decade, FPGA's would work their way into general-purpose computing, so that (for example) Photoshop filters would simply reconfigure the FPGA to run blazingly fast. Likewise with games, or video codecs, or 3D rendering, or whatever else was processor-intensive.

But that clearly hasn't happened. Instead, GPU's took off as the main computational supplement to CPU's.

Does anyone here have any insight as to why? Is there a technological reason why FPGA's never turned into general-purpose hardware standard on every desktop and laptop? Has it been a chicken-and-egg problem? A standardization problem? Or something else? Do FPGA's still have potential for general-purpose consumer computing? Or are they going to be forever relegated to special-purpose roles?

View on HN

Moore's law is quite amazing.

I believe there are 4 reasons why GPUs have taken off conventionally as compared to FPGAs:

1. Last I checked, the FPGA vendors will not open their toolchains up, and not even document the bitstream formats. They will claim NDA, proprietary, etc. This has the massive side effect that you are stuck with their bloated, slow, crappy toolchains. If this were open, I guarantee hackers would be inventing all kinds of interesting ways to convert their software into FPGA bits.

2. FPGAs are VERY hard to write and debug. You have to write your design in an HDL language (either VHDL or Verilog), and you have to use a software simulator to prototype the design on first (and of course these tools are either quite pricy or if free they are usually limited or hard to use). Then you can synthesize the design and download it into the FPGA for running.

The next problem is debugging your design. The entire internal state of the FPGA is only accessible through slow scan, unless you dedicate a portion of your design to "monitors", which tap the traffic and store their values into internal RAMs. So you may have to respin the design just to get more monitors to debug where the issue is.

3. FPGA compilation is SLOW. When I used them professionally a few years ago, a Virtex5 could take multiple hours to resynthesize/place & route a medium-sized design. I believe that Virtex7 they are advertising could take over a day to respin if you change your design.

4. Most new machines already have a built-in graphics with a GPU that can be utilized as a general-purpose GPU. No one ships FPGAs in any conventional computer.

(2) can probably be addressed with OpenCL -- Altera seems to be working an SDK[1] that allows you to write C code which, as I understand it, would compile to an image that you could then program on to your FPGA (or you could just compile for execution on a processor). So fortunately, no Verilog or VDHL necessary.

(3) is another issue, but I don't think the consumer would necessarily need to worry about compilation. The developer would just include the compiled programming files for different FPGAs in the application.

If you mean that it'll be slow on the developer's side, that's definitely a valid point. I'm sure, however, that you'll see FPGA manufacturers start to move toward remote compilations so that you're not necessarily limited by the hardware you have in-house.

[1] http://www.altera.com/products/software/opencl/opencl-index....

More about (3):

Altera calls it "logiclock," Xilinx has a different term, but the idea is that you don't need to re-synthesize the entire FPGA for every change. In fact, you may not want to. If you are tweaking a certain region, you're usually happier if the place & route doesn't send your stuff through a route that then kicks off a line in another block so that the timings are now off in that other block.

For an FPGA the timing is how you measure performance and getting the best timings can take quite a bit of work. Being able to lock that once you've got it right is a big plus.

Xilinx's ISE calls it "SmartGuide".

It's kind of a mixed bag. It's worked okay for me if changes are truly minor, but if there are large changes to the logic it doesn't seem to be very good about "forgetting" what it learned from the previous pass. Three or four times this week I've had a design fail to make timing with SmartGuide, but work when doing P&R from scratch.

Regarding (3) remote compilations, Altera is lifting off the hardware burdens for developers with remote compilations on cloud. see cloud.altera.com for Altera's tool extension

(2) is called High Level Synthesis. While a great idea, and quite practical, it does not lift you from the burden of understanding the FPGA. Generally you have to make your C code fit a very rigid format that compiles to a pipeline or similar - the advantage is that you can test it as C code, not that you take off the shelf code and run it on a FPGA. There would be no point to that - a hard processor will always be faster at running arbitrary C code.

In addition, most of these tools compile to HDL, so they only add to compilation time.

Probably only 4. matters.

I'm of the opinion that #2-#4 flow from #1. Fix #1 and the rest will eventually go away, so #1 is the one that matters.

My reasoning for each:

#2. More open tools would allow alternative programming models. For example, gcc already has a vhdl front end. Why not a gcc back end for an FPGA? That would open the door to more familiar languages.

#3. More open tools and specifications would allow programmers to start optimising and rethinking the FPGA compilation process, potentially leading to radical reductions in run times.

#4. People won't want FPGAs in their machines until they are easy to use. Solving #1 (and consequently #2 and #3) will make FPGAs easier to use, increasing demand, prompting manufacturers to consider including programmable logic in their machines. Granted its a chicken and egg situation between adoption and better tools, but opening the tools and specifications up could break the cycle.

Regarding your comment on an "FPGA backend" for GCC, you have to understand that simulating a VHDL design (what is implemented) is a drastically simpler task than synthesizing an FPGA image. Logic optimization, place and route, timing analysis--these are things entirely out of the scope of the GCC project, and the details differ significantly between FPGA vendors and between an individual vendor's products. It just isn't a realistic goal.

Agreed, that it is outside the current scope of gcc. Given that gcc is able to handle a simulation, that would indicate that gcc's intermediate representation is able to capture the semantics of a VHDL netlist? That's where I'm starting from.

Assuming the above, I'm thinking of a project, independent of gcc, that takes gcc's intermediate representation and does all the FPGA specific tasks that you mention. Yes, it would be a huge project, comparable in scope to gcc itself, and even that might be an underestimate. It could start small, to make it realistic, then incrementally expand its scope, just like linux and gcc did. Eventually, the FPGA vendors might have to choose between participation or losing customers? It might be able to exploit some of gcc's backend infrastructure in the FPGA process, but who knows?

> It just isn't a realistic goal.

Or it's a red rag to a bull, to the right person. :-)

> #3. More open tools and specifications would allow programmers to start optimising and rethinking the FPGA compilation process, potentially leading to radical reductions in run times.

Including using an FPGA to accelerate that process -- probably possible since from what I know there is a lot of parallelism involved in synthesising logic.

> there is a lot of parallelism involved in synthesising logic.

But not the kind of parallelism that's fast on an FPGA.

#2: Intermediate representations for hardware are vastly different from intermediate representations for software. That's because the execution model for hardware is vastly different from the execution model for software. You'd need a Sufficiently Smart Compiler(TM) to convert from the latter to the former and get even the slightest amount of efficiency (in general – I'm not talking about specialized DSP-filter-to-HDL tools).

#3: No. The information needed for synthesis (HDL to netlist), mapping, and placing is publicly available. These topics are actively researched, yet so far no truly usable open source tool has emerged. Routing tools are not possible without the information available, though.

#4: Sure, solving #1-3 would make FPGAs easier to use, but #2 and #3 don't follow from #1 even if #1 was satisfied.

I'm reminded of Viva from Starbridge which was supposed to make FPGA "programs" easier to build and debug - using large generic blocks.

I have no idea what happened to them, but I suppose the problem was harder than they believed or at least claimed.

It got bought by Data I/O and renamed Azido. I've used it briefly and it made me beg to go back to Verilog.

Wow. That really says something (to me anyway), begging to go back to Verilog.

There are a lot of pain points in the HDLs, but it seems like Verilog has more than the others.

I saw someone working on a clojure HDL, I think it might have compiled down to or emitted Verilog. I thought it was more confusing than the HDLs to begin with, but depending on one's background it might make more sense.

Interesting points. However, it's a bit hard to complain about it being slow (#3) considering the enormous complexity involved, no? I remember compiling things on a 486 (when I got into Linux) being pretty damn slow as well for anything substantial.

I don't mean to excuse the manufacturers, but at the same time they seem to be selling into a pretty small market and it's not clear to me that opening things up will magically lead to a big expansion in chip sales that will negate the competitive risk of being the first to open up. If you have time, I'd like to learn more about this since you seem to have a lot of experience with this technology.

I am certainly not expecting compiling HDL to be the same as compiling software, as yes it is drastically more complicated. However, compile times are growing more than linearly with respect to the number of gates (or logic blocks) that are in each FPGA. Whereas software grows linearly as the programs get larger. Also you have the other dimension of getting your block timed, so it can run on the FPGA at a guaranteed frequency. This is definitely a non-trivial problem, but one that I believe would be better solved by some hackers if there were a "GCC" for Verilog FPGA synthesis.

In my opinion there is very little for the manufacturers to gain by keeping their bitstream formats proprietary and undocumented. I don't think there is a competitive advantage, as all the manufacturers are pretty much doing the same thing. And their FPGA block diagrams are already open and documented (you can see how many flip flops, clocks, and muxes are in each logic cell, how the routing works, and where the memory cells and other units are).

I have only passing familiarity with FPGAs, so perhaps you can excuse my ignorance.

I was under the impression that FPGA vendors often license functional blocks (like PCIe SERDES) to FPGA users. Might it be that part of the purpose of obscuring the bitstream format is to make it more difficult for customers to use those functional blocks without paying the toll?

The bitstream format, at least for Xilinx, is not that obscure. Actually was documented in an old application note.

Take a look at VTR (formerly VPR): http://code.google.com/p/vtr-verilog-to-routing/. It's an academically developed tool for doing FPGA place and route. At the end of the day, you'll still need to use the proprietary tools to convert to the appropriate bitstream, but this an open source solution for the "heavy lifting" portion. However, last I checked the solutions produced by VPR aren't as good as the commercial tools.

> However, last I checked the solutions produced by VPR aren't as good as the commercial tools.

Well, that's no surprise: FPGA vendors spend a lot of manpower on improving their Place&Route software. If you wanted to build something competitive, you'd need a lot of money plus access to proprietary, non-public, information.

Bingo. FPGA routing is NP-Hard; Compiling software is generally P.

If you take the travelling salesman problem, you can dramatically simplify the problem by constraining the salesman to visit all of the cities within the same state sequentially.

Similarly, you can reduce the complexity of routing calculations by applying some constraints. You will potentially lose the possibility of an optimal solution, but you will gain a far faster compilation time. As always with engineering, it's a trade-off.

Yep, global vs. local routers are kinda like stay-withing-the-state.

One of my favorite ideas on this is space-filling curves: http://www2.isye.gatech.edu/~jjb/mow/mow.pdf

Laying out components on a chip and routing non overlapping edges (ie wires) is call "orthogonal edge routing". Graph drawing algorithms don't get much attention outside their niche (oddly to me at least). But this is one area that has profound importance.

I've made a note of the term "orthogonal edge routing", hopefully for eventual incorporation into my own software (http://www.nitrogenlogic.com/docs/palace/). Thanks.

a bit hard to complain about it being slow (#3) considering the enormous complexity involved, no?

It is if the original premise was to make Photoshop filters fast. A GPU can make my Photoshop filters fast now an FPGA implementation can make them fast 8 to 24 hours from now.

Not if you upload precompiled bitstreams into the FPGA.

2. HLS tools exist[0][1][2] to convert C to HLD for FPGA programming, these results are used in production designs. As @jangray says below, debug tools are sold by commercial vendors as a value-added capability for production teams; it's not a "freemium" market.

[0] http://en.wikipedia.org/wiki/High-level_synthesis [1] http://www.xilinx.com/products/design-tools/vivado/integrati... [2] http://www.synopsys.com/Systems/BlockDesign/HLS/Pages/defaul...

I agree with your reasons.

Also, GPUs might be a better match for the kinds of codes people care about. The world didn't need arbitrary bit-level computations except in rare cases, it needed insane memory bandwidth and high floating point throughput (exactly what a photoshop filter would need). The generality of most FPGAs mean they're not great for standard circuits that can be optimized. Maybe this means the FPGA market might see some success with a different trade-off of flexibility vs fixed hardware. The rise of FPGAs like the Zynq with dedicated processors or distributed RAM and DSP units is already happening.

1. is interesting. I always wondered if a completely open FPGA vendor would have any chance in the market.

The GPU vendors dont exactly have open toolchains either. OpenCL is not open in that we get to write assembler for the GPU... It is only a little better.

But GPUs got shipped in volume. I think they were just cheaper for the performance level.

Not sure how relevant it is, but isn't PTX available through LLVM?

LLVM has an open-source PTX backend, and newer versions of the official CUDA compiler use LLVM to generate PTX internally, but PTX is a device-independent intermediate layer, and the PTX-to-SASS compiler is closed-source.

"You have to write your design in an HDL language"

What???? There is a very mature set of tool for converting MATLAB to HDL.

http://www.mathworks.com/products/hdl-coder/

http://www.mathworks.com/products/hdl-verifier/

http://www.mathworks.com/products/filterhdl/

I'm sure there are similar tools for other languages. It requires you to program in a slightly different way (certain operations aren't optimal for FPGAs), but is extremely user-friendly.

At the company I work for, all FPGA programming is done in MATLAB. Unfortunately I work in a different department so I can't give you any technical details, but from what I understand, no one has written things directly to HDL in years.

    Some people, when confronted with a problem, think
    "I know, I'll use MATLAB." Now they have two problems.

(Apologies to jwz.)

It depends on what you are doing. There are tools in the Xilinx tool set enabling you to design filters or other things in MATLAB Simulink, which are very convenient. But if you want to write a processor, however small, you cannot really do that well. Because the hard part is getting a good design with proper timing and synchronization between different parts. I think it's harder to get such a good design using MATLAB/C to HDL tools than it is designing directly in HDL.

I can answer this, as an electrical engineer.

FPGA's are horrendously inefficient, space and power-wise, for many tasks. Much of the core is taken up by the programmable routing between different components, and generally most components will be not fully utilized (such as LUTs and RAM).

Yes, the Virtex-7 (a VERY EXPENSIVE fpga) can hold 1000 very simple 32 bit cores.... but a top end NVIDIA GPU has 2688 CUDA cores. While not entirely independent, these CUDA cores have far deeper pipelines and far superior ALU's to the one in the article. If your software fits the programming model, GPUs will handily beat a FPGA.

FPGA's are great for prototyping ASICs, and cases where timing is of critical importance - try implementing a VGA video generator on a CPU. Basically everywhere an FPGA would excel, an ASIC excels more, but FPGAs are great for low volume and or specialty hardware where a GPU is not good at accelerating the task at hand.

Agree with yout points that FPGAs are great for low volume prototyping/one-offs, interfacing, and when timing is of critical importance.

> the Virtex-7 (a VERY EXPENSIVE fpga) can hold 1000 very simple 32 bit cores.... but a top end NVIDIA GPU has 2688 CUDA cores.

But the point of the FPGA is to not build cores inside it; the OP article is just an exercise. Application specific logic built with FPGA might be much more efficient than generic CUDA cores.

Also, it is a given that an ASIC will be more power efficient than an FPGA, but the FPGA will be generic and hence more money efficient.

A contributing factor is that the Partition-Place-Route (PPR) software, that is necessary to map a design onto the FPGA die, is proprietary and controlled very tightly by the FPGA vendors, as are the specifications of the raw dies and the meaning of each bit in the corresponding bitstream.

Consequently, FPGAs don't lend themselves to an uncontrolled explosion of innovation. Compare with GPUs and CPUs where open source compilers are available and anyone can have a crack at innovating, at whatever level they choose.

As an example, if you want to dynamically generate programming for a Xilinx FPGA, you need to incorporate Xilinx's binary only PPR program somewhere into the flow. That acts as a ball and chain around the leg of reconfigurable computing, impeding its development and adoption.

One guess would be that GPUs address a wider market segment (everybody needs a display + hardware to drive it). More people buying GPUs, lower prices, more $$$ for R&D, repeat.

Another likely issue with FPGAs is that for everything but raw compute they still need support circuitry (physical I/O ports, memory interfaces, etc) that are different for every app but not really "reconfigurable" in the same sense as the FPGA fabric.

Finally, I'd wonder if reconfiguration time is part of the problem - until relatively recently, reconfiguring an FPGA was all-or-nothing and could take multiple milliseconds. Not a big deal when configuring a device once on boot, but serious headwind when trying to context-switch between different jobs that need FPGA assistance.

I think GPUs took off because the specific problems they solve were quite well-defined and enough people in the videogame/3d grapics market agreed about which protocols to use. Even for things like Photoshop and other general-purpose graphics software, GPU support seems to be a bit hit and miss.

I actualy have 2 FPGA-based devices that I use daily - polyphonic analog synthesizers, to be specific. Manufacturers are tight-lipped about how they're using the FPGAs, but it appears to be for ultra-rapid reconfiguration of analog circuit topologies without the load time delays that result from a traditional microcontroller > D/A converter arrangement. There are also field-programmable analog arrays on the market, but I have yet to see one in a commercial product and it seems like they have some way to go before being economical for audio synthesis applications.

I love FPGAs although I don't know much about how to et started with programming them. There is an ASIC coming out of patent in a year or so which I'd like to re-implement in an FPGA package, and I've thought about reaching out to the original architect who lives nearby and is a friendly fellow. I'm not sure how feasible this is, though.

To get started with FPGAs just download one of the free IDEs and have a play. You can buy dev boards for under $100 to get some feedback that what you are doing really works.

Can you recommend some boards? Whenever I looked into it, I got overwhelmed with all the options and I was not quite sure what to look for.

The Altera DE2 is great to start off with, and it's also heavily discounted for University students.

The Basys 2 is a little old, but it's very simple and easy.

The DE1-SoC board is $199 or $150 with a student discount. http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=E...

It has an ARM processor on the same chip as the FPGA, which I've found to be incredibly useful.

If you don't want the ARM processor, the regular DE1 is somewhat cheaper: $150 or $125 w/ student discount.

http://www.terasic.com.tw/cgi-bin/page/archive.pl?Language=E...

Yeah, the SoC boards a nice. So much of what you want to do on an FPGA these days requires the use of a processor anyhow, you might as well have an actual hard block instead of a NIOSII or whatever. We use DE1's at my company as the FPGA analog (pun not intended) of a Arduino Uno, for when we want to do a quick test of some part of a design in hardware, or want to stick the device into something but don't want to tie up a high end unit for something trivial.

Be aware that the DE1 has pretty limited resources for somethings. For exmaple, the on-chip memory can get tapped out pretty quickly when doing embedded applications, and it has less I/O and less RAM available off-chip.

Also note that the DE1-SoC actually uses a Cyclone V device, whereas the original DE-1 uses a Cyclone II, a nearly discontinued chip that is a big step down.

Intrigued by FPGA's capabilities, when checking out my classmate's profile http://orangesorter.com/, I started looking into some development kits to learn.

I found great documentation and economical boards starting at $55 available here: http://www.xess.com/store/fpga-boards/

BTW, I also found Scala based hardware construction language Chisel very interesting https://chisel.eecs.berkeley.edu/.

The "Parallella" hybrid board is awesome, but unfortunately has been saturated by orders, probably due to being $99. It contains a Xilinx dual ARM CPU with FPGA plus a custom Epiphany 16-core processor. http://parallella.org/

Which synthesizers?

An Elektron Analog Four and a DSI Tempest (possibly about to be replaced with another Elektron box). I can dig up pictures of the PCBs if that's helpful but I don't have the knowledge for detailed analysis of how it works.

Thanks for the other replies on dev boards etc.

I'd second the DE2 suggestion. It's a cheap, but pretty versatile board. It has lots of companion demos and tutorials, as well as a ton of resources online from other starters asking "How the heck do I do <task> on my DE2???" on forums and such.

Quartus II Web Edition is Altera's free IDE, and it comes with pretty much everything you need: a big suite of libraries (most of which are also free to use), a graphical entry environment, an HDL editor, the full synthesis toolchain, and integrated Eclipse tools for writing embedded C/C++/ASM code. Other than that all you'd need to get is ModelSim-altera, the free version of the standard simulation environment.

Altera also has some pretty comprehensive (i) free online training, (ii) IP block, i.e. library, documentation, and (iii) complete reference designs. I'd recommend checking out all three, especially (i), since at the beginning it's easy to get tunnel vision just learning VHDL or whatever, and then realize that you're somewhat clueless as to how to actually get things done in any useful capacity. There's a dizzying amount of jargon and proprietary bullshit, so it's useful to just have someone tell you what everything means, and How It's Done(tm).

All that said, if that ASIC is anything complicated it might be a bit of a big project to jump into. That and it's possible that it would require more resources than an entry level board will supply.

Anytime an algorithm is important enough to be of interest for hundreds of millions of user it is worth the investment to etch its primitives into silicon. And if there are new and exciting computations that will only be in hardware next year, CPUs are powerful enough that software can tide us over until the silicon arrives.

Especially when the price of entry to ASIC land is relatively low by industrial standards - http://electronics.stackexchange.com/questions/7042/how-much...

eg for something very simple you can do it for thousands or tens of thousands...but in that price range it's probably still more economical to implement in software or do it discretely with SMT unless you are very sure about the existence of a market.

It's not cheap. If you want to compete wit cpu/fpga/gpu ,you'll need to use the latest manufacturing processes and do complex designs,and now we're talking about more than 100 million USD investment.

Not unless you're trying to compete with Intel. Consider the various bitcoin ASIC miners: beat all other technologies for solving that problem for an investment of a few million.

However, algorithms are so rarely the stumbling block for applications; data storage, management and communications are. The major exception is graphics, hence the GPU.

a bitcoin miner isn't a isn't a general processing unit.It does something specific that's very very easy to optimize and implement, and you don't use latest manufacturing process but tools like easic , hence the small investment.

Hence my comment about it being cheap for very simple applications. If you want to compete with market leading vendors then yeah of course it's going to be hideously expensive.

I don't think he was suggesting that developing a general process cpu that is competitive with Intel's offering costs only 10k. He said that getting your ASIC design, i.e. application-specific integrated circuit, etched into silicon is cheaper than is used to be and that's true. I know guys who implemented things like novel power converters on an IC as their masters projects, using only the budget of, well, master projects.

The money is a huge barrier to entry for hobbyist types, but if we're talking about commercial stuff, it'll probably cost you a lot more to pay for the engineers who are competent enough to implement something that will actually work than it will to do the fabrication.

Pretty much the same answer from a CPU researcher formerly at Intel, in a reddit AMA.

"I like FPGAs, but I doubt they will ever become widely deployed. They pay ~20x overhead, so any algorithm that is a good fit for them becomes a new instruction in the next CPU generation. The reprogrammability is only a feature in highly constrained (i.e. niche) environments."

http://www.reddit.com/r/IAmA/comments/1yj77b/as_requested_i_...

Somewhat tangential, but the open hardware laptop that bunny and xobs are designing has a built-in FPGA, so you aren't the only person who thinks it would be nifty to have one. Personally, I think it'd be lots of fun to hack with and would open up a lot of interesting projects (perhaps a port of the 2048 game to an FPGA??).

http://www.kosagi.com/w/index.php?title=Novena_Main_Page

They don't have that FPGA to offload the CPU, I think its rather to interface with external components. GPUs don't come with external IO and for a lot of high-speed buses you are just dead in the water without an FPGA to handle the delicate timing.

That is really the unique benefit of FPGAs: the implicit parallelism makes them a really great fit for the kind of high-speed bit banging that would be impossible to get right on a normal CPU (not to mention very difficult to program in the first place).

How do you virtualize an FPGA? A GPU can be virtualized and shared between several processes. It takes waaay too long to flash an FPGA to implement time-division multiplexing on it. All you can do is "slice up" the FPGA and give different processes different portions, and even that is a security vulnerability waiting to happen unless the FPGA is designed to keep these "blocks" separately contained.

How do you balance the need for high-performance communication between the FPGA and the rest of the computer with the inherent inability to trust whatever configuration has been loaded into the FPGA? Software security is hard enough without infinitely reconfigurable devices lurking inside our machines.

How does a possible FPGA configuration work optimally across a wide variety of FPGAs (which can have various "built-in", non-reconfigurable components) and sizes that can only be determined at "flashtime"?

What exactly do regular users need an FPGA for that isn't already handled by dedicated silicon with much greater performance and much less power usage than an FPGA would?

EDIT: I'd like an FPGA card for my PC just for running FPGA "emulators," because you can recreate a SNES or whatever in a tiny fraction of the gates that you need to make a CPU capable of emulating it with cycle accuracy at full speed. I seriously doubt there's much demand for that, though: if you're going to go to the trouble of buying special hardware for emulation, you might as well just buy the console and a flash cart.

I would imagine that the FPGA would not be shared. Much like only one app can be full-screen on your computer, only one process could use the FPGA. The OS wouldn't let a second process use it if a first process already was.

As for regular users, personally I'd like it for video codecs. I'd like it for video transcoding. I'd like it for faster MP3 encoding. I'd like it for Photoshop filters. I'd like it for speech recognition. I'm sure I could think of things that other users would like to use it for, like 3D rendering. I don't know of dedicated silicon that does ANY of these things, except specifically for H.264 decoding. That's it. And the thing is, for all the items I've listed, it's totally fine that my computer is only ever doing one of them at a time. These are all "regular user" uses, whereas virtualization is not needed very much for regular users.

Most of the uses that you mention involve processing large (ish) amounts of data, and that's one of the drawbacks to GPUs. They're great as long as everything fits into the amount of RAM on the card. Otherwise you're limited by the PCI bus and you're constantly shuttling data back and forth from main memory. It's frustrating when you only have 6GB of RAM on the GPU and 96 or more attached to the CPU. They're just not that good at data processing.

Macbooks supposedly contain FPGA chips (Google around but it's mentioned for example here [1] go to "step 13"). I was trying to look into it a while back but I don't think I ever got some definite answers as to what they are used for.

[1] http://www.ifixit.com/Teardown/MacBook+Pro+15-Inch+Unibody+M...

FPGAs aren't particularly hard to find in the PC ecosystem, especially on first-gen parts or custom jobs like Apple machines. I've seen some SSD and RAID controllers ship as FPGAs, and some sound cards bundling them for DSP use. They're usually not reprogrammable.

1) FPGAs are not easy to develop for, and totally different from the skillset of a Photoshop developer. It is not as easy as dreaming up a design and pressing a button; if you are anywhere close to pushing the envelope it takes expertise & time.

2) GPUs, being purpose-built and mass-marketed, are both much cheaper and much faster. Think of the Ford Fiesta ST vs. a Jeep Wrangler. The Jeep is simple & more reconfigurable, yet is slower and more expensive- for exactly those reasons!

3) GPUs and CPUs compliment eachother well. The only gap is heavily parallel branching code- GPUs are bad at if-statements, CPUs are bad at heavily parallel. But a branch predictor is the key to if-statements, and branch predictors are hard.

FPGAs are fundamentally a prototyping tool. Can you think of examples of prototyping tools that eventually broke into the main market, replacing the incumbent product?

>FPGAs are fundamentally a prototyping tool. Can you think of examples of prototyping tools that eventually broke into the main market, replacing the incumbent product?

Python

> FPGAs are fundamentally a prototyping tool.

FPGAs can be used for prototyping ASICs, but that's by far not their major use-case.

What is then? I know they are used alongside PLDs, but I thought PLDs still dominated that use-case.

They are essentially low-volume ASIC replacements. Some applications:

- digital signal processing (DSP)

- network equipment (modern high-end FPGAs are able to function as 100G Ethernet switches and routers, just connect them to some PHYs and fast DRAM)

- systems on chip (SoC): processor, fast DSP, all kinds of IOs, memory controller – all on a single chip

- realtime video stream processing

For more examples, see http://www.xilinx.com/applications/index.htm

In general GPU's are same or better in floating points per given area of silicon. on top of that , FPGA's add other expenses due to lower market size.

Maybe FPGA's are competitive in integer math, but that's a pretty small niche ,not big enough for a coprocessor.

Very few common user tasks can be solved more efficiently with an FPGA than with a CPU or GPU.

CPU gives you speed in computation. Except for a custom ASIC, nothing can match a modern CPU in single thread speed.

GPUs gives you parallelism. You can get thousands of decent CPUs in cheap boards today.

IMHO FPGAs main advantages today are bandwidth and auditability. But neither are very important in most applications.

I also had to implement simple microprocessor on an FPGA about 10 years ago.

I think one of the main reason is programming the FPGA is not easy, the tools needed for FPGA development are all proprietary. Every FPGA has different way to program it.

Maybe in the next 5 years, when Moore's law may run out http://en.wikipedia.org/wiki/5_nanometer (unless Intel et al. have some extraourdinary technology up their sleeves) we will finally see the advent of FPGA's?

Without the annual growth of transistor density, the second best avenue to gain performance will probably be specialization, and reconfigurable specialized hardware looks more attractive than fixed one.

Given everyone would have different models, the compilation process (including placing and routing) would absolutely destroy things. I've seen them take 1+ hours on a fairly fast machine. The problem with connecting N logic blocks is that you need N^2 buses to connect them directly to one another. Luckily they aren't but that's why the placing/routing optimization problem takes so long to compute as transistor count is now in the billions.

GPUs were "there" and there was a logical path towards increasing their usefulness. It was partly an accident that they're not more programmable.

Technology sucks :(

Didn't Cyrix cpus have some fpga in them, that would be dynamically assigned to any repetitive code that the cpu was busy doing?

I think a big reason is the chicken-and-egg problem. GPUs gained large spread adoption because of their use for gaming. It's only relatively recently that they've been exploited for more general compute purposes. There hasn't really been a "killer app" for FPGAs that warrants many people to have one.

Speed. Reconfiguring an FPGA is a very slow process, and FPGA's can't match the clock speeds of conventional ASICs. That may change in the near future with FPGA-like devices built using memristors, which potentially could be reconfigurable at the speed of writing RAM and run at the same clock speeds as any ASIC.

Actually, modern FPGA are "capable of dynamically reconfiguring at multi-GHz rates": https://www.tabula.com/technology/technology.php

That's marketing hype. If you reconfigure just one gate it can be extremely fast, but typical FPGAs take a significant fraction of a whole second to reconfigure. Though they are getting faster over time.

Did you even read how their chips work?

Not a direct answer, but it's not just GPUs: on ARM "System on a Chip", you can get all sorts of components: audio, hardware codecs, networking, radio, and low-power companion cores (littlebig).

So, your vision of general-computation-in-silicon has occurred, just static, not dynamic.

I wonder how many people would have bet on GPUs in the late 90s. Even high-end 3d chipset were ousted quite brutally (3dlabs, evans & sutherlands) from the gpu market by small 'gaming' companies. And now they invade server side computations... quite funny.

> Does anyone here have any insight as to why?

1. They are already there in commodity HW.

2. GPU vendors make money with their hardware; they need not extort developers for a development environment like FPGA vendors think they have to do. Therefore, development for GPUs has a lower barrier of entry.

I have very limited knowledge of the subject, but I had an impression that GPUs started to catch up on programmable capabilities with shaders. As far as I know, shaders reprogram the rendering pipeline, so is it a kind of specialized HW programming?

FPGA are still more costly when compared to ASIC in large volume. Some of these high end FPGA can run $1K to $10K assuming you have even access to them due to their limited availability.

Most applications don't really need the flexibility of an FPGA. Just having massively parallel multiply-accumulate turns out to cover huge amounts of digital signal processing and machine learning applications.

A long time ago computers sometimes came with DSPs dedicated to Photoshop-like programs. The GPU is a logical extension of that. The FPGA is something entirely different.

They were used in the late 90s, and companies such as Cray had C to FPGA compilers. These were implemented as c style calls that the compiler transformed to FPGA.

The coding was hard and performed below expectation. The only customers that benefited were military/intelligence agencies who were using outdated techniques such as filtering in the Fourier basis.

The problem was data-transfer compounded by inflexible code generation. The data still needed to travel from RAM which meant that even without computation you couldn't get over a 50% increase in performance. It would need to be send back for more complex processing.

Reply on news.ycombinator.com