From 92adcafe623049712526b6296e8fb54a2b6ffe4a Mon Sep 17 00:00:00 2001 From: Michael Nolan Date: Sun, 29 Mar 2020 13:45:31 -0400 Subject: [PATCH] Add links to decoder info --- ...23_2020mar26_decoder_emulator_started.mdwn | 27 ++++++++++--------- 1 file changed, 15 insertions(+), 12 deletions(-) diff --git a/updates/023_2020mar26_decoder_emulator_started.mdwn b/updates/023_2020mar26_decoder_emulator_started.mdwn index 6a9ca7b..593d81a 100644 --- a/updates/023_2020mar26_decoder_emulator_started.mdwn +++ b/updates/023_2020mar26_decoder_emulator_started.mdwn @@ -185,18 +185,20 @@ specification to text, and wrote a module in python to extract those fields from an instruction. To test the decoder, we initially verified it against the tables we -extracted, and manually against the power ISA specification. Later -however, we came up with the idea of verifying the decoder against the -output of the GNU assembler. This is done by selecting an instruction -type (integer reg/reg, integer immediate, load store, etc), and -randomly selecting the opcode, registers, immediates, and other -operands. We then feed this instruction to GNU AS to assemble, and -then the assembled instruction is sent to our decoder. From this, we -can then verify that the output of the decoder matches what was generated -earlier. +extracted, and manually against the [POWER ISA +specification](https://openpowerfoundation.org/?resource_lib=power-isa-version-3-0). Later +however, we came up with the idea of [verifying the +decoder](https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/decoder/test/test_decoder_gas.py;h=9238d3878d964907c5569a3468d6895effb7dc02;hb=433ab59cf9b7ab1ae10754798fc1c110e705db76) +against the output of the GNU assembler. This is done by selecting an +instruction type (integer reg/reg, integer immediate, load store, +etc), and randomly selecting the opcode, registers, immediates, and +other operands. We then feed this instruction to GNU AS to assemble, +and then the assembled instruction is sent to our decoder. From this, +we can then verify that the output of the decoder matches what was +generated earlier. We also explored using a similar idea to test the functionality of the -entire SOC. By using the [QEMU](https://www.qemu.org/) powerpc +entire SOC. By using the [QEMU](https://www.qemu.org/) PowerPC emulator, we can compare the execution of our SOC against that of the emulator to verify that our decoder and backend are working correctly. We would write snippets of test code (or potentially randomly generate @@ -205,8 +207,9 @@ QEMU. We would then simulate our SOC until it was finished executing instructions, and use Qemu's gdb interface to do the same. We would then use Qemu's gdb interface to compare the register file and memory with that of our SOC to verify that it is working correctly. I did -some experimentation using this technique to verify a rudimentary -simulator of the SOC backend, and it seemed to work quite well. +some experimentation using this technique to verify a [rudimentary +simulator](https://git.libre-riscv.org/?p=soc.git;a=blob;f=src/soc/simulator/test_sim.py;h=aadaf667eff7317b1aa514993cd82b9abedf1047;hb=433ab59cf9b7ab1ae10754798fc1c110e705db76) +of the SOC backend, and it seemed to work quite well. *(Note from Luke: this automated approach, taking either other people's regularly-written code or actual PDF specifications, not only saves us a -- 2.30.2