target/sim: Add JTAG tasks for reg access and preloading

[alex96295]

First of three steps to merge back features/bugfixes from Carfield project. This is a testbench/simulation-only feature.

Remaining two steps (RTL features) are #102 and #74, to be addressed later

[alex96295]

@paulsc96 rfc when you have time

[paulsc96]

Here are my comments:

• Please stay consistent with code formatting. This file has no newlines in tasks, no trailing whitespaces in task parameter lists, and no spelling errors in comments, and all that is intentional :)
• Please don't duplicate functionality.
  • jtag_elf_halt_load does an exact subset of what jtag_elf_run does, so jtag_elf_run should reuse this new code.
  • Same goes with jtag_poll_bit0 and jtag_read_reg32.
  • Same goes with jtag_elf_run and jtag_write_reg32.
• Please name these meaningfully. If jtag_read_reg32 has the 32 suffix, why does jtag_read_reg, doing exclusively double reads, not have a 64 suffix? Why even hardcode access size if the difference in task code are so minimal?

Admittedly, I could have given this feedback earlier, but these "oversights" (read: you dumped this code here without a second look at the diff) discouraged me a bit. It's faster and simpler to do what you should have done and clean up the diff, but you knew I would anyways 😉 Good on you for dodging work at my expense.

[paulsc96]

Bonus round of comments (to be updated):

• (Added on top for relevance) What you set the SBCS register to is important. Your jtag_write_reg32 task sets sbreadonaddr, but never reads after writing to SBAddress0, leaving dead data behind in the debug module that a subsequent read task would erroneously read. This is bad.
• When checking writes, are you sure you can read immediately after writing? I am not sure anything is strictly enforcing read-write consistency on our debug path.
• The tasks are intentionally ordered by their dependencies (i.e. tasks depending on others are defined after their dependencies). Really helps reading these tasks.
• Why do your tasks hardcode 32 bit addresses? This is a 64-bit system with (potentially) up to 64 bits of address, and all other tasks use a doub_bt accordingly.
• You have a congruent set of four tasks reading and writing 32 and 64 bit data, but they cannot agree on consistent naming of arguments, variables, and even types (more in this in the next point).
  • Wait, are these supposed to be congruent? They are all over the place... jtag_read_reg and jtag_read_reg32 differ only in their argument types in effect (either both 2-value 64-bit or 4-value 32-bit), while jtag_write_reg and jtag_write_reg32 have the same widths (but not value types?) in both cases and just truncate them? Also, jtag_write_reg checks the write and jtag_write_reg32 does not. If this PR is an elaborate joke, this is where you should tell me. In any case, I am laughing by now..
  • At this point, I am not sure these actually work as intended - but then again, I can't discern the intent, so you got me there. Why is sbaccess always 2 (32-bit accesses)?
• 2-value and 4-value logic vectors are not the same, and the *_bt types are 2-value unlike the logic vectors you introduce (why? all other tasks of this kind use 2-value types).
• Whether and when a task displays messages should be consistent. Why do the register write tasks print, but the read tasks don't?

[paulsc96]

Here's my proposal for something mergeable:

• I integrated jtag_elf_halt_load into jtag_elf_run, as it was literally copy-pasted from that task to begin with.
• I discarded jtag_read_reg and jtag_write_reg, since I simply cannot understand what they intended to do or how they are supposed to differ from the 32-suffixed variants. Those, in turn, I cleaned up a bit and addressed the above points. Since I make no 32-bit writes yet, there is no point in reusing the 32 variants specifically.

If you want the non-32-variant tasks back, they should at least do something clearly discernable.