SPEC CINT2006 on BOOM

[Rafael]

Hi Chris.

First of all, congratulations on your BOOM project, it's an amazing/useful tool.

Now, here's the trouble:

I'm currently struggling to find a way to run the SPEC CINT2006 on the (old) BOOM RTL simulator. I know from your BOOM paper that you have actually done it (on an FPGA, I guess).

1) I found your useful tool (Speckle) that facilitates it to compile the benchmarks to RISC-V. I can actually compile some binaries, but I could not run it on the simulator. I think it's supposed to run over the pk, but the compiler (I think) is assigning the start address to 0x10000, maybe it should be 0x200. So, when the simulator starts running it, it runs for a few cycles, nothing happens and it ends execution. I don't know whats going on so I cannot give you more details.

2) I also cannot run the binaries on Spike. When I try to run bzip, for example:

./spike pk bzip.riscv

I get the output: terminate called after throwing an instance of 'trap_store_access_fault'

I could not find anything related to that yet.

3) Also, it's not possible to run SPEC bare metal, right?

4) Another thing that I found confusing on the RISC-V documentation is the actual difference between running the binaries over the pk and over the Linux kernel. Doesn't the pk also perform the system calls on Linux? 

I'm kind of confused here. Do you have any suggestion?

Thank you (a lot) in advance!

[Christopher Celio]

Some thoughts:

You can't run SPEC bare metal. They will make system calls. Lots of them. Printfs. File I/O. Threading. They will run under virtual memory, so their start address is irrelevant.

0x200 is the boot load/reset address I believe (or is it 0x1000?). That's only for the bootrom.

The kernel runs untranslated I believe and will be in physical memory at address 0x8000_0000. 

spike -d will let you see the cycle by cycle behavior.

You can run user programs on top of riscv-pk or linux. They share the same syscall numbers. However, riscv-pk doesn't implement all syscalls; for example, there is no pthread support. It can only allocate a fixed number of file descriptors, etc. About half of SPEC will run on riscv-pk (due to unsupported syscalls),  but I only ever use Linux for SPEC.

Look into Speckle's run script/command directory -- programs like bzip require arguments (what are you trying to zip?).

-Chris

[Rafael]

Thank you a lot for answering.

Still, I'm having some trouble with the proxy kernel. As I understand it, the pk should be loaded in the C++ simulator as an input program, and the actual program that I want to execute should be passed as an argument to the pk program, right? Should pk be in the .hex format?

I'm trying to to something like:

./BOOMsimulator pk hello.hex

Unfortunately nothing happens, the processor's program counter gets stuck at 0x200, but I cannot figure out what's going on. Even a simple hello world program does not work.

It has been a bit confusing to me to understand this process, because I cannot understand how pk actually works in details. Also, I don't really get why I need the pk since there is the HTIF inside the simulator, which should pass the system calls to the OS (why pk so?).

If you have any suggestion, I'd like to here it from you. Thank you a lot!

[Christopher Celio]

pk is a RISC-V binary. You can find it in $RISCV/riscv-???-elf/bin/pk, objdump it, and look at the dissassembly. Or go to riscv-tools/riscv-pk to look at the actual source code. 

pk accepts an elf file as its input, so it should be something like this:

riscv-...-gcc -o hello.elf hello.c 

./BOOMsimulator pk hello.elf

You can first do "spike pk hello.elf" to verify that your binary and pk work.

And "spike -d pk hello.elf" will give you line by line output so you can see what instructions are being executed.

Compiled into BOOM is "riscv-fesvr". The fesvr periodically reads BOOM's memory (at some address set aside for tohost/fromhost communications), which is how it handles proxied syscalls like "print".

-Chris