Live data from Hacker News

FPGAs Need a New Future

allaboutcircuits.com

61–70 of 170 posts

Re: FPGAs Need a New Future

#61
post #52
post #28

Earlier quoted context omitted.

I can't say I agree with you here, if anything FPGAs and general purpose microprocessors go hand in hand. It would be an absolute game changer to be able to literally download hardware acceleration for a new video codec or encryption algorithm. Currently this is all handled by fixed function silicon which rapidly becomes obsolete. AV1 support is only just now appearing in mainstream chips after almost 8 years, and so…

But why would it be amazing? The alternative right now is that you do it in software and just dedicate a couple of cores to the task (or even just put in a separate $2 chip to run the decoder). Like, I get the aesthetic appeal, and I accept that there is a small subset of uses where an FPGA really makes a difference. But in the general case, it's a bit like getting upset at people for using an MCU when a 555 timer wo…

Battery powered or thermally constrained devices.

Re: FPGAs Need a New Future

#62

Earlier quoted context omitted.

> sometimes … sometimes … sometimes … And sometimes you need support for multiple IO standards. I don’t understand what point you’re trying to get across. But if all you need is LVCMOS33, why do you not use a MAX10 FPGA with built-in voltage regulator? Or a similar FPGA device from GoWin that is positioned as a MAX10 alternative? What is wrong with those? > JTAG On our production line, we use JTAG to program the FPGA…

> I don’t understand what point you’re trying to get across. My point is twofold: 1. There are many niches. Your main needs are not the same as my main needs. And my needs are poorly met by existing products, so I want to see something better. (And I do buy chips.) 2. All of this is way, way harder than it needs to be. It could be easy, but it isn't. Everything is possible right now. But I wasn't random when I used t…

> make them easy to drop in instead of pains in the butt

How much easier does it need to be than putting down a single 1mm^2 LDO and a QFN IC? Is this really that difficult?

Re: FPGAs Need a New Future

#63

FPGAs need their "Arduino moment". There have been so, so, so many projects where I've wanted just a little bit of moderately-complicated glue logic. Something pretty easy to dash off in VHDL or whatever. But the damn things require so much support infrastructure: they're complicated to put down on boards, they're complicated to load bitstreams in to, they're complicated to build those bitstreams for, and they're com…

It's basically because they're so locked down, hard to get docs, stupid toolchains and ides like others have mentioned. It's like fpga companies don't want people using them, much like others like the pixart sensor I wanted to use: NDA because some parasite dipshit executive or manager thinks that register layouts are extremely sensitive information. I've had dozens of uses for an fpga...but every single time I just…

None of these things are true for the new, cheap Chinese contenders.

Re: FPGAs Need a New Future

#64
post #39

Earlier quoted context omitted.

> and quite a bit worse than just dealing with an MCU. Unless you're using some kind of USB DFU mode (which is annoying on assembly lines), SWD-based flashing of an MCU is substantially more complicated than the JTAG sequences that some internal-flash FPGAs use for programming.. These chips are just as easy or easier to program than any ARM MCU. Raw SPI NOR flash isn't "easy" to program if you've never done it before…

It's mostly the whole "two binaries" problem. Oh look, the factory screwed up and isn't flashing the MCU this week! Does the board survive? Oh look, the factory screwed up and isn't flashing the PLD this week! Does the board survive? Oh look, the factory... wait, what is the factory doing and why are they putting that sticker on that .... You get the idea. Yes, yes, it is all solvable. I have never claimed it isn't.…

I honestly start to wonder how in the world we survived flashing 3 different binaries, for years (bitstream, 2 MCUs), without ever getting a complaint from the production floor.

I should check my spam folder.

Re: FPGAs Need a New Future

#65
post #52

Earlier quoted context omitted.

But why would it be amazing? The alternative right now is that you do it in software and just dedicate a couple of cores to the task (or even just put in a separate $2 chip to run the decoder). Like, I get the aesthetic appeal, and I accept that there is a small subset of uses where an FPGA really makes a difference. But in the general case, it's a bit like getting upset at people for using an MCU when a 555 timer wo…

Battery powered or thermally constrained devices.

...which are playing back video, so they're likely blowing most of their power budget on the display and on radio. I guess my threshold of "amazing" is different. Again, I'm not denying some incremental utility in specialized uses, but most of the time, it just doesn't seem to be worth the pain - especially since nothing about the implementation will be portable or maintainable in the long haul.

In the same vein, no one is writing a smartwatch software stack in 100% bare-metal assembly, although in the hands of a capable developer, I'm sure it could prolong battery life.

Re: FPGAs Need a New Future

#66
My prediction is one of the Chinese FPGA makers will embrace open source, hire a handful of talented open source contributors, and within a handful of years end up with tooling that is way easier to use for hobbyists, students, and small businesses. They use this as an inroad and slowly move upmarket. Basically the Espressif strategy.

Xilinx, Altera, and Lattice are culturally incapable of doing this. For lattice especially it seems like a no brainer but they don’t understand the appeal of open source still.

Re: FPGAs Need a New Future

#67
post #66

My prediction is one of the Chinese FPGA makers will embrace open source, hire a handful of talented open source contributors, and within a handful of years end up with tooling that is way easier to use for hobbyists, students, and small businesses. They use this as an inroad and slowly move upmarket. Basically the Espressif strategy. Xilinx, Altera, and Lattice are culturally incapable of doing this. For lattice esp…

Gowin and Efinix's tools are extremely spartan compared to Vivado or Quartus: they're pretty much straight HDL to bitstream compilers. There's also a FOSS implementation flow available for the Gowin chips (but I haven't used it.)

HDL isn't getting any easier, though, and that's where most of the complexity is.

Re: FPGAs Need a New Future

#68
I imagine FPGA could just be part of general CPU that provides user space APIs to program them to accelerate certain work flow, in other words, this sounds like exactly JIT to me. People may program FPGA as they need to, e.g. AV1 encoder/decoder, accelerate some NN layers, or even a JS runtime, am I thinking something too wild for hardware capability or is it just the ecosystem isn't there yet to allow such flexible use cases?

Re: FPGAs Need a New Future

#69

Earlier quoted context omitted.

Or you could do the right thing, ignore the GUI for 99% of what you’re doing, and treat the FPGA tools as command line tools that are invoked by running “make”…

This is how most FPGA users interact with vivado/quartus these days.

One really wonders when reading some of the comments here…

Re: FPGAs Need a New Future

#70

I imagine FPGA could just be part of general CPU that provides user space APIs to program them to accelerate certain work flow, in other words, this sounds like exactly JIT to me. People may program FPGA as they need to, e.g. AV1 encoder/decoder, accelerate some NN layers, or even a JS runtime, am I thinking something too wild for hardware capability or is it just the ecosystem isn't there yet to allow such flexible…

Digital logic design isn't software programming, and today's FPGAs are for most intents and purposes 'single-configuration-at-a-time' devices - you can't realistically time-slice them.

The placement and routing flow of these devices is an NP-Complete problem and is relatively non-deterministic* (the exact same HDL will typically produce identical results, but even slightly different HDL can produce radically different results.)

All of these use cases you've mentioned (AV1 decoders, NN layers, but especially a JS runtime) require phenomenal amounts of physical die area, even on modern processes. CPUs will run circles around the practical die area you can afford to spare - at massively higher clock speeds - for all but the most niche of problems.

Post reply on HN