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…
FPGAs Need a New Future
61–70 of 170 posts
Re: FPGAs Need a New Future
#62Earlier 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…
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
#63FPGAs 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…
Re: FPGAs Need a New Future
#64Earlier 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 should check my spam folder.
Re: FPGAs Need a New Future
#65Earlier 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.
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
#66Xilinx, 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
#67My 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…
HDL isn't getting any easier, though, and that's where most of the complexity is.
Re: FPGAs Need a New Future
#68Re: FPGAs Need a New Future
#69Earlier 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.
Re: FPGAs Need a New Future
#70I 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…
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.