> While this may look like code in a normal programming language, it operates entirely differently.
So happy to see this called out up-front. One of the hardest things with FPGAs as a developer is understanding that you're reconfiguring hardware instead of a series of serial asm/opcodes. They look superficially the same but have very different requirements and constraints under the hood.
For those looking for cheap FPGA boards, I highly recommend looking for something that is based on the Lattice ICE40. The cheapest board you can find is probably the $9 Upduino, though trickier to get going. (Complete lack of documentation.)
But there are tons of hobby boards in existence.
The best part is Project IceStorm, a fully open source tool flow, from synthesis to bitstream. While not the best in terms of optimization, it's killer feature is that it's blazing fast. You can get small design synthesized and converted to a place-and-routed bitstream in under a minute.
Amazing project to learn how FPGAs work. Not overkill with some high speed interfaces, but touches all problems: no easy division by 3 and 5, counters everywhere, no copy/paste solutions, no libraries with helpful functions. Though Xilinx ISE is obsolete, Vivado is the current tool.
The most interesting part of all this is just how CHEAP some of the learning boards are. I don't know enough to understand how limited the ElbertV2 is, but at $30, it can still be pretty limited and a fun toy
I am pleasantly surprised by this reading!
I have been trained as an EE to consider FPGA design in the hardware skills domain, and indeed I would say that this writeup ignores the less friendly parts of FPGA development (timing closure, clock domain crossing and more...). Nevertheless, I think it is a good introduction for software developers to start thinking like "hardware description". Good work!
Great article! I've also been learning Verilog -- albeit in an academic setting -- and it has been an interesting experience. I discovered that you can do surprisingly complex things in Verilog (at least, from a digital logic point of view) using less code than I initially expected!
Would it have been better to use a ring counter instead of an adder for the modulo 3, modulo 5, and state counters?