Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

FPGAs Need a New Future

allaboutcircuits.com

Post reply on HN
Print view View original

31–40 of 170 posts

Re: FPGAs Need a New Future

#31

Post by exmadscientist »

tverbeure wrote: post #24
exmadscientist wrote: post #13

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…

The strong point of FPGAs is their versatility. If you wanted an FPGA that would be easy to put on a board, 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. Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.) Loading them is a matter of plugging in a JTAG cable and typing “mak…

> 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 horsepower. And sometimes you need the certainty of hardware timing, which you get on a gate array and don't get any time there's a processor involved. Or, often, what I actually need is just a little bit of weird logic that's asynchronous, but too hard to do with the remnants of 74-series or 4000-series logic that are still available.

> Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.)

It is not complicated for people who have spent a long time learning and who have past designs they can copy from. (I have a few of those myself.) It is nasty to explain to a new person and very nasty to explain well enough to reproduce in the future without me around.

> Loading them is a matter of plugging in a JTAG cable and typing “make program”.

Yes, for you on the bench. Now program them into a product on an assembly line. Of course it is possible. It is still a giant headache, and quite a bit worse than just dealing with an MCU.

> I don’t know what you mean with the “manage SW projects for”?

Two words: Xilinx ISE.

Re: FPGAs Need a New Future

#32

Post by delifue »

malmeloo wrote: post #22

One big issue with FPGAs is how annoying it is to learn how to use them. I did a course on embedded systems a few years ago and nobody could truly get to enjoy it because we spent most of our time downloading and installing huge toolchains, waiting for synthesis and PnR to complete and debugging weird IDE issues. We need to open up the space to allow people to develop better solutions than what these companies are fo…

Modern large productivity software (including IDE) are often "fragile".

Sometimes some configuration is wrong and it behave wrongly but you don't know which configuration.

Sometimes it relies on another software installed on system and if you installed the incompatible version it malfunctions without telling you incompatibility.

Sometimes the IDE itself has random bugs.

A lot of time is spent workarounding IDE issues

Re: FPGAs Need a New Future

#33

Post by ThrowawayR2 »

tyami94 wrote: post #28
nospice wrote: 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…

And you think that a downloaded codec on an FPGA would perform anywhere close to custom silicon? Because it won't; configurability comes at a steep cost.

Re: FPGAs Need a New Future

#34

Post by blackguardx »

exmadscientist wrote: post #14
blackguardx wrote: post #10

Earlier quoted context omitted.

You can pretty much do everything in Vivado from the command line as long as you know Tcl... Also, modern Verilog (AKA Systemverilog) fixes a bunch of the issues you might have had. There isn't much advantage to VHDL these days unless perhaps you are in Europe or work in certain US defense companies.

The main advantage to VHDL is the style of thinking it enforces. If you write your Verilog or SystemVerilog like it's VHDL, everything works great. If you write your VHDL like it's Verilog, you'll get piles of synthesis errors... and many of them will be real problems. So if you learn VHDL first, you'll be on a solid footing.

I think this can just be summarized to "write any HDL like you are modeling real hardware." Both VHDL and Systemverilog were primarily intended for validation and synthesis is a second class citizen.

Re: FPGAs Need a New Future

#35

Post by Neywiny »

malmeloo wrote: post #22

One big issue with FPGAs is how annoying it is to learn how to use them. I did a course on embedded systems a few years ago and nobody could truly get to enjoy it because we spent most of our time downloading and installing huge toolchains, waiting for synthesis and PnR to complete and debugging weird IDE issues. We need to open up the space to allow people to develop better solutions than what these companies are fo…

I'm all for your endeavor, but didn't see a device support list on your front page. Clicked the first of 2 links in your sidebar (docs) and got a 404. I'm not saying it's telling that your issues page works when your docs page doesn't, but it's not the foot I would have put forward.

Re: FPGAs Need a New Future

#36

Post by fooblaster »

Cadwhisker wrote: post #23
tverbeure wrote: post #20

Earlier quoted context omitted.

> My daily Vivado experience involves typing "make", … Exactly my experience with Quartus as well. One really can’t help but wonder if those who always whine about the IDE/GUI just don’t know any better?

I've managed to make nice 'make' flows for Vivado, ISE, Quartus and DC. Libero took a bit more poking, but it's also possible. The GUI interfaces are what newcomers tend to aim for straight away, but they're not good for any long-term "repeatable" build flows and they're no use for CI. I think this is where a lot of the frustration comes from.

I think my real problem is that xilinx pushes the gui flows heavily. It is extremely annoying to configure the mpsoc fabrics entirely outside of vivado. Same thing for using any of their bundled IP.

Re: FPGAs Need a New Future

#37

Post by exmadscientist »

exmadscientist wrote: post #31
tverbeure wrote: post #24

Earlier quoted context omitted.

The strong point of FPGAs is their versatility. If you wanted an FPGA that would be easy to put on a board, 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. Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.) Loading them is a matter of plugging in a JTAG cable and typing “mak…

> 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…

> often, what I actually need is just a little bit of weird logic that's asynchronous

As a concrete example of this: two weeks ago I wanted a 21-input OR gate. It would have been wonderful if I could spend a little bit of money, buy a programmable thing in a 24-pin package, put it down, figure out some way to get the bitstream in (this is never pleasant in medium-volume manufacturing, so it's not like we're going to solve it now), and get my gate function that is literally one line of HDL. One. Line.

As it was, a 21-input OR gate is so much work in 74-series logic that I abandoned that whole thing and we did the bigger-picture job in a different, worse, way.

Re: FPGAs Need a New Future

#38

Post by 15155 »

exmadscientist wrote: post #13

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

Re: FPGAs Need a New Future

#39

Post by 15155 »

exmadscientist wrote: post #31
tverbeure wrote: post #24

Earlier quoted context omitted.

The strong point of FPGAs is their versatility. If you wanted an FPGA that would be easy to put on a board, 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. Building bitstreams is IMO not complicated. (I just copy a Makefile from a previous project and go from there.) Loading them is a matter of plugging in a JTAG cable and typing “mak…

> 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, either.

Re: FPGAs Need a New Future

#40

Post by 15155 »

omneity wrote: post #4

If performant FPGAs were more accessible we’d be able to download models directly into custom silicon, locally, and unlock innovation in inference hardware optimizations. The highest grade FPGAs also have HBM memory and are competitive (on paper) to GPUs. To my understanding this would be a rough hobbyist version of what Cerebras and Groq are doing with their LPUs. Unlikely this will ever happen but one can always dr…

> highest grade FPGAs also have HBM memory

The three SKUs between Xilinx and Altera that had HBM are no longer manufactured because Samsung Aquabolt was discontinued.

Post reply on HN