Move target definition into individual files.

Instead of defining each target in targets.py, now each target gets its
own .py file. This means people can easily keep their own target files
around that they may not want to put into the main test source. As part
of that, I removed the freedom-u500-sim target since I assume it's only
used internally at SiFive.

Added a few cleanups as well:
* Update README examples, mostly --sim_cmd instead of --cmd.
* Allow defining misa in a target, to skip running of ExamineTarget.
* Rename target.target() to target.create(), which is less confusing.
* Default --sim_cmd to `spike`
* Got rid of `use_fpu`, instead looking at F or D in $misa.

1 files changed, 29 insertions, 19 deletions

diff --git a/debug/README.md b/debug/README.md
index 04aa13a..1a802cf 100644
--- a/debug/README.md
+++ b/debug/README.md
@@ -12,37 +12,47 @@ Targets
 64-bit Spike
 ------------
 
-`./gdbserver.py --spike64 --cmd $RISCV/bin/spike`
+`./gdbserver.py targets/RISC-V/spike64.py`
 
 32-bit Spike
 ------------
 
-`./gdbserver.py --spike32 --cmd $RISCV/bin/spike`
+`./gdbserver.py targets/RISC-V/spike32.py`
 
-32-bit SiFive Core on Supported FPGA Boards &  Hardware
--------------------------------------
+32-bit SiFive Core on Supported FPGA Boards & Hardware
+------------------------------------------------------
 
-`./gdbserver.py --freedom-e300`
-`./gdbserver.py --hifive1`
+`./gdbserver.py targets/SiFive/E300.py`
+`./gdbserver.py targets/SiFive/HiFive1.py`
 
+Custom Target
+-------------
 
-32-bit rocket-chip core in Simulation
--------------------------------------
+For custom targets, you can create a .py file anywhere and pass its path on the
+command line. The Targets class in `targets.py` contains documentation on what
+every variable means.
 
-`./gdbserver.py --freedom-e300-sim`
+
+Log Files
+=========
+
+All output from tests ends up in the `logs/` subdirectory, with one log file
+per test. If a test fails, this is where to look.
 
 Debug Tips
 ==========
 
-You can run just a single test by specifying <class>.<function> on the command
-line, eg: `./gdbserver.py --spike64 --cmd $RISCV/bin/spike
-SimpleRegisterTest.test_s0`.
-Once that test has failed, you can look at gdb.log and (in this case) spike.log
-to get an idea of what might have gone wrong.
+You can run just a single test by specifying any part of its name on the
+command line, eg: `./gdbserver.py targets/RISC-V/spike64.py S0` runs
+SimpleS0Test.  Once that test has failed, you can look at the log file to get
+an idea of what might have gone wrong.
+
+You can see what spike is doing by adding `-l` to the spike command, eg.:
+`./gdbserver.py --sim_cmd "$RISCV/bin/spike -l" targets/RISC-V/spike32.py Breakpoint`
 
-You can see what spike is doing by add `-l` to the spike command, eg.:
-`./gdbserver.py --spike32 --cmd "$RISCV/bin/spike -l"
-DebugTest.test_breakpoint`. (Then look at spike.log.)
+You can see what OpenOCD is doing by adding `-d` to the OpenOCD command, eg.:
+`./gdbserver.py --server_cmd "openocd -d" targets/RISC-V/spike32.py Breakpoint`
 
-You can run gdb under valgrind by passing --gdb, eg.: `./gdbserver.py --spike64
---gdb "valgrind riscv64-unknown-elf-gdb" -- -v DownloadTest`.
+You can run gdb under valgrind by passing --gdb, eg.: `./gdbserver.py
+--gdb "valgrind riscv64-unknown-elf-gdb" targets/RISC-V/spike64.py
+DownloadTest`