Update README files

test/README.md

@@ -0,0 +1,50 @@
+# Verification Testsuites
+
+The next folders contain all the verification flow within the hart is tested.
+
+All the testcases rely on [SVUT](https://github.com/dpretet/svut) and
+[Icarus Verilog](http://iverilog.icarus.com) or [Verilator](https://github.com/verilator).
+
+The testbench provides two configurations:
+
+- `core`: the hart is connected upon an AXI4-lite dual port RAM model, the instruction
+  bus on one port, the data bus on the other. Hart-only configuration.
+- `platform`: the core is connected upon an AXI4 crossbar with some peripherals
+  (GPIOs, UART, CLINT) and share the same master interface to the AXI4-lite RAM molde
+
+All testsuites support different tools and configuration, except [Apps](./apps) which support only
+Verilator and `platform` top level. A testsuite can contain one or more ASM/C file.
+
+To execute the flow, possible arguments are:
+
+```bash
+# To run all testcases over a specific configuration
+./run.sh --tb "core"     // to run the core-only simulation
+./run.sh --tb "platform" // to run the platform, the core + the peripherals
+
+# To run with a specific simulator:
+./run.sh --simulator verilator
+
+# To run a specific testcase:
+./run.sh --tc ./tests/rv32ui-p-test0.v
+
+# Combined arguments:
+./run.sh --tb platform --simulator --tc ./tests/rv32ui-p-test0.v
+```
+
+[Common](../common) folder contains:
+
+- `sim_main.cpp`: the verilator C++ testbench
+- `bin2hex.py*`: the utility to convert the assembler to binary used to initialize the RAM booted by
+  the core
+- `functions.sh*`: a setup of functions used compile and run the testsuites
+- `trace.py*`: a script to format the trace of the hart logging the jump/branch (debug purpose)
+- `axi4l_ram.sv`: the RAM used to store the program and boot the core
+- a set of waveform:
+    - `debug_core_icarus.gtkw`
+    - `debug_core_verilator.gtkw`
+    - `debug_platform_icarus.gtkw`
+    - `debug_platform_verilator.gtkw`
+- `files.f`: the file list to compile the testbench
+- `friscv_testbench.sv`: the system verilog testbench
+- `lfsr.sv`: a pseudo-random number generator used across the testbench

test/apps/README.md

@@ -3,20 +3,13 @@
 ## Overview
 
 This testsuite is composed by several applications, stressing out C toolchain and
-benchmarking the core.
+verifying the core with different applications.
 
-The testbench provides only "platform" support (CPU + AXI4 interconnect). The applications
-are interactive and require user inputs.
+The testbench provides only `platform` support (CPU + AXI4 interconnect) and `verilator`. 
+The applications are interactive and require user inputs.
 
 To execute the flow:
 
 ```bash
 ./run.sh --tc tests/repl.v
 ```
-
-All the testcases rely on [SVUT](https://github.com/dpretet/svut) and
-[Icarus Verilog](http://iverilog.icarus.com) or [Verilator](https://github.com/verilator).
-
-[Common](tests/common) folder contains a Makefile and a linker setup shared between
-all the testcases and symlinked into each test folder. A C runtime (crt0.S) is also provided
-to boot the processor, initialize the stack and jump to the main.

test/c_testsuite/README.md

@@ -1,38 +1,11 @@
 # C Testsuite
 
-## Overview
-
 This testsuite is composed by several applications, stressing out C toolchain and
 verifying the core. The testsuite is made of various C code, verifying the basics
 of C lang and its support with a hart.
 
-The testbench provides two configurations:
-
-- `core`: the hart is connected upon an AXI4-lite dual port RAM model, the instruction
-  bus on one port, the data bus on the other. Nothing else than a hart.
-- `platform`: the core is connected upon an AXI4 crossbar with some peripherals
-  (GPIOs, UART, CLINT) and share the same master interface to the AXI4-lite RAM model
-
-To execute the flow:
-
-```bash
-./run.sh --tb "core"     // to run the core-only simulation
-./run.sh --tb "platform" // to run the platform, the core + the peripherals
-```
-
-This will make all programs in tests/* folders, copy the RAM content generated,
-convert it to Verilog format then execute SVUT to run the testbench on each
-testcase.
-
 For more information about the bash front-end flow:
 
 ```bash
 ./run.sh -h
 ```
-
-All the testcases rely on [SVUT](https://github.com/dpretet/svut) and
-[Icarus Verilog](http://iverilog.icarus.com) or [Verilator](https://github.com/verilator).
-
-[Common](tests/common) folder contains a Makefile and a linker setup shared between
-all the testcases and symlinked into each test folder. A C runtime (crt0.S) is also provided
-to applications to boot the processor, initialize the stack and jump to the main.

test/priv_sec_testsuite/README.md

@@ -2,95 +2,8 @@
 
 Testsuite very dedicated to privilege and security features in the HART
 
-The testbench provides two configurations:
+## Test 1: M-mode <> U-mode transition
 
-- `core`: the hart is connected upon an AXI4-lite dual port RAM model, the instruction
-  bus on one port, the data bus on the other. Hart-only configuration.
-- `platform`: the core is connected upon an AXI4 crossbar with some peripherals
-  (GPIOs, UART, CLINT) and share the same master interface to the AXI4-lite RAM molde
+Focus on moving between M-mode, to boot the hart and configure it, and U-mode to execute
+some instructions. Basic scenario to ensure the U-mode is alive.
 
-The intent of this assembler flow is to create programs to stress the IP's core
-around U-mode / S-mode / H-mode and challenge the MPU stage (PMA + PMP).
-
-To execute the flow:
-
-```bash
-./run.sh --tb "core"     // to run the core-only simulation
-./run.sh --tb "platform" // to run the platform, the core + the peripherals
-```
-
-This will make all programs in tests/* folders, copy the RAM content generated,
-convert it to Verilog format then execute SVUT to run the testbench on each
-testcase.
-
-All the testcases rely on [SVUT](https://github.com/dpretet/svut) and
-[Icarus Verilog](http://iverilog.icarus.com) or [Verilator](https://github.com/verilator).
-
-For more information about the bash front-end flow:
-
-```bash
-./run.sh -h
-```
-
-[Common](../common) folder contains a Makefile and a linker setup shared between
-all the testcases and symlinked into each test folder. A folder can contain
-one or more ASM/C file.
-
-The compilation flow is derivated from RISCV official compliance testsuite,
-relying on its C flow to do unit testing.
-
-# Test plan
-
-## Test 1: Sequence of LUI/AUIPC/Arithmetic instructions
-
-Injects a set of alternating LUI / AUIPC / aritmetic instructions to ensure the
-control unit correctly handles this kind of situation. All these instructions
-are executed in one cycle and shouldn't introduce any wait cycles between each
-others.
-
-## Test2: Sequence of LOAD/STORE/ARITHMETIC instructions
-
-Injects a set of alternating LUI / AUIPC / LOAD  /STORE aritmetic instructions
-to ensure the control unit correctly handles this kind of situation.
-
-While aritmetic instructions are completed in one cycle, LOAD and STORE can
-span over several cycles. This test will ensure incoming instructions between
-them will not be lost and so the control unit properly manages this situation.
-
-## Test 3: Check FENCE/FENCE.i instructions
-
-Executes FENCE and FENCE.i between ALU and memfy instructions. The test is
-supposed for the moment harmless because the processor doesn't support neither
-out-of-order or parallel executions.
-
-## Test 4: JAL/JALR: Throttle execution by jumping back and forth
-
-Executes memory and arithmetic instructions break up by JAL and
-JALR instruction to ensure branching doesn't introduce failures.
-
-## Test 5: CSRs: Throttle execution by accessing the ISA CSRs
-
-Executes memory and arithmetic instructions break up by CSR
-accesses. CSR instructions require several cycles to complete, thus could lead
-to failure in control unit.
-
-## Test 6: LOAD/STORE outstanding requests support
-
-Stresses out outstanding requests management in Memfy module when issuing
-multiple read or write requests.
-
-## Test 7: RDCYCLE/RDTIME and RDINSTRET
-
-Checks instret, cycle and time are incremented accordingly the spec
-
-## Test 8: WFI
-
-Setup interrupt and checks the core manages EIRQ correctly.
-
-## Test 9: M extension
-
-Check multiply /division extension
-
-## Test 10: load / store collision
-
-Stresses out read / write with memfy and check collisions don't occur

test/riscv-tests/README.md

@@ -1,23 +1,3 @@
 # RISCV-Tests
 
 Official compliance testsuite from [RISCV test github](https://github.com/riscv/riscv-tests/).
-
-To execute the flow:
-
-```bash
-./run.sh --simulator icarus
-./run.sh --simulator verilator
-./run.sh --tb platform
-./run.sh --tb core
-```
-
-This will make all programs in tests/* folders, copy the RAM content generated,
-convert it to Verilog format then execute SVUT to run the testbench on each
-testcase.
-
-All the testcases rely on [SVUT](https://github.com/dpretet/svut) and
-[Icarus Verilog](http://iverilog.icarus.com) or [Verilator](https://github.com/verilator).
-
-[Common](../common) folder contains a Makefile and a linker setup shared between
-all the testcases and symlinked into each test folder. A folder can contain
-one or more ASM/C file and a markdown file describing the testcase scenarios.

test/wba_testsuite/README.md

@@ -1,46 +1,15 @@
 # White-Box Assembler Testsuite
 
-WBA testsuite is an example of integration of the processor core in a complete environment.
-
-The testbench provides two configurations:
-
-- `core`: the hart is connected upon an AXI4-lite dual port RAM model, the instruction
-  bus on one port, the data bus on the other. Hart-only configuration.
-- `platform`: the core is connected upon an AXI4 crossbar with some peripherals
-  (GPIOs, UART, CLINT) and share the same master interface to the AXI4-lite RAM molde
-
-The intent of this flow is to create programs to stress the IP's core
-with a white-box strategy, very driven by the architecture.
-
-To execute the flow:
-
-```bash
-./run.sh --tb "core"     // to run the core-only simulation
-./run.sh --tb "platform" // to run the platform, the core + the peripherals
-```
-
-This will make all programs in tests/* folders, copy the RAM content generated,
-convert it to Verilog format then execute SVUT to run the testbench on each
-testcase.
-
-All the testcases rely on [SVUT](https://github.com/dpretet/svut) and
-[Icarus Verilog](http://iverilog.icarus.com) or [Verilator](https://github.com/verilator).
+WBA testsuite is an example of integration of the processor core in a complete environment. The
+intent of this flow is to create programs to stress the IP's core with a white-box strategy, very
+driven by the architecture.
 
 For more information about the bash front-end flow:
 
 ```bash
 ./run.sh -h
 ```
 
-[Common](../common) folder contains a Makefile and a linker setup shared between
-all the testcases and symlinked into each test folder. A folder can contain
-one or more ASM/C file.
-
-The compilation flow is derivated from RISCV official compliance testsuite,
-relying on its C flow to do unit testing.
-
-# Test plan
-
 ## Test 1: Sequence of LUI/AUIPC/Arithmetic instructions
 
 Injects a set of alternating LUI / AUIPC / aritmetic instructions to ensure the