Hacker News Reader

This is exactly it.

The FPGA situation is the same as the microcontroller situation before Arduino blew open the flood gates: byzantine proprietary software and libraries you have to pay for to unlock hard IP functionality less you from scratch develop it yourself which can be very difficult. The Arduino gave people a solid kit: Simple to install IDE that wraps up a text editor, tool chain and libraries with matching plug and play hardware.

Arduino took microcontrollers from esoteric hardware for EE's to mainstream "makers" - people who were not technically educated but wanted to makes things using technology. FPGA's need a solid foundation like that.

I briefly worked with FPGAs and was having a lot of fun but the software really ruined it for me. I forget the details but I was moving my web license of the Xilinx tools to my desktop from my laptop, it kept failing and I gave up.

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.

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

## Irrelevant Complaining

Just ran across this last year: good looking software, great concept, first half of features work great … enough to hook me, so when I finally found out the other half was bug ridden I stuck it out but ouch. Needless to say, no design document so even fixing stuff was a pain point.

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 bugs. We've gone through several UI iterations just to see what would be most intuitive. Compare that to most pieces of academic software that should technically work, but are so difficult to use that nobody except the developers really know how to utilize it.

Our intention has never been to build a full alternative to e.g. Quartus Prime or Vivado that suits everyone's needs. Our main intention is to show people that FPGA toolchains don't have to be so difficult to get started with, and that alternatives are possible. And yes, I agree, that absolutely means good documentation on several levels to allow other people to continue working on the project. Good thing that's part of our mission, so it will be done; just takes a little bit of time ;)

have u looked at the teroshdl extension?

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.

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

I just remembered I have a Xilinx I bought over a decade ago lying around somewhere. I don't remember ever plugging it in, but I do both the excitement of getting it and trying to figure out the toolchain and getting confused.

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.

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.

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.

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.