Since the New Year we had 7 Verilog meetups at HackerDojo. We discussed the modern way of designing digital circuits using hardware description languages, the exercises on FPGA boards and the topic of microarchitecture. For the last two sessions we went over the most basic CPU core that can be used as a baseline for further exercises.
There are video recordings available for some meetups and Zoom calls. Particularly I recommend to see the first video (it gives a general overview) and a video about a baseline CPU core we can use for a number of exercises.
From the beginning we planned to split the meetups into two types of sessions:
1.Regular meetings of a small R&D team that develops multiple open-source repositories of SystemVerilog examples. Two focuses: compatibility (boards, ASIC and FPGA toolchains, peripherals) and microarchitecture (what the electronic companies ask you during a job interview - pipelines, FIFO queues, arbiters etc).
2) Occasional Show-and-Tell sessions for a wider audience interested in reconfigurable hardware as a way of computing different from software. Displaying graphics and recognizing music using FPGA boards, together with some presentations from the members of the regular R&D meetings: How do FPGAs work? What is their role in the electronic industry? How is it related to mass-market electronic devices? Can you make your own ASIC (Tiny Tapeout, OpenLane, eFabless etc)?
During the meetups there were three kinds of participants:
1) People who are curious about the technology but not interested in doing exercises. This is the prime audience for show-and-tell sessions.
2) People who are interested in learning new things to get additional career options. They can take some projects, but they may not be interested in coming every Sunday. Many prefer to work at home and communicate via email or Zoom.
3) People who already work in the field (like CPU designers) who can be interested in more advanced material (like new branch predictors or design verification techniques for multithreading), but who get bored when the discussion moves around basic topics or discussions about the example infrastructure (pins, toolchain details).
On the necessity of doing exercises
At this moment, in order to make progress toward both goals (implementing new examples and show-and-tell sessions) it is essential for the regular participants (mostly from group 2) to solve all the homework exercises (see the list here) in parallel with studying the recommended materials. I can review the results over the internet and during Zoom sessions.
There is no other way. I can spend a year talking, but if a listener does not do the exercises, there is no progress. In fact it happens all the time with recent college graduates: a graduate may have in his resume some sophisticated microarchitectural things (Tomasulo algorithm, MOESI cache coherence protocol), but when he is asked during a job interview to implement something straightforward (like a serial adder with valid and last signals, or a static pipeline to compute a formula with dependencies between the pipelined blocks) many struggle with such tasks.
In my opinion it is a bad idea to teach from high-level (Tomasulo and MESI models) to low-level (Verilog implementation) because on the transaction level a student does not have intuition about static timing analysis, does not have knowledge of how to verify the corner cases of what he designs, does not know how to measure the bandwidth etc. It is better to start from simple sequential logic tasks, then static pipelines, master them well, add flow control (including credit counters), and move to something more complicated. A person who knows only how to write very trivial things in Verilog (like a simple mux or an FSM) and can talk about superscalar CPUs - has very limited use in the industry, so you need to practically master the things in the middle.
There is no silver bullet and no way to skip SystemVerilog RTL exercises. High-level synthesis (C algorithms - to - hardware translation) was never adopted into the mainstream, new languages (Chisel, etc) do not substitute knowledge of sequential logic behavior, ChatGPT writes nonsense etc. If you want to design hardware for AI, or work in hardware to accelerate text search, DSP or graphics, you cannot skip the exercises with sequential logic, pipelines, FIFOs etc.
So the next steps are:
1) We are going to do Zoom call on each Sunday starting March 24, 2024 at 11 am California time (summer time). The link. During this call we are going to discuss the SystemVerilog Homework and the individual projects.
2) Once we get more materials, we are going to organize Show-and-Tell sessions in Hacker Dojo, for a wider audience. During the session several participants from the core team will present demos on various FPGA boards and explain to the curious how FPGA and ASIC work.
Now I would like to copy a fragment of the previous post "Verilog Meetups @ Hacker Dojo: the status and the plans for February 2024" which has all the necessary links and a list of the recommended literature:
Self Education to Guarantee the Quality
To ensure everybody's quality, we expect every member who is new to the field, to go through the following steps in his education. Those who already know the basics can review the materials to ensure their quality:
Do all the homework from https://github.com/yuri-panchul/systemverilog-homework.
Run and review all the examples in https://github.com/yuri-panchul/basics-graphics-music
Get a tutorial in Bash if you have not done this before. We use Bash scripts to isolate users from vendor-specific toolchains.
Get a tutorial in Git if you have not done this before. We use Git and GitHub Forks / Pull requests as the vehicle of collaboration inside the team and to publish the examples.
Get a tutorial in Markdown markup language as we use it for documentation.
Study a diagram editor for microarchitecture diagrams such as Lucidspark or draw.io.
Learn how to use wavedrom.com for microarchitecture diagrams.
Learn how to use edaplayground.com useful to create verification examples with full-featured SystemVerilog.
The Recommended Literature
In parallel with going through the problems and examples, we recommend studying the following books and online articles:
Digital Design and Computer Architecture, RISC-V Edition by Sarah Harris and David Harris.
Logic Design and Verification Using SystemVerilog – March 1, 2016 by Donald Thomas. Not to be confused with the old (starting 1980s) books of the same author.
Digital Design: A Systems Approach by William James Dally and R. Curtis Harting.
IEEE 1800-2017 - Standard for SystemVerilog should be used as a reference.
Verilog Gotcha articles by Stuart Sutherland, Don Mills and Chris Spear: Part 1 and Part 2.
The articles of Cliff Cummings.
Once we get to verification examples:
Writing Testbenches using SystemVerilog 2006th Edition by Janick Bergeron.
Getting Started with UVM: A Beginner's Guide - May 22, 2013 by Vanessa R. Cooper. This book does an excellent job of setting up the minimum necessary skeleton for the UVM testbench. However, the BFM driver code in this book is not good for pipelined and out-of-order protocols. There are no good books on BFMs for pipelined and out-of-order protocols - we have examples of how to do this right here, but we need to convert this example into UVM using Vanessa R. Cooper's UVM skeleton example.
Once we get to CPU-specific examples (like branch predictors, caches and Tomasulo), we recommend:
Talk to you on Sunday's Zoom call at 11 am California time (summer time) - The link. During this call we are going to discuss the SystemVerilog Homework and the individual projects.
