mirror of
https://github.com/openhwgroup/cvw
synced 2025-01-24 05:24:49 +00:00
Merge branch 'main' of https://github.com/openhwgroup/cvw
This commit is contained in:
commit
a57453b343
@ -414,7 +414,7 @@ if (args.ccov): # only run RV64GC tests on Questa in code coverage mode
|
||||
elif (args.fcov): # only run RV64GC tests on Questa in lockstep in functional coverage mode
|
||||
addLockstepTestsByDir(WALLY+"/addins/cvw-arch-verif/tests/rv32/", "rv32gc", coveragesim, 1)
|
||||
addLockstepTestsByDir(WALLY+"/addins/cvw-arch-verif/tests/rv64/", "rv64gc", coveragesim, 1)
|
||||
addLockstepTestsByDir(WALLY+"/tests/riscof/work/wally-riscv-arch-test/rv64i_m/privilege/src/", "rv64gc", coveragesim, 0)
|
||||
# addLockstepTestsByDir(WALLY+"/tests/riscof/work/wally-riscv-arch-test/rv64i_m/privilege/src/", "rv64gc", coveragesim, 0)
|
||||
elif (args.fcovrvvi): # only run RV64GC tests on Questa in rvvi coverage mode
|
||||
addTests(tests64gc_nofp, coveragesim)
|
||||
if (args.fp):
|
||||
|
5
bin/wsim
5
bin/wsim
@ -142,6 +142,11 @@ for d in ["logs", "wkdir", "cov", "ucdb", "fcov", "fcov_ucdb", "fcovrvvi", "fcov
|
||||
|
||||
cd = "cd $WALLY/sim/" +args.sim
|
||||
|
||||
# check for unsupported sims
|
||||
if (args.tb == "testbench_fp" and args.sim != "questa"):
|
||||
print("Error: testbench_fp presently only supported by Questa, not VCS or Verilator, because of a touchy testbench")
|
||||
exit(1)
|
||||
|
||||
# per-simulator launch
|
||||
if (args.sim == "questa"):
|
||||
if (args.gui) and (args.tb == "testbench"):
|
||||
|
@ -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.
|
@ -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
54
gitflow.txt
@ -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.
|
Loading…
Reference in New Issue
Block a user