daiteq demo (RISC-V)
Overview
This project contains examples and simple programs for testing the functionality of daiteq FPU and SWAR extensions in the RISC-V CPU (with BSP for NOEL-V systems).
A specific toolchain and compiler is required for building the examples. It can be checked out with the following commands
$ riscv64-daiteq-elf-as --version $ clang --version
Directory structure
daiteq-demo |- examples - complex examples which can be executed in the QEMU emulator or in the board |- libs - libraries required for building the examples (BSP, libc, libm, ...) |- scripts - auxiliary python scripts for building tests and examples - simple - set of simple programs which test individual compiler features for RISC-V CPU with the daiteq extensions
Simple programs
Simple tests are placed in the directory simple. The directory contains a Makefile
so all tests can be built directly with the make command.
$ cd simple $ make
The building process creates the BUILD directory in the simple directory.
Each built test is placed in an individual subdirectory in the BUILD directory.
The directory contains all generated files. If all the compilation steps have finished
successfully, passed the directory also contains a file named done.
The directory contains an output for each step of the compilation, including the
internal files generated during compilation, and a file with an error output.
The directory contains the following files:
.ast - output of the clang compiler frontend *.bc - bitcode of the LLVM Intermediate Representation *.ll - human readable LLVM Intermediate Representation *.dis_ll - human readable LLVM Intermediate Representation disassembled from *.bc *.S - target assembler code - output of the compiler *.o - assembled target object file (from the *.S file using the target assembler) *.dis - disassembled code from the output object file (.o)
Examples
The directory examples contains complex programs which can be built for the target
board or for the QEMU emulator.
The directory contains a Makefile and a bash script for building programs which are
stored in individual subdirectories.
Before compilation of any example the libraries must be once initialised with script './libs/init.sh'. The script clones and patches 'newlib' library from a remote git repository.
The examples can be compiled with the Makefile in two ways. One is to use the bash
script and the recipe file with build configurations. An example of such a file is test_list.txt.
This file contains compilation of all the examples for several configurations.
The following commands start compilation from the recipe
$ cd examples $ ./test.sh build ./test_list.txt
The recipe file contains lines with settings, for example, which linker script is to be used, which compilation flags will be used, etc. Each line for each example contains three or more parametrs. The first parameter is the name of the example (name of the directory that contains the example). The second parameter is a user identification number which distinguishes compiled programs; it is useful if the same program is compiled many times with different build options. The third parameter is the selected daiFPU or SWAR configuration for which the is program built. All other parameters are used as compiler options. More detailed description of the recipe file syntax is included in 'test.sh' script.
The second way how to compile a program is a direct execution of the make tool.
$ cd examples $ make TEST= ID= FPUCFG= LDSCRIPT= UCFLAGS=''
Both ways create a directory BUILD that contains subdirectories named according to the selected daiFPU or SWAR configurations. The subdirectory contains compiled examples stored as ELF and DAT files. The compiled output is disassembled, and three log files are produced that contain a summary of hardware FPU instructions generated and soft-float functions called. There are also other subdirectories that contain object files compiled from the used libraries.
There are two files with recipes for all complex programs. The first file (test_list.txt) contains complex programs that test and demonstrate the use of the daiFPU floating-point unit. The second file (test_list_swar.txt) contains examples for testing the daiteq SWAR extension. All examples except the linpack program are compiled for 128KB or 256KB RAM, which is the standard memory size configured for the Virtex5 target in the LEON2FT version with the daiteq extensions. The linpack program does not fit in 256KB RAM, so it is compiled for 4MB RAM.