Comment by namank | Hacker News Reader

Comment by namank | Hacker News Reader

Parent Full thread

Would you trade off developer time to figure out how many registers to use, how many pipeline stages you want every single time you need to write code? How many of your developers are apt at figuring that out? And that's a decision you have to make every time you want to add a feature because FPGA architecture is, more often than not, dependent on the business logic you want it to encapsulate. It's cheaper to get an Arduino instead.

FPGAs look very attractive when you're used to comparing C#/Python/Java/everything to C but that fades away as soon as the complexity in managing code on FPGAs comes to light.

All the points mentioned in the article under "performance"? It's left up to you, the developer, to configure the board in such a way that you can leverage them. And that's before you've written a single line of the business logic.

In theory, FPGAs give you the power to code your business logic as circuits (making it monumentally faster) but in practice, the story is very different. You may want to look at High Frequency Trading - they use FPGAs for stock analysis there.

I worked at one of the first companies to ship a program with OpenGL ARB Fragment Shaders, so yeah, we traded developer time for customer performance. Managing the code was an utter nightmare, and we developed a ton of custom tools to try to tame that beast. If we'd had something like LLVM available at the time, it would have been a godsend.

And yes, getting performance out of the video card was left up to us, and that was a beast.

I'd think the single most important factor would be the data you had, and the operations you needed to perform on them. If your business logic was amenable to FPGA, then it might make sense...

When you need an FPGA, you need an FGPA. I don't think anyone would spec out one gate at a time if C and an operating system could cut it.

For example, I once purchased an oscilloscope that could measure up to ... I forget, but it was probably either 200MHz or 500MHz. Anyway, it was a hobbyist scope, so the manufacturer could not afford custom silicon. Nor, I presume, could the speed requirements be met by a DSP chip. They used a microprocessor mated to an FPGA to do signal capture & processing, which was fed to the microprocessor.

But that's not the contention here; those applications are outside the domain of most programmers, including embedded developers.

"embedded" encompasses a host of different applications- many of which either could benefit from an FPGA, or might benefit from prototyping on an FPGA for custom silicon.

Somewhat true.

I think the OP is targeted at programmers en masse. So, if we were to pick majority of embedded programmers and see if their application would benefit directly from an FPGA, I'm fairly certain my previous post would come in to play.

Reply on news.ycombinator.com