4 ms·

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

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

aseipp 8y ago
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...
q3k 8y ago
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)
- Sir_Substance 8y ago
  >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.
  - q3k 8y ago
    > 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.
tomxor 8y ago
> 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?

aseipp 8y ago

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

q3k 8y ago

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)

Sir_Substance 8y ago
>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.
- q3k 8y ago
  > 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.

tomxor 8y ago

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