From 747b78370f3431e86643e9cb08070611d0e6dbcb Mon Sep 17 00:00:00 2001 From: Damien Pretet Date: Sat, 16 Sep 2023 12:02:12 +0200 Subject: [PATCH] Update README files --- test/README.md | 50 +++++++++++++++++ test/apps/README.md | 13 +---- test/c_testsuite/README.md | 27 --------- test/priv_sec_testsuite/README.md | 93 +------------------------------ test/riscv-tests/README.md | 20 ------- test/wba_testsuite/README.md | 37 +----------- 6 files changed, 59 insertions(+), 181 deletions(-) create mode 100644 test/README.md diff --git a/test/README.md b/test/README.md new file mode 100644 index 0000000..bd590f3 --- /dev/null +++ b/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 diff --git a/test/apps/README.md b/test/apps/README.md index c481d00..a7eb358 100644 --- a/test/apps/README.md +++ b/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. diff --git a/test/c_testsuite/README.md b/test/c_testsuite/README.md index 339e033..f5a859d 100644 --- a/test/c_testsuite/README.md +++ b/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. diff --git a/test/priv_sec_testsuite/README.md b/test/priv_sec_testsuite/README.md index e9e9dea..f98754c 100644 --- a/test/priv_sec_testsuite/README.md +++ b/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 diff --git a/test/riscv-tests/README.md b/test/riscv-tests/README.md index bfc2bb4..8e6239c 100644 --- a/test/riscv-tests/README.md +++ b/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. diff --git a/test/wba_testsuite/README.md b/test/wba_testsuite/README.md index 4f855b3..a53fdef 100644 --- a/test/wba_testsuite/README.md +++ b/test/wba_testsuite/README.md @@ -1,30 +1,8 @@ # 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: @@ -32,15 +10,6 @@ For more information about the bash front-end flow: ./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