While technicaly you are right, i think you missed the spirit of what the doc was saying.
You may write it all in a single process, but you will always have duplicated code blocks, especialy if those 3 types of hardware (ff,ff with reset, comb) share assignements with the same condition.
Honnestly, i haven't realy think about it.
Not a constraining one, but more something like :
Do what ever you want with it, but if you find a bug, please tell me, and if you use it in a project which has a lot of money, please, share a bit with opensource guys, don't be too greedy ^^
Yes it would be, it is very easy to retarget the CPU to another memory bus.
Then the Wishbone one isn't "perfect" as it can't map memories which have latencies without performance penality. It would be oky for the data bus of the cpu with or without cache, but for the instruction, without instruction cache, peak CPI would be divided by the memory latency.
Yes, silicon implementation provide the JTAG, but it's very likely their implementation will not be reusable for FPGA project (including JTAG debug things) because of their over complicated (but powerfull) solutions which would consume way to much area and restrict the FMax.
Then this specific VexRiscv ecosystem also provide a basic SoC with an multi master AXI4 inteconnect, SDRAM controller, embedded ram, APB3 interconnect, some slave like GPIO, UART, Timer, VGA. It's not incredible, but it's already a starting point ^^
See https://github.com/SpinalHDL/VexRiscv#briey-soc
Chisel, SpinalHDL, Clash, Migen, Amaranth aren't HLS
Most of the time, if you get some verilog out of those tools with mangled names, it can be because of bad coding practice.
Here is some examples about how to preserve good names for SpinalHDL : https://spinalhdl.github.io/SpinalDoc-RTD/master/SpinalHDL/S...