repo sync
m renode_clean renode
m qemu_clean qemu
Go to the following spreadsheet and write or select one's name under the DRI - Unit Test
.
Now you've signed up to develop a unit test for this vector instruction :)
Side Note: The following pivot table is very useful for quickly scanning through the instructions available: DRI Pivot Table
The easiest way to get started will be to look at a test that should be similar to the test one is planning to write.
These tests are located at:
cd ${ROOTDIR}/sw/vec/tests
Then change the names in the template to match one's current vector instruction of interest.
There is a demo test written in C++, which serves as a sample of the testing strategy, a convenient way to develop before making a macro version, as well as a place to debug and step through need be.
Demo test will look like the following:
TEST_F(VaddViTest, vadd_vi_demo) {
One possible workflow is to develop the demo test, then proceed through the following steps to make sure it builds and passes in Qemu(proceeding straight to the next step), and then developing the macro version and ensuring it builds/passes as well.
Note: To disable a demo test, prefix the test with DISABLED_
as shown:
TEST_F(VaddViTest, DISABLED_vadd_vi_demo) {
Edit the CmakeLists.txt (path follows):
${ROOTDIR}/sw/vec/tests/CMakeLists.txt
Include a new vec_cc_test
at the bottom of the file:
vec_cc_test( NAME vadd_test SRCS vadd_vi_test.cpp vadd_vx_test.cpp vadd_vv_test.cpp LINKOPTS -Xlinker --defsym=__itcm_length__=128K TIMEOUT 20 )
Name should be the root type of the test (e.g. as above vadd_test
which covers vadd.vi
, vadd.vx
, and vadd.vv
).
Sources to be included in the test go under the SRCS
section.
Note: Most tests will only need around 20 seconds and require less than 128K, but some tests may require more, we need to play this by ear.
Check and address any build errors:
m springbok
We‘re using Qemu as our baseline for out tests, unit tests should at minimum pass in Qemu. If a test passes in Qemu, and not in Renode (whose vector support is WIP), it may indicate a problem in Renode’s vector implementation.
cd
into the following directory:
${ROOTDIR}/out/springbok
Then use the following to start running through all of the tests from CMakeLists.txt
file earlier:
ctest --verbose -R qemu --gtest_color=yes
For convenience, one might include the building/testing in a single line:
cd ${OUT}/springbok && m springbok && ctest --verbose -R qemu --gtest_color=yes
Note: The -R
flag filters tests which match a regular expression, in this case we're filtering on qemu tests, but more specific filters are possble:
For example, if you had wanted only to test the vadd_tests
in qemu:
cd ${OUT}/springbok && m springbok && ctest --verbose -R qemu_vadd --gtest_color=yes
Renode tests won't necessarily pass, many of these are still in progress on the Antmicro side, but please do log success/fail of the Renode tests on the tracker:
ctest --verbose -R renode --gtest_color=yes
Running a specific test can be done (to save time), example below for the vadd_test
group:
ctest --verbose -R renode_vadd --gtest_color=yes
Note: at minimum, one's test should be expected to pass in Qemu. Since Renode vec support is WIP, a unit test failing may indicate problem in the Renode implementation.
On the unit test tracker:
When done testing, disable the demo test by prefixing the demo test name with “DISABLED_
”:
TEST_F(VaddViTest, DISABLED_vadd_vi_demo) {