Add debug module

[marnovandermaas]

This is a pretty big pull request, but it was quite complex to put together so I would rather not peal it apart too much. Apologies if this makes reviewing more difficult.

You can of course do a code review, but please also test this PR. You can do so with the following commands:

pushd sw/cpp/cheri_sanity
make CHERIOT_LLVM_ROOT=<path-to>/llvm-cheriot/bin CHERIOT_RTOS_SDK=<path-to>/cheriot-rtos/sdk
popd
pushd sw/cpp/error_leds
make CHERIOT_LLVM_ROOT=<path-to>/llvm-cheriot/bin CHERIOT_RTOS_SDK=<path-to>/cheriot-rtos/sdk
popd
fusesoc --cores-root=. run --target=synth --setup --build lowrisc:sonata:system
# Please connect up your Sonata board before the following command.
openFPGALoader -c ft4232 build/lowrisc_ibex_demo_system_0/synth_sonata-vivado/lowrisc_ibex_demo_system_0.bit
# You can observe that the user LEDs start blinking and respond to joystick presses after the previous command.
./util/load_new_software_on_fpga.sh ./sw/cpp/cheri_sanity/boot.elf
# You can now observe that the capability exception LEDs start cycling through.
# Also you can press the reset button (SW5) to clear remaining user LED state.

The first four commits are just lint cleanups I found along the way, which you can ignore during the review process.

[marnovandermaas]

The last force push squashes the changes to the load software script and the TCL because they are very related.

[GregAC]

Well doesn't work first time for me, I think it's the general JTAG flakiness we've been seeing rather than anything specific to do with this PR. I'll hopefully have some time to try again with the olimex JTAG adapter instead see if that works.

[GregAC]

Well works fine with the Olimex which is good. Maybe we're messing up the FTDI config somehow? I did just copy/paste the ftdi_layout_init from elsewhere without working out what it actually did, other than noting it seemed to work at the time!

[GregAC]

Oh and one more question, what's happening when the new program is being written to memory? There's nothing explicit to halt the CPU core so presumably it's running as we rewrite the instruction memory and then issue a reset? That could be pretty unreliable, especially if one binary allocates something as data it's actively reading and writing to and the new binary allocates the same space as code.

[HU90m]

Oh and one more question, what's happening when the new program is being written to memory? There's nothing explicit to halt the CPU core so presumably it's running as we rewrite the instruction memory and then issue a reset? That could be pretty unreliable, especially if one binary allocates something as data it's actively reading and writing to and the new binary allocates the same space as code.

Yep, the CPU core is reset with every word written from JTAG at the moment :nauseated_face: :

https://github.com/lowRISC/sonata-system/blob/a1345240eb7c872d59c7a1aeb226c600be4130cf/rtl/system/sonata_system.sv#L510

But we will probably be fine, because the CPU will likely never get past the first few lines of boot/setup-code before the next write.