Live data from Hacker News

FPGAs Need a New Future

allaboutcircuits.com

161–170 of 170 posts

Re: FPGAs Need a New Future

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

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

All of their IDE/programmer/etc binaries are basically entirely unprotected, almost all of their chips are entirely implemented in https://github.com/YosysHQ/apicula - if other manufacturers cared to implement it, it wouldn't be hard.

Re: FPGAs Need a New Future

#162

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…

Have you seen the YoWASP toolchain for VSCode [1]? It sounds pretty similar. [1] https://github.com/YoWASP/vscode

Yes! YoWASP is fantastic. In fact, that extension came to be after we contracted the dev to create NPM packages for the WebAssembly bundles they're maintaining. We use the exact same bundles if the extension detects that it is running in a browser (or if the user explicitly wants to use them). However, if possible we prefer to download and maintain native tool bundles for performance reasons.

Their VSCode extension is a lot more basic than ours, but it might be more suitable for advanced users. It's basically just a wasm tool runner that you pass command line options into, whereas we also include things such as project management and various visualization options. Which one to use depends on what your needs are, really.

Re: FPGAs Need a New Future

#163

It seems to me that there are exactly 3 buyers for FPGAs: Government contractors (who spend millions all at once), retro gamers (small market), and electronics hobbyists (another small market). It's no wonder every company has orientated itself towards the first one. I look to China to accidentally make chips that are an order of magnitude better "just because they can".

You forget network infrastructure, high frequency trading, ASIC prototyping and emulation. These are not hobbyist or government markets

True but they behave exactly like government markets ("no price is too high") so I don't quite understand why the comment.

Re: FPGAs Need a New Future

#164
post #160

Earlier quoted context omitted.

> software developers generally aren't very good at doing things in parallel If only hardware people would stop stereotyping. Also, do you guys not use use formal tools (BMC etc) now? Who do you think wrote those tools? Heck all the EDA stuff was designed by software people. I just can't with the gatekeeping. (Btw, this frustration isn't just pointed at you. I find this sentiment being parroted allover /r/FPGA on red…

> EDA stuff was designed by software people. No - EDA software is built by hardware experts moonlighting as software engineers, which is partly why it is so obtuse.

I said "was", not "is". Also, I know how that's working out. Working with Vivado makes me want to barf.

Re: FPGAs Need a New Future

#165
post #112
post #74

Earlier quoted context omitted.

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

I could order MOQ (minimum order quantity) of anywhere from 100-500 depending upon range. I didn't need to be an LLC, but it sure helps to actually know the lingo and understand how to deal with distributors and FAEs (field application engineers).

One thing you absolutely have to remember is that when it comes to distributors and FAEs is that as an individual you are wasting their time. Talking to anyone other than you is more profitable. Nevertheless, most won't ignore you (sales is their job, after all) but you very definitely have to make their lives as easy as possible and understand that you get their time after they have serviced everybody more profitable.

Tariffs made everything miserable because the FAEs and salespeople were up to their earballs dealing with the daily price swings of customers with actual volumes.

Re: FPGAs Need a New Future

#166
post #161
post #74

Earlier quoted context omitted.

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

> 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. All of their IDE/programmer/etc binaries are basically entirely unprotected, almost all of their chips are entirely implemented in https://github.com/YosysHQ/apicula - if other manufacturers cared to implement it, it wouldn't be hard.

Support is stuck at the old levels--none of the GW5 series are implemented. This is just like how the Lattice support is similarly stuck at the ice40/ECP5 level which is almost a decade old.

Re: FPGAs Need a New Future

#167

Earlier quoted context omitted.

> it's just me and a professor of previously mentioned course who are actively involved in the project Unfortunately, past experiences I have are that a very small academic team = stay away, project will have too many rough edges. I hope your experience goes better. Tip: A revenue stream gives you something to work with. Failing that, carefully document your whole architecture so contributors will be willing to help.…

I know exactly what you mean and I share your frustrations with academic software. In our case I think it helps that our main goal is to provide a good user experience: we're not reinventing toolchains from scratch, but rather making existing ones available in a user-friendly way. Especially in the past year or so I've spent a lot of effort on reducing tech debt, modernizing the underlying architecture and squashing…

have u looked at the teroshdl extension?

Re: FPGAs Need a New Future

#168
post #118

Earlier quoted context omitted.

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

If I really need something I'll go that route, yes. But for something that is just on a "cool, that might be interesting" it's too much effort.

Exactly!

If I need it I will go do the thing and jump through the hoop.

If I am exploring, hell no.

And, next week, if that thing I was exploring turns out to be useful, congratulations, you just sold 100,000 chips.

Re: FPGAs Need a New Future

#169

Earlier quoted context omitted.

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

Would a SLG46880 work for you? It has 28 GPIOs, enough LUTs to make a 21-input OR gate, runs off 2.3-5.5V (two VCCIO partitions, but you can tie them together). It costs like a buck in 5k quantities - they used to be much cheaper when you bought them directly from Silego, but now that they've been acquired the price has been _improved_. https://www.renesas.com/en/products/slg46880

The Silego stuff has been really attractive at high volume. This is what I think about when some of the other posters in this thread sniff at my cost expectations: this stuff can get real cheap if you have volume behind it.

It was not a fit for this use case (on this product I am literally counting tenths of pennies, so, no go), and I dread dealing with Renesas in any form, but it's the right fit for something.

Re: FPGAs Need a New Future

#170

Earlier quoted context omitted.

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

> It did not make anything really hard suddenly become easy. It did. Onboarding people onto embedded programmer. You just ran it, wrote few lines and you had working blinky. Write some more and you have useful toy. You could even technically make products with it but going from this to C++ was easier coz you already know what you could do, just needed to go thru pain of switching the toolchain once you're already inv…

Ah, but that's only medium hard on my difficulty scale ;)
Post reply on HN