Live data from Hacker News

FPGAs Need a New Future

allaboutcircuits.com

51–60 of 170 posts

Re: FPGAs Need a New Future

#51
post #39

Earlier quoted context omitted.

> you’d have to drop support for multiple voltage rails and thus multiple IO standards, which is exactly what you don’t want to lose. Yes? Yes it is? 9 times out of 10, my entire board is LVCMOS33. I would love to have the option to drop all of the power rail complexity in a simplified series of parts. Sometimes you need maximum I/O speed. Sometimes you need maximum I/O flexibility. Sometimes you need processing hors…

> 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 am just claiming it is a giant pain in the ass and limits use of these things. I will bend over backwards to keep boards at one binary that needs to be loaded.

Re: FPGAs Need a New Future

#52
post #28
post #12

To folks who wax lyrical about FPGAs: why do they need a future? I agree with another commenter: I think there are parallels to "the bitter lesson" here. There's little reason for specialized solutions when increasingly capable general-purpose platforms are getting faster, cheaper, and more energy efficient with every passing month. Another software engineering analogy is that you almost never need to write in assemb…

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 would do. Sure, except doing it the "right" way is actually slower, more expensive, and less flexible, so why bother?

Re: FPGAs Need a New Future

#53
post #38

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…

> they're complicated to put down on boards https://gowinsemi.com/en/product/detail/46/ - Requires just 1V2 + 3V3 - Available in QFN - Bitstream is saved in internal flash or programmed to SRAM via a basic JTAG sequence https://www.efinixinc.com/products-trion.html

> Contact Sales

> Request Sample

> Please login to download the document.

I mean, yeah. My argument isn't that anything is impossible. My argument is that all of this is harder than it needs to be and this is not countering me!

Re: FPGAs Need a New Future

#54

Earlier quoted context omitted.

> you’d have to drop support for multiple voltage rails and thus multiple IO standards, which is exactly what you don’t want to lose. Yes? Yes it is? 9 times out of 10, my entire board is LVCMOS33. I would love to have the option to drop all of the power rail complexity in a simplified series of parts. Sometimes you need maximum I/O speed. Sometimes you need maximum I/O flexibility. Sometimes you need processing hors…

> 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 the dreaded A-word ("Arduino"). Arduino is a kind of horrible product that did not make anything possible and did not really invent anything. It did not make anything really hard suddenly become easy. Hard things before Arduino were still hard after Arduino. It "just" made some things that used to be medium-hard pains-in-the-butt actually really quick and easy (at a little backend complexity cost: now you've got the Arduino IDE around, hope it doesn't break!).

It turns out that is very valuable.

And is what I would like to see happen with FPGAs: make them easy to drop in instead of pains in the butt. All pieces for this exist, nothing is new tech, no major revolutions need to happen. "Just" ease of use.

Re: FPGAs Need a New Future

#55
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.…

Embed the bitstream into your MCU firmware binary, bitbang the 50-100KB bitstream into SRAM via JTAG from your MCU in all of 10ms. This is <100 lines of Rust.

Re: FPGAs Need a New Future

#56
post #38

Earlier quoted context omitted.

> they're complicated to put down on boards https://gowinsemi.com/en/product/detail/46/ - Requires just 1V2 + 3V3 - Available in QFN - Bitstream is saved in internal flash or programmed to SRAM via a basic JTAG sequence https://www.efinixinc.com/products-trion.html

> Contact Sales > Request Sample > Please login to download the document. I mean, yeah. My argument isn't that anything is impossible . My argument is that all of this is harder than it needs to be and this is not countering me!

This is your job, and it really shouldn't feel difficult. This is really not tedious: the minimum board design for these chips literally consists of just power, JTAG pins, and a clock (if the internal oscillator isn't good enough.)

The Gowin FPGAs are available (at a massive premium) from Mouser, just like whatever MCU you are already using. Many are available for All of the Gowin documentation is available on their site with a free, approval-less email login and no NDA, or via Google directly (PDFs, just like Xilinx, even numbered similarly.)

Re: FPGAs Need a New Future

#57
Here’s the first big misconception: HDL is hardware. It isn’t. HDL is software and should be managed like software.

Yes, that's certainly a big misconception. Maybe not the one the author meant to call out, but... yes, a big misconception indeed.

Re: FPGAs Need a New Future

#58

This article is a rant about how bad tools are without going into specifics. "VHDL and Verilog are relics", well so is "C" but they all get the job done if you've been shown how to use them properly. "engineers are stuck using outdated languages inside proprietary IDEs that feel like time capsules from another century.". The article misses that Vivado was developed in the 2010's and released around 2013. It's a huge…

"VHDL and Verilog are relics", well so is "C" but they all get the job done if you've been shown how to use them properly.

Or how to use an LLM properly.

Re: FPGAs Need a New Future

#59

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 can't be bothered. Why, when they make it a pain in the ass on purpose.

Re: FPGAs Need a New Future

#60

Earlier quoted context omitted.

The device that you were looking was not an FPGA but a GAL22V10L.

No, it wasn't. Those are mostly available in PLCC and DIP packages and even if you can get the SOIC/TSSOP versions they still cost $1.20 each at 10k volume. That's flat-out unacceptable for 99% of the things I do. The entire rest of the board I was talking about was $4.60. Processor included. $1.20 is not going to fly.

“Reduces use case and requirements to something impossibly niche and low volume then yells at the clouds.”

Anyway, just tie the output of 21 emitter followers together, add a resistor and - tadaaa - 21 input OR!

Post reply on HN