LibraryTest

• Forming part of a larger test suite, each kernel has an associated test driver; the associated test driver implementation is housed in

  ${REPO_HOME}/src/test/${KERNEL}

  and built by providing

  ${REPO_HOME}/src/test/${KERNEL}/Makefile.in

  for the build system to include.

• For a given kernel, the test process is essentially:

  1. build the test driver, producing a test executable

     ${REPO_HOME}/build/${ARCH}/bin/test_${KERNEL}

  2. execute the test executable, an thereby generate a Python-based validation (meta-)program

     ${REPO_HOME}/build/${ARCH}/test/test_${KERNEL}.py

  3. execute the validation (meta-)program, producing output into

     ${REPO_HOME}/build/${ARCH}/test/test_${KERNEL}.log

     Essentially this means using Python (or appropriate library for it) as a test oracle if/where need be.

  The test strategy used depends on the kernel: some use randomised testing, whereas others fixed, hard-coded test vectors.

• Note that for the riscv and riscv-xcrypto target architectures, execution of the test executable implies simulation via a suitable version of Spike, i.e., either riscv/riscv-isa-sim or scarv/riscv-isa-sim, as supported by the proxy kernel.