Dan Gisselquist writes about FPGA design, formal verification, and building the ZipCPU, an open source CPU.
HN commenters praise it as excellent, say they learn a lot from it, and credit it with introducing them to formal verification.
As other commenters have said, just picking up an open source *NIX is a great start.
If the lack of open hardware bothers you, there are several non-x86 architectures that are fully open source. Chief among them is RISC-V[0]; SiFive[1] is taping out RISC-V processors to real hardware, selling dev boards, and stuff like that. These are real, competitive, Linux-capable CPUs, although widespread adoption has not happened yet.
On the more minimalist front, the ZipCPU[2] is simpler (though has less software support), and it's author writes some really great blog posts about HDL[3] (Hardware Description Language -- how these CPUs are defined).
You might also enjoy developing for very small embedded systems. I like AVR CPUs such as the ATMega328P (of Arduino fame) for this purpose. Although not open-source, they have quite good and thorough datasheets. AVRs are very small 8 bit systems, but as a result, you can fit most of the important details in your head at once.
If you want to talk more about these topics, feel free to get it touch with me. You can find my contact info on my profile, and on my website (also listed in my profile).
0 - https://riscv.org/
1 - https://www.sifive.com/
2 - https://github.com/ZipCPU/zipcpu
3 - http://zipcpu.com/
I've been learning a lot from the https://zipcpu.com/ blog lately, and I'm just starting to play around with formal verification after reading all of the recommendations for that from the blog.
SpinalHDL has been very nice to use so far instead of Verilog: https://spinalhdl.github.io/SpinalDoc-RTD/master/index.html It even has simulation and formal verification workflows built in. In the simulation you can wiggle the bits on your ports using Scala, so you can code an emulation of any peripheral or the like that you want and have your design use it. (You can also do the same thing using C++ if you use Verilator directly instead.)
You can code a bridge between a serial port in your simulated design and a TCP port, and then write a second program to bridge a real serial port to a TCP port the same way. You can then write tools that connect to the TCP port and then use those same tools against both your simulated design and your design in hardware.
Cool stuff. Well presented. Just by coincidence was just reading this yesterday: https://vivonomicon.com/2020/06/13/lets-write-a-minimal-risc-v-cpu-in-nmigen/
nMigen is super interesting but I'm still stuck in Xilinx Vivado as a beginner because it makes integrating small cores so easy. Full RISC-V SoC that does something useful in the FPGA part and runs a small version of Linux and programs that call the FPGA part would be super neat.
Seems small RISCV cores can be written very quickly https://github.com/darklife/darkriscv#introduction, but actually making them production hardware take a long time: https://zipcpu.com/zipcpu/2021/03/18/zipos.html
The books by Pong Chu are really good. You can choose either VHDL or Verilog and then the FPGA you are getting started with. I went through 'FPGA Prototyping by Verilog Examples' as my first starting point with Verilog and it was very easy to follow. This will give you a basic level of understanding of FPGA development, from there you can study more specific topics.
There was a good article yesterday on HN that went through the process of taking the Cordic algorithm and implementing it in Verilog, it's a good example of using FPGAs to implement a specific algorithm.
http://zipcpu.com/dsp/2017/08/30/cordic.html
Quite different from a modern key debouncer circuit like http://zipcpu.com/blog/2017/08/04/debouncing.html .
The modern FPGA circuit first passes the input through two latches to synchronize it to the system clock, and then has a digital counter to add a delay to rapid bounces. Here the delay is analog, and there is no clock input: the output digital signal is still completely asynchronous.
I wonder if they needed a second module to synchronize the signal and avoid metastability issues, or maybe that doesn't matter at the low clockspeeds they were using?
If you found this article interesting, I'd recommend this article by the same author: https://zipcpu.com/blog/2020/11/26/zipcpu-biz.html
> On another team I worked with, I was asked to call a man by female pronouns. This one brings me more grief, as I enjoyed working with the individual in question. He wanted to declare himself to be a woman. He changed his name, his clothing, his looks, his dress, you name it. While I might disagree with his decisions, who made me a judge? However, for me to call a man a “she” would make me a liar. This I refused to do.