We need one example unit test of how to run some assembly code "qemu vs simulator" rather than "qemu vs hardware" or, even just "qemu with some asserts" but looking *exactly* like how it's done in the simulator, right now. and that ultimately it should be possible to have a runtime switch (or a suite of tests) that allow us to verify *aaalll* the simulator test_pipe_caller.py tests, in the following way: * simulator vs qemu * qemu vs hardware * hardware vs simulator later i would very much like to be able to add microwatt to that list. <https://bugs.libre-soc.org/show_bug.cgi?id=325#c82>
Ok, I did this quite a while ago, testing against my crappy handwritten python simulator. I'll give testing against the pseudocode simulator tomorrow a go. Beware, from what I remember only general purpose registers work. qemu-gdb seemed to have a bug (or maybe it's qemu? idk) where you couldn't read out XER, CR, and friends directly from gdb.
(In reply to Michael Nolan from comment #1) > Ok, I did this quite a while ago, testing against my crappy handwritten > python simulator. I'll give testing against the pseudocode simulator > tomorrow a go. that would be superb. > Beware, from what I remember only general purpose registers work. qemu-gdb > seemed to have a bug (or maybe it's qemu? idk) where you couldn't read out > XER, CR, and friends directly from gdb. hmmm... we could cheat, in a similar way to how gdb itself works: substitute some instructions, actually execute mfcrf and mfmsr etc. directly putting the result into a register, read *that*, then restore them afterwards. or, it could just be that python-gdb doesn't have the capability added yet. at least however if we can check int registers, then another hack-way to do it would be to actually add, into the assembly listing being emulated, the instruction to copy out to RT. it's a bad hack.
We could also do what I did originally. It's not particularly elegant, but at the end of a program where I wanted to check CR, I manually added a mfcr $some_register to the end. It won't allow us to check everything in lockstep, but it will let us verify that the two simulators produce the same results for a given program.
Oh, since the actual debug interface uses gdb and has nothing to do with qemu, it might be possible to run the generated programs under gdb on power hardware.
(In reply to Michael Nolan from comment #4) > Oh, since the actual debug interface uses gdb and has nothing to do with > qemu, it might be possible to run the generated programs under gdb on power > hardware. oh of course. and... hmmm... here's an idea. if an option can be added which allows that to be done through ssh, we'd be able to work locally and not have to have a full dev environment on talos1.libre-soc.org (each). one utterly cool way of doing remote python execution: https://github.com/tomerfiliba/rpyc he invented a packet format and a protocol that contains commands like "dir()" so you get back the list of objects, and so on. even exceptions are properly transferred. once "on" that remote system, the only library that would need to be installed on the *remote* system: pygdbmi.
Ok, I think I've got something working. In soc/simulator/test_sim.py, I replaced the code dealing with my handwritten simulator with what's needed to use the pseudocode simulator. All the tests, except for multiplication now work
(In reply to Michael Nolan from comment #6) > Ok, I think I've got something working. In soc/simulator/test_sim.py, I > replaced the code dealing with my handwritten simulator with what's needed > to use the pseudocode simulator. All the tests, except for multiplication > now work fantastic. now we're cooking. ultimately it should be possible to morph this into classes that have a "set inputs" method, a "run_program" method, and a "get results" method. then we can construct unit tests that can be passed in one class instance that does qemu, and another that does hardware, another that does simulator, and compare anything-against-anything.
https://docs.cocotb.org/en/latest/quickstart.html should allow us to also include microwatt in the mix. TODO later. thank you michael for getting this started.