A CPU runs instructions one at a time. An FPGA becomes the circuit you need.
Think of a regular CPU — the chip in your laptop — as a super-fast chef who can only do one task at a time, but switches between tasks so quickly it feels instant. It reads instructions one by one from a program, executes them in sequence, and even though it seems like it does many things "at once," under the hood it's a tight loop of fetch → decode → execute, over and over, billions of times a second.
An FPGA is a completely different kind of chip. Imagine a warehouse full of thousands of empty, identical Lego-like blocks (called LUTs, short for Look-Up Tables) sitting on a grid, along with a mesh of wires connecting them. When you "program" an FPGA, you're not writing instructions for it to execute — you're deciding how to wire those blocks together to physically become the circuit you want. Once configured, there's no "loop" happening. Every block is just sitting there, constantly computing its little piece of the puzzle, all at the same time, every clock tick.
Why this matters for your CNN work specifically: imagine your 3×3 convolution operation. On a CPU, this means: loop over 9 pixel-weight pairs, multiply, add to accumulator, repeat for every pixel in the image — all one at a time, sequentially, even if it "feels" fast because the clock runs in gigahertz.
On an FPGA, you build a physical circuit where all 9 multiplications happen simultaneously in dedicated hardware (using DSP48 slices, covered in Phase 5), and the results get summed the same clock cycle. As pixels stream in, you get one finished output pixel per clock tick — not because it's "faster instructions," but because the multiplication and addition are physically wired to happen in parallel, permanently, as long as the chip is powered.
This is the entire reason a project like this targets FPGA deployment instead of just running the CNN on a CPU: latency. A CPU-based sequential approach could easily blow past a 10-second budget; a properly pipelined FPGA circuit does it in a fraction of that because nothing is waiting in a queue.
A useful mental model: a CPU is a general-purpose calculator you give different instructions to. An FPGA is a pile of raw materials you use to build a purpose-specific calculator, once — but it only does your one task, extremely fast and extremely efficiently, because there's zero instruction-fetching overhead.
One more distinction worth planting early: "programming" an FPGA (with Verilog, Phase 4) is fundamentally different from programming a CPU (with Python or C). In software, code runs top-to-bottom, one line after another. In Verilog, you're not writing a sequence of steps — you're describing a static structure of wires and components that all exist and operate simultaneously, forever, once powered on. This trips up almost every software person learning hardware for the first time: you are describing a physical thing, not a sequence of actions.
Your 3×3 convolution can run as one single physical circuit that produces one output per clock tick, instead of a CPU looping through multiplications. This is the entire reason a project like this targets FPGA deployment instead of a CPU: a 10-second latency budget is easy to blow past with sequential execution, but a properly pipelined circuit does it in a fraction of that.