[kop316]

"The adoption of FPGA technology in the market has always been limited by the severe learning curve required to take advantage of it."

I vehemently disagree with this. FGPAs and their toolchains are notoriously expensive and proprietary. I have no doubt that if tool chains were opened up and an average person could program for it, you would see much more.rapid adoption because then an average person could start the learning curve much easier

[tfmkevin]

The "average person" cannot program for it. I've managed teams as large as 60 extremely competent full-time EDA engineers working for years on only the synthesis portion of the problem. It is FAR more complex than, say, developing a compiler. Both Xilinx and Intel have more engineers developing FPGA software tools than they do developing FPGA hardware. It's a common misconception that just any group of competent software engineers could whip out better FPGA tools if they only had access...

[jhallenworld]

I also disagree. The main problem is much simpler: they cost too much for fundamental reasons. The die-size for an FPGA that would have equivalent power of an Intel CPU or Nvidia GPU would be huge and expensive.

[Traster]

That's simply not right. The FPGA in your NIC is much more powerful for packet processing than any CPU or GPU. Yes, the CPU is better at being a CPU- but that's just a matter of using the right tool for the job.

[aseipp]

What does "equivalent power" even mean? It's completely useless without any qualifiers or specific metrics/goals.

My Nvidia GPU also doesn't run x86 programs at the speed of my desktop, but I never expected it to. It's true in the vacuous sense only.

[jhallenworld]

They are all Turing machines, all that matters is can I run my algorithm at higher performance than equivalent priced conventional solutions.

[rowanG077]

This is incredibly naive. There are algorithm where CPU but GPU easily. There are also algorithms where a GPU beats a CPU easily. There are also algorithms where an FPGA beats a GPU and a CPU easily. You simply can't say x is better then y in general. They all have their own domains.

[rowanG077]

This. It's not so hard, any competent software engineer could learn HDLs in one or two weeks. The fucking toolchain though? Months...

[PAGAN_WIZARD]

Ive seen plenty of HDL written by people who are software engineers, it's not good. It seems to me most software engineers struggle with visualizing their behavioral code as a schematic and tend to write code that is not very synthesis friendly and overly convoluted. Not to mention most issues with hardware engineering cant be solved by a google search of how to do X in Verilog/VHDL, problems tend to be device specific which means you NEED to understand your tool chain and can't abstract away the code from from the implementation like you can with most high level software to the ASM/binary.

[rowanG077]

I have seen some code written by software engineers that was bad and also a lot that was good. They simply need to be taught how HDLs work which is conceptually simpler then something like C++.

I very much disagree that most issues are hardware specific. FPGAs all work the same way. What is different is the IP that can be ran on different FPGAs but that is generally a tooling problem not inherent to the problem domain.

[Traster]

Software Engineers can learn HDLs in one or two weeks about as well as hardware engineers can learn C++ in one or two weeks. Will they get to something syntactically correct? Sure. That doesn't mean what they'd be able to write would be useful. And it's not just the toolchain, it's about understanding that HDL isn't a tool for programming FPGAs, it's a tool for programming hardware and FPGAs are one very specific target for which writing performant code requires a high level of knowledge about the underlying structure of the FPGA.

[rowanG077]

HDLs are conceptually much, much simpler then C++. HDLs actually are a tool for programming FPGAs, that this is actually programming hardware is an implementation detail.

[enos_feedler]

It's a chicken and egg problem too. Toolchain friction and depth of knowledge required is one part. Ubiquity of FPGA silicon lying around in the average programmer's (and end-user's) machine is not there.

[kbob]

Silicon availability has recently been solved. There are FPGA dev boards available for under $50. They're low-powered but great to learn on. One, the FOMU, actually fits inside a USB type-A port.