What to do when developing an RP2040 emulator but validating the emulator instruction by instruction is a slow and tedious process? Why, automatically compare it against the real hardware if you’re [Uri Shaked], of course. This is the purpose of gdbdiff. This project uses the GDB remote serial protocol via OpenOCD to run test firmware step by step.
During a livestream (video linked via the above link), this allowed [Uri] to find a number of instruction bugs in the emulator this way. These issues involved issues such as incorrect flags in the APSR register and an edge case in the LSRS register. This gdbdiff livestream is part of an entire series of live-coding sessions during which [Uri] writes an RP2040 emulator from scratch.
We applaud [Uri] for creative thinking here, and assume that this way the livestream was probably more entertaining to watch than when doing instruction-level debugging purely by hand :)
15 thoughts on “Gdbdiff: Diff-ing A Real RP2040 MCU Against An Emulated MCU”
Why would anyone need an emulator for a product that costs $5.00 ? Just buy the dam thing and try it for real.
Or why would RPi make this thing and why is HaD obsessed with all things Pi?
The state machines are actually pretty cool. Why shouldn’t RPi make it? It’s a pretty sweet and flexible chip. While its datasheet isn’t in a traditional form, it’s a pretty easy read and I haven’t found any missing info yet.
Only birds don’t pee
For proving out a design before prototyping it on actual hardware?
I get having an emulator if you have an FPGA with like 500+ pins and its price is hundreds of dollars. But this is an RP2040. It can’t do a whole hell of allot, and no board its connected to including parts is going to cost much. So the amount of time invested to do this (though a great job) is not really useful. The time it took to develop this you could have prototyped 8 designs,
For continuous integration.
The author built a framework for emulating embedded micros, including Arduino and pico. It’s a great tool for prototyping and teaching. The capabilities are amazing: for instance you can hook an in browser gdb session.
The author just implemented a PIO debugger, so you can emulate, single-step and examine the PIO controllers. This is not possible on real hardware, so it is a fantastic development aid—it alone would justify the usefulness of the simulator.
for running unit tests, for debugging race conditions, for testing with hardware that doesnt exist yet, for teaching….
The first problem is that they are trying to run on silicone… so I won’t give it my sealant of approval.
No need to write an emulator, it’s 2021 and all the hardware is open hardware!
Just take the VHDL and launch it in Verilator!
What a wonderful world!
Now when you have this, can you use this to train an AI model such that it learns how the real hardware behaves and then use that as an emulator?
We still do not know what an AI “thinks” and the news are full of reports of AI mishaps.
Please be kind and respectful to help make the comments section excellent. (Comment Policy)