You’ve probably seen it a hundred times by now. Someone builds a custom CPU core, and the first thing the internet asks is: “But can it run Doom?”
It’s a joke. It’s also the smartest engineering validation strategy nobody talks about.
Recently, a team did exactly this — they built a custom RISC-V CPU core on an FPGA, wrote it in Chisel, took it through synthesis, and then ran Doom on it. The internet lost its mind. Comments flooded in. The post went viral. And buried under all the nostalgia and pixelated demon-slaying was something far more interesting than the game itself.
The best benchmark isn’t a number. It’s a feeling.
Here’s what everyone misses about the “Doom on custom hardware” phenomenon. People think the viral moment proves the CPU is efficient, or innovative, or practical. It doesn’t. It proves something better: that the design is correct. Every instruction, every memory access, every pipeline stage — they all work. Not because a test suite says so, but because a real, decades-old piece of software boots up and runs without crashing.
That’s the twist. Doom isn’t a stress test. It’s a truth serum for your hardware.
Think about the traditional alternative. You write a testbench. You run some synthetic benchmarks. You get numbers — MIPS, Dhrystone, CoreMark. They look great in a paper. They mean almost nothing to anyone outside your team. Nobody screenshots a CoreMark score and sends it to a friend.
But Doom? Doom is a universal language. It’s the one piece of software that every hardware nerd, every retro gaming enthusiast, every curious engineer recognizes instantly. When someone sees Doom running on a chip you designed from scratch, they don’t need to understand RISC-V. They don’t need to know what Chisel is. They just get it.
You can argue with a benchmark. You can’t argue with a demon getting shot in the face on hardware you built yourself.
Now, let’s be honest about something. Building a custom RV32I core on an FPGA to run a 1993 game is, by any practical measure, absurd. The effort is wildly disproportionate. You could buy a Raspberry Pi for $35 and run Doom better in five minutes. But that’s exactly the point.
The hardware community doesn’t value utility. It values proof. Proof that you understood the ISA well enough to implement it. Proof that your memory controller actually works under real software load. Proof that you cared enough to go from Verilog to pixels on a screen.
This is why the article’s comment section is so revealing. One person notes it’s an RV32I core, not a custom architecture — and there’s a flicker of disappointment, like someone who thought they were seeing magic and realized it was engineering. But another commenter lights up at seeing Chisel “in the wild.” That’s the real audience. Not the people who want a product. The people who want to see the craft.
The hardware world runs on two currencies: respect and curiosity. Doom buys you both at once.
If you’re a student or hobbyist staring at a half-finished CPU design wondering whether it’s worth pushing through to completion, here’s your answer. Don’t write another testbench. Don’t generate another waveform dump. Port Doom. Or port something — anything — that produces a recognizable output on a screen. Because the moment you see that first frame render on hardware you designed, something shifts. The abstract becomes tangible. The spreadsheet becomes a shotgun.
That’s not just satisfying. It’s the entire point.
We spend so much time in hardware engineering talking about efficiency, optimization, and practical applications that we forget the thing that drew us in originally: the sheer, irrational thrill of making something work. Not because it’s useful. Not because it’s fast. Because it’s cool.
The best engineering doesn’t solve a problem. It creates a moment where someone says, “Wait — you actually built that?”
Doom on a custom CPU isn’t a benchmark. It’s a love letter to the craft of building things from nothing. And the internet’s reaction proves what we’ve always known but rarely admit: that the deepest technical validation isn’t a number on a chart. It’s a room full of people who can’t stop watching a 30-year-old game run on a chip that didn’t exist last month.
So stop benchmarking. Start building something that makes people feel something. The numbers will follow. Or they won’t. Either way, you’ll have something better — a story worth screenshotting.
FAQ
Q: Isn't running Doom just a gimmick that tells you nothing about real CPU performance?
A: It absolutely won't give you a clean MIPS score or tell you how your core handles modern workloads. But it tells you something more fundamental: that your instruction set implementation is correct enough to run real, compiled software. That's a validation milestone synthetic benchmarks often can't match.
Q: What's the practical takeaway for someone learning hardware design?
A: Stop obsessing over benchmark numbers and start obsessing over visible, tangible proof that your design works. Port a real program — Doom, Pong, a text editor — and get it running on your hardware. The moment you see real software execute on a chip you designed, you've crossed the line from 'student project' to 'working system.'
Q: Is the viral attention around 'Doom on X' actually harmful to hardware engineering discourse?
A: Yes, partially. It risks reducing complex hardware validation to a meme, and it can mislead beginners into thinking running Doom means their CPU is production-ready. But the counterargument is stronger: anything that gets people excited about low-level hardware design in an era of black-box abstraction is a net positive. The gimmick opens the door; the craft keeps people inside.