rename picorv32_soc to toy_SoC, add readme

.gitmodules

@@ -17,11 +17,11 @@
 	path = examples/hazard3/Hazard3
 	url = https://github.com/Wren6991/Hazard3.git
 [submodule "examples/picorv32_soc/picorv32"]
-	path = examples/picorv32_soc/picorv32
+	path = examples/toy_SoC/picorv32
 	url = https://github.com/YosysHQ/picorv32
 [submodule "examples/picorv32_soc/urv-core"]
-	path = examples/picorv32_soc/urv-core
+	path = examples/toy_SoC/urv-core
 	url = https://ohwr.org/project/urv-core.git
 [submodule "examples/picorv32_soc/mdu"]
-	path = examples/picorv32_soc/mdu
+	path = examples/toy_SoC/mdu
 	url = https://github.com/zeeshanrafique23/mdu.git

README.md

@@ -8,7 +8,7 @@ GVI generates glue code that allows to run Verilog modules inside of VHDL testbe
  - examples/serv: Run an instance of the serv risc-v cpu.
  - examples/ibex: Run an instance of a more performant risc-v cpu.
  - examples/hazard3: Run an instance of yet another risc-v cpu.
- - examples/picorv32_soc: A slightly more complex example with yet another risc-v CPU. The CPU has a custom wishbone wrapper for data and instruction bus and runs a firmware stored in memory that calculates digits of PI and writes these digits onto a pseudo UART device that ends up in a text file in the simulation directory (`cpu_output.txt`). 
+ - examples/toy_SoC: A slightly more complex example with a simple SoC. Three RISC-V CPUs (uRV, picorv32, serv with MDU) are available. They have a custom wishbone wrapper for data and instruction bus and all CPUs runs the exact same firmware stored in memory that calculates digits of PI and writes these digits onto a pseudo UART device that ends up in a text file in the simulation directory (`cpu_output.txt`). [more details are here](examples/toy_SoC/README.md)
  - examples/wr-cores: Run an instance of the WhiteRabbit core, [build instructions are here](examples/wr-cores/README.md)
  - examples/vhdl_verilog_mixed: Demonstrate a fully mixed language design. VHDL implementation, Verilog implementation, and Verilog instantiating VHDL entity running together in the same testbench. This is possible because GHDL can convert VHDL code into Verilog code using its synthesis capabilities (only tested with GHDL version 4). 
 

examples/toy_SoC/README.md

@@ -0,0 +1,25 @@
+# Toy SoC with different drop-in compatible CPUs 
+
+This is a small SoC to play around with firmware and different RISC-V CPUs.
+The layout of the SoC looks like this.
+
+![SoC](soc.png)
+
+Before running the testbench (`make`) git submodules must be enabled (`git submodule init; git submodule update`).
+All CPUs are wrapped with a [wishbone](https://cdn.opencores.org/downloads/wbspec_b4.pdf) interface to make the drop-in compatible.
+
+## CPU selection
+
+  - [uRV](https://ohwr.org/project/urv-core): the most performant available CPU, bus also the largest
+  - [picorv32](https://github.com/YosysHQ/picorv32): smaller then uRV but also less performant, but has higher f_max
+  - [serv](https://github.com/olofk/serv) with MDU: even smaller but ~10x slower than picorv32
+
+  The CPU selection happens in `testbench.vhd` by selecting the type of the `cpu` instance. Just uncomment the one you want.
+
+## Firmware
+
+  The firmware [based on this code](https://crypto.stanford.edu/pbc/notes/pi/code.html) calculates the first 800 digits of PI and writes the output into a file `cpu_output.txt`.
+  You can observe the output by calling `tail -f cpu_output.txt` while the simulation is running.
+
+  The compiled `firmware/firmware.bin` is included in the repository so that no additional compiler is needed to run the testbench simulation.
+  On Arch Linux you can compile the binary from source code after installing the package `riscv64-elf-gcc`.