The correctness of the simulator's results is directly linked to the
correctness of the instruction implementations: if the instructions are
not correct, then the results generated by the simulator are unreliable.
This software package, therefore, also contains an instruction implementation
test harness, test.py.
An example execution would be elucidative:
mkdir -p /tmp/nebula/test
python3 riscv/test.py \
--loop 5
--insns addi slli c.addi16sp \
-- \
10000 \
/opt/riscv/bin/riscv-unknown-elf-gcc
/tmp/nebula/test
The mkdir command just creates a location for all the artifacts of
the test harness's execution. The --loop parameter tells the test
harness that the tests it executes are to be performed 5 times apiece;
if this parameter is omitted, the tests are performed once.
The --insns parameter gives the instructions whose implementations
are to be tested; if this parameter is omitted, all of the instruction
implementations are tested. Finally, the last three parameters tell:
the network port to use, the location of the RISC-V cross compiler
(see: Sample Binaries),
and the location of the output directory, respectively.
The test harness creates a small assembly language program with randomly generated inputs, and the expected correct response. For instance, if the ADD instruction is being tested, and tne inputs to it are 2 and 3, then the expected correct output is 5. If the result returned by the Bergamot pipeline is different than 5, the test harness will halt and print the assembly program, as well as the expected result and the result returned by the Bergamot pipeline.
The problem causing the discrepancy may be either the simulator's implementation of the instruction, or the test harness's expected result. But if the two mismatch, that is a sign that further investigation needs to be done to indentify the cause of the discrepancy.