Comment by mechagodzilla | Hacker News Reader

Comment by mechagodzilla | Hacker News Reader

Parent Full thread

Regarding open-source FPGA design, you're in luck! "Project IceStorm" reverse-engineered the Ice40 line of FPGAs from Lattice, and has a fully open-source toolchain for them. They're not super high end chips, but the HX8k line isn't terrible (~7680 LUTs, I believe).

That being said, both Xilinx and Intel/Altera have both supported Linux for years, and the free versions of their software basically support all of their chips that don't cost several hundred dollars per chip. The licensing and such is pretty awful if you're a purist about these things, but they are giving you a fully fledged hardware design suite.

I think the main issue is that using FPGAs is actually doing hardware design, and most people don't want to do hardware design, they want an automagical way to make their software go faster. FPGAs are a great way to implement digital logic without having to incur the huge capital costs of taping out a chip, not a magical 'go faster' device for a random algorithm.

>Regarding open-source FPGA design, you're in luck! "Project IceStorm" reverse-engineered the Ice40 line of FPGAs from Lattice, and has a fully open-source toolchain for them.

I've used it. It's at the "technically doesn't not work" stage. I take my hat off to them for the work already done, but it's night and day between icestorm and, say, arduino studio.

In fairness to them, they are fighting an uphill battle reverse engineering the chip, but as much respect as I have for their work, I don't believe there's a long term open source option in there. At some point Lattice will stop making the Ice40 FPGA line. When we reach that point, the icestorm team will have to reverse engineer a new chip, which is pretty close to starting from scratch.

People are already working on that, and there are current reversing projects underway for both Xilinx -7 series chips as well as Lattice ECP-series chips. FPGAs tend to have long lifespans anyway, and the ICE series seems to have no indication of going away soon. Nobody is standing still here.

Besides, I'd argue the biggest problem isn't even reversing the chips, but it's recreating all the useful middleware outside of the chip that will take a long time (e.g. ChipScope alternatives, interactive floorplanners, etc). A lot of this isn't even vendor-specific work, it's just a huge effort. On top of the effort of already writing synthesizers and routing descriptions for VTR...

I don't understand your comparison between Arduino Studio and Project Icestorm. I'm going to assume you mean the ease of use.

If your pain point is a lack of a good IDE, then this isn't something any other suite of FPGA vendor tooling will fix. They all have terrible UX. And in my opinion, that responsibility lies in tooling around your text editor, anyway. It's going to happen sooner or later, as the difficult problem of linting and analysing RTL is already solved in the F/OSS world (Verilator). I've also seen some effort on Twitter of building an IDE around Yosys.

Yosys/Arachne/Icestorm are lacking in features compared to vendor suites (timing driven PnR, floorplanning, ...), but none of them really should be required for beginners. And the fact that the entire suite is cross platform and installable from a package manager more than makes up for those deficiencies for simple projects. All in all, the pipeline for running the fully open toolchain is still much less complex than today's average frontend project.

(disclaimer: working with authors of yosys&Icestorm, but speaking for myself)

>I don't understand your comparison between Arduino Studio and Project Icestorm. I'm going to assume you mean the ease of use.

Lets call it "time to hello_world".

If you buy an arduino, you can go from opening the box and reading the pamphlet to altering how quickly the LED blinks in about 5 minutes, and most of that is dependent on your internet speed.

A lot of that is because of really basic things like having a friendly list of the different boards (development boards, _not_ chips) you might be using so you can just pick the name you recognise from the list without actually having to know what you're doing. It's really important for people to be able to learn by flailing around without knowing what they are doing if you want mass adoption of a technology.

On the other hand, pretty much the first thing you notice on the icestorm page is a massive list of different packages and the command line arguments you need to use for them, which means you need to know the exact fpga package you are working with. I'm not saying that all the other FPGA toolchains don't do the exact same thing, because they definitely do.

Never the less, this whole process feels a lot more like circa-1995 gcc commands than it does "go build". It's such a little thing, but enough little things can make something too hard to bother with, and there are _lots_ of little frustrations with FPGAs. The hardware of arduino was fairly unremarkable, the revolution was that you could just buy it and start bashing around with it in minutes on any computer. No signups, no technical manuals and no compiling from source.

> It's really important for people to be able to learn by flailing around without knowing what they are doing if you want mass adoption of a technology.

I'm not really sure that this is applicable to hardware design.

I see it this way: Arduino got really popular because it pushed the software paradigm to electronics, which was previously dominated by careful planning, studying of datasheets and having at your disposition at least a multimeter and bench power supply. Now you could just write a few lines of imperative code instead of using a few transistors for turning a fan on and off when you press a button. And if things went wrong, you just serial.println until you figure things out.

FPGAs are entirely unlike this. By the point where you're first synthesizing a design onto silicon, you should've thoroughly tested it on a simulator, just because of how much easier it is to debug there than on really hardware. And that all requires discipline - something that is not really achievable by changing things around until they work.

Sure, you can get by making hacked together designs that will probably synthesize - but they'll be unstable, slow and unmaintainable. And you will be no wiser by the end about what you did wrong until you actually pick up an EE book and understand setup/hold times, metastability, clock domain crossing, FSM design and signaling techniques. Or even what exactly does an always (*) block with mixed blocking and nonblocking statements synthesize to.

I don't know, maybe I'm just underestimating people. Sure brings me closer to actually starting a series of lectures or blog posts on this.

>FPGAs are entirely unlike this. By the point where you're first synthesizing a design onto silicon, you should've thoroughly tested it on a simulator, just because of how much easier it is to debug there than on really hardware.

In fairness, I have not experimented much with FPGA simulators. My casual research into them suggests they're less reliable than testing on actual hardware, and even harder to set up and get licences for than the FPGA toolchains. Aka they're a deeper level of the same shitshow as FPGA design suites.

If I'm mistaken I'd love to hear it. Is there a non-terrible free-as-in-beer simulator out there I can try on a linux machine?

For pre-synthesis, try Verilator (converts your Verilog module into a C++ class - super cool for cosimulation) or Icarus Verilog (takes traditional Verilog Testbenches). They both can emit VCD waveform trace files that you can then analyze using GTKWave.

I have never heard of a simulator being less accurate than hardware, unless we're talking about very obscure bugs (and those are mostly limited to UI bugs).

If you code in VHDL, I have had a good experience with GHDL: http://ghdl.free.fr/

Excellent, I'll check it out, thanks!

> I've used it. It's at the "technically doesn't not work" stage.

What did you try and when, why does It not not technically work? I haven't tried myself, but i've seen a few little videos of people synthesising and running little things on the ice40 using all open source toolchain. One of them was a little open source CPU. I could understand "technically works but not practical for many things", but not work at all?

I think the main issue is that using FPGAs is actually doing hardware design, and most people don't want to do hardware design

Half the time FPGA's come up, people ask "which FPGA can I get that has an integrated ARM core". So I suspect you may be on the money.

Reply on news.ycombinator.com