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

141–150 of 170 posts

Re: FPGAs Need a New Future

#141

Post by SV_BubbleTime »

mikepurvis wrote: post #78
delifue wrote: post #32

Earlier quoted context omitted.

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

Building for an fpga shouldn’t be any harder than building for cortex mcus, and there are lots of free/oss toolchains and configurations for those.

> shouldn’t

Is doing so much heavy lifting here, I need to ask; how much FPGA configuration you have done before?

Re: FPGAs Need a New Future

#142

Post by almostgotcaught »

BrannonKing wrote: post #136

The whole place-and-route thing is completely wrong for using FPGAs as accelerators. We don't need an optimal layout, we need a tiled layout (like the GPU does). All that we need for this to happen is for the companies making the FPGAs to open up the board layout file spec. They don't need to even make/ship any software at all. Just ship the dang file that says where the resources & timings are and some instructions…

> we need a tiled layout

You are presuming an existing tile IP - if you're already in possession of such an IP then the place and route is already coarse grained. There are lots of papers on this.

> (like the GPU does)

What exactly does the GPU do? Yes there are tiles but it's up to you to now tile your workload. You understand this is the exact same problem you're bemoaning re place and route - you need to figure out how to shuffle individual bits efficiently through an existing fabric (roughly it's the same thing as routing 32 wires at a time).

> we need for this to happen is for the companies making the FPGAs to open up the board layout file spec

What exactly is this going to do for you if you're placing tiles? Also you can already recover this by exhaustively enumerating all a->b paths (yes people really do this).

To anyone else that thinks they just absolutely are certain of the silver bullet for digital design: download a copy of Vivado and report back what you discover!

Re: FPGAs Need a New Future

#143

Post by malmeloo »

amelius wrote: post #119
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 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 Platfor…

I agree, this won't be for everyone. But if you're trying to learn how to use FPGAs, I think it helps a lot to have a tool like the one we're building. The learning process is also inherently very visual: it helps a lot to see what the individual steps look like, how Yosys synthesizes your Verilog code, where Nextpnr places the elements, what the chip looks like, what exactly your testbench is doing...

People who want to stick to the command line can always just use the tools directly. The extension tries to stay close to the tools by allowing users to directly modify the command line arguments and making invocations visible to the user. Heck, you could even use our standalone 'edacation' tool to run tasks defined in project config files (although admittedly I haven't tested that in a long time, so it might not really work that well)

Our intention has never been to build a one-size-fits-all solution. We want to show people that these fantastic OSS tools exist and can provide a viable alternative to Big FPGA's tools. We hope to be(come) a source of inspiration for what the scene could look like if we just let go of these massive toolchains that nobody really likes to use.

Re: FPGAs Need a New Future

#144

Post by pjc50 »

mikewarot wrote: post #95

An FPGA is like a spreadsheet for bits that can recalculate at hundreds of millions of times per second. It's a declarative programming system, and there's a massive impedance match when you try to write source code for it in text. I suspect that something closer to flow charts, would be much easier to grok. Verilog is about as good at match as you are likely to get, if you stick with the source code approach to desi…

Very good metaphor. I'm going to use that in the future. It even has rows and columns.

Except the spreadsheet is a really accessible technology that's been cloned, while the critical problem with FPGA is the proprietary tooling. This is the same reason that NVIDIA made a gazillion dollars by turning GPUs into general purpose compute: a proper API, CUDA.

Re: FPGAs Need a New Future

#145

Post by mikepurvis »

SV_BubbleTime wrote: post #141
mikepurvis wrote: post #78

Earlier quoted context omitted.

Building for an fpga shouldn’t be any harder than building for cortex mcus, and there are lots of free/oss toolchains and configurations for those.

> shouldn’t Is doing so much heavy lifting here, I need to ask; how much FPGA configuration you have done before?

Very little, just student projects in undergrad.

So yes, in that sense I'm talking out of my ass. But perhaps you can help enlighten me what it is that makes building FPGA firmware different from building MCU firmware.

Re: FPGAs Need a New Future

#147

Post by zerofor_conduct »

completely agree, it's a miserable environment for software developers. The Xilinx environment was a 1 GB download, EACH TIME they issued an update. I actually met with someone from higher up to give them some feedback, but they were clearly not interested in the slightest in making any changes.

Re: FPGAs Need a New Future

#148

Post by lesuorac »

0xpgm wrote: post #110
checker659 wrote: post #85

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…

And their cited example was students. I think students would struggle at something new until they 'get it'. Would a software developer who does FPGA development professionally struggle more than, say, a hardware engineer?

Sure but most of software development is about running single-core workflows on top of a parallel environment so the experience of a SWE is very heavily single-threaded.

The ever so popular JS is explicitly singlely threaded.

The default way of programming is with code on individual lines and when you run a debugger you step from one line to the next. This is not how code actually runs within a pipelined CPU though.

Re: FPGAs Need a New Future

#149

Post by thijson »

mikepurvis wrote: post #78
delifue wrote: post #32

Earlier quoted context omitted.

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

Building for an fpga shouldn’t be any harder than building for cortex mcus, and there are lots of free/oss toolchains and configurations for those.

Compiling RTL to run on an FPGA is way more complicated than compiling code to run on a CPU. Typically it has to meet timing, which requires detailed knowledge of logic placement. I'm not saying that's impossible, just that it's more complicated.

Re: FPGAs Need a New Future

#150

Post by misnome »

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…

Oh christ, absolutely this. We spent some time evaluating FPGA for our purposes and ended up GPU instead (algorithms we running can be adapted to strength of either).

The concepts are easy enough but learning the toolsets are an exercise in frustration… the documentation/onboarding is either nonexistent or extremely unhelpful, and getting past the stage of “the entire thing doesn’t work because you misclicked a button in the gui several hours ago”. In theory everything can be scripted, usually in TCL, but this is also unstable and seems liable to break every different version of the toolsets.

Alongside Xilinx, we also looked at Altera/Intel OneAPI/dpcpp and this seemed promising until we realised we were encountering so many toolchain/actual compiler bugs that nobody else could have been actually using this, except the oneapi cloud platform that seemed it had been hotpatched to fix some of the issues. In the end, after selling us some compatible cards they dropped the OS and card from support. I guess this taught us not to trust Intel!

We decided teaching to Juniors would be an exercise in frustration unless hiring explicitly for, and decided to go the GPU route.

Post reply on HN