Study guide — what to focus on

This module is curated — the teaching is a top free video course (linked in the card above); our job is to point you at the right things, make you practice them, and certify you. It picks up where the first FPGA module left off: you've read digital logic, now you'll write it as real Verilog RTL.

The plan

1. Watch the course (the card above). It's a full series — you don't need every lecture, and you don't need to memorise it. Aim to understand the ideas below and be able to write them.
2. Focus on these — they're what the check tests and what you'll actually type:
   • The module — its port list (inputs/outputs) and how you instantiate one design inside another.
   • wire vs reg — nets driven continuously (assign) vs variables assigned inside a procedural block. reg does not automatically mean a hardware register.
   • always @(*) vs always @(posedge clk) — the first models combinational logic; the second models clocked, sequential logic (flip-flops/registers).
   • Blocking (=) vs non-blocking (<=) — use <= in clocked blocks so all registers update together; use = in combinational blocks. This is the single most common beginner bug.
   • Finite state machines (FSMs) — a state register on the clock plus combinational next-state/output logic (usually a case).
   • Testbenches — a non-synthesizable module that instantiates your design, drives stimulus (an initial block, # delays, a generated clock), and checks the output.
   • Simulation vs. synthesis — what runs only in the simulator vs. what actually becomes hardware.
3. Practice in an online simulator (next section) — write a small design and its testbench, simulate them in the browser, no install needed.
4. Take the K-Check to earn your certificate.

Why this matters

The first module gave you the vocabulary of gates, flip-flops, and a first module; this one gives you the craft of describing hardware in text and proving it works. Almost every RTL bug a new engineer hits lives in exactly these details — a reg that should be a wire, an always @(*) with the wrong sensitivity, a = where a <= belonged, an FSM that never leaves its reset state. Learning to write the design and the testbench that checks it — before any silicon or FPGA is involved — is the habit that separates code that simulates from code that actually works. That discipline is what lets you design your own digital blocks with confidence rather than only wiring up someone else's.

The fastest way to make Verilog stick is to write a design and its testbench and simulate both — and you can do that free in your browser, nothing to install. Open EDA Playground, a free online HDL editor and simulator: put your design on the right, your testbench on the left, pick a Verilog simulator (e.g. Icarus Verilog) plus Open EPWave after run for waveforms, and hit Run.

For a first exercise, build a small N-bit up-counter: a module counter(input clk, input rst, output reg [3:0] count); with an always @(posedge clk) block that resets to 0 when rst is high and otherwise does count <= count + 1; — note the non-blocking <=. Then write a testbench that has no ports, instantiates the counter, generates a clock (an always #5 clk = ~clk;), pulses reset, lets it run for a while with # delays, and prints the value with $monitor (and $finish to stop). Run it, watch count step 0,1,2,… on each rising edge in the waveform, and confirm reset forces it back to 0. That loop — write the module, write the testbench, simulate, check against what you expected — is exactly how real RTL design works, just scaled down.