It’s a trope among thriller writers; the three-word apocalyptic title. An innocuous item with the power to release unimaginable disaster, which of course our plucky hero must secure to save the day. Happily [Sylvain Lefebvre]’s DOOM chip will not cause the world to end, but it does present a vision of a very 1990s apocalypse. It’s a hardware-only implementation of the first level from id Software’s iconic 1993 first-person-shooter, DOOM. As he puts it: “Algorithm is burned into wires, LUTs and flip-flops on an #FPGA: no CPU, no opcodes, no instruction counter. Running on Altera CycloneV + SDRAM”. It’s the game, or at least the E1M1 map from it sans monsters, solely in silicon. In a very on-theme touch, the rendering engine has 666 lines of code, and the level data is transcribed from the original into hardware tables by a LUA script. It doesn’t appear to be in his GitHub account so far, but we live in hope that one day he’ll put it up.
“Will it run DOOM” is almost a standard for new hardware, but it conceals the immense legacy of this game. It wasn’t the first to adopt a 1st-person 3D gaming environment, but it was the game that defined the genre of realistic and immersive FPS releases that continue to this day. We first played DOOM on a creaking 386, we’ve seen it on all kinds of hardware since, and like very few other games of its age it’s still receiving active development from a large community today. We still mourn slightly that it’s taken the best part of three decades for someone to do a decent Amiga port.
Just asked to port it to the more common misterfpga.org platform
I sort of amazed but i dont understand how it works. How does it output video with no counter, how does it determine what part of map to render, etc. Need more info…
It just says no program counter, not that there are no counters at all. I’d imagine there are pixel counters and counters for specialized things. I would guess it is just a series of state machines. The game engine is much like a CPU emulator, so what if the .WAD files are the native “instruction set?”
I tried something similar – implementing things normally done in software – in hardware (using VHDL – target was ProASIC3) – what i ended up was bunch of quiet complicated state machines. The line between software and hardware started to blurry. If you have plain old three-process state machine with hard coded everything that is probably still hardware, but what if you replace for example the output process logic (large case and bunch of if statements) with lookup table (address being the inputs and the encoded state, data is the outputs)? Still hardware? Or is that software? You can argue that normal CPU/MCU executes from somehow changeable memory – but what about mask ROM cpus? You can have mask ROM cpu with just registers and no RAM – that will look just like bunch of logic from one point of view – like a complicated state machine. Also there is micro-programmed state machines – they have opcodes but don’t have program counter.
DOOM in FPGA is impressive though, would be nice to know what language was used to make it.
It doesn’t matter if you use LUTs or IF statements as the synthesis engine will always reduce it to a minimum gate count.
The LUTs or IF statements only exist at the HDL abstraction level.
For me the destinction between software or hardware implementation is weather there is sequential indexed execution like a program counter.
Well imagine this – you have 8051 core in HDL – than instead of connecting it to some flash interface, you define the program as large constant in HDL (array, large case / when … this can be easily generated by script from machine code representation of a program). The synthesis tool will dissolve this into some kind of logic to the point that it will remove unused parts of the 8051 – the CPU core will be optimized to run that one single program. Yes, somewhere in there will be something resembling counter – but on the LUT level, it can happen that it will be hardly recognizable as counter as it can be dissolved into other logic and optimized. Hardware or software? It clearly executes 8051 machine code – but is hardware optimized for that single program.
FPGA synthesis tools are not good enough for this. Maybe some small parts of the instruction decoder will be pruned but that will be about it I think. Proving that the input language has no way to use for example certain addresses is far from trivial.
Your example is software as it still sequentially executing op codes.
The doom chip is not this. It has no op codes or sequential execution.
It’s hard to tell anymore if this is actually truly fascinating or just a tired old social media meme
It’s only tired when there are no more novel things to run DOOM on.
I’m not into gaming at all but it sounds pretty cool to me.
Because it couldn’t possibly be anything in between?
Neat implementation, a lot of work, but not ground breaking…
This is a combination of 2 old concepts. Back in 2006, I helped college students implement Wolfenstein 3D in this manner on an FPGA. Granted, that implementation had a program counter. It was a final project for Computer Hardware Design (CSE 378) at Oakland University in Michigan, USA.
The same year, we developed the algorithms to turn Java bytecode into VHDL for use on FPGAs without implementing a CPU. A few years later it was adapted to accept .NET CIL code. This research project was called Flowpaths, also done at Oakland University, with papers published about it.
Never good when someone put doom and realistic in the same sentence.
There’s much attention paid to Doom. So much less to Duke Nukem 3D that I’ve spent the last fortnight unable to remember it’s name until just now.
if you watch the video, he implemented a CPU within the FPGA. So, not exactly bare metal as everyone is saying.
Can you help me see it? Which video do you mean / what shows a CPU being there?
On a less serious note: if I don’t watch it, does he NOT implement the CPU?
Code is now in github: https://github.com/sylefeb/Silice/tree/draft/projects/doomchip