Add links to decoder info

diff --git a/updates/023_2020mar26_decoder_emulator_started.mdwn b/updates/023_2020mar26_decoder_emulator_started.mdwn
index 6a9ca7b36c2aeae519460f65b4ace40ffda1ac89..593d81a3ca8210a776aafeda31f92a372638ee41 100644 (file)
--- 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