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