Live data from Hacker News

FPGAs Need a New Future

allaboutcircuits.com

111–120 of 170 posts

Re: FPGAs Need a New Future

#111

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…

> (at a little backend complexity cost: now you've got the Arduino IDE around, hope it doesn't break!)

Doesn't really matter if it does break; just use gcc and a Makefile like you would for any other firmware.

You probably want to replace the Arduino libraries with your own ones eventually anyway, because there's so much cruft in there that you're never going to use.

Re: FPGAs Need a New Future

#112
post #74
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…

> My prediction is one of the Chinese FPGA makers will embrace open source Sadly, this doesn't seem to be panning out because the Chinese domestic market has perfectly functional Xilinx and Altera clones for a fraction of the price. Consequently, they don't care about anything else. It irritates me to no end that Gowin won't open their bitstream format because they'd displace a bunch of the low end almost immediately…

Gowin seemingly doesn't even sell the chips to individuals. Either set up an LLC so you can request samples from a destributor, or desolder one from a sipeed dev kit.

Re: FPGAs Need a New Future

#113
I program FPGAs professionally (Xilinx Zynq, VHDL). I agree that the tool's GUI is atrocious, the actual way to use it is to write everything in TCL scripts, and invoke the tools through a Makefile. I only open the GUI to look at timing issues or ask it for code templates.

I disagree with "HDL is software" though. It's not, it's even in the name: "hardware description language". Yes it's a text file with what looks a lot like regular code in it. However what's being decribed is how to connect boxes of logic together, and how to compute the output of the boxes from their inputs. There's no implicit program counter that's advancing from one line to the next.

It is (theoretically) possible to write these kind of things with a lot of abstraction, but every time you try that by using more advanced language features, you hit some bugs in the tool's implementation of the language. If you're lucky it'll tell you where you're doing undupported stuff. Often it'll crash. Sometimes it'll sythesize hardware that doesn't conform with the language spec.

Finally, FPGAs are simple only when you're looking at a bird's eye view (just like CPUs are simple when you're looking at a diagram with a few boxes saying "ALU", "Cache", "Registers"). The actual datasheets are thousands of pages long.

FPGAs are still useful though, their use case is "I need custom hardware and I don't have the volume to build an ASIC". For example, my application is a custom signal processing pipeline that's handling about 3.5 Gbit/s of streaming raw data. On a $40 chip.

I think my main point is that yes, the tooling is a pain to use, with heaps of bugs and bad language support. However a HDL is conceptually different from a software language and I'm not sure you can hide away the complexities of designing hardware behind "modern" language features.

For those suggesting diagram-based languages, go program something in LabView, you'll quickly understand why that's a bad idea (works for trivial designs, anything complex is an opaque mess of boxes and lines, unsearchable, and impossible to integrate with version control).

Re: FPGAs Need a New Future

#114

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 already happened, people just haven't realized. iCE40-UP5K costs a few bucks, needs minimal support circuitry, and is supported by FOSS toolchains (yosys). Fun packages like the pico-ice bring it all the way down to the entry-level arduino crowd. It just doesn't have the marketing mindshare.

Funny enough it is available on an UPDuino board: https://tinyvision.ai/pages/the-upduino

Re: FPGAs Need a New Future

#115
post #35

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.

Ha yeah, I agree the website isn't great. I set it up a while ago just so we have something to fill up the void. Right now it's just me and a professor of previously mentioned course who are actively involved in the project, so we've been mostly focused on the technical part.

That said, functionally speaking the extension is 90% of the way there. Synthesis, PnR, simulation, visualization and more all work for ECP5 & iCE40 FPGAs, and to limited extent some others as well. We have a few more features that we're working on, but a very solid basis already exists.

For technical reasons we have a bit of a deadline on finishing the project, which is likely in around ~6-7 months. So by then we intend to have a 1.0 release and very solid documentation out.

Re: FPGAs Need a New Future

#116

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…

But Vivado doesn't get the job done. The intended workflow is to click around in the GUI until it (hopefully) synthesizes something. The state is then recorded in some proprietary project file that cannot be version controlled or shared with other developers. The workaround is to generate some unholy mess of tcl scripts that automate the clicking, such that one can start from scratch for each synthesis. The scripting mess breaks with each minor release of Vivado, so you need to either never update, or have a separate (~100 GB) Vivado installation for every single project. And if your chip is more than a home-gamer ZYNQ, you hopefully like paying subscription fees for the experience.

Re: FPGAs Need a New Future

#118
post #56

Earlier quoted context omitted.

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…

> All of the Gowin documentation is available on their site with a free, approval-less email login The problem is trust. I'm hesitant to hand out my e-mail anywhere because far too often I have been hounded by salespeople as a result, not to mention data breaches or bombardment of newsletters.

So just use Google to obtain the documentation? Or a fake email? The PDFs are pretty easily obtainable by title:

https://www.google.com/search?q=gowin+user+guide+filetype%3A...

https://www.google.com/search?q=gowin+primitives+filetype%3A...

https://www.google.com/search?q=gowin+gw1n+filetype%3Apdf

Re: FPGAs Need a New Future

#119

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 agree but I think that writing yet another IDE extension is not going to solve the problems. An IDE will bring you one step further away from the actual hardware, and makes it more difficult to solve unexpected problems. Also, not everybody likes IDEs, some just prefer Vim and the commandline. An IDE is not the magical solution here.

Instead of focusing on the IDE, maybe focus on a build system. Look at how PlatformIO does it.

Re: FPGAs Need a New Future

#120
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.

You definitely don't want an FPGA if those are your concerns.
Post reply on HN