Github_Repos/cvw
1
0
Fork 1
mirror of https://github.com/openhwgroup/cvw synced 2025-01-22 20:44:28 +00:00
Code Issues Packages Projects Releases Wiki Activity

Removed and trimmed old docs per Issue #979

Browse Source
This commit is contained in:
David Harris 2024-10-10 10:55:24 -07:00
parent 3fdc0e34ce
commit fba6c60655
3 changed files with 0 additions and 112 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

28
docs/testplans/testplan.md
View File

@ -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.

30
dvtestplan.md
View File

@ -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

54
gitflow.txt
View File

@ -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.