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

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

In riscv-tools/regression.sh, there is a line to test spike+benchmarks.
make -C ${base_dir}/riscv-tests/benchmarks/ run-riscv
And this task is missing now.

Is riscv-tests installation depends on 64-bit toolchain?

how to install for 32-bit toolchain?

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?

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

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.

Those instructions are listed in the Risc-V spec 2.0 as part of the RV32I Base Instruction Set but I can't find them in riscv-tests

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.

The current privileged spec (1.10) says that medeleg and mideleg should not exist on systems with only M-mode. But the M-mode tests (rv32mi and rv64mi) are accessing them anyway.

What kind of test runs the mm benchmark?

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.

Fixed in #26

I do not think the temporary GDB log files are actually getting created:

Temporary logs: simv.log, /tmp/openocdd0LJbx.log, /tmp/[email protected], /tmp/[email protected]
[ComplianceAndPassTest] pass in 434.44s
:::::::::::::::::::::::::::[ ran 1 tests in 434s ]::::::::::::::::::::::::::::
1 tests returned pass

less /tmp/[email protected]
/tmp/[email protected]: No such file or directory

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

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

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

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.

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

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!

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?

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

As far as I can tell, the ma_fetch.S test doesn't test JAL or branch instructions, only JALR.

This may be vestigial from Ye Olde RISC-V in which the target instruction was the faulting instruction, but now it is the control-flow instruction that faults.

Found by way of: https://github.com/ucb-bar/riscv-boom/issues/32

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?

TL;DR: The illegal test does not appear to check the badaddr/mtval CSR on an illegal instruction.

As far as I can tell, the accepted values are either 0x0 or the XLEN bits of the instruction. It'd be a nice sanity check to see that valid behavior is being exercised. As oppose to just shoving in the PC.

This just bit me in updating to the latest Priv 1.10 specification.
https://github.com/ucb-bar/riscv-boom/issues/45

It might be useful to define the elf entry point as "_start" in the linker script here:

https://github.com/riscv/riscv-test-env/blob/ce70afbf50a203be04bc326326cfa75831fe7f5d/p/link.ld

Some simulator (e.g. gem5) starts execution from the entry point. If not the entry point not defined, I think the default is the .text section? That won't work for asm tests.

So maybe add this line to the linker script?

ENTRY( _start )

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?

The gdbserver.py requires some non-standard Python packages, notably pexpect. Can we add a requirements.txt file to aid in automated testing with gdbserver?
@timsifive

Currently the timeout for OpenOCD to report that it is ready for GDB connections is hard-coded to 60 seconds. This should be a parameter. For a simulation target this is way too short.

@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

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

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.

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?

It was commented out in #90

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?

EBREAK and ECALL set EPC register to the address of the EBREAK/ECALL instruction, per the Privileged Specification v1.11.

The rv64si/sbreak.S test only checks the cause register, not the epc register.

Looks like I've been called out: https://github.com/ucb-bar/riscv-boom/issues/39

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?

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.

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

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

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?

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.

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.

riscv-tests/isa/rv32mi/../rv64mi/ipi.S:30: Error: Instruction csrwi requires absolute expression
make[1]: *** [rv32mi-pm-ipi] error 1

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

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.

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.

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?

Since bad shift amounts became errors and not warnings: riscvarchive/riscv-binutils-gdb@78cca1e

rv32mi/shamt.S: Assembler messages:                                                                                                              $(eval $(call compile_template,rv64sv,-march=rv64g -Wa$(comma)-march=rv64gxhwacha -mabi=lp64))
rv32mi/shamt.S:20: Error: Improper shift amount (32)  

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.