Inconsistent Speed Results on Riscv CPU

[genesys2]

Hi,

I am not sure if I am doing anything wrong here but on my platform, the speed benchmark results are fairly inconsistent. I am using a VexRiscv Core on a Genesys2 FPGA running Linux (125 Mhz).

I set up the boardsupport file as follows (the FENCE instruction is not necessary; it was just an attempt to make the results more consistent):

Boardsupport.c

#include <support.h>
#include <boardsupport.h>

void
initialise_board ()
{
  __asm__ volatile ("li a0, 0" : : : "memory");
}

void __attribute__ ((noinline)) __attribute__ ((externally_visible))
start_trigger ()
{
  __asm__ volatile ("FENCE\n\t"
                    "RDTIME %[lo]\n\t"
                    "RDTIMEH %[hi]\n\t"
                    "FENCE\n\t" : [lo]"=r"(lo), [hi]"=r"(hi) : :);
  t_start = (((unsigned long long)hi) << 32) | lo;
}

void __attribute__ ((noinline)) __attribute__ ((externally_visible))
stop_trigger ()
{
  __asm__ volatile ("FENCE\n\t"
                    "RDTIME %[lo]\n\t"
                    "RDTIMEH %[hi]\n\t" : [lo]"=r"(lo), [hi]"=r"(hi) : :);
  t_stop = (((unsigned long long)hi) << 32) | lo;
  unsigned long normalized = (t_stop-t_start)/CPU_MHZ;
  printf("%llu;\n", normalized);
}

Boardsupport.h

#include <stdio.h>
#define CPU_MHZ 125

unsigned long hi = 0, lo = 0;
unsigned long long t_start = 0;
unsigned long long t_stop = 0;

The chipsupport files are untouched, chip.cfg looks like this:

cflags = [
    '-c',  '-O2', '-march=rv32im', '-mabi=ilp32',
    '-fdata-sections', '-ffunction-sections'
]
ldflags = [
    '-O2', '-march=rv32im', '-mabi=ilp32', '-Wl,-gc-sections'
]
user_libs = ['-lm']

For compilation I used ./build_all.py --arch=riscv32 --cc=riscv32-unknown-linux-gnu-gcc --cflags="-O2 -ffunction-sections" --cpu-mhz=125 --chip=vex --board=genesys2 --logdir=log --builddir=bd2.

The results I am getting vary dramatically and I am not sure why (e.g. the results of crc32 vary between 11472 and 900 cycles) . The results of coremark and dhrystone are stable. Is this a bug or am I doing something wrong?

Thanks for your help!

[PaoloS02]

Hello, sorry for the slow reply.

I'm not familiar with the VexRiscv core, but according to what you said may I assume that you're testing the model of the VexRiscv as described here? https://github.com/SpinalHDL/VexRiscv

Embench is currently designed only for bare metal embedded systems, where the execution time can be safely measured with the count of the executed cycles multiplied by a constant value of the clock period. There are plans to more complex support in the future, like support for application class embedded processors running operating systems like Linux. I strongly encourage you to subscribe to the mailing list: https://embench.org/ And to join the monthly calls. Send an email to paolo.savini@embecosm.com, so I can send you the details for the call. You can follow also here: https://twitter.com/EmbenchOrg

That being said, just for the sake of curiosity. Have you tried counting the cycles with RDCYCLES instead of RDTIME? Of course that would just count the cycles executed by the core, but it would probably be more close to the kind of measurement that we do for a bare embedded system, where the cycle count multiplied by the provided cycle period is accurate. In any case I encourage you to join the mailing list and the calls for the future developments.

[genesys2]

Hi Paolo,

thanks for your response! That makes sense, the RDTIME / RDCYCLE instruction seems pretty noisy to me. I think one would have to average over probably 100 or more runs. I did also try the RDCYCLE instruction, but it leads to similar results. (I think the difference of RDTIME and RDCYCLE is mostly relevant on multi core systems)

I subscribed to the mailing list, thanks for the link :-) Regarding the calls - right now, I am pretty busy with other projects, so I don't think I have time for more. Anyway, thanks for the offer!

[PaoloS02]

My pleasure,

Thank you for sharing your doubts and for subscribing, and looking forward to discussing further whenever needed.

[jeremybennett]

Marking as closed