From fba6c6065559f321b52741764c22a17c5cadcc50 Mon Sep 17 00:00:00 2001 From: David Harris Date: Thu, 10 Oct 2024 10:55:24 -0700 Subject: [PATCH] Removed and trimmed old docs per Issue #979 --- docs/testplans/testplan.md | 28 -------------------- dvtestplan.md | 30 --------------------- gitflow.txt | 54 -------------------------------------- 3 files changed, 112 deletions(-) delete mode 100644 dvtestplan.md delete mode 100644 gitflow.txt diff --git a/docs/testplans/testplan.md b/docs/testplans/testplan.md index 95ce72f8b..c77156842 100644 --- a/docs/testplans/testplan.md +++ b/docs/testplans/testplan.md @@ -17,31 +17,3 @@ CORE-V Wally is functionally tested in the following ways. Each test is run in | Code Coverage | 5.11.10 | | rv64gc | TBD | TBD | TBD | | Functional Coverage | 5.11.11 | | rv64gc | TBD | TBD | TBD | - - - -* Run [RISC-V Architecture Compatibility Tests](https://github.com/riscv-non-isa/riscv-arch-test) in lock-step against the ImperasDV reference model. -* Run custom tests to cover virtual memory, PMP, privileged unit, and peripherals in lock step against ImperasDV. -* ***pending: Run random tests generated by risc-dv -* Run CoreMark and Embench benchmarks. -* Run performance validation against reference models for the branch predictor and caches. -* Run the TestFloat suite against all precisions of all operations for the FPU unit. -* *** 83.5% coverage of statements, branches, expressions, and FSM states and transitions -* Boot Buildroot Linux in lock-step against ImperasDV. -* Boot Buildroot Linux on an FPGA and run programs. - -# Running Tests - -# - -# Detailed Test Plans - -The test plans for specific units are lined below: - -* Privileged Unit -* Memory Management Unit -* Peripherals -* Branch Predictor Performance Validation -* Cache Performance Validation - -Wally is described in an upcoming textbook, *RISC-V System-on-Chip Design*, by Harris, Stine, Thompson, and Harris. \ No newline at end of file diff --git a/dvtestplan.md b/dvtestplan.md deleted file mode 100644 index 3b469e3b2..000000000 --- a/dvtestplan.md +++ /dev/null @@ -1,30 +0,0 @@ -# core-v-wally Design Verification Test Plan - -This document outlines the test plan for the Wally rv64gc configuration to reach Technology Readiness Level 5. - -1. Pass riscv-arch-test -2. Boot Linux -3. FPU pass all TestFloat vectors -4. Performance verification: Caches and branch predictor miss rates match independent simulation -5. Directed tests - - Privileged unit: Chapter 5 test plan - - MMU: PMA, PMP, virtual memory: Chapter 8 test plan - - Peripherals: Chapter 16 test plan -6. Random tests - - riscdv tests -7. Coverage tests - - Directed tests to bring coverage up to 100%. - - Statement, experssion, branch, condition, FSM coverage in Questa - - Do not measure toggle coverage - -All tests operate correctly in lock-step with ImperasDV - -Open questions: -1. How to define extent of riscdv random tests needed? -2. What other directed tests? - PMP Tests - Virtual Memory Tests - How to define pipeline tests? - Simple ones like use after load stall are not important. - Hard ones such as page table walker fault during data access while I$ access is pending are hard to articulate and code - Is there an example of a good directed pipeline test plan & implementation diff --git a/gitflow.txt b/gitflow.txt deleted file mode 100644 index f6f70de74..000000000 --- a/gitflow.txt +++ /dev/null @@ -1,54 +0,0 @@ -########################################### -## A component of the CORE-V-WALLY configurable RISC-V project. -## https://github.com/openhwgroup/cvw -## -## Copyright (C) 2021-23 Harvey Mudd College & Oklahoma State University -## -## SPDX-License-Identifier: Apache-2.0 WITH SHL-2.1 -## -## Licensed under the Solderpad Hardware License v 2.1 (the “License”); you may not use this file -## except in compliance with the License, or, at your option, the Apache License version 2.0. You -## may obtain a copy of the License at -## -## https://solderpad.org/licenses/SHL-2.1/ -## -## Unless required by applicable law or agreed to in writing, any work distributed under the -## License is distributed on an “AS IS” BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, -## either express or implied. See the License for the specific language governing permissions -## and limitations under the License. -################################################################################################ - -Setup -1. goto github and fork openhwgroup/cvw.git -2. clone: git clone --recurse-submodules git@ross144/cvw.git -3. git remote add upstream https://github.com/openhwgroup/cvw.git -4. install gh (github command line interface) -type -p curl >/dev/null || sudo apt install curl -y -curl -fsSL https://cli.github.com/packages/githubcli-archive-keyring.gpg | sudo dd of=/usr/share/keyrings/githubcli-archive-keyring.gpg \ -&& sudo chmod go+r /usr/share/keyrings/githubcli-archive-keyring.gpg \ -&& echo "deb [arch=$(dpkg --print-architecture) signed-by=/usr/share/keyrings/githubcli-archive-keyring.gpg] https://cli.github.com/packages stable main" | sudo tee /etc/apt/sources.list.d/github-cli.list > /dev/null \ -&& sudo apt update \ -&& sudo apt install gh -y - -Once per session (This authorizes gh to use your github account) -1. gh auth login -2. Use ssh and point to your public key -3. Copy one-time code from terminal to browser - -Fetch upstream and sync fork -1. git pull upstream main # fetch and merge the upstream openhwgroup/cvw into your local clone -2. git push # pushes changes back to your fork. Now all three should be in sync - -Create pull request -1. git pull upstream main # fetch and merge the upstream openhwgroup/cvw into your local clone -3. git push # pushes changes back to your fork. Now all three should be in sync -4. gh pr create # Create a pull request. -5. Must include a title and strongly encourage a body message explaining your changes. -6. Wait for pull request to be approved, rejected, or needs changes. -7. Finish by fetching the upstream and pushing back to your fork. - 1. git pull upstream main # fetch and merge the upstream openhwgroup/cvw into your local clone - 3. git push # sync your fork with the upstream and clone - - -If the pull request need changes, modify accordingly, commit, and push changes back to the fork. -The pull request will automatically update.