4 ms·

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

>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.
- Sir_Substance 8y ago
  >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?
  - q3k 8y ago
    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).
  - ur-whale 8y ago
    If you code in VHDL, I have had a good experience with GHDL: http://ghdl.free.fr/ http://ghdl.free.fr/
    - Sir_Substance 8y ago
      Excellent, I'll check it out, thanks!

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.

Sir_Substance 8y ago
>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?
- q3k 8y ago
  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).
- ur-whale 8y ago
  If you code in VHDL, I have had a good experience with GHDL: http://ghdl.free.fr/ http://ghdl.free.fr/
  - Sir_Substance 8y ago
    Excellent, I'll check it out, thanks!