Is it normal for my homemade CPU to work in simulation but freeze on real hardware?

Nov 07, 2026 Last reply: 17 hours ago 4 Replies

First reply

BirchSteve97

Your instinct about that reset button is solid, start there. In the simulator a floating input shows up as an unknown, but on real silicon the pin just settles at whatever stray voltage is floating around, so your logic may genuinely belive reset is held down forever. Check the…

Read the full reply

So I've been slowly building my own little computer on an FPGA board, just a simple thing with a tiny instruction set I made up myself. everythign runs fine in the simulator. I can watch the signals step thru, the test program does exactly what I want, life is good. Then I load the same design onto the actual chip and it just sits there. The LEDs show my reset state and nothing moves after that. Same code, same everything, as far as I can tell. I keep reading that clock signals are ussually the culprit, so maybe I should look there first, but honestly I don't even know what to measure. I don't own a scope and I'm not sure the cheap logic analyzer I found secondhand would help much anyway. Could it also be that my reset logic behaves differently in real silicon? I tied it to a button and I wonder if the pin is floating when I'm not pressing it. That's the only thing that stands out to me so far.


Your instinct about that reset button is solid, start there. In the simulator a floating input shows up as an unknown, but on real silicon the pin just settles at whatever stray voltage is floating around, so your logic may genuinely belive reset is held down forever. Check the board schematic: most buttons wire to ground when pressed, which means the pin needs somethig holding it at the other level while you're not pressing. You can usually enable an internal pull resistor in your pin settings file, no soldering required. And while you're in that file, verify every signal is mapped to a real physical pin, in the right direction, and that pressed reads as the value your code expects. Some boards give you a zero when the button is down, not a one. A wrong or missing pin mapping is the single most common reason a design runs perfectly in simulation and does absolutely nothing on the board.

I'd push back a little on the claim that a bad pin mapping is the single most common cause here. In my experiance the design sitting frozen in its reset state with the simulator clean usually points to the clock never reaching the fabric at all, like an input assigned as a plain pin when the board routes it through some clock-only input. The tool will often let it pass synthesis and then it just goes nowhere on the chip. Simple test without any gear: replace the real clock input for one run with a button as the clock, and if the logic starts stepping you know the design works and the clock path is the problem.

Had something similar-ish happen with my first attempt at a small CPU, and it turned out the tools had optimized half my design away because nothing external depended on it. Synthesis finished clean, I assumed all was good, but my state machine was basicly gutted. Might be worth wiring one of the LEDs to a counter bit straight off your clock, something dumb that can't be removed. If that LED blinks on the board you know the clock is alive and the problem is elsewhere. If it stays dark you've narrowed things down alot without needing any gear.

Update: so the reset button was exactly the problem. I pulled up the board schematic and that input has no pull resistor on it, so the pin was just dangling whenever I let go. Jumpered it to ground through a switch I had spare and the design suddenly runs. One thing though, the reply about synthesis deleting unused logic has me worried. How do you tell if your state machine actually survived without hooking everything to an output first?

Join the Discussion

Have something to add? Share your thoughts — no account required.

Didn't find your answer?

Ask the community — no account required