Giter VIP home page Giter VIP logo

riscv-tests's Introduction

riscv-tests

About

This repository hosts unit tests for RISC-V processors.

Building from repository

We assume that the RISCV environment variable is set to the RISC-V tools install path, and that the riscv-gnu-toolchain package is installed.

$ git clone https://github.com/riscv/riscv-tests
$ cd riscv-tests
$ git submodule update --init --recursive
$ autoconf
$ ./configure --prefix=$RISCV/target
$ make
$ make install

The rest of this document describes the format of test programs for the RISC-V architecture.

Test Virtual Machines

To allow maximum reuse of a given test, each test program is constrained to only use features of a given test virtual machine or TVM. A TVM hides differences between alternative implementations by defining:

  • The set of registers and instructions that can be used.
  • Which portions of memory can be accessed.
  • The way the test program starts and ends execution.
  • The way that test data is input.
  • The way that test results are output.

The following table shows the TVMs currently defined for RISC-V. All of these TVMs only support a single hardware thread.

TVM Name Description
rv32ui RV32 user-level, integer only
rv32si RV32 supervisor-level, integer only
rv64ui RV64 user-level, integer only
rv64uf RV64 user-level, integer and floating-point
rv64uv RV64 user-level, integer, floating-point, and vector
rv64si RV64 supervisor-level, integer only
rv64sv RV64 supervisor-level, integer and vector

A test program for RISC-V is written within a single assembly language file, which is passed through the C preprocessor, and all regular assembly directives can be used. An example test program is shown below. Each test program should first include the riscv_test.h header file, which defines the macros used by the TVM. The header file will have different contents depending on the target environment for which the test will be built. One of the goals of the various TVMs is to allow the same test program to be compiled and run on very different target environments yet still produce the same results. The following table shows the target environment currently defined.

Target Environment Name Description
p virtual memory is disabled, only core 0 boots up
pm virtual memory is disabled, all cores boot up
pt virtual memory is disabled, timer interrupt fires every 100 cycles
v virtual memory is enabled

Each test program must next specify for which TVM it is designed by including the appropriate TVM macro, RVTEST_RV64U in this example. This specification can change the way in which subsequent macros are interpreted, and supports a static check of the TVM functionality used by the program.

The test program will begin execution at the first instruction after RVTEST_CODE_BEGIN, and continue until execution reaches an RVTEST_PASS macro or the RVTEST_CODE_END macro, which is implicitly a success. A test can explicitly fail by invoking the RVTEST_FAIL macro.

The example program contains self-checking code to test the result of the add. However, self-checks rely on correct functioning of the processor instructions used to implement the self check (e.g., the branch) and so cannot be the only testing strategy.

All tests should also contain a test data section, delimited by RVTEST_DATA_BEGIN and RVTEST_DATA_END. There is no alignment guarantee for the start of the test data section, so regular assembler alignment instructions should be used to ensure desired alignment of data values. This region of memory will be captured at the end of the test to act as a signature from the test. The signature can be compared with that from a run on the golden model.

Any given test environment for running tests should also include a timeout facility, which will class a test as failing if it does not successfully complete a test within a reasonable time bound.

#include "riscv_test.h"

RVTEST_RV64U        # Define TVM used by program.

# Test code region.
RVTEST_CODE_BEGIN   # Start of test code.
        lw      x2, testdata
        addi    x2, 1         # Should be 42 into $2.
        sw      x2, result    # Store result into memory overwriting 1s.
        li      x3, 42        # Desired result.
        bne     x2, x3, fail  # Fail out if doesn't match.
        RVTEST_PASS           # Signal success.
fail:
        RVTEST_FAIL
RVTEST_CODE_END     # End of test code.

# Input data section.
# This section is optional, and this data is NOT saved in the output.
.data
        .align 3
testdata:
        .dword 41

# Output data section.
RVTEST_DATA_BEGIN   # Start of test output data region.
        .align 3
result:
        .dword -1
RVTEST_DATA_END     # End of test output data region.

User-Level TVMs

Test programs for the rv32u* and rv64u* TVMs can contain all instructions from the respective base user-level ISA (RV32 or RV64), except for those with the SYSTEM major opcode (syscall, break, rdcycle, rdtime, rdinstret). All user registers (pc, x0-x31, f0-f31, fsr) can be accessed.

The rv32ui and rv64ui TVMs are integer-only subsets of rv32u and rv64u respectively. These subsets can not use any floating-point instructions (major opcodes: LOAD-FP, STORE-FP, MADD, MSUB, NMSUB, NMADD, OP-FP), and hence cannot access the floating-point register state (f0-f31 and fsr). The integer-only TVMs are useful for initial processor bringup and to test simpler implementations that lack a hardware FPU.

Note that any rv32ui test program is also valid for the rv32u TVM, and similarly rv64ui is a strict subset of rv64u. To allow a given test to run on the widest possible set of implementations, it is desirable to write any given test to run on the smallest or least capable TVM possible. For example, any simple tests of integer functionality should be written for the rv64ui TVM, as the same test can then be run on RV64 implementations with or without a hardware FPU. As another example, all tests for these base user-level TVMs will also be valid for more advanced processors with instruction-set extensions.

At the start of execution, the values of all registers are undefined. All branch and jump destinations must be to labels within the test code region of the assembler source file. The code and data sections will be relocated differently for the various implementations of the test environment, and so test program results shall not depend on absolute addresses of instructions or data memory. The test build environment should support randomization of the section relocation to provide better coverage and to ensure test signatures do not contain absolute addresses.

Supervisor-Level TVMs

The supervisor-level TVMs allow testing of supervisor-level state and instructions. As with the user-level TVMs, we provide integer-only supervisor-level TVMs indicated with a trailing i.

History and Acknowledgements

This style of test virtual machine originated with the T0 (Torrent-0) vector microprocessor project at UC Berkeley and ICSI, begun in 1992. The main developers of this test strategy were Krste Asanovic and David Johnson. A precursor to torture was rantor developed by Phil Kohn at ICSI.

A variant of this testing approach was also used for the Scale vector-thread processor at MIT, begun in 2000. Ronny Krashinsky and Christopher Batten were the principal architects of the Scale chip. Jeffrey Cohen and Mark Hampton developed a version of torture capable of generating vector-thread code.

riscv-tests's People

Contributors

aap-sc avatar aswaterman avatar ccelio avatar cgsfv avatar chihminchao avatar colinschmidt avatar daniellustig avatar en-sc avatar hcook avatar ingallsj avatar jerryz123 avatar lz-bro avatar marekvcodasip avatar mohanson avatar mwachs5 avatar neelgala avatar palmer-dabbelt avatar pdonahue-ventana avatar qmn avatar richardxia avatar rogerchang23424 avatar sdtwigg avatar srivatsa611y avatar takahirox avatar timsifive avatar tommymurphytm1234 avatar wren6991 avatar yenhaochen avatar yunsup avatar zhemao avatar

Stargazers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

Watchers

 avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar  avatar

riscv-tests's Issues

./gdbserver.py --spike64 --cmd $RISCV/bin/spike fails

I am missing module 'pexpect' when I invoke the following.

./gdbserver.py --spike64 --cmd $RISCV/bin/spike

testlib.py line 9 can not import 'pexpect'. FWIW, I could not find pexpect.* in my RISCV installation.

debug: Additional Test Suggestion

Can we add a test which targets the priorities in DCSR.cause? Add a breakpoint on an 'ebreak' instruction that we single-step to, and so on?

Error compiling from architecture RV64IMA

I use this instruction for compilation :
riscv64-unknown-elf-gcc -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/../env -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/common -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/median -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/16math -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/16switch -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/16switchcase -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/32math -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/8math -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/8switch -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/8switchcase -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/fir -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/floatingpointmath -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/matrixmulti -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/qsort -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/rsort -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/towers -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/vvadd -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/multiply -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/mm -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/dhrystone -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/spmv -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/mt-vvadd -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/mt-matmul -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/pmp -DPREALLOCATE=1 -mcmodel=medany -march=rv64ima -mabi=lp64 -static -std=gnu99 -O2 -ffast-math -fno-common -fno-builtin-printf -o median.riscv /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/median/median_main.c /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/median/median.c /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/common/syscalls.c /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/common/crt.S -static -nostdlib -nostartfiles -lm -lgcc -T /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/common/test.ld

but I recieved this error :
configure: WARNING: using cross tools not prefixed with host triplet
Building project riscv-tests
/tmp/ccs1G48s.o: In function dmul': median_main.c:(.text+0x8): undefined reference to __muldf3'
collect2: error: ld returned 1 exit status
make[1]: *** [median.riscv] Error 1
make: *** [benchmarks] Error 2

Running tests, spike or qemu ?

I apologise in advance if this sounds a dumb question.

Having successfully built the tools, and the simulator.
How can I run the ISA tests on a reference simulator ?

For example if I want to run the executable
build/isa/rv32ui-p-add
how should I do this

I tried
spike -d build/isa/rv32ui-p-add
but saw an exception error for illegal instruction

core   0: 0xffffffff80000074 (0x3b029073) csrw    pmpaddr0, t0
core   0: exception trap_illegal_instruction, epc 0xffffffff80000074
core   0:           badaddr 0x0000000000000000

in essence I want to run the ISA tests to get disassembly and register dumping from the golden reference

Thx
E

Index of CSR misa in tests is wrong

Watching dump for rv32mi-p-mcsr, instruction 800000c8 <test_2>:
800000c8: 30102573 csrr a0,misa
Bytecode for csr is supposed to be misa, but it equals 0b001100000001 = 0x301
misa offest for v1.9 is 0xF10, 0x301 does not exist in v1.9, for v1.7, 0x301 is offset for mtvec csr.

Are tests or compiler outdated?

separate make target for running debug tests?

We probably should keep it so that make only builds the tests, and make check executes them. Main reason is to speed up building the tools, which is a significant bottleneck for regression testing.

debug: server_timeout_sec is ignored

There is a variable server_timeout_sec inside targets.py. This used to actually do something (namely, not time out waiting for the server to be ready for GDB connections). But this code apparently was removed, and this variable is no longer used for anything. This means that slow running targets (e.g. simulators) fail the tests.

undefined reference to __modsi3

riscv64-unknown-elf-gcc -I./../env -I./common -I./median -I./qsort -I./rsort -I./towers -I./vvadd -I./multiply -I./mm -I./dhrystone -I./spmv -I./mt-vvadd -I./mt-matmul -I./pmp -DPREALLOCATE=1 -mcmodel=medany -static -std=gnu99 -O2 -fno-common -fno-builtin-printf -march=rv32i -mabi=ilp32 -static -nostdlib -nostartfiles -lgcc -T ./common/test.ld -o median.riscv ./median/median_main.c ./median/median.c ./common/syscalls.c ./common/crt.S
/tmp/ccc310MB.o: In function .L47': syscalls.c:(.text+0x12c): undefined reference to __umodsi3'
/tmp/ccc310MB.o: In function .L56': syscalls.c:(.text+0x154): undefined reference to __udivsi3'
syscalls.c:(.text+0x164): undefined reference to `__umodsi3'
collect2: error: ld returned 1 exit status
Makefile:54: recipe for target 'median.riscv' failed
make: *** [median.riscv] Error 1

updated env breaks testing

I accidentally committed a change to env in change 1d30772. This is breaking the spike breadth tests for reasons that I don't understand. Once I figure out how to undo that I will, later tonight.

I still don't understand git submodules and specifically what touches env well enough to really make sense of this.

Error compiling from architecture RV64IMA

Tried to compile som fir becnhmark test and with this instruction :
riscv64-unknown-elf-gcc -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/../env -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/common -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/median -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/16math -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/16switch -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/16switchcase -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/32math -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/8math -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/8switch -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/8switchcase -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/fir -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/floatingpointmath -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/matrixmulti -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/qsort -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/rsort -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/towers -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/vvadd -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/multiply -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/mm -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/dhrystone -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/spmv -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/mt-vvadd -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/mt-matmul -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/pmp -DPREALLOCATE=1 -mcmodel=medany -march=rv64ima -mabi=lp64 -static -std=gnu99 -O2 -ffast-math -fno-common -fno-builtin-printf -o fir.riscv /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/fir/fir.c /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/common/syscalls.c /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/common/crt.S -static -nostdlib -nostartfiles -lm -lgcc -T /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/common/test.ld

and I got this error:
/tmp/cc4S73gG.o: In function .L8': fir.c:(.text.startup+0xac): undefined reference to __floatunsisf'
/tmp/cc4S73gG.o: In function .L3': fir.c:(.text.startup+0xb8): undefined reference to __mulsf3'
fir.c:(.text.startup+0xc4): undefined reference to __addsf3' fir.c:(.text.startup+0xdc): undefined reference to __floatunsisf'
fir.c:(.text.startup+0xec): undefined reference to __mulsf3' fir.c:(.text.startup+0xf8): undefined reference to __addsf3'
collect2: error: ld returned 1 exit status
make[1]: *** [fir.riscv] Error 1
make: *** [benchmarks] Error 2

debug: Simulation targets .cfg files are wrong

For a simulation target, OpenOCD needs to use remote-bitbang or jtag_vpi interface. Currently the sim targets are set to use Freedom.cfg, which has hard-coded the FTDI interface.

Rather than fixing these, perhaps the CFG and Target files should just be the responsibility of the repository which actually knows how to run a simulation, and the VCS simulation targets can be removed here. Unless these targets are added to a regression here they will keep getting broken.

Error: Instruction csrr requires absolute expression

Hi. I'm trying to build the tests, but i'm getting the following error (using master branch of this repo):

home/angelterrones/Sources/RISCV/riscv-tests/benchmarks/common/syscalls.c: Assembler messages:
/home/angelterrones/Sources/RISCV/riscv-tests/benchmarks/common/syscalls.c:57: Error: Instruction csrr requires absolute expression
/home/angelterrones/Sources/RISCV/riscv-tests/benchmarks/common/syscalls.c:57: Error: Instruction csrr requires absolute expression
/home/angelterrones/Sources/RISCV/riscv-tests/benchmarks/Makefile:83: recipe for target 'syscalls.o' failed
make[1]: *** [syscalls.o] Error 1
make[1]: Leaving directory '/home/angelterrones/Sources/RISCV/riscv-tests/benchmarks'
Makefile:16: recipe for target 'benchmarks' failed
make: *** [benchmarks] Error 2

I have updated the riscv-tools following the instructions from the main repo (fresh clone):

$ git submodule update --init --recursive
$ export RISCV=/path/to/install/riscv/toolchain
$ ./build.sh

Thanks.

how to printf float?

I want to run CoreMark. But printf(" the score = %f", score) output the score = %f, not the score(float type). Does system_call support to print float?
Looking for your reply ,thanks a lot!

debug: --32 and --64 arguments seem ignored

IN gdbserver.py, there are arguments for the command line, --32 and --64, which are supposed to allow knowing the XLEN, used for the GDB set arch command. But all they do is set target.xlen, but it is hart.xlen which is used for everything. In addition, $misa is read anyway and XLEN is determined from that.

This doesn't show up in the tests under regression because those have separate Hart subclasses which all specify their xlen explicitly.

So what is the point of the command line argument? What is the expected relationship between the command line argument, the xlen value that the hart subclasses specify, and the $misa value determined during ExamineTarget?

The fmin test is expecting the wrong result for FMAX instruction when one input is sNAN another one is common value

@aswaterman

Hi, Andrew

I noticed you have updated the riscv-tests/isa/rv64uf/fmin.S in the latest version as below:

FMIN(sNaN, x) = x

TEST_FP_OP2_S(20, fmax.s, 0x10, 1.0, sNaNf, 1.0);

Means, you expect the result is x if the input is a sNaN and x. This seems is not correct, because we can see from the the ISA Spec, it is clearlly stating:

"For FMIN and FMAX, if at least one input is a signaling NaN, or if both inputs are quiet NaNs,
the result is the canonical NaN. " --------------------- So the expected result should be sNaN, rather than the x....

And I even noticed you actually set the correct expecation in the previous version, but just changed it to this wrong style in latest version, is there any reason why you did it in this way?

I just tried to use spike to run this test, and I found the spike is also printint the wrong result, so does it means the Spike also implemented it in the wrong style, which is also mismatch with the spec?

Thanks
Bob

incorrect overflow test on isa/rv32um/div.S

Hi

I thought I would mention that there may be a mistake in this test.
when running the tests on 32 / 64 bit, I only see an overflow issue on the 64 bit test, not the 32bit test
I think there is an error here

TEST_RR_OP( 6, div, -1<<63, -1<<63, 1 );
TEST_RR_OP( 7, div, -1<<63, -1<<63, -1 );

I am guessing the shift should be 31, not 63 ?

E

Are tests meant to test RISCV v1.7?

Watching rv32ui-p-simple with objdump, instruction in _0x200 <start>: csrr a0,mhartid is said to read from mhartid register, but bitecode for csr index is 0xF10.

In RISCV v1.7 manual it is index for mhartid, but for v1.9 manual mhartid index is now 0xF14 instead, 0xF10 is for misa reg now.

Are these tests still compiling with gcc for v1.7?

I have the latest pulls for all your reps

TriggerLoadAddress read watch breakpoint issue

I am trying to run debug tests in simulation mode on ROCKET-CHIP in Redhat linux machine.

When I am setting a read watch breakpoint as mentioned in "TriggerLoadAddress" test as mentioned below

(gdb) rwatch *((&data)+1)
Hardware read watchpoint 3: *((&data)+1)

I am getting the following error,
(gdb) c
Continuing.
keep_alive() was not invoked in the 1000ms timelimit. GDB alive packet not sent! (2943). Workaround: increase "set remotetimeout" in GDB
"dbus_scan failed jtag scan
Timed out waiting for debug int to clear.
Debug interrupt didn't clear"

Are all the debug tests work on ROCKET-CHIP hardware in simulation mode or is there anything I am missing in my environment.

Load and Store operations semantics is not clear

Ex., test rv32ui-p-sh, section 800001c4 < test_9 >:

800001c4:   00002097            auipc   ra,0x2
800001c8:   e4a08093            addi    ra,ra,-438 # 8000200e <tdat8>
800001cc:   ffffa137            lui sp,0xffffa
800001d0:   00a10113            addi    sp,sp,10 # ffffa00a <_end+0x7fff7fea>
800001d4:   00209023            sh  sp,0(ra)
800001d8:   00009183            lh  gp,0(ra)
800001dc:   ffffaeb7            lui t4,0xffffa
800001e0:   00ae8e93            addi    t4,t4,10 # ffffa00a <_end+0x7fff7fea>
800001e4:   00900e13            li  t3,9
800001e8:   35d19663            bne gp,t4,80000534 <fail>

Test supposed to store 16 lower bits of 0xffffa00a to memory (which is 0xa00a) as it is said in your manual:
The SW, SH, and SB instructions store 32-bit, 16-bit, and 8-bit values from the low bits of register rs2 to memory.

Then test supposed to load 16-bit value from memory, which is the same 0xa00a, but then test checks the value for ffffa00a.

Why is that?

What's the difference between benchmark qsort and rsort ?

introduction is the same, but code is different, as well as trace and cfg.
can someone explain the programming idea of rsort ?

//**************************************************************************
// Quicksort benchmark
//--------------------------------------------------------------------------
//
// This benchmark uses quicksort to sort an array of integers. The
// implementation is largely adapted from Numerical Recipes for C. The
// input data (and reference data) should be generated using the
// qsort_gendata.pl perl script and dumped to a file named
// dataset1.h The smips-gcc toolchain does not support system calls
// so printf's can only be used on a host system, not on the smips
// processor simulator itself. You should not change anything except
// the HOST_DEBUG and PREALLOCATE macros for your timing run.

Running Virtual Memory tests on Spike

Hi All,

I am trying to run the -v- tests on spike, but I am getting unexpected behavior, so for example

spike -l --pc=0x80000000 --isa=RV32IMAFD riscv-tests/isa/rv32ui-v-addi

this does not seem to do what I expect.
At the point where the sret is called I get the following

core   0: 0xffffffff800000c0 (0x10200073) sret
core   0: exception trap_instruction_access_fault, epc 0x00000000000029e8
core   0:           badaddr 0x00000000000029e8
core   0: 0x00000000ffc000c4 (0x00000000) addi    s0, sp, 0
core   0: exception trap_illegal_instruction, epc 0x00000000ffc000c4
core   0:           badaddr 0x0000000000000000
core   0: 0x0000000080000008 (0x2600206f) j       pc + 0x2260

this then ends up in a loop, and eventrually ends with

core   0: 0xffffffff8000224c (0x00f76733) or      a4, a4, a5
3 0xffffffff8000224c (0x00f76733) x14 0x0000000000000000
core   0: 0xffffffff80002250 (0xfe070ae3) beqz    a4, pc - 12
3 0xffffffff80002250 (0xfe070ae3)
*** FAILED *** (tohost = 420)

I presume I am configuring spike incorrectly, as the tests are built simpy by configure/make

Is there a procedure I can follow which describes

  1. The building of the conformance tests
  2. Execution of the tests on spike to validate the tests operate correctly

Many Thx
Lee

Compilation failure for sb test

After updating to the latest commit of riscv-tests, I get the following compilation failure.

riscv64-unknown-elf-gcc  -DENTROPY=188850 -static -mcmodel=medany -fvisibility=hidden -nostdlib -nostartfiles -std=gnu99 -O2 -I./../env/v -I./macros/scalar -T./../env/v/link.ld ./../env/v/entry.S ./../env/v/vm.c rv64ui/sb.S -lc -o rv64ui-v-sb
rv64ui/sb.S: Assembler messages:
rv64ui/sb.S:63: Error: illegal operands `la x1,0xffffffffffffffdd'
rv64ui/sb.S:64: Error: illegal operands `la x1,0xffffffffffffffcd'
rv64ui/sb.S:65: Error: illegal operands `la x1,0xffffffffffffffcc'
rv64ui/sb.S:66: Error: illegal operands `la x1,0xffffffffffffffbc'
rv64ui/sb.S:67: Error: illegal operands `la x1,0xffffffffffffffbb'
rv64ui/sb.S:68: Error: illegal operands `la x1,0xffffffffffffffab'
rv64ui/sb.S:70: Error: illegal operands `la x1,0x33'
rv64ui/sb.S:71: Error: illegal operands `la x1,0x23'
rv64ui/sb.S:72: Error: illegal operands `la x1,0x22'
rv64ui/sb.S:73: Error: illegal operands `la x1,0x12'
rv64ui/sb.S:74: Error: illegal operands `la x1,0x11'
rv64ui/sb.S:75: Error: illegal operands `la x1,0x01'

I've already tried updating my compiler, but I still get this error message.

ISA tests for 32-bit double-precision (e.g. rv32ud)

I noticed that there is no ISA test for the 32-bit implementation with hardware double-precision support (e.g rv32ud, while both rv32uf and rv64ud exist - why? RV32D is an extension that is listed in the ISA spec, so it would only be natural that it also should have unit tests?

If there are no currently existing tests or plans to release such tests I will have to make them myself, but I'm not fully confident that I would be able to fully exercise the ISE and all edge cases so having official ones would be of great help (a few of the rv64ud tests seem to work as is though).

"Error: value of N too large for field" errors on macOS Sierra

I tried to build on macOS Sierra today with an updated GNU toolchain (all other RISC-V code was from riscv/homebrew-riscv) and I got this error:

riscv64-unknown-elf-gcc -march=rv32g -mabi=ilp32 -static -mcmodel=medany -fvisibility=hidden -nostdlib -nostartfiles -I/Users/brettcannon/Repositories/harmony/riscv-tests/isa/../env/p -I/Users/brettcannon/Repositories/harmony/riscv-tests/isa/macros/scalar -T/Users/brettcannon/Repositories/harmony/riscv-tests/isa/../env/p/link.ld rv32ui/sll.S -o rv32ui-p-sll
rv32ui/../rv64ui/sll.S: Assembler messages:
rv32ui/../rv64ui/sll.S:34: Error: value of 71144870016 too large for field of 4 bytes at 568
rv32ui/../rv64ui/sll.S:34: Error: value of 71144870016 too large for field of 4 bytes at 572
rv32ui/../rv64ui/sll.S:35: Error: value of 9106543362048 too large for field of 4 bytes at 600
rv32ui/../rv64ui/sll.S:36: Error: value of 1193612851550355456 too large for field of 4 bytes at 628
rv32ui/../rv64ui/sll.S:42: Error: value of 71144870016 too large for field of 4 bytes at 720
rv32ui/../rv64ui/sll.S:42: Error: value of 71144870016 too large for field of 4 bytes at 724
rv32ui/../rv64ui/sll.S:43: Error: value of 9106543362048 too large for field of 4 bytes at 752
make[1]: *** [rv32ui-p-sll] Error 1
make: *** [isa] Error 2

Is this something broken on my machine or is this a bug while running under macOS?

Issues building ISA tests

When running make isa, I get the following error when it tries to build rv64ui-v-add.

make[1]: Entering directory '/home/zhehao/programs/research/zscale-chip/riscv-tests/build'
riscv64-unknown-elf-gcc  -static -fpic -fvisibility=hidden -nostdlib -nostartfiles -Wa,-march=RVIMAFDXhwacha -std=gnu99 -O2 -I/home/zhehao/programs/research/zscale-chip/riscv-tests/build/../isa/../env/v -I/home/zhehao/programs/research/zscale-chip/riscv-tests/build/../isa/macros/scalar -T/home/zhehao/programs/research/zscale-chip/riscv-tests/build/../isa/../env/v/link.ld /home/zhehao/programs/research/zscale-chip/riscv-tests/build/../isa/../env/v/entry.S /home/zhehao/programs/research/zscale-chip/riscv-tests/build/../isa/../env/v/vm.c /home/zhehao/programs/research/zscale-chip/riscv-tests/build/../isa/rv64ui/add.S -lc -o rv64ui-v-add
/tmp/ccC3ITMu.s: Assembler messages:
/tmp/ccC3ITMu.s:368: Error: illegal operands `jump pop_tf@'
/home/zhehao/programs/research/zscale-chip/riscv-tests/build/../isa/Makefile:84: recipe for target 'rv64ui-v-add' failed
make[1]: *** [rv64ui-v-add] Error 1

dhrystone

I tried to compile dhrystone for 32 bits with:
riscv32-unknown-elf-gcc -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/ri
scv-tools/riscv-tests/build/../benchmarks/../env -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/common -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/median -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/qsort -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/rsort -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/towers -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/vvadd -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/multiply -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/mm -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/dhrystone -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/spmv -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/mt-vvadd -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/mt-matmul -I/home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/pmp -DPREALLOCATE=1 -mcmodel=medany -static -std=gnu99 -O2 -ffast-math -fno-common -fno-builtin-printf -static -nostdlib -nostartfiles -lgcc -T /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/common/test.ld -o dhrystone.riscv /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/dhrystone/dhrystone.c /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/dhrystone/dhrystone_main.c /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/common/syscalls.c /home/edgar/Desktop/RISCV_FOLDERS/rocket-chip/riscv-tools/riscv-tests/build/../benchmarks/common/crt.S

But faiol and say me i have this error:
/tmp/cckATb8W.o: In function .L47': syscalls.c:(.text+0x13c): undefined reference to __umoddi3'
/tmp/cckATb8W.o: In function .L58': syscalls.c:(.text+0x168): undefined reference to __udivdi3'
syscalls.c:(.text+0x180): undefined reference to `__umoddi3'
collect2: error: ld returned 1 exit status

isa tests does not have start instructions

Correct me if I'm wrong, but i cloned this repo and built tests using your toolchain.
But some found some issues:

  1. riscv-qemu faults running these tests (segfault or memory allocation fault). Followed the instruction on your site
  2. starting pc in the test header (ex., rv32(64)mi-p-csr) is set to 80002000, but there is no code in this place (section .tohost)
    Can you explain me how to fix this?

How do I use Debug Test for Rocket-Chip core in simulation

There are two targets in simulation (freedom-e300-sim and freedom-u500-sim) https://github.com/riscv/riscv-tests/tree/master/debug

What about testing debug for default rocket chip in simulation?

I have a try as described below:

1. Add WithJtagDTM to Rocket Chip default configuration:

appending code as following to rocket-chip/src/main/scala/rocketchip/Configs.scala, witch I copy from https://github.com/sifive/freedom/blob/master/src/main/scala/unleashed/u500vc707devkit/Configs.scala#L9

class DefaultFreedomUConfig extends Config(
  new WithJtagDTM ++ new BaseConfig
)

2. Build the VCS simulator with DefaultFreedomUConfig configuration:

$ make CONFIG=DefaultFreedomUConfig

3. Run Debug Test:

I have built riscv tools using 64 bits, so I use freedom-u500-sim target.
$ python2.7 gdbserver.py --freedom-u500-sim --run rocket-chip/vsim/simv-rocketchip-DefaultFreedomUConfig

I found that it runs into infinite loop in testlib.VcsSim

        while not done:
            line = listenfile.readline()
            if not line:
                time.sleep(1)
            match = re.match(r"^Listening on port (\d+)$", line)
            if match:
                done = True
                self.port = int(match.group(1))
                os.environ['JTAG_VPI_PORT'] = str(self.port)

In simv.log:

+ rocket-chip/vsim/simv-rocketchip-DefaultFreedomUConfig +jtag_vpi_enable
Chronologic VCS simulator copyright 1991-2014
Contains Synopsys proprietary information.
Compiler version I-2014.03_Full64; Runtime version I-2014.03_Full64;  Dec 29 07:55 2016

I think that simv-rocketchip-DefaultFreedomUConfig never output strings like "Listening on port", so it would be in infinite loop.

I wonder if I missing some arguments in $ python2.7 gdbserver.py --freedom-u500-sim --run rocket-chip/vsim/simv-rocketchip-DefaultFreedomUConfig or simv-rocketchip-DefaultFreedomUConfig maybe take a long time so I just wait for it?

debug: "Timeout Exceeded" message in postMortemException

the gdbserver log file on a failure makes no sense to me. The error in this case was that I forgot to define hart.ram, so the error that makes sense is

    addrB = self.hart.ram + self.hart.ram_size - size
TypeError: unsupported operand type(s) for +: 'NoneType' and 'NoneType'

But I get this Timeout exceeded. message in the postMortem Exception log

This might just be user misunderstanding, but what is the point of postMortem Exception log? Why is a timeout reported when the error was pretty clear from the Python execution?

Test: MemTest64
Target: RocketSim
STARTING A SIMULATION
/scratch/megan/federation/rocket-chip/emulator/emulator-freechips.rocketchip.system-WithJtagDTMSystem_DefaultRV32Config-debug +verbose -v regression32.vcd dummybin | tee emulator.log
Waiting for OpenOCD to start...
--------------------------------[ Traceback ]---------------------------------
Traceback (most recent call last):
  File "/scratch/megan/federation/rocket-chip/riscv-tools/riscv-tests/debug/testlib.py", line 737, in run
    result = self.test()    # pylint: disable=no-member
  File "/scratch/megan/federation/rocket-chip/riscv-tools/riscv-tests/debug/gdbserver.py", line 156, in test
    self.access_test(8, 'long long')
  File "/scratch/megan/federation/rocket-chip/riscv-tools/riscv-tests/debug/gdbserver.py", line 136, in access_test
    addrB = self.hart.ram + self.hart.ram_size - size
TypeError: unsupported operand type(s) for +: 'NoneType' and 'NoneType'
---------------------------[ postMortem Exception ]---------------------------
Timeout exceeded.
...

debug: priv tests are disabled

Commit 22576f7 disabled the test coverage for the virtual priv register.

These need to be re-enabled. I'm under the impression that it works, but if not then OpenOCD needs to be fixed.

Build fails with ImportError: No module named spike64

Tried to install RISC-V Tests on a new VM and got an error during install. Error text reads:

Traceback (most recent call last): File "/opt/riscv-tools/riscv-tests/build/../debug/gdbserver.py", line 787, in <module> sys.exit(main()) File "/opt/riscv-tools/riscv-tests/build/../debug/gdbserver.py", line 772, in main target = targets.target(parsed) File "/opt/riscv-tools/riscv-tests/debug/targets.py", line 136, in target module = importlib.import_module(module_name) File "/usr/lib/python2.7/importlib/__init__.py", line 37, in import_module __import__(name) ImportError: No module named spike64

Any ideas?

fmin sNaN propagation

Hi
I have noted that the behavior of the sNaN propagation as per the test for rv64uf-p-fmin has changed since the release of v2.2 of the ISA Specification
In the 2.2 spec an sNaN on any input of FMIN/FMAX should generate a canonical NaN
This is no longer the expectaion with either the current test or spike.

In order to have a set of tests and a version of spike which reflects the specification as per 2.2, how is this to be done ?
as far as I can see there are no 'releases' bound to the version of the ISA, I would like to have a set of tests and golden reference simulator which matches the 2.2 spec.

Thx
Lee

Missing stuff for init.c

I've written a RISC-V simulator, and I wanted to run the available stress tests. I started here with riscv-tests. I ran ./configure with the latest SiFive SDK for macOS (the git master for RISC-V GCC fails to build from source in my macOS). It seemed to compile successfully. The repo readme doesn't have info on how to run the tests, so I started poking around and tried to make debug-check. That procedure involves compiling some C source files, including programs/init.c. That C source file includes init.h, which I can't find anywhere. Can you please provide more information on how to find the required dependencies?

debug: `assert threads` failure

I am running riscv-tests against a simulator, and get an assertion failure after GDB attempts to do info threads. If I run everything manually, everything works fine, but I am suspicious that it may be attempting to do info threads before GDB has finished connecting to OpenOCD. However, with this error, no GDB log is generated so it is hard to debug.

What timeout/handshake is used to ensure that info threads is not called before GDB finishes connecting to OpenOCD?

Also the code which printed the temporary GDB file paths to the stdout has been removed, which makes it impossible to monitor the progress of the tests on a simulation.

Recommend Projects

  • React photo React

    A declarative, efficient, and flexible JavaScript library for building user interfaces.

  • Vue.js photo Vue.js

    🖖 Vue.js is a progressive, incrementally-adoptable JavaScript framework for building UI on the web.

  • Typescript photo Typescript

    TypeScript is a superset of JavaScript that compiles to clean JavaScript output.

  • TensorFlow photo TensorFlow

    An Open Source Machine Learning Framework for Everyone

  • Django photo Django

    The Web framework for perfectionists with deadlines.

  • D3 photo D3

    Bring data to life with SVG, Canvas and HTML. 📊📈🎉

Recommend Topics

  • javascript

    JavaScript (JS) is a lightweight interpreted programming language with first-class functions.

  • web

    Some thing interesting about web. New door for the world.

  • server

    A server is a program made to process requests and deliver data to clients.

  • Machine learning

    Machine learning is a way of modeling and interpreting data that allows a piece of software to respond intelligently.

  • Game

    Some thing interesting about game, make everyone happy.

Recommend Org

  • Facebook photo Facebook

    We are working to build community through open source technology. NB: members must have two-factor auth.

  • Microsoft photo Microsoft

    Open source projects and samples from Microsoft.

  • Google photo Google

    Google ❤️ Open Source for everyone.

  • D3 photo D3

    Data-Driven Documents codes.