Legup Wiki

Quartus II – Used to make changes to the Hardware in SOPC buidler, generate simulation files, compiling and generating .sof to program

NiosII IDE – Used to create the memory intialization files (i.e. sdram.dat, onchip_mem.hex) and run the testing platform (i.e. ModelSim or Board)

ModelSim-Altera or ModelSim SE – Used to simulate the design (ModelSim-Altera is unbearably slow)

DE2 Board – Using the DE2 is 20~30x faster than ModelSim and the results deviate by a very acceptable amount (almost identical as seen in benchmark results)

Source Files – Get the source files from http://www.legup.org/hwprofile/NiosII/NiosIISource.rar (contain all required projects set up)

For the table of results, go to http://www.legup.org/wiki/doku.php?id=niosii_benchmarking_results or the data files containing the results which are in http://www.legup.org/hwprofile/NiosII

UnRAR NiosIISource.rar, which contains 3 folders named NiosII-f/NiosII-s/NiosII-e corresponding to the fast, standard, economical versions of the NiosII processor.

The results for any C program are gathered using a Performance Counter, which outputs the results to the JTAG UART.

First, start the NiosII IDE. Click

 File > Import 

and choose

 Altera NiosII > Existing NiosII IDE project into workspace 

then click next.

Browse to the set up project within NiosII directory

 PATHTOSOURCE\NiosII-f\software\ 

and choose the benchmarks folder then click Finish.

Do the same for the benchmarks_syslib folder.

Now in the NiosII IDE you should have benchmarks and benchmarks_syslib [niosII_system] in the NiosII C/C++ Projects tab.

Go to the directory

 PATHTOSOURCE\NiosII-f\pure .c\ 

which contains all the 13 benchmarks source code.

These C files contain all required macros and were tweaked to work with the NiosII IDE. NOTE: Each benchmark is only a .c file except sha.

Heres a list of which source code corresponds to what benchmark:

adpcm -- adpcm.c
aes -- aes.c
blowfish -- bf.c
dfadd -- dfadd.c
dfdiv -- dfdiv.c
dfmul -- dfmul.c
dfsin -- dfsin.c
dhrystone -- dhry.c
gsm -- gsm.c
JPEG -- main.c
mips -- mips.c
motion -- mpeg2.c
sha -- sha_driver.c and sha.h

Now drag and drop the source file(s) into the benchmark project.

NOTE: The projects are set up with compiler flag [-D “printf(x,…)=”] which disables all printf statements within the code to get rid of the printing to JTAG UART overhead when benchmarking.

Make sure that the DE2 Board is connected, then right click the benchmark project and click

 Run As > Nios II Hardware 

This will automatically build the project, compile the code, program it onto the DE2, and show the output in a terminal.

Right click the benchmark project and click

 Run As > Nios II ModelSim 

This will automatically build the project, compile the code, and run ModelSim.

NOTE: You will be asked to set the ModelSim path in the NiosII IDE if not set.

Once ModelSim is run, input

 s 

into the ModelSim command prompt. This will compile the hardware and take you to the simulation.

Then input

 run -all 

or click the run all button to start the simulation. The simulation will run until you hit break or if you inserted a break point in the code.

Wait till an output on the terminal appears.

If any new benchmarks are required, then you will need to insert the performance counter macros in the right places. Also, the NiosII IDE displays many errors when a .c file is included in another .c file (which is the case with most of the CHstone benchmarks).

If any .c file has .c includes, one solution is to manually copy and paste the included .c in the right place in the main .c file. If this is too troublesome, you can run the GCC preprocessor pass on the code, which outputs a single .c file. (this is what was done for all the benchmarks except sha, for which I did the first alternative)

In the directory

 PATHTOSOURCE\NiosII-f 

there is a README file, which contains all the code needed to utilize the performance counter, and comments on where to put it. Note that the locations are more suitable for the way the CHstone and Dhrystone benchmarks are written. But the locations can be deduced from the readme.