Key Takeaways
- A custom CPU built from scratch successfully ran Doom in real time after substantial work on memory, cache behavior, peripherals, and software porting.
- The project moved beyond simple programs like Pong and Mandelbrot, but hardware limits and performance bottlenecks made Doom a much harder target.
- After compiler and hardware fixes, the game reportedly reached 15–20 FPS, and a short video of the result drew millions of views.
What happened
The project began as a custom CPU designed at the logic-gate level and deployed on an FPGA. Before Doom, the system had already run smaller programs such as Pong and Mandelbrot, but the jump to Doom forced the builders to solve much harder problems in memory capacity, memory latency, and overall throughput.
One major obstacle was storage size. The article says the FPGA’s on-board BRAM was under a megabyte, while Doom’s shareware data file alone was described as 14 megabytes. That meant the team had to integrate external DDR3 memory rather than rely only on the FPGA’s internal memory. But DDR3 introduced its own complications: slower access, variable latency, and much wider bus widths than the CPU had previously used.
To deal with that, the CPU design was expanded around a more standard five-stage pipeline: instruction fetch, decode, register read, execute, and writeback. The fetch and execute paths were separated from memory details through a unified interface, and the system gained both an instruction cache and a data cache. According to the source, each cache was a simple directly mapped design with 2,048 lines and four words per line.
The article also describes a memory arbiter, needed because both caches could request memory at once even though the board had only one DDR3 chip. The arbiter queued requests and prioritized the data cache to avoid starvation. For the low-level hardware interface, the builders used Xilinx’s Memory Interface Generator and added clock-domain crossings, FIFOs, and wrappers so the CPU could talk to DDR3 reliably.
The team also had to add the peripherals Doom would need. The post says they used memory-mapped I/O for display output, a timer, debug output, and keyboard input. The VGA controller was expanded to 12-bit color and connected to HDMI. Keyboard input ended up being handled through a UART receiver from a laptop after an attempted USB path did not work as planned.
Porting Doom itself exposed a second layer of issues. The source says the builders used doomgeneric to simplify the port, but they still ran into file-system problems, rendering issues, printf bugs, and CPU errors that only surfaced under a larger workload. At one point, the game would appear to halt in random places or jump to nonsensical addresses. The breakthrough came when the simulation was changed to initialize DDR3 memory with random values before loading the program, which revealed that Doom had been assuming zeroed uninitialized memory. After additional linking and assembly fixes, the game finally loaded in hardware.
Why it matters
The story is less about Doom as a game and more about what it exposed about the CPU design process. Running a real application with a meaningful memory footprint forced the builders to confront the practical tradeoffs of cache design, pipeline hazards, DDR3 latency, and peripheral integration.
That makes the project a useful case study in computer architecture. A CPU that can run small test programs is not necessarily ready for real software. Doom became a stress test for the full stack: instruction fetch, memory arbitration, cache coherence within the design, I/O paths, compiler assumptions, and hardware/software debugging. The article suggests that many of the bugs were not Doom-specific at all; they were latent CPU issues that had not been triggered by earlier demos.
The performance progression is also notable. The author says the game first ran at about 0.7 FPS, then improved through a series of optimizations: a faster clock, a more efficient fetch stage, multiplication support, direct writes to VGA BRAM, pipelined cache hits, and finally compiler optimization after fixing a missing volatile on the hardware timer MMIO pointer. With those changes, Doom reportedly reached 15–20 FPS, which the author described as playable.
There is also a software lesson in the compiler bug. The CPU worked until optimization changed the generated code, exposing the fact that the timer register had not been declared volatile. That kind of issue is common in systems programming, but in this case it directly affected whether the game would run at all.
What to watch
The article says the team is now working on out-of-order processing and better memory access patterns, both of which could improve performance further. Those changes would likely alter much of the existing pipeline, which is why the author says they did not want to invest too heavily in this version of the CPU.
Future hardware work could matter just as much as software changes. The author mentions the possibility of a basic GPU and a larger FPGA board, and even floats the idea of porting Quake II later on. For now, the more immediate question is whether the current CPU design can keep improving without a major rewrite.
The viral response is another thing to watch. The source says a nine-second video of Doom running on the custom CPU drew about 2 million views. That kind of attention often turns a hobby project into a broader showcase for hardware design, especially when the underlying engineering details are as substantial as they are here.
