Xavi/cvw
1
0
Fork 0
forked from Github_Repos/cvw
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Config file & wally-riscv-arch-test cleanup

Browse Source
This commit is contained in:
David Harris 2022-02-02 16:35:52 +00:00
parent f27961f54b
commit 4ba37d5cc0
22 changed files with 20 additions and 4260 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

1024
pipelined/config/rv32e/BTBPredictor.txt
View File

File diff suppressed because it is too large Load Diff

1024
pipelined/config/rv32e/twoBitPredictor.txt
View File

File diff suppressed because it is too large Load Diff

134
pipelined/config/rv32e/wally-config.vh
View File

@ -1,134 +0,0 @@
//////////////////////////////////////////
// wally-config.vh
//
// Written: David_Harris@hmc.edu 4 January 2021
// Modified:
//
// Purpose: Specify which features are configured
// Macros to determine which modes are supported based on MISA
//
// A component of the Wally configurable RISC-V project.
//
// Copyright (C) 2021 Harvey Mudd College & Oklahoma State University
//
// Permission is hereby granted, free of charge, to any person obtaining a copy of this software and associated documentation
// files (the "Software"), to deal in the Software without restriction, including without limitation the rights to use, copy,
// modify, merge, publish, distribute, sublicense, and/or sell copies of the Software, and to permit persons to whom the Software
// is furnished to do so, subject to the following conditions:
//
// The above copyright notice and this permission notice shall be included in all copies or substantial portions of the Software.
//
// THE SOFTWARE IS PROVIDED "AS IS", WITHOUT WARRANTY OF ANY KIND, EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
// OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND NONINFRINGEMENT. IN NO EVENT SHALL THE AUTHORS OR COPYRIGHT HOLDERS
// BE LIABLE FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT
// OF OR IN CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE SOFTWARE.
///////////////////////////////////////////
// include shared configuration
`include "wally-shared.vh"
`define FPGA 0
`define QEMU 0
`define BUILDROOT 0
`define BUSYBEAR 0
`define DESIGN_COMPILER 0
// RV32 or RV64: XLEN = 32 or 64
`define XLEN 32
// IEEE 754 compliance
`define IEEE754 0
// E
`define MISA (32'h00000010)
`define ZICSR_SUPPORTED 1
`define ZIFENCEI_SUPPORTED 0
`define COUNTERS 32
`define ZICOUNTERS_SUPPORTED 0
// Microarchitectural Features
`define UARCH_PIPELINED 1
`define UARCH_SUPERSCALR 0
`define UARCH_SINGLECYCLE 0
`define MEM_DTIM 0
`define MEM_DCACHE 0
`define MEM_IROM 0
`define MEM_ICACHE 0
`define MEM_VIRTMEM 0
`define VECTORED_INTERRUPTS_SUPPORTED 1
// TLB configuration. Entries should be a power of 2
`define ITLB_ENTRIES 0
`define DTLB_ENTRIES 0
// Cache configuration. Sizes should be a power of two
// typical configuration 4 ways, 4096 bytes per way, 256 bit or more lines
`define DCACHE_NUMWAYS 4
`define DCACHE_WAYSIZEINBYTES 4096
`define DCACHE_LINELENINBITS 256
`define DCACHE_REPLBITS 3
`define ICACHE_NUMWAYS 4
`define ICACHE_WAYSIZEINBYTES 4096
`define ICACHE_LINELENINBITS 256
// Integer Divider Configuration
// DIV_BITSPERCYCLE must be 1, 2, or 4
`define DIV_BITSPERCYCLE 4
// Legal number of PMP entries are 0, 16, or 64
`define PMP_ENTRIES 0
// Address space
`define RESET_VECTOR 32'h80000000
// Peripheral Addresses
// Peripheral memory space extends from BASE to BASE+RANGE
// Range should be a thermometer code with 0's in the upper bits and 1s in the lower bits
`define BOOTROM_SUPPORTED 1'b1
`define BOOTROM_BASE 34'h00001000
`define BOOTROM_RANGE 34'h00000FFF
`define RAM_SUPPORTED 1'b1
`define RAM_BASE 34'h80000000
`define RAM_RANGE 34'h07FFFFFF
`define EXT_MEM_SUPPORTED 1'b0
`define EXT_MEM_BASE 34'h80000000
`define EXT_MEM_RANGE 34'h07FFFFFF
`define CLINT_SUPPORTED 1'b1
`define CLINT_BASE 34'h02000000
`define CLINT_RANGE 34'h0000FFFF
`define GPIO_SUPPORTED 1'b1
`define GPIO_BASE 34'h10060000
`define GPIO_RANGE 34'h000000FF
`define UART_SUPPORTED 1'b1
`define UART_BASE 34'h10000000
`define UART_RANGE 34'h00000007
`define PLIC_SUPPORTED 1'b1
`define PLIC_BASE 34'h0C000000
`define PLIC_RANGE 34'h03FFFFFF
`define SDC_SUPPORTED 1'b0
`define SDC_BASE 34'h00012100
`define SDC_RANGE 34'h0000001F
// Bus Interface width
`define AHBW 32
// Test modes
// Tie GPIO outputs back to inputs
`define GPIO_LOOPBACK_TEST 1
// Hardware configuration
`define UART_PRESCALE 1
// Interrupt configuration
`define PLIC_NUM_SRC 4
// comment out the following if >=32 sources
`define PLIC_NUM_SRC_LT_32
`define PLIC_GPIO_ID 3
`define PLIC_UART_ID 4
`define TWO_BIT_PRELOAD "../config/rv32ic/twoBitPredictor.txt"
`define BTB_PRELOAD "../config/rv32ic/BTBPredictor.txt"
`define BPRED_ENABLED 1
`define BPTYPE "BPGSHARE" // BPLOCALPAg or BPGLOBAL or BPTWOBIT or BPGSHARE
`define TESTSBP 0

18
pipelined/config/rv32etim/wally-config.vh
View File

@ -39,11 +39,11 @@
// IEEE 754 compliance
`define IEEE754 0
// E, M, C
`define MISA (32'h00001014)
`define ZICSR_SUPPORTED 1
// E
`define MISA (32'h00000010)
`define ZICSR_SUPPORTED 0
`define ZIFENCEI_SUPPORTED 0
`define COUNTERS 32
`define COUNTERS 0
`define ZICOUNTERS_SUPPORTED 0
// Microarchitectural Features
@ -55,7 +55,7 @@
`define MEM_IROM 1
`define MEM_ICACHE 0
`define MEM_VIRTMEM 0
`define VECTORED_INTERRUPTS_SUPPORTED 1
`define VECTORED_INTERRUPTS_SUPPORTED 0
// TLB configuration. Entries should be a power of 2
`define ITLB_ENTRIES 0
@ -93,16 +93,16 @@
`define EXT_MEM_SUPPORTED 1'b0
`define EXT_MEM_BASE 34'h80000000
`define EXT_MEM_RANGE 34'h07FFFFFF
`define CLINT_SUPPORTED 1'b1
`define CLINT_SUPPORTED 1'b0
`define CLINT_BASE 34'h02000000
`define CLINT_RANGE 34'h0000FFFF
`define GPIO_SUPPORTED 1'b1
`define GPIO_SUPPORTED 1'b0
`define GPIO_BASE 34'h10060000
`define GPIO_RANGE 34'h000000FF
`define UART_SUPPORTED 1'b1
`define UART_SUPPORTED 1'b0
`define UART_BASE 34'h10000000
`define UART_RANGE 34'h00000007
`define PLIC_SUPPORTED 1'b1
`define PLIC_SUPPORTED 1'b0
`define PLIC_BASE 34'h0C000000
`define PLIC_RANGE 34'h03FFFFFF
`define SDC_SUPPORTED 1'b0

2
pipelined/config/rv32gc/wally-config.vh
View File

@ -75,7 +75,7 @@
`define DIV_BITSPERCYCLE 4
// Legal number of PMP entries are 0, 16, or 64
`define PMP_ENTRIES 16
`define PMP_ENTRIES 64
// Address space
`define RESET_VECTOR 32'h80000000

6
pipelined/config/rv32ic/wally-config.vh
View File

@ -95,13 +95,13 @@
`define CLINT_SUPPORTED 1'b1
`define CLINT_BASE 34'h02000000
`define CLINT_RANGE 34'h0000FFFF
`define GPIO_SUPPORTED 1'b1
`define GPIO_SUPPORTED 1'b0
`define GPIO_BASE 34'h10060000
`define GPIO_RANGE 34'h000000FF
`define UART_SUPPORTED 1'b1
`define UART_SUPPORTED 1'b0
`define UART_BASE 34'h10000000
`define UART_RANGE 34'h00000007
`define PLIC_SUPPORTED 1'b1
`define PLIC_SUPPORTED 1'b0
`define PLIC_BASE 34'h0C000000
`define PLIC_RANGE 34'h03FFFFFF
`define SDC_SUPPORTED 1'b0

12
pipelined/config/rv64ic/wally-config.vh
View File

@ -42,9 +42,9 @@
// MISA RISC-V configuration per specification
`define MISA (32'h00000104)
`define ZICSR_SUPPORTED 1
`define ZIFENCEI_SUPPORTED 1
`define ZIFENCEI_SUPPORTED 0
`define COUNTERS 32
`define ZICOUNTERS_SUPPORTED 1
`define ZICOUNTERS_SUPPORTED 0
// Microarchitectural Features
`define UARCH_PIPELINED 1
@ -54,12 +54,12 @@
`define MEM_DCACHE 1
`define MEM_IROM 0
`define MEM_ICACHE 1
`define MEM_VIRTMEM 1
`define MEM_VIRTMEM 0
`define VECTORED_INTERRUPTS_SUPPORTED 1
// TLB configuration. Entries should be a power of 2
`define ITLB_ENTRIES 32
`define DTLB_ENTRIES 32
`define ITLB_ENTRIES 0
`define DTLB_ENTRIES 0
// Cache configuration. Sizes should be a power of two
// typical configuration 4 ways, 4096 bytes per way, 256 bit or more lines
@ -76,7 +76,7 @@
`define DIV_BITSPERCYCLE 4
// Legal number of PMP entries are 0, 16, or 64
`define PMP_ENTRIES 64
`define PMP_ENTRIES 0
// Address space
`define RESET_VECTOR 64'h0000000080000000

2
pipelined/regression/regression-wally
View File

@ -57,7 +57,7 @@ def getBuildrootTC(short):
tc = TestCase(
name="buildroot-checkpoint",
variant="rv6gc",
variant="rv64gc",
cmd="vsim > {} -c <<!\ndo wally-buildroot-batch.do 400100000 400000001 400000000\n!",
grepstr="400100000 instructions")
configs.append(tc)

413
tests/wally-riscv-arch-test/CHANGELOG.md
View File

@ -1,413 +0,0 @@
# CHANGELOG
## [2.5.3] - 2021-10-15
- fix the lower case `i` in the `RVTEST_CASE` macros used in the shift operation tests.
## [2.5.2] - 2021-10-14
- update format for aes32 and sm4 instructions
- update reference signature for sha256 and sm3 instructions in rv64i_m/K_unratified
- delete zip and unzip tests in rv64i_m/K_unratified
- update tests for aes64ks1i, sm4ed and sm4ks to use byte_count with overlap = "Y" to improve the coverage of S-boxes
## [2.5.1] - 2021-10-07
- added styles files to the F coverage report directories.
## [2.5.0] - 2021-10-01
- Added rv32f tests, references, coverage files and data propagation reports
- fixed broken links in READMEs across the repo.
- corrected string "EBREAK" in io string macro to "ECALL" for ecall.S tests. #207
- fixed typo `.alive` --> `.align` in `riscv-target/example_target/model_test.h`.
## [2.4.7] - 2021-10-01
- Fix for the issue #206
## [2.4.6] - 2021-08-02
- Added rv32e tests in riscv-test-suite
## [2.4.5] - 2021-07-29
- fix for issue #195
## [2.4.4] - 2021-07-19
- Annotating tags during releases
## [2.4.3] - 2021-05-20
- added new 64-bit K crypto tests as per the test-plan presented by the scalar crypto task group
[here](https://github.com/riscv/riscv-crypto/blob/d89dfee25780f79c162da4eb69cd9076dd701c88/tests/compliance/test-plan-scalar.adoc)
- added new 32-bit K crypto tests as per the above mentioned test-plan.
- added coverage and data propagation reports for the above tests.
- updated README in riscv-test-suite
- added missing semi-colon in example target Makefile.include files
## [2.4.2] - 2021-04-20
- changed all occurances of SPTBR to the new name SATP
## [2.4.1] - 2021-04-01
- updated issue number in TestFormatSpec to be consistent with doc history
- adding a contribution guideline
- updated comment on usage of RISCV_DEVICE in Makefile.include
- updated licenses that are currently used by tests
- renamed K tests to K_unratified
- updated ci to build and upload pdf for testformatspec
## [2.4.0] - 2021-03-26
2021-03-26 Duncan Graham <info@imperas.com>
- Added new K Crypto (scalar) (0.8.1) tests from Imperas
## [2.3.1] - 2021-03-20
### Changed
- Compliance Task Group changed to Architecture Test SIG in all docs and comments
- replacing old riscv-compliance link with new riscv-arch-test links
- fixed ci for release
### Removed
- spec/TestFormatSpec.pdf is removed since its old. Keeping only adoc file
- removing obsolete and commented out portions from doc/README
## [2.3] - 2021-03-11
### Added
- updated maintainers list in root-level readme
- updated the links to riscof, isac and ctg repos and docs in root-level readme
- adding CI to update versions automatically
### Removed
- replaced spike target with a REAMDE pointing to riscv-isa-sim/arch_test_target/README.md
## [2.2] - 2021-01-28
2021-01-22 Tobias Wölfel <tobias.woelfel@mailbox.org>
* Add missing base ISA check in riscv-test-suite
2021-01-20 Xiretza <xiretza@xiretza.xyz>
* Deduplicate makefiles in riscv-test-suite
* Makefile: Fix ordering of simulate and verify targets to allow multi-job runs (make -j)
* Makefile.include: Document RISCV_TEST
* Makefile: use $(TARGETDIR) variable for postverify target instead of hard-coded path
2021-01-16 S Pawan Kumar <spawan1999@gmail.com>
* Fixed NARGS macro defintion to work correctly.
2021-01-15 Xiretza <xiretza@xiretza.xyz>
* style: Add a missing space to the "OK" message in verify.sh
2020-12-17 Neel Gala <neelgala@incoresemi.com>
* remove env folder symlinks from all riscv-test-suite src folders
* fixed assertion macros for ovpsim
* renamed RVTEST_ASSERT to RVMODEL_ASSERT in the Makefile and ovpsim macros
* tests updated with right set of "correctvals"
2020-11-24 Neel Gala <neelgala@incoresemi.com>
* added MIGRATION.adoc in doc directory to indicate how old framework targets can work with
changes made as part of this PR
* updated doc/README.adoc to avoid the word "compliance" and updated the section on porting a new
target to the framework.
* Added an example_target directory to host dummy files which can be used as a starting point for
porting targets. This was provided by MarcKarasek.
* migrated/ported existing targets (except codasip and sifive-formal) to the new framework
changes.
* in riscv-test-env/p/riscv_test.h changed names of RVTEST_[CODE/DATA]_[BEGIN/END] to
RVTEST_[CODE/DATA]_[BEGIN/END]_OLD respectively to avoid conflicts with the new framework macros.
* in riscv-test-env/p/riscv_test.h re-strutucture RVTEST_DATA_BEGIN_OLD/END to ensure that all
target specific data contents are introduced in RVTEST_DATA_END after the signature.
* added new file riscv-test-suite/env/arch_test.h which contains the macros used by the new set of
tests. A symlink to this in the riscv-test-env directory is also created. The arch_test also
includes aliases for the old macros.
* encoding.h moved to riscv-test-suite/env and a symlink to this file exists in riscv-test-env.
This was done to ensure that the arch_test.h and encoding.h are not to be modified by the
targets
* Added riscv-test-stats which includes coverage and data propagation reports for the tests
available in the riscv-test-suite directory.
* upddted the directory structure of the riscv-test-suite as per definition found in the
TestFormatSpec document.
* new set of tests with better coverage for rv[32/64][I,M,C, Zifencei] added. Almost all tests
were generated using the open source riscv_ctg tool. A few tests like fence, fencei, ebreak,
ecall, etc were handwritten/modified to follow the new macro conventions.
* Updated TestFormatSpec to avoid the word compliance and also updated the definitions of macros
and signatures
* created a root-level Makefile.include to decouple the Makefile and target specific settings.
* Added riscv-target and Makefile.include to the .gitignore file to stop tracking target specific
changes.
* Added special targets for compile(build), simulate(run) and verify in the Makefiles of each
test-suite.
* the existing riscv-targets have been either updated for the new framework or migrated to the
framework.
2020-10-15 Simon Davidmann <simond@imperas.com>
* riscvOVPsim enhanced and moved to its own respository: github.com/riscv-ovpsim
2020-04-24 Allen Baum <allen.baum@esperantotech.com>
* fixed the I-SB-01.S and I-SH-01.S tests and associated reference signatures to account
of tests with negative offsets (which causes stores outside the signature area)
2020-03-19 Neel Gala <neelgala@gmail.com>
* restructuring the riscv-test-suite to indicate clearly what is deprecated, wip and usable
tests.
* based on the above fixed the directory structure for riscv-targets where-ever applicable. Only
tested riscvOVPsim and spike.
* fixed script bugs for spike as well
* renamed rv32i/I-IO.S to rv32i/I-IO-01.S along with necessary changes to the reference files
and Makefrag
* renamed mbadaddr csr to mtval as raised in issue #31
* C.SWSP-01.S test updated to fix issue #37
2020-03-18 Neel Gala <neelgala@gmail.com>
* fixed doc/README.adoc with correct version to pass the sanity-check in the doc/Makefile
2020-02-07 Prashanth Mundkur <prashanth.mundkur@gmail.com>
* Support F extension on RV32 sail-riscv-c.
2019-12-01 Allen Baum <allen.baum@esperantotech.com>
* modified macro names to conformn to riscof naming convention of model specific vs. pre-defined
* add more complete list of macros, their uses, parameters, and whether they are required or optional
* minor structural changes (moving sentences, renumbering) and typo fixes
* clarified impact of debug macros
* clarified how SIGUPD and BASEUPD must be used
* remove section about test taxonomy, binary tests, emulated ops
* clarify/fix boundary between test target and framework responsibilities
(split test target into test target and test shell)
* remove To Be discussed items that have been discussed
* remove default case condition; if conditions are unchanged, part of same case
* minor grammatical changes related to the above
2019-10-16 Allen Baum <allen.baum@esperantotech.com>
* spec/TestFormatSpec.adoc: changed the format of the signature to fixed physical address size, fixed 32b data size extracted from COMPLIANCE_DATA_BEGIN/END range.
* more gramatical fixes, clarifications added
* added To Be Discussed items regarding emulated instruction and binary tests
2019-09-11 Allen Baum <allen.baum@esperantotech.com>
* spec/TestFormatSpec.adoc: more grammar and typo corrections and changes
clarified and added To Be Discussed issues
2019-09-11 Allen Baum <allen.baum@esperantotech.com>
* spec/TestFormatSpec.adoc: many grammar and typo corrections and changes
removed many "to Be Discussed items and made them official
Added wording to clarify spec intent (work in progress/goal rather than final)
Added macros to ease test authoring: RVTEST_SIGBASE, RVTEST_SIGUPDATE, RVTEST_CASE
Added detail on proposals for connection to framework (how framework selects tests).
Expanded definition of signature format
Changed the (proposed) directory structure and naming convention to eliminate ambiguities, add consistancy and slightly better match existing structure
Added many "future work" items related to the above
Added examples and comments to code examples to indicate how proposed macros would be used
* .gitignore: added condition to ignore Mac file system artifacts
2019-11-05 Lee Moore <moore@imperas.com>
* Restructured RV32I to move Zicsr and Zifencei into their own suites
2019-10-14 Lee Moore <moore@imperas.com>
* Added Ability to run a single test by using the Make Variable RISCV_TEST
for example, to only run the test I-ADD-01 from the rv32i suite
make RISCV_ISA=rv32i RISCV_TEST=I-ADD-01
* Added Top Level Variable to Makefile RISCV_TARGET_FLAGS,
in the case of the RISCV_TARGET this can be passed and appended to the invocation
commandline configuration, for example to pass a command line flag to the RISCV_TARGET
to perform tracing. The value of this flag will be target specific
make RISCV_ISA=rv32i RISCV_TEST=I-ADD-01 RISCV_TARGET_FLAGS="--trace"
This is has also been added to all other targets to allow target configuration from
the commandline
2019-10-07 Philipp Wagner <phw@lowrisc.org>
* When executing the test suite, Ibex always writes an instruction
log. Update the Makefile to write it to a test-specific location
(next to all other log files).
* On Ibex, provide an additional .objdump-noalias disassembly file
with no aliases and numeric register names (instead of ABI names).
This file matches the Ibex trace and can be used to debug the test
runs.
2019-08-29 Robert Balas <balasr@iis.ee.ethz.ch>
* Added support for using RI5CY as a target.
* Added subdirectory riscv-target/ri5cy
2019-08-08 Lee Moore <moore@imperas.com>
* Added support for lowRISC/ibex RTL as a target using Verilator.
In conjunction with Philipp Wagner of lowRISC phw@lowrisc.org
2019-07-18 Paul Donahue <pdonahue@ventanamicro.com>
* Fix typos/grammar and use correct architectural terms.
2019-06-21 Ben Selfridge <benselfridge@galois.com>
* Added support for using the the GRIFT simulator as a target.
* Added subdirectory riscv-target/grift
* updated README.md and doc/README.adoc
2019-05-23 Prashanth Mundkur <prashanth.mundkur@gmail.com>
* Added support and instructions for using the C and OCaml simulators from the Sail RISC-V formal model as targets.
* added subdirectories riscv-target/sail-riscv-c and riscv-target/sail-riscv-ocaml
* updated README.md and doc/README.adoc
2019-04-05 Allen Baum <allen.baum@esperantotech.com>
* spec/TestFormatSpec.adoc: Adding details, minor corrections, ToBeDiscussed
items and clarifications to the specification of the future compliance test
suite. Also removing restrictions on having absolate addresses in signature
2019-02-21 Lee Moore <moore@imperas.com>
* Fixed bug in RVTEST_IO_ASSERT_GPR_EQ which was not preserving register t0
* Corrected commit I-LUI-01.S, register target changed but missed assertion
2019-02-21 Deborah Soung <debs@sifive.com>
* added RiscvFormalSpec as a target with its own unique environment
2019-02-15 Radek Hajek <radek.hajek@codasip.com>
* updated rv32i tests to support all registers (x31) with assertions
* updated spec/TestFormatSpec.adoc example ISA test with new assertions
2019-02-05 Deborah Soung <debs@sifive.com>
* [Issue #33] fixing rv32si/ma_fetch.S test
* [Issue #32] fixing breakpoint test
2019-02-01 Lee Moore <moore@imperas.com>
* updated Infrastructure macros to support non-volatile registers
* updated riscvOVPsim
2019-01-29 Deborah Soung <debs@sifive.com>
* Added Rocket Chip generated cores as a target
* riscv-target/rocket/compliance_io.h created
* riscv-target/rocket/compliance_test.h created
* riscv-target/rocket/*/Makefile.include created for existing test suites
* README.adoc updated with instructions for using Rocket cores as targets
2019-01-22 Premysl Vaclavik <pvaclavik@codasip.com>
* feature: initial version of Compliance Test Format Specification
* This new document outlines how we should like the compliance
system to work going forward. By contrast the doc/README.adoc file
describes the current system as it is.
* Approved at Compliance TG meeting of 9 Jan 2019.
2019-01-02 Radek Hajek <radek.hajek@codasip.com>
* unified macros in all compliance tests
2018-12-20 Lee Moore <moore@imperas.com>
* fixed riscvOVPsim
2018-11-22 Simon Davidmann <simond@imperas.com>
* added information on test suite status
2018-11-21 Olof Kindgren <olof.kindgren@gmail.com>
* Added support for using external target directories with $TARGETDIR
2018-11-21 Neel Gala <neelgala@incoresemi.com>
* riscv-test-suite/rv_/references/_.reference_output: changed signature
format for all tests to include only 4-bytes per line starting with the
most significant byte on the left.
* riscv-target/spike/device/rv_/Makefile.include: Added a patch for
spike-device Makefiles where the old-signature format is post-processed
to generate a signature in the new format at the end of each test.
* riscv-target/riscvOVPsim/device/rv_/Makefile.include: same patch as above.
* Makefile: default target for Makefile is now to run all tests supported by
the target mentioned defined by RISCV_TARGET variable.
2018-10-11 Simon Davidmann <simond@imperas.com>
* Ported github riscv/riscv-tests for RV32 processors to this compliance env
* rv32ua rv32uc rv32ud rv32uf rv32ud rv32ui
2018-09-10 Lee Moore <moore@imperas.com>
* Added tests to RV32I to improve coverage, usage of Imperas Mutating Fault Simulator to
identify untested usage cases
* Macro renames to support GPR, (S)FPR, (D)FPR
* Added test suite RV32IM to test 32 bit Multiply and Divide instructions
* Added test suite RV32IMC to test 32 bit Compressed instructions
* Added test suite RV64I to test 64 bit Integer instructions
* Added test suite RV64IM to test 64 bit Multiply and Divide instructions
2018-06-15 Radek Hajek <hajek@codasip.com>
Modifications to support Codasip simulator.
The simulator is renamed as Codasip-simulator (was
Codasip-IA-simulator), compliance_test.h has been moved to target
directories and a COMPILE_TARGET has been added to Makefile to
allow use of LLVM.
* Makefile: Include Codasip simulator target.
* riscv-target/codasip-IA-simulator/compliance_io.h: Renamed as
riscv-target/Codasip-simulator/compliance_io.h.
* riscv-target/Codasip-simulator/compliance_io.h: Renamed from
riscv-target/codasip-IA-simulator/compliance_io.
* riscv-target/Codasip-simulator/compliance_test.h: Created.
* riscv-target/codasip-IA-simulator/device/rv32i/Makefile.include:
Renamed as
riscv-target/Codasip-simulator/device/rv32i/Makefile.include
* riscv-target/Codasip-simulator/device/rv32i/Makefile.include:
Renamed from
riscv-target/codasip-IA-simulator/device/rv32i/Makefile.include.
* riscv-test-env/compliance_test.h: Renamed as
riscv-target/riscvOVPsim/compliance_test.h.
* riscv-target/riscvOVPsim/compliance_test.h: Renamed from
riscv-test-env/compliance_test.h.
* riscv-target/riscvOVPsim/device/rv32i/Makefile.include: Updated
for new environment.
* riscv-target/spike/compliance_test.h: Created.
* riscv-target/spike/device/rv32i/Makefile.include: Updated for
new environment.
* riscv-test-suite/rv32i/Makefile: Likewise.
2018-06-10 Jeremy Bennett <jeremy.bennett@embecosm.com>
Put placeholders in empty directories to make sure they show in
the GitHub hierarchy.
* riscv-test-suite/rv32i/.gitignore: Created.
* riscv-test-suite/rv32m/.gitignore: Created.
2018-06-10 Jeremy Bennett <jeremy.bennett@embecosm.com>
* README.md: Make references to files in the repo into links.
2018-06-09 Jeremy Bennett <jeremy.bennett@embecosm.com>
* .gitignore: Ignore editor backup files.
2018-06-09 Jeremy Bennett <jeremy.bennett@embecosm.com>
* README.md: Add better link to documentation README.md.
2018-06-08 Jeremy Bennett <jeremy.bennett@embecosm.com>
* README.md: Move AsciiDoc details into new README.md in the doc
directory.
2018-06-08 Jeremy Bennett <jeremy.bennett@embecosm.com>
* README.md: Fix typo in link to AsciiDoc cheat sheet
2018-06-08 Jeremy Bennett <jeremy.bennett@embecosm.com>
* COPYING.BSD: Created.
* COPYING.CC: Created.
* README.md: Add git process, licensing and engineering process.
2018-06-08 Jeremy Bennett <jeremy.bennett@embecosm.com>
* README.md: Correct details for running the compliance tests and
directory for OVPsim.
2018-06-08 Jeremy Bennett <jeremy.bennett@embecosm.com>
Clean restructuring to just the work of interest.
* thought-experiments: Directory removed.
* .gitignore: Merged with TestStructure/.gitignore
* Makefile: Renamed from TestStructure/Makefile.
* TestStructure/Makefile: Renamed as Makefile.
* README.md: Merged with TestStructure/README.md.
* TestStructure/.gitignore: Deleted and contents moved into
.gitignore.
* TestStructure/README.md: Deleted and contents moved into
README.md.
* TestStructure/doc: Directory deleted.
* TestStructure/riscv-target: Directory moved to riscv-target.
* riscv-target: Directory moved from TestStructure/riscv-target
* TestStructure/riscv-test-env: Directory moved to riscv-test-env.
* riscv-test-env: Directory moved from
TestStructure/riscv-test-env.
* TestStructure/riscv-test-suite: Directory moved to
riscv-test-suite.
* riscv-test-suite: Directory moved from
TestStructure/riscv-test-suite.
* thought-experiments: Directory deleted.
2018-05-21 Jeremy Bennett <jeremy.bennett@embecosm.com>
Initial commit to populate the repository.
* ChangeLog: Created.
* README.md: Created.

66
tests/wally-riscv-arch-test/CONTRIBUTION.md
View File

@ -1,66 +0,0 @@
# Contributing to RISC-V Architecture Tests
Your inputs are welcome and greatly appreciated! We want to make contributing to this project as easy and transparent as possible, whether it's:
- Reporting a bug
- Discussing the current state of the code
- Submitting a fix
- Proposing new features
- Becoming a maintainer
## We develop with Github
We use github to host code, to track issues and feature requests, as well as accept pull requests.
## We use a simple git flow where all code changes happen through Pull Requests
Pull requests are the best way to propose changes to the codebase. We actively welcome your pull requests:
1. Fork the repo and create your branch from `master`.
2. If you have added new tests, please ensure they adhere to the latest TestFormatSpec and that you have run them on the RVI approved reference
models (if support in those models is available).
3. If you have updated any test-macros make sure to update the documentation as well.
4. If you have updated the docs, ensure that they render correctly in the respective format.
5. Make sure to create an entry in the CHANGELOG.md. Please refer to the section on versioning below
to choose an appropriate version number.
6. Ensure the existing tests are not broken and still pass on the the RVI approved reference models.
7. Please include a comment with the SPDX license identifier in all source files, for example:
```
// SPDX-License-Identifier: BSD-3-Clause
```
8. Issue that pull request!
## Versioning
When issuing pull requests, an entry in the CHANGELOG.md is mandatory. The arch-test-repo adheres to
the [`Semantic Versioning`](https://semver.org/spec/v2.0.0.html) scheme. Following guidelines must
be followed while assigning a new version number :
- Patch-updates: all doc updates (like typos, more clarification,etc) and updates to unratified extensions.
- Minor-updates: Updates to ratified extensions OR migration of extensions to ratified OR changes in docs regarding policies or spec.
- Major-updates: Changes to the framework flow (backward compatible or incompatible).
Note: You can have either a patch or minor or major update.
Note: In case of a conflict, the maintainers will decide the final version to be assigned.
## Any contributions you make will be under the permissive open-source License
In short, when you submit code changes, your submissions are understood to be under a permissive open source license like BSD-3, Apache-2.0 and CC, etc that covers the project. Feel free to contact the maintainers if that's a concern.
## Report bugs using Github's [issues](https://github.com/riscv/riscv-arch-test/issues)
We use GitHub issues to track public bugs. Report a bug by [opening a new issue](https://github.com/riscv/riscv-arch-test/issues/new); it's that easy!
## Write bug reports with detail, background, and sample code
**Great Bug Reports** tend to have:
- A quick summary and/or background
- Steps to reproduce
- Be specific!
- Give sample code if you can.
- What you expected would happen
- What actually happens
- Notes (possibly including why you think this might be happening, or stuff you tried that didn't work)
## License
By contributing, you agree that your contributions will be licensed under its permissive open source
licenses.

74
tests/wally-riscv-arch-test/README.md
View File

@ -1,74 +0,0 @@
# RISC-V Architecture Test SIG
This is a repository for the work of the RISC-V Foundation Architecture Test SIG. The repository owners are:
- Neel Gala (InCore Semiconductors)
- Marc Karasek (Inspire Semiconductors)
Details of the RISC-V Foundation, the work of its task groups, and how to become a member can be found at [riscv.org](https://riscv.org/).
For more details and documentation on the current testing framework see: [doc/README.adoc](doc/README.adoc)
For more details on the test format spec see: [spec/TestFormatSpec.adoc](spec/TestFormatSpec.adoc)
For contributions and reporting issues please refer to [CONTRIBUTION.md](CONTRIBUTION.md)
## Test Disclaimers
The following are the exhaustive list of disclaimers that can be used as waivers by target owners
when reporting the status of pass/fail on the execution of the architectural suite on their respective targets.
1. The references uploaded for the following misaligned load/store tests will match targets which do
not support misaligned load/stores in hardware. Targets with hardware misaligned support for
load/stores will fail these tests.
1. rv32i_m/privilege/src/misalign-[lb[u],lh[u],lw,sh,sb,sw]-01.S
2. rv64i_m/privilege/src/misalign-[lb[u],lh[u],lw[u],ld,sb,sh,sw,sd]-01.S
2. The references uploaded for the following misaligned instruction tests will match targets which
have compressed extension support enabled by default. Targets without the compressed extension
support will fail the following tests:
1. rv[32/64]i_m/privilege/src/misalign-b[ge[u],lt[u],eq,ne]-01.S
2. rv[32/64]i_m/privilege/src/misalign[1,2]-jalr-01.S
3. The machine mode trap handler used in the privilege tests assumes one of the following conditions.
Targets not satisfying any of the following conditions are bound to fail the entire
rv32i_m/privilege and rv64i_m/privilege tests:
1. The target must have implemented mtvec which is completely writable by the test in machine mode.
2. The target has initialized mtvec, before entering the test (via RVMODEL_BOOT), to point to a memory location which has both read and write permissions.
## Contribution process
Please refer to to [CONTRIBUTION.md](CONTRIBUTION.md) for guidelines on contributions.
## Licensing
In general:
- code is licensed under one of the following:
- the BSD 3-clause license (SPDX license identifier `BSD-3-Clause`);
- the Apache License (SPDX license identifier `Apache-2.0`); while
- documentation is licensed under the Creative Commons Attribution 4.0 International license (SPDX license identifier `CC-BY-4.0`).
The files [`COPYING.BSD`](./COPYING.BSD), [`COPYING.APACHE`](./COPYING.APACHE) and [`COPYING.CC`](./COPYING.CC) in the top level directory contain the complete text of these licenses.
## Engineering practice
- Documentation uses the structured text format _AsciiDoc_. See [`doc/README.adoc`](doc/README.adoc) for more details.
- Some directories use `ChangeLog` files to track changes in the code and documentation. Please honor these, keeping them up to date and including the ChangeLog entry in the _git_ commit message.
- Please include a comment with the SPDX license identifier in all source files, for example:
```
// SPDX-License-Identifier: BSD-3-Clause
```
## Quick Links:
- RISCOF \[[DOCS](https://riscof.readthedocs.io/en/latest/)\] \[[REPO](https://github.com/riscv-software-src/riscof)\]: This is the next version of the architectural test framework currently under development
- RISCV-ISAC \[[DOCS](https://riscv-isac.readthedocs.io/en/latest/index.html)\] \[[REPO](https://github.com/riscv-software-src/riscv-isac)\] : This is an ISA level coverage extraction tool for RISC-V which used to generate the coverage statistics of the architectural tests.
- RISCV-CTG: \[[DOCS](https://riscv-ctg.readthedocs.io/en/latest/index.html)\]\[[REPO](https://github.com/riscv-software-src/riscv-ctg)\]: This is a RISC-V Architectural Test generator used to generate some of the tests already checked into this repository.
- [Videos](https://youtu.be/VIW1or1Oubo): This Global Forum 2020 video provides an introduction to the above mentioned tools
- [riscvOVPsim](https://github.com/riscv-ovpsim/imperas-riscv-tests): Imperas freeware RISC-V reference simulator for compliance testing
- [riscvOVPsimPlus](https://www.ovpworld.org/riscvOVPsimPlus/): Imperas enhanced freeware RISC-V reference simulator for test development and verification

6
tests/wally-riscv-arch-test/doc/.gitignore vendored
View File

@ -1,6 +0,0 @@
# Ignore editor backups
*~
# Generated files
custom.dict
README.pdf
README.html

147
tests/wally-riscv-arch-test/doc/ChangeLog
View File

@ -1,147 +0,0 @@
2019-02-21 Deborah Soung <debs@sifive.com>
* README.adoc: Documentation for rocket chip as target.
2019-02-05 Deborah Soung <debs@sifive.com>
* README.adoc: Update documentation for rocket chip as target (fixed rv32si/ma_fetch.S).
* README.adoc: Update documentation for rocket chip as target (fixed breakpoint.S).
2019-01-29 Deborah Soung <debs@sifive.com>
* README.adoc: Documentation for rocket chip as target.
2018-11-21 Olof Kindgren <olof.kindgren@gmail.com>
* README.adoc (Repository structure) Added documentation for the $TARGETDIR environmental variable
2018-11-21 Neel Gala <neelgala@incoresemi.com>
* README.adoc: Added new signature format spec.
2018-06-18 Jeremy Bennett <jeremy.bennett@embecosm.com>
* README.adoc (Future work): Reflect changes made to support
Codasip simulator.
(Repository structure): Diagrammatic representation of the file
structure deleted.
2018-06-12 Jeremy Bennett <jeremy.bennett@embecosm.com>
* .gitignore: Add custom.dict.
2018-06-12 Jeremy Bennett <jeremy.bennett@embecosm.com>
Document issue 1.8 Draft.
* README.adoc (Introduction): Add Future work section and bump
version.
* custom.wordlist: Add words needed for Future work section.
2018-06-12 Jeremy Bennett <jeremy.bennett@embecosm.com>
* README.adoc: Remove special apostrophe from "licensor's".
* custom.wordlist: Updated with more words to be ignored.
2018-06-12 Jeremy Bennett <jeremy.bennett@embecosm.com>
* README-old.md: Deleted.
* README.adoc: Include details of how to contribute and installing
the tools from the old README and reference the licence as an
appendix.
2018-06-11 Jeremy Bennett <jeremy.bennett@embecosm.com>
This makes the document appear directly as the README of the doc
directory, so there is now no longer a need to publish to GitHub
pages.
* .gitignore: Change name of files ignored.
* Makefile: Remove publish target.
* README.adoc: Symbolic link removed and replaced by design.adoc,
to which the CC license text has been added.
* design.adoc: Renamed as README.adoc.
* publish.sh: Deleted.
2018-06-11 Jeremy Bennett <jeremy.bennett@embecosm.com>
* README.md: Previous version moved to README-old.md for the time
being.
* README.adoc: Created as symbolic link to design.adoc.
2018-06-10 Jeremy Bennett <jeremy.bennett@embecosm.com>
* README.md: Note about make publish.
* design.adoc (Overall structure): Make list or instruction sets
and extensions compact representation.
2018-06-10 Jeremy Bennett <jeremy.bennett@embecosm.com>
* publish.sh: Only publish from clean and committed master branch
to avoid difficult use of git stash.
2018-06-10 Jeremy Bennett <jeremy.bennett@embecosm.com>
* publish.sh: Don't rely on doc directory being available on
gh-pages branch.
2018-06-10 Jeremy Bennett <jeremy.bennett@embecosm.com>
* publish.sh: Make executable and correctly set top level
repository directory.
2018-06-10 Jeremy Bennett <jeremy.bennett@embecosm.com>
Add a mechanism to make the latest documentation available via
GitHub pages. This means that design.html is no longer part of
the master branch, but is published by copying to index.html on
the gh-pages branch.
* .gitignore: Ignore design.html.
* Makefile: Add publish target and delete design.html when cleaning.
* README.md: Link to GitHub pages for latest documentation.
* design.adoc: Deal with AsciiDoc apparent bug with consecutive
comment blogs.
* design.html: Deleted.
* publish.sh: Created.
2018-06-10 Jeremy Bennett <jeremy.bennett@embecosm.com>
* README.md: Fix link to generated documentation.
* design.html: Regenerated.
2018-06-09 Jeremy Bennett <jeremy.bennett@embecosm.com>
* Makefile: Add sanity check for version number and spell target.
* design.adoc: Fix trivial typo.
* design.html: Regenerated.
2018-06-09 Jeremy Bennett <jeremy.bennett@embecosm.com>
* .gitignore: Don't ignore .html or .xml
* README.md: Note location of old documentation, give link to HTML
and explain how to contribute.
* custom.wordlist: Created.
* design.adoc: Cleaned up from top to bottom and spell checked.
* design.html: Generated.
2018-06-08 Jeremy Bennett <jeremy.bennett@embecosm.com>
* Makefile: Clean up and add license header.
* README.md: Created.
* design.adoc: Add licensing and SPDX license identifier.
* legacy.adoc: Deleted.
2018-06-04 Jeremy Bennett <jeremy.bennett@embecosm.com>
This is the first version of the document taken from Simon
Davidmann's MS Word document. The main document is design.adoc,
legacy material, currently just appendices C and D has been moved
to legacy.adoc.
design.adoc is correct AsciiDoc. legacy.adoc is just a raw dump,
which needs cleaning up.
The next step will be restructuring design.adoc as agreed.
* .gitignore: Created.
* ChangeLog: Created.
* Makefile: Created.
* design.adoc: Created.
* legacy.adoc: Created.

88
tests/wally-riscv-arch-test/doc/MIGRATION.adoc
View File

@ -1,88 +0,0 @@
= Migration guide
:toc:
:icons: font
:numbered:
:source-highlighter: rouge
This document serves as a guide to users of the architectural suite to migrate their targets from an
older version to a newer version with minimal changes. This guide thus provides a patch scheme to get
the previous versions of the targets up and running with the new versions of the framework.
However, users are strongly encouraged to completely migrate to the newer versions, as and when
available, and avoid using these patches.
== Migration from v0.1 to v0.2
This section will describe the changes required to transition your targets ported on v0.1 to v0.2
framework. For examples please see: `riscv-target/riscvOVPsim_0p1` and `riscv-target/spike_0p1`.
=== Change header filename
In version v0.1 the target specific assembly macros were split across two files: `compliance_test.h`
and `compliance_io.h`. In version v0.2 these macros are to merged into a single file named
`model_test.h`. The following commands can the achieve the above:
----
mv compliance_test.h model_test.h
cat compliance_io.h >> model_test.h
rm compliance_io.h
----
=== Change device directory structure
In version v0.1 a target would have one or multiple of the directories defined to indicate supported
extensions: `rv32i`, `rv32im`, `rv32imc`, `rv32Zicsr` and `rv32Zifencei`. In version v0.2 the
directories of the extensions have changed in order to provide more consistency and less ambiguity.
For version v0.2, the `device` directory first needs to have either a `rv32i_m` directory to indicate
that the target is a 32-bit machine. The extension directories, as supported by the target, are
now to be created in each of these directories using the following mapping scheme:
. device/rv32i -> device/rv32i_m/I
. device/rv32im -> device/rv32i_m/M
. device/rv32imc -> device/rv32i_m/C
. device/rv32Zicsr -> device/rv32i_m/privilege
. device/rv32Zifencei -> device/rv32i_m/Zifencei
The contents of the extension directories need not change, unless there are dependencies on the path
of the directory itself. The following commands will achieve the above:
----
cd device
mkdir rv32i_m
mv rv32i rv32i_m/I
mv rv32im rv32i_m/M
mv rv32imc rv32i_m/C
mv rv32Zicsr rv32i_m/privilege
mv rv32Zifencei rv32i_m/Zifencei
----
=== Changes in target macro names.
Since some of the macros from the old framework have been re-purposed in the new v0.2 framework,
there will be name conflicts rendering the old ones useless. In order to retain the old macros, they
have been renamed with a post-fix `_OLD`. The macros that have been renamed are given below:
. `RVTEST_CODE_BEGIN` -> `RVTEST_CODE_BEGIN_OLD`
. `RVTEST_CODE_END` -> `RVTEST_CODE_END_OLD`
. `RVTEST_DATA_BEGIN` -> `RVTEST_DATA_BEGIN_OLD`
. `RVTEST_DATA_END` -> `RVTEST_DATA_END_OLD`
The user is thus required to make the above changes in the new `model_test.h` that was created
as part of this migration. The following commands will help achieve the above:
----
sed -i 's/RVTEST_CODE_BEGIN/RVTEST_CODE_BEGIN_OLD/g' model_test.h
sed -i 's/RVTEST_CODE_END/RVTEST_CODE_END_OLD/g' model_test.h
sed -i 's/RVTEST_DATA_BEGIN/RVTEST_DATA_BEGIN_OLD/g' model_test.h
sed -i 's/RVTEST_DATA_END/RVTEST_DATA_END_OLD/g' model_test.h
----
note:: the RVTEST_DATA_END in v0.1 enforced a 16-byte alignment before the signature end. This
constraint has been removed.
=== Changes in device Makefile.include files
No changes required.

82
tests/wally-riscv-arch-test/doc/Makefile
View File

@ -1,82 +0,0 @@
# Makefile for RISC-V Architectural Test SIG documentation
# This file is part of the RISC-V Foundation Architectural Test SIG
# tool set and documentation.
# Copyright (C) 2017 CodaSip Limited <www.codasip.com>
# Copyright (C) 2018 Embecosm Limited <www.embecosm.com>.
# Copyright (C) 2018 Imperas Limited <www.imperas.com>
# All rights reserved.
# Redistribution and use in source and binary forms, with or without
# modification, are permitted provided that the following conditions are met:
# 1. Redistributions of source code must retain the above copyright notice,
# this list of conditions and the following disclaimer.
# 2. Redistributions in binary form must reproduce the above copyright
# notice, this list of conditions and the following disclaimer in the
# documentation and/or other materials provided with the distribution.
# 3. Neither the name of mosquitto nor the names of its
# contributors may be used to endorse or promote products derived from
# this software without specific prior written permission.
# THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND CONTRIBUTORS "AS IS"
# AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
# IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
# ARE DISCLAIMED. IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
# LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR
# CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
# SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR BUSINESS
# INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
# CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR OTHERWISE)
# ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE
# POSSIBILITY OF SUCH DAMAGE.
# SPDX-License-Identifier: BSD-3-Clause
ROOT = README
SRC = $(ROOT).adoc
SRC_STRIPPED = $(ROOT)-stripped.adoc
.PHONY: all
all: pdf html
.PHONY: pdf
pdf: $(ROOT).pdf
$(ROOT).pdf: sanity-check $(SRC)
asciidoctor-pdf -d article $(SRC)
.PHONY: html
html: $(ROOT).html
$(ROOT).html: sanity-check $(SRC)
asciidoctor -d article -b html $(SRC)
# It is all too easy for the document history and title page to have diverging
# version numbers. This target checks first.
.PHONY: sanity-check
sanity-check:
@s=$$(sed -n < $(SRC) -e '3s/Issue //p') ; \
t=$$(sed -n < $(SRC) -e "/== Document history/,/^$$/p" | \
grep -c "$${s}") ; \
if [ $${t} -ne 1 ] ; \
then \
echo "Version number of title and document history do not match" ; \
exit 1 ; \
fi
custom.dict: custom.wordlist
aspell --lang=en create master ./$@ < $<
.PHONY: spell
spell: custom.dict $(SRC)
sed < $(SRC) > $(SRC_STRIPPED) -e 's/`[^`]\+`//gp' -e '/^----$$/,/^----$$/d'
aspell --master=en_US --mode=none --add-extra-dicts=./custom.dict \
-c $(SRC_STRIPPED)
$(RM) $(SRC_STRIPPED)
clean:
rm -f $(ROOT)-stripped.adoc $(ROOT).pdf $(ROOT).html custom.dict

460
tests/wally-riscv-arch-test/doc/README.adoc
View File

@ -1,460 +0,0 @@
= RISC-V Architectural Testing Framework =
RISC-V Foundation Architecture Test SIG
Issue 1.16 Draft
:toc:
:icons: font
:numbered:
:source-highlighter: rouge
////
SPDX-License-Identifier: CC-BY-4.0
Document conventions:
- one line per paragraph (don't fill lines - this makes changes clearer)
- Wikipedia heading conventions (First word only capitalized)
- US spelling throughout.
- Run "make spell" before committing changes.
- Build the HTML and commit it with any changed source.
- Do not commit the PDF!
////
== Introduction
=== About
This document describes the RISC-V Architectural Testing framework which is used to test if a RISC-V device's has understood and implemented the specifications correctly
* It explains the framework around the tests, the running of individual tests, and the suites of tests.
* It explains how to set up targets to run the tests.
This document is made freely available under a <<app_cc_by_4.0>>.
=== Intent of the architectural test suite
The RISC-V Architectural Tests are an evolving set of tests that are created to help ensure that software written for a given RISC-V Profile/Specification will run on all implementations that comply with that profile.
These tests also help ensure that the implementer has both understood and implemented the specification correctly.
The RISC-V Architectural Test suite is a minimal filter. Passing the tests and having the results approved by RISC-V International is a prerequisite to licensing the RISC-V trademarks in connection with the design. Passing the RISC-V Architectural Tests does not mean that the design complies with the RISC-V Architecture. These are only a basic set of tests checking important aspects of the specification without focusing on details.
The RISC-V Architectural Tests are not a substitute for rigorous design verification.
The result that the architecture tests provide to the user is an assurance that the specification has been interpreted correctly and the implementation under test (DUT) can be declared as RISC-V Architecture Test compliant.
=== Intended audience
This document is intended for design and verification engineers who wish to check if their RISC-V implementation (simulation models, HDL models, etc.) is compliant to the RISC-V specification.
For those who wish to develop new architectural tests and/or to write or adapt their own test framework are suggested to read the link:../spec/TestFormatSpec.adoc[`Test Format Spec`].
=== Contribute
You are encouraged to contribute to this repository (including changes to this document) by submitting pull requests and by commenting on pull requests submitted by other people as described in the link:../README.md[`README.md`] file in the top level directory.
While submitting a pull request note that some directories use `ChangeLog` files to track changes in the code and documentation. Please honor these, keeping them up to date and including the ChangeLog entry in the _git_ commit message.
Make sure to also include a comment with the SPDX license identifier in all source files, for example:
```
// SPDX-License-Identifier: BSD-3-Clause
```
NOTE: Don't forget to add your own name to the list of contributors in the document.
== Licensing
In general:
* code is licensed under the BSD 3-clause license (SPDX license identifier `BSD-3-Clause`);
* documentation is licensed under the Creative Commons Attribution 4.0 International license (SPDX license identifier `CC-BY-4.0`).
The files link:../COPYING.BSD[`COPYING.BSD`] and link:../COPYING.CC[`COPYING.CC`] in the top level directory contain the complete text of these licenses.
NOTE: The riscv-ovpsim simulator is licensed under an Imperas license. There is no dependency on this and it is included as a convenience to users.
==== AsciiDoc
This is a structured text format used by this document. Simple usage should be fairly self evident.
* Comprehensive information on the format is on the http://www.methods.co.nz/asciidoc/[AsciiDoc website].
* Comprehensive information on the tooling on the https://asciidoctor.org/[AsciiDoctor website].
* You may find this https://asciidoctor.org/docs/asciidoc-syntax-quick-reference/[cheat sheet] helpful.
==== Installing tools
To generate the documentation as HTML you need _asciidoctor_ and to generate as
PDF you need _asciidoctor-pdf_.
* These are the https://asciidoctor.org/docs/install-toolchain/[installation instructions for asciidoctor].
* These are the https://asciidoctor.org/docs/asciidoctor-pdf/#install-the-published-gem[installation instructions for asciidoctor-pdf].
To spell check you need _aspell_ installed.
==== Building the documentation
To build HTML:
[source,make]
----
make html
----
To build PDF:
[source,make]
----
make pdf
----
To build both:
[source,make]
----
make
----
To check the spelling (excludes any listing or code phrases):
[source,make]
----
make spell
----
Any custom words for spell checking should be added to link:./custom.wordlist[`custom.wordlist`].
=== Contributors
This document has been created by the following people (in alphabetical order of surname).
* Jeremy Bennett
* Mary Bennett
* Simon Davidmann
* Neel Gala
* Radek Hajek
* Lee Moore
* Milan Nostersky
* Marcela Zachariasova
=== Document history
[cols="<1,<2,<3,<4",options="header,pagewidth",]
|================================================================================
| _Revision_ | _Date_ | _Author_ | _Modification_
| 1.16 Draft | 23 September 2020 | Neel Gala| Changed Compliance to Architecture/Architectural. Refined the steps to port a new target. Removed simulator and target specific docs. Added vocabulary from the Test Format Specification
| 1.15 Draft | 14 March 2019 |
Prashanth Mundkur |
Added support and instructions for using the C and OCaml simulators from the Sail RISC-V formal model as targets.
| 1.14 Draft | 21 February 2019 |
Deborah Soung |
Documented how to use SiFive's RISC-V ISA Formal Specification model as a target.
| 1.13 Draft | 29 January 2019 |
Deborah Soung |
Added documentation on how to use Rocket Chip generated cores as targets.
| 1.12 Draft | 22 November 2018 |
Simon Davidmann |
Updated notes on Test Suites.
| 1.11 Draft | 21 November 2018 |
Neel Gala |
Added new signature format specs .
| 1.10 Draft | 20 June 2018 |
Simon Davidmann, Lee Moore |
Cleaned up description of updated framework and inclusion of riscvOVPsim.
| 1.9 Draft | 12 June 2018 |
Jeremy Bennett |
Update Future work section to take account of Codasip changes. Remove diagrammatic directory structure.
| 1.8 Draft | 12 June 2018 |
Jeremy Bennett |
Add Future work section.
| 1.7 Draft | 12 June 2018 |
Jeremy Bennett |
Add CC license as an appendix.
| 1.6 Draft | 10 June 2018 |
Jeremy Bennett |
Tidy up areas that are flawed in HTML version.
| 1.5 Draft | 8 June 2018 |
Jeremy Bennett |
General tidy up.
| 1.4 Draft | 8 June 2018 |
Jeremy Bennett |
Added license preamble.
| 1.3 Draft | 5 June 2018 |
Simon Davidmann |
Updated to reflect directory structure and trace macros.
| 1.2 Draft | 3 June 2018 |
Jeremy Bennett |
Converted to AsciiDoc, cleaned up and restructured.
| 1.1 Draft | 1 June 2018 |
Simon Davidmann
Lee Moore |
Revised format and expand to describe framework, usage of many tests groups,
and different Targets
|1.0 | 24 December 2017 |
Radek Hajek
Milan Nostersky
Marcela Zachariasova |
First version of the document.
|================================================================================
== Repository structure
The top level directory contains :
- a `README.md` file providing high-level details about the RISC-V Architecture Testing Framework.
- top level `Makefile` for running the tests on a RISC-V implementation.
- `ChangeLog` for logging changes with respect to code.
- complete license files for the Creative Commons and BSD licenses used by the task group.
There are then five top level directories.
`doc`:: All the documentation for the project, written using _AsciiDoc_.
`coverage`:: This directory contains a sub-directory structure similar to the `riscv-test-suite` directory. The coverage reports of each test-suite are available in the corresponding directories. The reports are available in the html and yaml formats. The directory also contains multiple coverpoint YAMLs which capture all the coverpoints of interest which are covered by all the tests in the `riscv-test-suite` directory.
`riscv-target`:: Contains a further subdirectory for each target, within which are placed the `model_test.h` header for that target and a `device` directory for all the devices of that target. If the `$TARGETDIR` environment variable is set to another directory, the scripts will search this directory for targets instead.
`riscv-test-env`:: This contains the `verify.sh` script which checks if the signatures generated the riscv-target device match the statically hosted reference signatures at the end of simulation. The directory also contains symbolic-links to the `arch_test.h` and `encoding.h` files present in the `riscv-test-suite/env` directory.
`riscv-test-suite`:: This contains a further `env` subdirectory which contains the `arch_test.h` and the `encoding.h` file which includes common assembly macros and routines which is used across the tests in the suite. Further directories are present which contain the actual architectural tests. The names and structure of these directories is based on the link:../test-pool structure guideline highlighted above.
`riscv-ovpsim`:: This contains a README pointing to the Imperas OVP riscvOVPsim simulator for use in architectural testing.
== Vocabulary
=== The architectural test
At the heart of the testing infrastructure is the detailed <<The architectural tests, _architectural test_>> available as `.S` assembly files. The specification and format of the tests is defined in the link:./TestFormatSpec.adoc[`Test Format Specification`].
=== The architectural test pool
The <<The architectural test, _architectural tests_>> are grouped into different functional test suites targeting the different subsets of the RISC-V specification. For more details on the test-pool structure, hierarchy and conventions please refer to the link:./TestFormatSpec.adoc[`Test Format Specification`].
For information on the currently supported different test suites, look here: link:../riscv-test-suite/README.md[../riscv-test-suite/README.md]
=== The test signature
Each test in the <<The architectural test pool, _architectural test pool_>> generates a <<The test signature, _test signature_>>, which represents the data written into specific memory locations during the execution of the test. The signature typically will record values (or sanitised values) of the operations carried out in the test. More details on the format and nature of the signatures is available in the link:./TestFormatSpec.adoc[`Test Format Specification`]
=== The reference signature
In order to claim that a device/implementation has passed the RISC-V Architecture Tests, the <<The test signature, _test signatures_>> obtained from the execution of the tests on the implementation need to be compared against a set of _golden_ <<The reference signatures, _reference signature_>>. These reference signatures are currently generated by the link:https://github.com/rems-project/sail-riscv[`RISC-V SAIL`] formal model and statically hosted in the repository for each test.
=== The test target
The <<The test target,_test target_>> can be either a RISC-V Instruction Set Simulator (ISS), a RISC-V emulator, a RISC-V RTL model running on an HDL simulator, a RISC-V FPGA implementation or a physical chip. Each of the target types offers specific features and represents specific interface challenges. It is a role of the <<The target shell, _target shell_>> to handle different targets while using the same <<The architectural test pool,_architectural test pool_>> as a test source.
=== The target shell
The <<The target shell, _target shell_>> is the software and hardware environment around the <<The test target,_test target_>> that enables it to communicate with the framework, including assembling and linking tests, loading tests into memory, executing tests, and extracting the signature. The input to the <<The target shell, _target shell_>> is a .S <<The architectural test,_architectural test_>> file, and the output is a <<The test signature,_test signature_>>.
== Porting a new target
In this section, a short tutorial on how to add a user target to the RISC-V Architectural Test Framework is provided.
The following steps demonstrate an example in which a target was replaced by the RISCV-ISA-SIM
(a.k.a Spike). In a similar way, any RISC-V ISA simulator or any RTL simulation model of the
RISC-V processor can be ported as a potential target for testing.
=== Setup environment variables
NOTE: `ROOTDIR` will always point to the riscv-arch-test repo.
1. Clone the repository:
---
git clone https://github.com/riscv/riscv-arch-test.git
cd riscv-arch-test
---
2. Open the `Makefile.include` available in the root folder of the repository and edit the following
variables based on your target:
a. `TARGETDIR` : set `TARGETDIR` to point to the directory which contains a sub-folder in the same name
as the target. For example, the arch-test repo includes the targets: sail-riscv-c and spike
under the `riscv-target` folder, in which case we set the `TARGETDIR` to riscv-target as shown
below. One can set this completely arbitrary paths as suitable by the user.
---
export TARGETDIR ?= $(ROOTDIR)/riscv-target
---
b. `XLEN`: set XLEN to max supported XLEN. Allowed values are 32 and 64.
---
export XLEN ?= 64
---
c. `RISCV_TARGET`: set this variable to the name of the target. A folder of the same name must exist in
the `TARGETDIR` directory
---
export RISCV_TARGET ?= spike
---
d. `RISCV_DEVICE`: set the `RISCV_DEVICE` environment to the extension you want to compile, simulate and verify. Leave
this blank if you want to iterate through all the supported extensions of the target. Allowed values
are the individual names of the extensions supported by your target like: I, M, C or Zifencei, etc. Multiple extensions are not be provided.
---
export RISCV_DEVICE ?=
---
e. `RISCV_TARGET_FLAGS`: set this to a string which needs to be passed to your target's Makefile.include files
---
export RISCV_TARGET_FLAGS ?=
---
f. `RISCV_ASSERT`: set this if you want to enable assertions on the test-suites. **Currently no tests use assertions.**
---
export RISCV_ASSERT ?= 0
---
g. `JOBS`: set the number of parallel jobs (along with any other arguments) you would like to
execute. Note that the target needs to be coded in such a way to support parallel execution. Some
targets use common intermediate files, rather than unique files, which makes them unsuitable for
parallel execution, these targets will need to be re-coded.
---
JOBS= -j1
---
3. Now inside your `TARGETDIR/RISCV_TARGET` directory you will need to create the following files:
a. `model_test.h`: A header file containing the definition of the various target specific
assembly macros that are required to compile and simulate the tests. The list and definition of the
required target specific macros is available in the link:../spec/TestFormatSpec.adoc[Test Format
Specification]
b. `link.ld`: A linker script to compile the tests for your target.
c. Any other files required by the target (configuration scripts, logs, etc.) can also be placed in
this directory.
4. Inside the `TARGETDIR/RISCV_TARGET` directory create a new folder named: `device`. If your device
is a 32-bit target then create a directory `device/rv32i_m`. If your device is a 64-bit target then
create a directory `device/rv64i_m`. If your target is configurable on the `XLEN` parameter then
both the folders need to be created.
5. Within the `rv32i_m`/`rv64i_m` directories sub-folders in the name of the extensions supported
by the target need to be created. For eg. A target supporting the ISA RV32IMC_Zifence will have the
following directory structure:
---
- rv32i_m/I
- rv32i_m/M
- rv32i_m/C
- rv32i_m/privilege
- rv32i_m/Zifencei
---
6. Each of the above extension directories will now need to include a file: `Makefile.include` which
defines the following Makefile variables:
a. `RUN_TARGET`:: This variable needs to include commands and steps to execute an ELF on target device. Note here that this variable should include all the necessary steps and arguments to run that specific test-suite. For example, in case of spike for the `rv32i_m/C` test-suite the corresponding `Makefile.include` has the `--isa=rv32ic` argument as opposed to just `--isa=rv32i` for the base `rv32i_m/I` test-suite. This variable should also include other steps to extract and sanitize the signature file as well for each test. The only argument available to this variable is the compiled `elf` file.
b. `COMPILE_TARGET`:: This variable should include the commands and steps required to compile an assembly test for the target for each extension mentioned above. Note, currently only the GCC compiler is supported. This compiler takes `march` and `mabi` arguments from the corresponding architectural suite framework. `COMPILE_TARGET` will more or less be the same across test-suites. The only argument available to `COMPILE_TARGET` is the assembly file of one architectural test.
The following figure depicts the final directory structure of a target device that should get created at the end of the above steps:
[#img-testStruct]
.File Structure of the Target directory
image::./file-struct.jpg[TargetStruct]
=== Generating Signature
As previously mentioned the execution of each test on the target must generate a signature file. The name of the signature file should be `<test-file-name.signature_output>`. The signature file should follow the guidelines mentioned in the link:../spec/TestFormatSpec.adoc[`Test Format Specification`].
In case of spike, we have ensured that the signature region is bounded by the labels: `begin_signature` and `end_signature`. This is enforced in the `RVMODEL_DATA_BEGIN` and `RVMODEL_DATA_END` macros defined in the `riscv-target/spike/model_test.h` file. Additionally, if you look closely at the `RUN_TARGET` variable defined in the `Makefile.include` files of the spike target, it includes a few bash commands to sanitize the signature produced from spike. This is done to conform the final signature file to the specification defined in the link:../spec/TestFormatSpec.adoc[`Test Format Specification`].
=== Compile, simulate and verify the tests
Once you have ported your target to the riscv-arch-test framework by following the above steps, you
are now ready to compile, simulate and verify the tests on your target
If you would like to compile, simulate and verify all the extension tests applicable to your target
simply run `make` from the `ROOTDIR`.
NOTE: For the above to work the `RISCV_DEVICE` in `ROOTDIR/Makefile.include` must be left empty.
If you would like to only compile the tests for a particular extension you can use the following
command.
make RISCV_DEVICE=M compile
make RISCV_DEVICE=C compile
The arguments to the `RISCV_DEVICE` variable must be the extensions supported by the target.
NOTE: If `RISCV_DEVICE` is not defined/empty it will default to the `I` extension which is necessary
for all targets.
To simulate the compiled tests on your target:
make RISCV_DEVICE=M simulate
make RISCV_DEVICE=Zifencei simulate
NOTE: If `RISCV_DEVICE` is not defined/empty it will default to the `I` extension which is necessary
for all targets.
To verify if the generated signatures match the corresponding reference signatures.
make RISCV_DEVICE=M verify
NOTE: If `RISCV_DEVICE` is not defined/empty it will default to the `I` extension which is necessary
for all targets.
All the above steps create and modify files in the `work` directory created in `ROOTDIR` folder. To
clean the `workdir` simple run :
make clean
By default the working directory is set to `ROOTDIR/work`. This can be overwritten by assigning a
new working directory path via the command line. Note, the path must be absolute and not relative :
make WORK=/home/me/my_path/mywork clean compile simulate

73
tests/wally-riscv-arch-test/doc/custom.wordlist
View File

@ -1,73 +0,0 @@
AsciiDoc
asciidoc
AsciiDoctor
asciidoctor
aspell
autotools
CGEN
cmake
Codasip
creativecommons
CY
Davidmann
discoverable
DUT
EF
enforceability
FPGA
GDB
Generis
github
Hajek
HDL
http
https
IC
ies
immunities
Imperas
io
IM
ISA
legalcode
licensor
licensors
licensor's
LLVM
makefile
makefiles
Marcela
md
merchantability
Nostersky
nz
pagewidth
parameterization
pdf
publicdomain
Radek
README
riscv
riscvOVPsim
RTL
rv
RVTEST
SiFive
spdx
src
subdirectory
sublicensable
synched
tbd
testbench
toc
toolchain
TVM
URI
Verilator
Verilog
waivable
WIPO
wordlist
www
Zachariasova

BIN
tests/wally-riscv-arch-test/doc/file-struct.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 642 KiB

43
tests/wally-riscv-arch-test/riscv-ovpsim/README.md
View File

@ -1,43 +0,0 @@
riscvOVPsim
===
A Complete, Fully Functional, Configurable RISC-V Simulator
===
riscvOVPsim has moved to its own GitHub repository.
It can now be found here: [github.com/riscv-ovpsim](https://github.com/riscv-ovpsim/imperas-riscv-tests)
For the enhanced version, please download from [ovpworld.org/riscv-ovpsim-plus](https://www.ovpworld.org/riscvOVPsimPlus).
The simulators implement the full and complete functionality of the RISC-V Foundation's public User and Privilege specifications.
The simulator is command line configurable to enable/disable all current optional and processor specific options.
The simulator is developed, licensed and maintained by [Imperas Software](http://www.imperas.com/riscv) and it is fully compliant to the OVP open standard APIs.
As a member of the RISC-V Foundation community of software and hardware innovators collaboratively driving RISC-V adoption, Imperas has developed the riscvOVPsim simulator to assist RISC-V adopters to become compliant to the RISC-V specifications. The latest RISC-V compliance test suite and framework can be downloaded from https://www.github.com/riscv/riscv-compliance.
riscvOVPsim includes an industrial quality model and simulator of RISC-V processors for use for compliance and test development. It has been developed for personal, academic, or commercial use, and the model is provided as open source under the Apache 2.0 license. The simulator is provided under the Open Virtual Platforms (OVP) Fixed Platform Kits license that enables download and usage. riscvOVPsim and Imperas RISC-V support is actively maintained and enhanced. To ensure you make use of the current version of riscvOVPsim versions do expire. Please download the latest version.
![](riscvOVPsim.jpg)
Extending riscvOVPsim and building your own models and platforms
---
riscvOVPsim is a fixed function simulation of one configurable processor model in a fixed platform.
Full extendable platform simulations of reference designs booting FreeRTOS, Linux, SMP Linux etc.
are available as open source and are available from [www.IMPERAS.com](http://www.imperas.com),
[www.OVPworld.org](http://www.OVPworld.org).
About Open Virtual Platforms (OVP) and Imperas Software
---
**Open Virtual Platforms** was created in 2008 to provide an open standard set of APIs and methodology to develop virtual platforms and simulation technology.
[www.OVPworld.org](http://www.OVPworld.org/riscv).
**Imperas Software Ltd.** is the leading independent commercial developer of virtual platforms and high-performance software simulation solutions for embedded processor and systems. Leading semiconductor and embedded software companies use Imperas simulators for their processor based simulation solutions.
[www.imperas.com](http://www.imperas.com/riscv).
![OVP Image ](http://www.imperas.com/sites/default/files/partner-logos/ovp_0.jpg)
![Imperas Imperas](https://www.imperas.com/sites/default/files/imperas-web-logo_2.png)
---
This is the riscvOVPsim/README.md

BIN
tests/wally-riscv-arch-test/riscv-ovpsim/riscvOVPsim.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 80 KiB

606
tests/wally-riscv-arch-test/spec/TestFormatSpec.adoc
View File

@ -1,606 +0,0 @@
= RISC-V Architecture Test Format Specification =
RISC-V Foundation Architecture Test SIG
Issue 1.2.6 Draft
:toc:
:icons: font
:numbered:
:source-highlighter: rouge
////
SPDX-License-Identifier: CC-BY-4.0
Document conventions:
- one line per paragraph (don't fill lines - this makes changes clearer)
- Wikipedia heading conventions (First word only capitalized)
- US spelling throughout.
- Run "make spell" before committing changes.
- Build the HTML and commit it with any changed source.
- Do not commit the PDF!
////
== Introduction
=== About
This document contains the RISC-V <<The RISC-V architectural test pool,_architectural test pool_>> structure and <<The architectural test,_architectural test_>> format specification which shall be used as a reference document for those who write or are going to write tests for the RISC-V architectural test pool and for those who are going to use the <<The RISC-V architectural test pool,_architectural test pool_>> in their own architectural test framework.
* It includes, as example, source code listing and detailed description of one <<The architectural test,_architectural test_>>
Framework specification which includes description of how the <<The RISC-V architectural test suite,_architectural test suites_>> are built and used for the appropriate RISC-V configurations is given in the complementary Framework Specification document. This document is made freely available under a <<app_cc_by_4.0>>.
=== Intended audience
This document is intended for design and verification engineers who wish to develop new architectural tests and also for those who wish to write or adapt their own test framework.
=== Future work
This is a draft document; it partially documents what exists, and partially documents the longer-term goal.
As such, this document still under review and its content will change.
Its primary aim is to get a long-term stable version of the spec and to give test authors sufficient lead time to prepare test authoring tools and strategies.
=== Contributors
This document has been created by the following people (in alphabetical order of surname).
* Allen Baum
* Jeremy Bennett
* Radek Hajek
* Premysl Vaclavik
=== Document history
[cols="<1,<2,<3,<4",options="header,pagewidth",]
|================================================================================
| _Revision_ | _Date_ | _Author_ | _Modification_
| 1.2.6 Draft | 24 September 2020 | Neel Gala | Replaced Compliance with Architecture/Architectural. Minor beautification in macro definitions.
| 1.2.5 Draft | 22 Jan 2020 |
Allen Baum |
* removed references to test pool reference doc, mentioned that the framework will generate it
* clarified that macros defined in a test may be used in a test
* minor clarifications, consistency changes, added page breaks
| 1.2.4 Draft | 08 Jan 2020 |
Allen Baum |
* typos fixed
* added RVTEST_BASEUPD macro
* added explanations for each macro
* clarified restrictions on #ifdefs
* added comment that test cases with identical conditions should be combined into a single case
* documented that test case first parameter should match the #ifdef parameter that precedes it
| 1.2.3 Draft | 02 Dec 2019 |
Allen Baum |
* modified macro names to conformn to riscof naming convention of model specific vs. pre-defined
* add more complete list of macros, their uses, parameters, and whether they are required or optional
* minor structural changes (moving sentences, renumbering) and typo fixes
* clarified impact of debug macros
* clarified how SIGUPD and BASEUPD must be used, fixed parameter description
| 1.2.2 Draft | 21 Nov 2019 |
Allen Baum |
* remove section about test taxonomy, binary tests, emulated ops
* clarify/fix boundary between test target and framework responsibilities
(split test target into test target and test shell)
* remove To Be discussed items that have been discussed
* remove default case condition; if conditions are unchaged, part of same case
* minor grammatical changes related to the above
| 1.2.1 Draft | 19 Nov 2019 |
Allen Baum |
* spec/TestFormatSpec.adoc: changed the format of the signature to fixed 32b data size only extracted from COMPLIANCE_DATA_BEGIN/END range.
* made test suite subdirectories upper case, with sub-extensions camel case
* updated example to match most recent riscof implement macros
* fix format so Appendix is now in TOC
* moved note about multiple test cases in a test closer to definition
* fixed cut/paste error in example of test pool
* more gramatical fixes, clarifications added
* added To Be Discussed items regarding emulated instruction and binary tests
* added graphic of test suite/test_pool/test/test_case hierarchy
| 1.2.1 Draft | 12 Oct 2019 |
Allen Baum |
minor grammar, wording, syntax corrections, added detail and clarification from suggestions by Paul Donahue
| 1.2 Draft | 12 Sep 2019 |
Allen Baum |
minor grammar, wording, syntax corrections, added detail and clarification
Added detail regarding the 2 approaches for test selection: central database, or embedded conditions embedded in macros
Added detail of proposed standard macros RVTEST_SIGBASE, RVTEST_SIGUPD, RVTEST_CASE
More explanation of spec status in initial _future work_ paragraph (i.e. goal, not yet accomplished)
Removed many "to Be Discussed items and made them official
Removed options, made POR for test selection and standard macros RVTEST_SIGBASE, RVTEST_SIGUPD, RVTEST_CASE
Removed prohibition on absolute addresses
Clarified which test suites a test should be in where they are dependent on multiple extensions
Clarified use of includes and macros (and documented exsiting deviations)
Clarified use of YAML files
Added detail to description and uses of common compliance test pool reference document
| 1.1 Draft | 15 Feb 2019 |
Radek Hajek |
Appendix A: example assertions update
| 1.0 Draft | 10 Dec 2018 |
Radek Hajek, Premysl Vaclavik |
First version of the document under this file name. Document may contain some segments of the README.adoc from the compatibility reasons.
|================================================================================
<<<
== Foreword
The architectural test pool shall become a complete set of architectural tests which will allow developers to build an architectural test suite for any legal RISC-V configuration. The architectural tests will be very likely written by various authors and therefore it is very important to define the architectural test pool structure and architectural test form, which will be obligatory for all tests. Unification of tests will guarantee optimal architectural test pool management and also better quality and readability of the tests. Last but not least, it will simplify the process of adding new tests into the existing architectural test pool and the formal revision process.
== Vocabulary
=== The architectural test
The architectural test is a nonfunctional testing technique which is done to validate whether the system developed meets the prescribed standard or not. In this particular case the golden reference is the RISC-V ISA standard.
For purpose of this document we understand that the architectural test is a single test which represents the minimum test code that can be compiled and run. It is written in assembler code and its product is a <<The test signature,_test signature_>>. A architectural test may consist of several <<The test case,_test cases_>>.
=== The RISC-V architectural test pool
The RISC-V architectural test pool consists of all approved <<The architectural test,_architectural tests_>> that can be assembled by the test framework, forming the <<The RISC-V architectural test suite,_architectural test suite_>>. The RISC-V architectural test pool must be test target independent (so, should correctly run on any compliant target). Note that this nonfunctional testing is not a substitute for verification or device test.
=== The RISC-V architectural test suite
The RISC-V architectural test suite is a group of tests selected from the <<The RISC-V architectural test pool,_architectural test pool_>> to test adherence for the specific RISC-V configuration. Test results are obtained in the form of a <<The test suite signature,_test suite signature_>>. Selection of tests is performed based on the target's asserted configuration, and the spec, Execution Environment or platform requirements. Compliant processor or processor models shall exhibit the same test suite signature as the golden reference test suite signature for the specific configuration being tested.
=== The test case
A _test case_ is part of the architectural test that tests just one feature of the specification.
----
Note: a single test can contain multiple test cases, each of which can have its own test inclusion condition (as defined by the cond_str parameter of the RVTEST_CASE macro.
----
[#img-testStruct]
.Test Suite, Test_Pool, Test, Test_Case relationship
image::./testpool.jpg[testStruct]
=== The test case signature
The _test case signature_ is represented by single or multiple values. Values are written to memory at the address starting at the address specified by the RVMODEL_DATA_BEGIN and ending at RVMODEL_DATA_END. Signatures can be generated most easily using the RVTEST_SIGUPD macro.
=== The test signature
The <<The test signature,_test signature_>> is a characteristic value which is generated by the architectural test run. The <<The test signature,_test signature_>> may consist of several <<The test case signature,_test case signatures_>>, prefixed with a separate line containing the name of the test and a unique value indicating its version (e.g. git checkin hash). The test target is responsible for extracting values from memory and properly formatting them, using metadata provided to it by the framework using the RVMODEL_DATA_BEGIN and RVMODEL_DATA_END macros. Test case signature values are written one per line, starting with the most-significant byte on the left-hand side with the format <hex_value> where the length of value will be 32 bits (so 8 characters), regardless of the actual value length computed by the test. Furthermore, the signature should always begin at a 16-byte (128-bit) boundary and the size of the signature should be a multiple of 16-bytes (i.e. it should also end at a 16-byte boundary).
=== The test suite signature
The _test suite signature_ is defined as a set of <<The test signature,_test signatures_>> valid for given <<The RISC-V architectural test suite,_architectural test suite_>>. It represents the test signature of the particular RISC-V configuration selected for the architectural test.
=== The target shell
The <<The target shell, _target shell_>> is the software and hardware environment around the <<The test target,_test target_>> that enables it to communicate with the framework, including assembling and linking tests, loading tests into memory, executing tests, and extracting the signature. The input to the <<The target shell, _target shell_>> is a .S <<The architectural test,_architectural test_>> file, and the output is a <<The test signature,_test signature_>>.
=== The test target
The <<The test target,_test target_>> can be either a RISC-V Instruction Set Simulator (ISS), a RISC-V emulator, a RISC-V RTL model running on an HDL simulator, a RISC-V FPGA implementation or a physical chip. Each of the target types offers specific features and represents specific interface challenges. It is a role of the <<The target shell, _target shell_>> to handle different targets while using the same <<The RISC-V architectural test pool,_architectural test pool_>> as a test source.
=== The RISC-V processor (device) configuration
The RISC-V ISA specification allows many optional instructions, registers, and other features. Production directed targets typically have a fixed subset of available options. A simulator, on the other hand, may implement all known options which may be constrained to mimic the behavior of the RISC-V processor with the particular configuration. It is a role of the Architectural Test Framework to build and use the <<The RISC-V architectural test suite,_architectural test suite_>> suitable for the selected RISC-V configuration.
=== The architectural test framework
The <<The architectural test framework,_architectural test framework_>> selects and configures the <<The RISC-V architectural test suite,_architectural test suite_>> from the <<The RISC-V architectural test pool,_architectural test pool_>> for the selected <<The test target,_test target_>> based on both the specific architectural choices made by an implementation and those required by the Execution Environment It causes the <<The target shell, _target shell_>> to build, execute, and report a signature. The <<The architectural test framework,_architectural test framework_>> then compares reported signatures, inserts test part names and version numbers and summarizes differences (or lack of them) into a RISC-V test report. The primary role of the well-defined <<The RISC-V architectural test pool,_architectural test pool_>> structure is to provide the tests in a form suitable for the Architectural Test Framework selection engine.
<<<
== Architectural test pool
=== Test pool structure
The structure of <<The architectural test,_architectural tests_>> in the <<The RISC-V architectural test pool,_architectural test pool_>> shall be based on defined RISC-V extensions and privileged mode selection. This will provide a good overview of which parts of the ISA specification are already covered in the <<The RISC-V architectural test suite,_architectural test suite_>>, and which tests are suitable for certain configurations. The architectural test pool has this structure:
----
architectural-tests-suite (root)
|-- <architecture>_<mode>/<feature(s)>, where
<architecture> is [ RV32I | RV64I | RV32E ]
<mode> is [ M | MU | MS | MSU ], where
M Machine mode tests - tests execute in M-mode only
MU Machine/User mode tests - tests execute in both M- & U-modes (S-mode may exist)
MS Machine/Supv mode tests - tests execute in both M- & S-modes (not U-mode)
MSU All mode tests - tests execute in all of M-, S-, & U-Modes
<feature(s)> are the lettered extension [A | B | C | M ...] or subextension [Zifencei | Zam | ...] when the tests involve extensions, or more general names when tests cut across extension definitionss (e.g. Priv, Interrupt, Vm). The feature string consists of an initial capital letter, followed by any further letters in lower case.
----
Note that this structure is for organizational purposes, not functional purposes, although full test names will take advantage of it.
Tests that will be executed in different modes, even if the results are identical, should be replicated in each mode directory, e.g. RV32I_M/, RV32I_MS/, and RV32I_MU/. These tests are typically those involving trapping behavior, e.g load, store, and privilged ops.
=== Test naming
The naming convention of a single test:
<__test objective__>-<__test number__>.S
* __test objective__ – an aspect that the test is focused on. A test objective may be an instruction for ISA tests (ADD, SUB, ...), or a characteristic covering multiple instructions, e.g. exception event (misaligned fetch, misalign load/store) and others.
* __test number__ – number of the test. It is expected that multiple tests may be specified for one test objective. We recommend to break down complex tests into a set of small tests. A simple rule of thumb is one simple test objective = one simple test. The code becomes more readable and the test of the objective can be improved just by adding <<The test case,_test cases_>>. The typical example are instruction tests for the F extension.
* A test name shall not include an ISA category as part of its name (i.e. the directory, subdirectory names). +
Experience has shown that including ISA category in the test name leads to very long test names. Instead, we have introduced the <<Test pool structure,test pool structure>> where the full name is composed of the test path in the <<Test pool structure,test pool structure>> and the simple test name. +
Since full names can be reconstructed easily it is not necessary to include the path in test names.
=== Assembly macros and test labels
There are both pre-defined and model-specific macros which shall be used in every test to guarantee
their portability. In addition, there are both pre-defined and model specific macros that are not required,
but may be used in tests for either convenience or debugging purposes.
==== *Required, Pre-defined Macros*
These macros are be defined in the file **compilance_test.h** by the author of the test. A
significant amount of the framework shall depend on the existence of these macros.
`RVTEST_ISA(isa_str)`::
- defines the Test Virtual Machine (TVM, the ISA being tested) +
- empty macro to specify the isa required for compilation of the test. +
- this is mandated to be present at the start of the test.
`RVTEST_CODE_BEGIN`::
- start of code (test) section
- macro to indicate test code start add and where test startup routine is inserted. +
- no part of the test-code section should precede this macro
- this macro includes an initialization routine which pre-loads all the GPRs with unique values
(not `0xdeadbeef`). Register t0 and t1 are initialized to point to the labels :
`rvtest_code_begin` and `rvtest_code_end` respectively.
- the macros contains a label `rvtest_code_begin` after the above initilization routine to mark
the begining of the actual test.
`RVTEST_CODE_END`::
- end of code (test) section +
- macro to indicate test code end. +
- no part of the test-code section should follow after this macro.
- the macro enforces a 16-byte boundary alignment
- the macro also inlcudes the label `rvtest_code_end` which marks the end of the actual test.
- if trap handling is enabled, this macro contains the entire trap handler code required by the
test.
`RVTEST_DATA_BEGIN`::
- marks the begining of the test data section +
- used to provided initialized data regions to be used by the test +
- this region starts at a 16-byte boundary +
- the start of this is macro can be addressed using the label: `rvtest_data_begin`
- when trap handling is enabled, this macro also includes the following labels :
. trapreg_sv: This region is used to save the temporary registers used in the trap-handler
code
. tramptbl_sv: This region is used to save the contents of the test-target's initial
code-section which is overwritten with the necessary trampoline table.
. mtvec_save: a double-word region to save the test-target specific mtvec register
. mscratch_save: a double-word region to save the test-target specific mscratch register
`RVTEST_DATA_END`::
- this macros marks the end of the test input data section.
- the start of this macro can be addressed using the label: `rvtest_data_end`
`RVTEST_CASE(CaseName, CondStr)`::
- execute this case only if condition in cond_str are met +
- caseName is arbitrary string +
- condStr is evaluated to determine if the test-case is enabled and sets name variable +
- condStr can also define compile time macros required for the test-case to be enabled. +
- the test-case must be delimited with an #ifdef CaseName/#endif pair +
- the format of CondStr can be found in https://riscof.readthedocs.io/en/latest/cond_spec.html#cond-spec
==== *Required, Model-defined Macros*
These macros are be defined by the owner of the test target in the file **model_test.h**.
These macros are required to define the signature regions and also the logic required to halt/exit
the test.
`RVMODEL_DATA_BEGIN`::
- This macro marks the start of signature regions. The test-target should use this macro to create a label to indicate the begining of the signature region. For example : `.globl begin_signature; begin_signature`. This macro must also begin at a 16-byte boundary and must not include anything else.
`RVMODEL_DATA_END`::
- This macros marks the end of the signature-region. The test-target must declare any labels required to indicate the end of the signature region. For example : `.globl end_signature; end_signature`. This label must be at a 16-byte boundary. The entire signature region must be included within the RVMODEL_DATA_BEGIN macro and the start of the RVMODEL_DATA_END macro. The RVMODEL_DATA_END macro can also contain other target specific data regions and initializations but only after the end of the signature.
`RVMODEL_HALT`::
- This macros must define the test-target halt mechanism. This macro is called when the test is
to be terminated either due to completion or dur to unsupported behavior. This macro could
also include routines to dump the signature region to a file on the host system which can be
used for comparison.
==== *Optional, Pre-defined Macros*
`RVTEST_SIGBASE(BaseReg,Val)`::
- defines the base register used to update signature values +
- Register BaseReg is loaded with value Val +
- hidden_offset is initialized to zero
`RVTEST_SIGUPD(BaseReg, SigReg [, Offset])`::
- if Offset is present in the arguments, hidden_offset if set to Offset +
- Sigreg is stored at hidden_offset[BaseReg]
- hidden_offset is post incremented so repeated uses store signature values sequentially
`RVTEST_BASEUPD(BaseReg[oldBase[,newOff]])`::
- [moves &] updates BaseReg past stored signature +
- Register BaseReg is loaded with the oldReg+newOff+hidden_offset +
- BaseReg is used if oldBase isn't specified; 0 is used if newOff isn't specified +
- hidden_offset is re-initialized to 0 afterwards
`RVTEST_SIGUPD_F(BaseReg, SigReg, FlagReg [, Offset])`::
- This macro is used for RV32F and RV64D (where XLEN==FLEN).
- if Offset is present in the arguments, hidden_offset if set to Offset+(XLEN*2) +
- SigReg is stored at hidden_offset[BaseReg]
- FlagReg is stored at hidden_offset+XLEN[BaseReg]
- hidden_offset is post incremented so repeated uses store signature values sequentially
==== *Optional, Model-defined Macros*
`RVMODEL_BOOT`::
- contains boot code for the test-target; may include emulation code or trap stub. If the
test-target enforces alignment or value restrictions on the mtvec csr, it is required that
this macro sets the value of mtvec to a region which is readable and writable by the machine
mode. May include code to copy the data sections from boot device to ram. Or any other code
that needs to be run prior to running the tests.
`RVMODEL_IO_INIT`::
- initializes IO for debug output
- this must be invoked if any of the other RV_MODEL_IO_* macros are used
// `RVMODEL_IO_CHECK`
// - checks IO for debug output
// - <needs description of how this is used >
`RVMODEL_IO_ASSERT_GPR_EQ(ScrReg, Reg, Value)`::
- debug assertion that GPR should have value +
- outputs a debug message if Reg!=Value +
- ScrReg is a scratch register used by the output routine; its final value cannot be guaranteed
- Can be used to help debug what tests have passed/failed
`RVMODEL_IO_WRITE_STR(ScrReg, String)`::
- output debug string, using a scratch register +
- outputs the message String
- ScrReg is a scratch register used by the output routine; its final value cannot be guaranteed
`RVMODEL_SET_MSW_INT`::
- This macro needs to include a routine to set the machine software interrupt.
- Currently the test forces an empty macro if a target does not declare this. Future tests may
change this.
`RVMODEL_CLEAR_MSW_INT`::
- This macro needs to include a routine to clear the machine software interrupt.
- Currently the test forces an empty macro if a target does not declare this. Future tests may
change this.
`RVMODEL_CLEAR_MTIMER_INT`::
- This macro needs to include a routine to clear the machine timer interrupt.
- Currently the test forces an empty macro if a target does not declare this. Future tests may
change this.
`RVMODEL_CLEAR_MEXT_INT`::
- This macro needs to include a routine to clear the machine external interrupt.
- Currently the test forces an empty macro if a target does not declare this. Future tests may
change this.
=== Required labels
The test must define a `rvtest_entry_point` label to indicate the location to be used by the linker
as the entry point in the test. Generally, this would be before the `RVMODEL_BOOT` macro and should
belong to the `text.init` section.
=== The test structure of an architectural test
All tests shall use a signature approach. Each test shall be written in the same style, with defined mandatory items.
The test structure of an architectural test shall have the following sections in the order as follows:
. Header + license (including a specification link, a brief test description and RVTEST_ISA macro)).
. Includes of header files (see Common Header Files section).
. Test Virtual Machine (TVM) specification,
. Test code between “RVTEST_CODE_BEGIN” and “RVTEST_CODE_END”.
. Input data section, marked with "RVTEST_DATA_BEGIN" and "RVTEST_DATA_END".
. Output data section between “RVMODEL_DATA_BEGIN” and “RVMODEL_DATA_END”.
Note:: Note that there is no requirement that the code or scratch data sections must be contiguous
in memory, or that they be located before or after data or code sections
(configured by embedded directives recognized by the linker)
==== Common test format rules
There are the following common rules that shall be applied to each <<The architectural test,_architectural test_>>:
. Always use “//” as commentary. “#” should be used only for includes and defines.
. As part of the initialization code, all GPRs are preloaded with unique predefined values (which is
not `0xdeadbeef`). However, t0 is initialized with `rvtest_code_begin` and t1 is initialized with
`rvtest_data_begin`.
. The signature section of every test is pre-loaded with the word `0xdeadbeef`
. The signature region should always begin at a 16-byte boundary
. A test shall be divided into logical blocks (<<The test case,_test cases_>>) according to the test goals. Test cases are enclosed in an `#ifdef <__CaseName__>, #endif` pair and begin with the RVTEST_CASE(CaseName,CondStr) macro that specifies the test case name, and a string that defines the conditions under which that <<The test case,_Test case_>> can be selected for assembly and execution. Those conditions will be collected and used to generate the database which in turn is used to select tests for inclusion in the test suite for this target.
. Tests should use the RVTEST_SIGBASE(BaseReg,Val) macro to define the GPR used as a pointer to the output signature area, and its initial value. It can be used multiple times within a test to reassign the output area or change the base register. This value will be used by the invocations of the RVTEST_SIGUPD macro.
. Tests should use the RVTEST_SIGUPD(BaseReg, SigReg, ScratchReg, Value) macro to store signature values using (only) the base register defined in the most recently encountered RVTEST_SIGBASE(BaseReg,Val) macro. Repeated uses will automatically have an increasing offset that is managed by the macro.
.. Uses of RVTEST_SIGUPD shall always be preceded sometime in the test case by RVTEST_SIGBASE. +
.. Tests that use SIGUPD inside a loop or in any section of code that will be repeated (e.g. traps) must use the BASEUPD macro between each loop iteration or repeated code to ensure static values of the base and offset don't overwrite older values.
. When macros are needed for debug purposes, only macros from _model_test.h_ shall be used.
Note that using this feature shall not affect the signature results of the test run.
. Test shall not include other tests (e.g. #include “../add.S”) to prevent non-complete tests, compilation issues, and problems with code maintenance.
. Tests and test cases shall be skipped if not required for a specific model test configuration based on test conditions defined in the RVTEST_CASE macro. Tests that are selected may be further configured using variables (e.g. XLEN) which are passed into the tests and used to compile them. In either case, those conditions and variables are derived from the YAML specification of the device and execution environment that are passed into the framework. The flow is to run an architectural test suite built by the <<The architectural test framework,_Architectural Test Framework_>> from the <<The RISC-V architectural test pool,_architectural test pool_>> to determine which tests and test cases to run.
. Tests shall not depend on tool specific features. For example, tests shall avoid usage of internal GCC macros (e..g. ____risc_xlen__), specific syntax (char 'a' instead of 'a) or simulator features (e.g. tohost) etc.
. A test will end by either jumping to or implicitly reaching the `RVTEST_CODE_END` macro (i.e.
rvtest_code_end label). The `RVTEST_CODE_END` macro is always followed by the `RVMODEL_HALT` macro.
. Macros defined outside of a test shall only be defined in specific predefined header files (see <<Common Header Files,_Common Header Files_>> below), and once they are in use, they may be modified only if the function of all affected tests remains unchanged.
It is acceptable that macros use may lead to operand repetition (register X is used every time).
- The aim of this restriction is to have test code more readable and to avoid side effects which may occur when different contributors will include new <<The architectural test,_architectural tests_>> or updates of existing ones in the <<The RISC-V architectural test pool,_architectural test pool_>>.
This measure results from the negative experience, where the <<The RISC-V architectural test suite,_architectural test suite_>> could be used just for one target while the architectural test code changes were necessary to have it also running for other targets.
. All contents of the signature region must always be initialized to `0xdeadbeef`.
. The result of no operation should be stored in the signature even though not register has
been altered.
. Pseudo ops other than `li` and `la` which can map to multiple standard instruction sequences
should not be used.
. The actual test-section of the assembly must always start with the `RVTEST_CODE_BEGIN` which contains a routine to initialize the registers to specific values.
==== Common Header Files
Each test shall include only the following header files:
. _model_test.h_ – defines target-specific macros, both required and optional: (e.g. RVMODEL_xxx)
. _arch_test.h_ – defines pre-defined test macros both required and optional: (e.g. RVTEST_xxx)
The inclusion of the _arch_test.h_ should always occur after the _model_test.h_ file.
Important points to be noted regarding header files :
. Adding new header files is forbidden in the test. It may lead to macro redefinition and compilation issues.
. Macros maybe defined and used inside a test, as they will not be defined and used outside that specific test.
// . Assertions will generate code that reports assertion failures (and optionally successes?) only if enabled by the framework.
// . In addition, the framework may collect the assertion values and save them as a signature output file if enabled by the framework.
==== Framework Requirements
The framework will import files that describe
- the implemented, target-specific configuration parameters in YAML format
- the required, platform-specific configuration parameters in YAML format
The framework will generate intermediate files, including a Test Database YAML file that selects tests from the test pool to generate a test suite for the target.
The framework will also invoke the <<The target shell, _target shell_>> as appropriate to cause tests to be built, loaded, executed, and results reported.
The YAML files define both the values of those conditions and values that can be used by the framework to configure tests (e.g. format of WARL CSR fields).
Tests should not have #if, #ifdef, etc. for conditional assembly except those that surround RVMODEL_CASE macros
Instead, each of those should be a separate <<The test case,_test case_>> whose conditions are defined in
the common reference document entry for that test and test case number.
<<<
[appendix]
== Example ISA test _add-01.S_
.1) Header to inlcude comments
----
#This assembly file tests the add instruction of the RISC-V I extension for the add covergroup.
----
.2) Includes of header files
----
#include "model_test.h"
#include "arch_test.h"
----
.3) Set the TVM of the test
----
RVTEST_ISA("RV32I")
----
.4) Test target specifc boot-code
----
RVMODEL_BOOT
----
.5) Start of GPR intialization routine and test code
----
RVTEST_CODE_BEGIN
----
.6) Define the RVTEST_CASE string and conditions
----
#ifdef TEST_CASE_1
// this test is meant for devices implementing rv32I extension and requires enabling the compile
// macro TEST_CASE_1. This test will contribute to the "add" coverage label.
RVTEST_CASE(0,"//check ISA:=regex(.*32.*);check ISA:=regex(.*I.*);def TEST_CASE_1=True;",add)
----
.7) Initialize pointer to the signature region
----
RVTEST_SIGBASE( x16,signature_x16_1) // x16 will point to signature_x16_1 label in the signature region
----
.8) Define the test cases
----
TEST_RR_OP(add, x9, x4, x6, 0x80000005, 0x80000000, 0x00000005, x16, 0, x24)
TEST_RR_OP(add, x5, x5, x14, 0xfffffeff, 0x00000000, 0xfffffeff, x16, 4, x24)
...
...
----
.9) Change signature base register
----
// this will change the signature base register to x3. x3 will not point to signature_x3_0 in
// the signature region
RVTEST_SIGBASE( x3,signature_x3_0)
// continue with new test cases ..
TEST_RR_OP(add, x4, x24, x27, 0x55555955, 0x00000400, 0x55555555, x3, 0, x5)
...
...
----
.10) End the test and halt the test-target
----
RVTEST_CODE_END
RVMODEL_HALT
----
.11) Create test input data section
----
RVTEST_DATA_BEGIN
rvtest_data:
.word 0xbabecafe
RVTEST_DATA_END
----
.12) Create pre-loaded signature region
----
RVMODEL_DATA_BEGIN
.align 4
signature_x16_0:
.fill 0*(XLEN/32),4,0xdeadbeef
signature_x16_1:
.fill 16*(XLEN/32),4,0xdeadbeef
signature_x3_0:
.fill 86*(XLEN/32),4,0xdeadbeef
#ifdef rvtest_mtrap_routine
mtrap_sigptr:
.fill 64*(XLEN/32),4,0xdeadbeef
#endif
#ifdef rvtest_gpr_save
gpr_save:
.fill 32*(XLEN/32),4,0xdeadbeef
#endif
RVMODEL_DATA_END
----

BIN
tests/wally-riscv-arch-test/spec/testpool.jpg
View File

Binary file not shown.
Side by Side

Before

Width:  |  Height:  |  Size: 73 KiB