Running the VCS simulator

[clare7]

As I was trying to make a VCS simulator binary (default configuration) from the folder vcs, I have successfully generate the DefaultL2Config-sim. Next I would like to simulate the hello program using PK. I understand from the previous version of tutorial, there are 3 ways to generate the hello program. There used to be a make file in $TOP/riscv-tools/hello that generates three different executables for all environment but this was not longer available in the latest lowriscv so hence I did the following:

riscv64-unknown-elf-gcc hello.c -o hello

and run with the simulator

./DefaultL2Config-sim pk ex

However, I get the following on the terminal and it just goes on continuously without ending:

C0: 71181 [1] pc=[0000000004] W[r 0=0000000000000008][1] R[r 5=0000000040000000] R[r 0=0000000000000000] inst=[00028067] DASM(00028067) C0: 71182 [0] pc=[0040000000] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000000] DASM(00000000) C0: 71187 [1] pc=[0000000000] W[r 5=0000000040000000][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[40000297] DASM(40000297) C0: 71188 [1] pc=[0000000004] W[r 0=0000000000000008][1] R[r 5=0000000040000000] R[r 0=0000000000000000] inst=[00028067] DASM(00028067) C0: 71189 [0] pc=[0040000000] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000000] DASM(00000000) C0: 71194 [1] pc=[0000000000] W[r 5=0000000040000000][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[40000297] DASM(40000297) C0: 71195 [1] pc=[0000000004] W[r 0=0000000000000008][1] R[r 5=0000000040000000] R[r 0=0000000000000000] inst=[00028067] DASM(00028067)

Any advice what could have went wrong? Thanks

[wsong83]

The VCS directory is there currently for internal use. So it is not documented. But anyway, you can use it, nearly in the same way as using the vsim directory (verilator).

For your question, simply put, starting from v0.2, lowRISC does not need pk. Run ./DefaultL2Config-sim +load=ex

[clare7]

I just tried and got the same outcome as the one I mentioned in the first post.

./DefaultL2Config-sim +load=hello

and same case for vsim directory.

On Tue, Aug 22, 2017 at 5:48 PM, Wei Song notifications@github.com wrote:

The VCS directory is there currently for internal use. So it is not documented. But anyway, you can use it, nearly in the same way as using the vsim directory (verilator).

For your question, simply put, starting from v0.2, lowRISC does not need pk. Run ./DefaultL2Config-sim +load=ex

— You are receiving this because you authored the thread. Reply to this email directly, view it on GitHub https://github.com/lowRISC/lowrisc-chip/issues/65#issuecomment-323976964, or mute the thread https://github.com/notifications/unsubscribe-auth/AcHzHGZGz7OQTh-inzDBLJkpgDBCjZfeks5saqQDgaJpZM4O-UZG .

-- Regards, Ming

[wsong83]

There are two levels of bootloaders. The BootROM is always located at 0x0000_0000 A first stage BootRAM is normally located at 0x4000_0000 and it is implemented as on-chip BRAMs. If running on FPGA, DDR is normally located to an address higher than 0x6000_0000 (see the generated dev_map.h for more details).

After power on, processor starts with 0x0000_0000. The first two instructions of the BootROM are always loading pc with the address of the first stage booloader, the BRAMs at 0x4000_0000. Normally the bare-matel program is loaded to this BRAM.

According to the trace, processor successfully jumps to BRAM at 0x4000_0000, however, there is no valid instruction pc=[0040000000] inst=[00000000]. This triggers an exception, which sends pc back to the BootROM as the back-up trap vector. Then this loops forever.

Somehow, your ex is NOT loaded correctly.

The elfloader in simulation load elf according to the addresses of various sections. The ex elf should be generated using a proper link script, something like this one https://github.com/lowRISC/riscv-test-env/blob/5d635368e109eaa0220c9ee721c7e82892f67d4c/p/link.ld

Since I do not know exactly how did you compile/generate the ex program, I think the code section might be located somewhere else.

You might want to run make run-asm-tests in /vsim or /vcs (not sure), and then see how these tests are compiled/linked.

[clare7]

Ok. This seems odd to me but I shall look into this. Thanks for the help. Meanwhile I have another question. If it doesnt run on pk then my executable or my program should not has any code like printf? Also any other way to test the processor apart from stimulating it as an emulator and run with a program? Perhaps sooner I may need to add in coprocessor to the system via rocc, which i have yet to know how but I would need to do that for my project work.

Thanks for the advice

[wsong83]

Without pk, the bare-metal tests indeed have accesses to limited variety of peripherals. However, a reduced version of printf is actually available. Printf can be used to print out string and integers only. Also the implementation is not delegated to htif, which means the simulator will actually bit-bang the UART IP to print out characters. In Verilator/VCS simulation, a C++/DPI implemented terminal emulator is available from the trace debugger. http://www.lowrisc.org/docs/debug-v0.3/simulation/

As for you second question, I think what you mean is what debug method is available besides tracing signals in the waveform generated by simulation? Right now, there is trace debugger which allows you to generate your own software traces, with no simulation speed overhead. Also, as mentioned, printf is available, although very slow due to the bit-banging.

[clare7]

Does it mean that bare-metal test with (reduced version) of printf is still feasible? Any example of which I could refer to? Say I manage to run a bare-metal test to perform simple addition: ./DefaultL2Config-sim +load=rv64i-p-add

and then observed a print out of the memory contents such as the following (just a fragment of the output) on the terminal:

C0: 1231 [1] pc=[0040000590] W[r 2=000000000000001e][1] R[r 0=0000000000000000] R[r30=000000000000000b] inst=[01e00113] DASM(01e00113) C0: 1232 [1] pc=[0040000594] W[r 0=000000000000002e][1] R[r 1=0000000000000010] R[r 2=000000000000001e] inst=[00208033] DASM(00208033) C0: 1233 [1] pc=[0040000598] W[r29=0000000000000000][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000e93] DASM(00000e93) C0: 1234 [1] pc=[004000059c] W[r28=0000000000000026][1] R[r 0=0000000000000000] R[r 6=000000000000000b] inst=[02600e13] DASM(02600e13) C0: 1235 [1] pc=[00400005a0] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r29=0000000000000000] inst=[01d01463] DASM(01d01463) C0: 1236 [1] pc=[00400005a4] W[r 0=0000000000000001][0] R[r 0=0000000000000000] R[r28=0000000000000026] inst=[01c01c63] DASM(01c01c63) C0: 1240 [1] pc=[00400005bc] W[r 0=0000000000000004][0] R[r 0=0000000000000000] R[r31=000000000000000b] inst=[0ff0000f] DASM(0ff0000f) C0: 1267 [1] pc=[00400005c0] W[r28=0000000000000001][1] R[r 0=0000000000000000] R[r 1=000000000000000b] inst=[00100e13] DASM(00100e13) C0: 1268 [0] pc=[00400005c4] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000073] DASM(00000073)

Is there is anyway I can actually see the outcome of the addition from printf instead of the content of the registers?

And for the second question, yes that is what I meant; alternative debug method besides tracing signal in the waveform. Therefore, the trace debugger that you mentioned is all in the link above and can be done without FPGA implementation?

[wsong83]

I suggest you to have a detailed look of how to use trace debug in simulation.

For isa tests, if anything goes wrong, the test will return a failure code, otherwise, it is executed correctly. If you like to see the results of individual instructions, the instruction trace is actually convenient. You can use printf (which probably does not matter for isa tests as they are pure assembly), printing out a single character probably costs several hundreds of cycles in half a second in real time. Using software trace is a much better way.

For your question, YES, you can use nearly all functions of the trace debugger without FPGA implementation. Our tutorial should have provided step by step guide of how to run it in simulation with Verilator, courtesy to Stefan.

[clare7]

Thank you so much. I will put in effort to look into the tutorial and try on it again. I shall close the issue for now. Should I face any other issue after this I will start a new post. Thanks again!

[wsong83]

FYI, if you put spike-dasm at end of the simulator, it will translate instructions to readable assembly for you.

./DefaultL2Config-sim +load=rv64i-p-add | spike-dasm

Glad to be helpful.