Running CoreMark benchmark in DarkRISCV!
samsoniuk opened this issue · comments
I am checking some suggestions and updates for DarkRISCV from @vgegok:
There are some points open, but the most interesting update is the support for CoreMark application! It appears to work and the result of 0.925 CoreMark/MHz is comparable to other RISCV cores pointed here:
https://www.esa.informatik.tu-darmstadt.de/assets/publications/materials/2019/heinz_reconfig19.pdf
Well, but there are some fixes in order to make it work:
a) it appears that the boot.s is missing in your version:
$ make
make -C src all
make -C darksocv all
make[2]: *** No rule to make target `../common/boot.s', needed by `../common/boot.o'. Stop.
make[1]: *** [all] Error 2
make: *** [all] Error 2
$ find . -name boot.s
$
I got it from my version, but I made some changes (see below).
b) there is no darksocv.lds:
/usr/local/share/gcc-riscv32-embedded-elf/bin//riscv32-embedded-elf-as -march=rv32e -c ../common/boot.s -o ../common/boot.o
make[2]: *** No rule to make target `darksocv.lds', needed by `darksocv.ld'. Stop.
make[1]: *** [all] Error 2
make: *** [all] Error 2
It is probably because the .gitignore... I get it from the coremark.lds.
c) The lds is asking about a include/io.o, but it is better use the following syntax:
.io : { *io.o(COMMON) } > IO
So it will need no paths inside de lds...
d) I think the new src/ directory structure is good, but I think use "darklibc" instead of "common" sounds better! Maybe I can separate the stdio.c in different files, so is possible include only is needed for specific applications.
e) I moved the banner and printf from boot.s to main.c, in order that to remove the putchar/printf dependency in the boot.s.
f) Regarding the coremark app, I found that it is too large:
WARNING: ../rtl/darksocv.v:250: $readmemh(../src/darksocv.mem): Too many words in the file for the requested range [0:4095].
But you mentioned it in the README.md, so when the memory size was adjusted, I get the correct results... in the case of the kintex-7 FPGA, I got the folowing results:
CoreMark start in 92932555 us
2K performance run parameters for coremark.
CoreMark Size : 666
Total ticks : 18537518
Total time (scs): 18
Iterations/Sec : 222
Iterations : 4000
Compiler version : GCC9.0.0 20180818 (experimental)
Compiler flags : -O2 -DPERFORMANCE_RUN=1
Memory locatin : STACK
seedcrc : 0xe9f5
[0]crclist : 0x%x
[0]crcmatrix : 0x1fd7
[0]crcstate : 0x8e3a
[0]crcfinal : 0x65c5
Correct operation validated. See README.md for run and reporting rules.
CoreMark finish in 111516081 us
I am not sure how read it... it is othe interactions/second per MHz? in this case 0.925 coremarks/MHZ? I tested with rv32i too, but it shows almost the same speed. Of course, the performance is pretty deterministic regardless the clock.
f) I am not much aware about the numbers for coremark, so I guess the dhrystone is much more comprehensive, as it shows a magic number that divided by another magic number shows the performance in VAXMIPS... maybe I will try port it as an application in the new scheme!
@vgegok: I will make some additional changes and update to your repo... as long we close the open points, we can merge it to the main version! :)
Thank you for creating a new issue to discuss coremark.
a) It appears that the boot S is missing:
I checked my warehouse and found that boot.s file:
src/common/boot.s
src/coremark/include/boot.s //call banner; print-->ee_printfb) no darksocv.lds
The same problem.
It is probable because the Gitignore I get it from the coremark Lds
I will fix the above two problems and update my code warehouse as soon as possible
c)The lds is asking about a include/io.o
In my test, if io.h and stdio.h in the same directory, Unnecessary functions in stdio.h, which will lead to coremark compilation errors. Therefore, in order to avoid this problem, we have to use different directories to contain io.h.
d) Use "darklibc" instead of "common"
GREAT! I agree with you. It looks more elegant.
In addition, I will create README in the src directory to explain the directory structure and usage.
So I think splitting stdio.h is a good choice. In this way, you can call GCC stdio.h.
f) Iterations/sec: 222
If the clock cycle is 100MHz, 222/100=2.22, I have no in-depth understanding of this result, but there is no doubt that this result is correct, ha ha
I have fixed the above problem, vgegok/darkriscv
I put my changes here:
It appears to be working! Please generate a Pull Request, so I can merge it to the main line! :)
I just updated it. I suggest you start with upstream
vgegok@5489762
Interesting point about the results:
- spartan-6: 76 int/sec @100MHz -> 0.760 coremarks/MHz w/ GCC-11
- kintex-7: 181 int/sec @200mhz -> 0.905 coremarks/MHz w/ GCC-9
- kintex-7: 222 int/sec @240MHz -> 0.925 coremarks/MHz w/ GCC-9
It appears that there is a "ovehead" in the coremark that is linked to the periodic timer in the processor, in a way that better clock results in large processing and less overhead!?
You mean TIMEUS is causing more expenses?
Nope, it is probably related to the way that the benchmark is designed and it is probably more precise when the processor is faster.
I think so. More iterations may lead to more accurate results, but corenmark must run for 10-100 seconds。
I have generated a Pull Request！
thank you!
I have verified my changes and ensured that the original make command works.
You have closed my pull request，I don't see any updates to the master branch.
I tested here and is working fine! :)
but feel free to reopen or submit updates case you need change anything!