VexRiscV system with GDB-Server in Hardware

Interesting approach to put this into pure hardware, but I strongly 
believe you'll get more 'love' with implementing a proper JTAG protocol 
directly to the core (avoiding the puzzling RISC-V debug interface 
design).
I tend to stay away from the serial gdb server protocol as far as I can 
due to stability issues seen in the past. When it comes to debugging: 
Keep it as simple as possible, use in-circuit-emulation only.

From my viewpoint the "the puzzling RISC-V debug interface" is a very 
interesting interface directly into the core of the VexRiscV, which 
allows to adapt different frontends for debugging.
If you don't want to spend much hardware for the debug interface, you 
are definitely better off with JTAG. There is already a JTAG interface 
available for the VexRiscV processor and a related OpenOCD port.

The approach presented here serves to make access to the processor from 
the development environment view "as simple as possible". Beginners in 
particular often find it very difficult to put the necessary environment 
of debugger, GDB server and suitable debug interface together to debug 
self-designed processor systems in FPGAs.

The presented GDB server in hardware simplifies experimenting with the 
very interesting VexRiscV. With the Basys3 board, you only need a single 
USB connection to the PC. The board is first configured via this 
connection and then the GDB debugger can be directely connected to the 
GDB server via the COM port of the same USB connection.

I am surprised that you address stability issues of other systems you 
have seen in the past at this point. This GDB-Server runs very stable. 
This has to be the case, since it is also used in training courses for 
beginners in FPGA design and computer organization.

Great project!
However, I also prefer JTAG ;)

In case you are interested, here is a RISC-V compliant debug transport 
module (JTAG TAP): https://github.com/stnolting/riscv-debug-dtm

This module has been successfully integrated (together with a compatible 
"debug module") into an open RISC-V soft-core SoC: 
https://github.com/stnolting/neorv32

Thanks for this very interesting hint.