[lowrisc-dev] Porting tagged memory support to current version of RISC-V Rocket Chip

Wei Song ws327 at cam.ac.uk
Wed Oct 14 09:30:28 BST 2015

Hello Zhe Cheng,

Yes, for the cases with results in our paper you can run them using the
way you have figured out without Linux.
You need to revise the run scripts a little bit.

Best regards,

On 13/10/2015 21:55, Zhe Cheng Lee wrote:
> Wei,
> Thanks for the response. I don't have access to my development
> environment right now, so just to be sure: when you said to use pk on
> the FPGA, you mean something like this (after booting the Zynq board
> and mounting the SD card)?
> |./fesvr-zynq pk -c /sdcard/path/to/bzip2_base.riscv ${input} >
> /path/to/output|
> Speckle generated a run script for a portable directory containing the
> SPEC benchmark binaries and input data compiled with RISC-V Linux GCC.
> So for FPGA runs (not in booted Linux), instead of copying the
> directory into the Linux root image, we would just copy it to a
> separate location in the SD card and execute the run script. We would
> also need to modify the run script so that instead of calling spike,
> it calls fesvr-zynq. Is this correct?
> Thanks,
> -Zhe Cheng
> On Tue, Oct 13, 2015 at 4:54 AM, Wei Song <ws327 at cam.ac.uk
> <mailto:ws327 at cam.ac.uk>> wrote:
>     Hello Zhe Cheng,
>     I am afraid it is a bit complicated.
>     Most SPEC benchmark cases (at least for the subset of integer
>     suite) are single thread programs.
>     Single thread programs can run in bare-metal mode (use pk) instead
>     of inside Linux, which is better for collecting miss rate and
>     running time.
>     So I did it using pk on FPGA rather than booting a Linux.
>     You will need to modify the scripts from Speckle to compile for
>     FPGA runs (if I remember it right, use the linux gcc rather than
>     newlib gcc).
>     pk has an option to report running time (actually it is the cycle
>     count) before exit.
>     For missing rate, I had added a lot of hardware performance
>     counters in L1/L2 to collect cache requests and misses.
>     Some of the code can be found in
>     https://github.com/lowrisc/lowrisc-chip.git branch "perform".
>     However, it is the version for the old code base and without L2.
>     I have not gotten time to update the latest code base yet.
>     I have also modified fesvr to read/report the performance counters
>     before exit.
>     If you need to run benchmarks in Linux, you do not need to install
>     SPEC (I believe) but it is still difficult for the following reasons:
>     1. When running benchmarks, the Linux kernel has booted, L1/L2
>     caches are occupied (not empty).
>     2. Kernel may affect the running time.
>     3. There is no easy way of reporting the value of performance
>     counters as they are implemented as CSRs. Reading CSRs in user
>     mode program needs special syscalls added to the Linux kernel.
>     4. The timing (cycle count) function is also on the supervisor side.
>     But if the only thing interests you is the running time, in Linux
>     should be OK.
>     Oh, be careful the time you get from the FPGA Linux, which is not
>     real time.
>     If I remember it right, there is a static configuration in the
>     kernel to define the clock frequency, with no regard to the real
>     FPGA clock frequency.
>     Good luck!
>     Wei
>     On 13/10/2015 04:31, Zhe Cheng Lee wrote:
>>     Hello Wei,
>>     We want to measure the execution time in the FPGA using SPEC
>>     benchmarks.We have compiled the SPEC benchmark binaries with
>>     Speckle. After moving the SPEC binaries (the .riscv files e.g.
>>     bzip2_base.riscv, correct?) into the Linux root image and booting
>>     Linux at the rocket-chip FPGA, how exactly do we run the binaries
>>     in the booted Linux? Do we need to install SPEC in the FPGA? If
>>     so, how?
>>     Also, in the paper, there are measurements such as MPKI. Is this
>>     a measurement given by running SPEC alone, or is it a measurement
>>     you modelled?
>>     Thanks,
>>     -Zhe Cheng

More information about the lowrisc-dev mailing list