Performance of rocket-chip

[cassebas]

Hi Eugene,
I'm not sure if you can help me, but I'll try anyway. I'm running performance evaluations with a 32-bit Rocket-chip single core. I'm using benchmarks from the TacleBench benchmark suite, running them bare metal.

I have generated a rocket32s1 core from your repository, simply using the latest commit. (Without any modifications.) Then I run a TacleBench benchmark using the xsdb debugger, much like in your helloworld example.

In the benchmark code, I have added the cycle counter as a performance counter. As an example I use dijkstra. Right before starting the benchmark, I save the number of cycles and right after running the benchmark I do this again. The difference is the number of cycles spent in the dijkstra_main function.

I do expect the number of cycles to vary somewhat, because of the DRAM, which I guess does not always give the same performance. It runs in a different clock domain compared to the core. But the strange thing is, sometimes after a reset (I push the button), the number of cycles is way off and it stays way off until I push the reset button again. In attached file you see some of the output, where each time I hit the reset button, the core starts again.

taclebench-dijkstra-performance-rocket32s1.txt

Do you have any clue as to why sometimes, the performance is worse? It seems that once in a while, the Rocket core wakes up in a bad mood or something.

Any ideas much appreciated!
thnx

[eugene-tarassov]

It looks like the test reads some uninitialized memory location.
The reset causes random changes of DRAM data.
This can cause random variations in the test behavior.

[cassebas]

Thank you for your quick response. I have investigated the problem further today. It really seems that I get two 'distributions', depending on the state in which the core(?) finds itself after a reset. Today I ran the dijkstra benchmark 100 times after a number of resets, so after each reset 100 times automatic runs with xsdb. In this graph two of the distributions are shown

(So I did) :

• [reset] run dijkstra 100 times
• [reset] run dijkstra 100 times
• [reset] run dijkstra 100 times
• etc

I have also tried to initialize the memory by putting in the bootrom:

        asm volatile ("li  t0, %0" :: "n" (BOOTROM_MEM_ADDR));
        asm volatile ("li  t2, %0" :: "n" (BOOTROM_MEM_ALT));
        asm volatile ("boot_rom_initmem:");
        asm volatile ("sw   x0, 0(t0)");
        asm volatile ("sw   x0, 4(t0)");
        asm volatile ("addi t0, t0, 8");
        asm volatile ("bne  t0, t2, boot_rom_initmem");

But this doesn't help unfortunately, same behaviour.
Do you know if it would it be possible to flush/invalidate the cache somehow (both data and instruction)? I have tried to find this for rocket-chip, but couldn't find it.

[eugene-tarassov]

As far as I know, flush/invalidate is not supported because it is not needed - RocketChip implements cache coherent interconnect.

[cassebas]

Hi Eugene,
I'm still trying to figure out why I'm seeing different distributions of execution times. I was wondering if it could have something to do with the temperature of the FPGA. I have downloaded the Rocket64b2 image, with that I can run Linux, this works fine. But the fan is not active, which surprises me because it might get too hot.

I'm trying to understand the working of the fan. The fan_control.v module is not used in case of the Genesys2 board. I can see that the XADC is part of the design and it is connected to the fan_en port. Also it has an output device_temp to the DDR module.

But I guess the XADC is not enabled by default? I don't see any code that activates it. I could try to activate it myself by reading and writing to the registers of the AXI lite XADC component in bare metal mode, or somehow activate the Linux xadc kernel driver?

Thanks again!

[eugene-tarassov]

XADC is enabled by default. It is programmed to turn on fan at 60C, turn off at 50C. The fan is not active because the temperature does not reach 60C. To see and edit default XADC setting, double click on the XADC block in Vivado. When device_temp changes, the DDR controller re-runs calibration, it uses test patters to find actual delay on DDR data lines to set optimal phase shift between data and clock. XADC does not require a driver, unless you want to adjust setting at run time, or to check current temperature and voltages.

[cassebas]

Thank you. Indeed I can adjust the fan temperature, and I see my fan go on and off.

About this calibration, could it be that this is run after a reset? I can't image that this calibration runs during the processor's activity?

[eugene-tarassov]

The re-calibration (aka temperature monitor calibration and dynamic calibration) can run during the processor's activity. According to the docs, it is done during idle cycles, and does not impact the performance of the memory interface. It is not same as initial calibration at power up.