·
12h
·
Hardware was built and then gatekept behind $100k and 4-years of college Now in 2026, AI can build what we want and when we want it. This is a technical guide to the language of hardware (SystemVerilog) and the AI workflow I use to write it. By the end, you’ll understand the fundamentals and have your first hardware component running on your laptop.
The Entire Language in 90 Seconds
AI can write SystemVerilog. You need to read it. Here are the core constructs that cover 90% of real RTL ( just code):
- Module : It is a blueprint for a physical component. It has inputs, outputs, and internal logic.
This isn’t a class you instantiate at runtime , it’s a circuit you fabricate once.
2. Signals : They are declared with logic. Forget Verilog’s wire/reg split.
Just use logic for everything
3. Types of Logic Blocks
always_comb is combinational logic with no clock and no memory : output reacts instantly to inputs.
always_ff @(posedge clk) : sequential logic with a clock and memory.
4. Assign : This creates a permanent physical wire that’s always active. It’s a wire that continuously carries the value of the function that it is assigned
This isn’t an instruction that executes , it’s a wire that continuously carries the value of a + b, 24/7.
5.Instantiation : wires modules together by creating instances and connecting ports.
This is an example of how to instantiate a module
6. Parameters : compile-time configuration that generates different physical circuits.
This is what a Parameter looks like
7. Literals – number constants that must specify bit width to prevent truncation bugs.
This is a literally what a literal looks like (lol)
8. Testbenches : simulation-only constructs that don’t synthesize to real hardware.
Implementation of a Testbench
That’s the language. Eight constructs. Everything else is patterns built from these primitives : FSMs, pipelines, arbiters are all just combinations of always_ff, always_comb, and assign. Internalize these eight concepts and you can read any hardware design.
The Fun Part Begins : Install Two Things
Verilator : the open-source SystemVerilog simulator:
GateFlow – the plugin I built:
That’s it. No IDE, no license server, no FPGA board. You’ll write .sv files in any editor and run them from the terminal or let GateFlow generate them for you.
Watch GateFlow Build Your First Hardware
Open Claude Code and type:
End to End Orchestration
GateFlow kicks in. It follows a strict workflow: ASK → PLAN → BUILD → VERIFY.
This swarm of specialist agents builds it for you.
The workflow is a relay where each agent hands off to the next, and if anything breaks, specialist fixers jump in automatically
The Complete Agent Workflow
In 30 seconds, you get:
The module for a Counter
Testbench for a Counter
Congratulations, you just built hardware.
- A physical counter : the same primitive inside every processor on Earth
- Those 6 lines of logic synthesize into physical transistors
- Put this on an FPGA board and LEDs start counting
- You described a machine in SystemVerilog, and now it exists
But here’s the thing: you should understand what GateFlow just made.
- AI can generate correct code
- But if you don’t know why each line exists, you can’t: modify it , debug it or design the next component
- The plugin is a tool, not a replacement for understanding
What Those Lines Actually Mean
Hardware is not software. You need three fundamental ideas
Idea 1: There’s no instruction pointer
- In software: your CPU executes line 1, then line 2, then line 3
- In hardware: everything runs at the same time
- Every wire, every gate, every register : all operating simultaneously, continuously
Idea 2: The clock is the heartbeat
- If everything runs at once, how does anything happen in sequence?
- The clock : a signal that toggles between 0 and 1 a hundred million times per second
- On every rising edge, all the registers in your design sample their inputs and update
- One rising edge is one tick of your machine
Idea 3: Two kinds of hardware
- Combinational logic : a pure functionOutput depends only on current inputs.This updates instantly
- Sequential logic : has memory (flip-flops) that capture a value on the clock edge and hold it until the next one
Now the counter makes sense
Counter module
- A module is hardware’s version of a class : it has inputs and outputs
- logic is the signal type : use it for everything
- [3:0] means 4 bits wide
- always_ff means “this describes flip-flops” this means it is sequential hardware
- @(posedge clk or negedge rst_n) means “update on the rising clock edge, or immediately when reset goes low”
- <= is non-blocking assignment : the hardware way of saying “all updates happen simultaneously at the clock edge”
- 4’d0 means “4-bit decimal zero”
- Always specify the width : implicit widths cause silent truncation bugs
- The counter wraps from 15 to 0 automatically
- A 4-bit binary number overflows from 1111 back to 0000
testbench for
- Instantiation: counter u_dut (…) wires up your design under test; .clk(clk) connects ports like plugging a chip into a breadboard
- Stimulus and time control: always #5 clk = ~clk; generates a 100 MHz clock : @(posedge clk) waits one cycle and apply inputs, wait cycles, observe outputs
- Observation: $dumpfile/$dumpvars capture waveforms (view in GTKWave) : $display prints values and $finish ends simulation
Running It Yourself (Without GateFlow)
You can build everything manually. Save the files, then:
What this does:
- –binary → Make a runnable program
- -j 0 → Use all CPU cores
- -Wall → Show all warnings
- –trace → Record waveforms
- counter.sv tb_counter.sv → Your design + testbench
- -o sim → Name the output “sim”
Verilator converts your SystemVerilog to C++, compiles it, and creates simulation file.
The Testbench executes and the clock toggles. Your hardware can now run and tests can either pass or fail.
Template for any design
GateFlow does this automatically. But you should know how to do it yourself.
Building Something Real: A Synchronous FIFO
Time to build the component that’s inside every chip. A FIFO (First In, First Out) is a buffer that sits between a producer and a consumer. Data goes in one end, comes out the other, in order. FIFOs are inside every CPU pipeline, every network buffer, every GPU command queue.
In Claude Code:
Here is the exact prompt
Notice what this prompt does: it encodes the contract the boundary behavior, the invariants. T he more precise your spec is the less the AI has to guess.
In hardware, guessing costs silicon.
GateFlow’s orchestrator enforces: ASK → PLAN → BUILD → VERIFY → ASSESS → (loop or done)
The planner architects the design.
- sv-codegen generates RTL.
- gf-lint checks it.
- sv-testbench writes tests.
- gf-sim runs simulation.
- If anything fails, specialist agents fix it and loop.
In under a minute, you get a working FIFO:
Here is FIFO code my Claude code gave me during writing this article
That’s the entire FIFO. 30 lines.
Not 300. Not “plus some library we’re importing.” Thirty odd lines. And it’s production-grade : this exact architecture is in server NICs moving 100 Gbps of data.
But you need to understand why each line exists.
Understanding the FIFO (Every Line)
- $clog2 calculates address bits :DEPTH=8 needs 3 bits (addresses 0–7)
- Extra-bit pointer trick : Pointers are ADDR_W+1 bits; MSB is a lap counter: same addresses, different MSBs = full; identical = empty
- Neat Tricks: This MSB trick is inside every FIFO, network switch, GPU queue, and DMA engine
- No memory reset :Pointer logic prevents reading unwritten slots, saving 256 flip-flops
- Combinational read : rd_data uses assign; oldest entry always visible, rd_xfer advances pointer (first-word fall-through)
- Natural wrapping : 4-bit counter cycles 0–15–0; lower 3 bits address memory, MSB toggles every 8 cycle and binary overflow handles it
The Testbench: Proving It Works
GateFlow generated a testbench with a scoreboard .
A software model that runs alongside the simulation. If hardware and model disagree, something is wrong.
Here is the detailed explanantion of the testbench
Here is the Output of all your hardwork
The above snippet is from the Output of the counter, since I want everyone reading this article to get their own win by doing the FIFO tests Stop. Feel this. I am Proud of You>
You just built a counter. The same primitive that’s inside every processor on Earth. Not a simplified tutorial version :the actual thing.
6 lines of SystemVerilog. A working testbench. and also a FIFO
This counter pattern is in your phone’s CPU, your laptop’s GPU, every network router, every hard drive controller. You described a machine in code, and now it exists.
If you had an FPGA board ($50 on Amazon), you could put this counter on actual silicon and watch LEDs increment at 100 MHz. That’s 100 million counts per second. YOU BUILT THIS !!!
What You Just Learned
You’re not a beginner anymore. You’re a hardware engineer who hasn’t built much yet That content you went through ? That’s 90% percent of a $150k/year skill. The other 10% is a decade long journey and by building more things, recognising patterns faster and debugging corner cases But foundation or atleast the curiosity you have it now.
Patterns you will use everywhere
Four patterns appear in nearly every design. GateFlow’s agents know them. You should too.
- Two-process FSM. State machines split into a register (always_ff) and logic (always_comb). The register holds current state; the logic computes next state. Start the always_comb with next_state = state so it holds by default.
- Pipeline stage. A register with valid/ready handshake. s_ready = !m_valid || m_ready :”I accept new data if I’m empty or downstream is taking my current data.” Chain them and backpressure propagates automatically.
- CDC synchronizer. When a signal crosses clock domains, pass it through 2 flip-flops in the destination domain. Only works for single-bit signals. Multi-bit crossings need a FIFO with gray-code pointers.
- Latch prevention. Always start always_comb blocks with a default assignment. If any path doesn’t assign the output, synthesis infers a latch. Latches are almost never what you want.
Why I Built Gateflow and also The End
I built GateFlow because if everyone can code, everyone can build hardware. Here is the repo :
Star, fork, build, copy whatever just get started
This is my first attempt at getting the world to write hardware. If it’s rough, that’s because we’re all figuring this out together.
Don’t just read this. Do it.
The tools are free. The knowledge is in this article. The only thing standing between you and hardware engineering is whether you actually open that terminal. Welcome to hardware. ❤️
gof.art.blog 