chipsalliance / rocket-chip

Rocket Chip Generator
Other
3.19k stars 1.12k forks source link

Discrepency between simulation with and without traces #3630

Closed bantierr closed 4 months ago

bantierr commented 4 months ago

Type of issue: bug report

Impact: unknown

Other information

I have created a dedicated repository for the bug at: https://github.com/bantierr/rocket_issue.git

If the current behavior is a bug, please provide the steps to reproduce the problem: I am simulating an automatically generated program, and I am experiencing outputs mismatches between a simulation with traces and without traces on verilator. Please, find all the relevant files in the repository attached above. It seems like this behavior also happens on modelsim.

What is the current behavior?

When simulating the program without traces, the program behaves correctly. The program executes an ECALL instruction from Supervisor mode, and then reads mcause, which holds the expected value for Environment call from S-mode (0x9). When simulating the program with traces, mcause holds the value for Supervisor external interrupt (0x8000000000000009). SPIKE OUTPUT:

core   0: 0x0000000080000138 (0x30200073) mret
core   0: 0x000000003c2b67b0 (0x00000073) ecall
core   0: exception trap_supervisor_ecall, epc 0x000000003c2b67b0
(spike) 
core   0: >>>>  $xrv64i2p1_m2p0_a2p1_f2p2_d2p2_zicsr2p0_zifencei2p0_zmmul1p0
core   0: 0x000000008002f810 (0x342020f3) csrr    ra, mcause
(spike) reg 0 mcause
0x0000000000000009

VERILATOR OUTPUT WITHOUT TRACE:

[1] pc=[0000000080000138] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[30200073] DASM(30200073)
[0] pc=[000000003c2b67b0] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000073] DASM(00000073)
[1] pc=[000000008002f810] W[r 1=0000000000000009][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[342020f3] DASM(342020f3)

VERILATOR OUTPUT WITH TRACE:

[1] pc=[0000000080000138] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[30200073] 
[0] pc=[000000003c2b67b0] W[r 0=0000000000000000][0] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[00000073] 
[1] pc=[000000008002f810] W[r 1=8000000000000009][1] R[r 0=0000000000000000] R[r 0=0000000000000000] inst=[342020f3] 

What is the expected behavior?

I expect the simulation to have the same behavior with and without traces.

Please tell us about your environment:

rocket-chip hash: d03aec2643b152e81468ee36f3bfd45872c14d6a verilator hash: 5b8941d7170b0c11eff46703514b064becd3a648 OS: Ubuntu 22.04.3 LTS

jerryz123 commented 4 months ago

I was unable to reproduce the failing issue across Verilator and VCS, with and without traces (waveforms, I assume). All the simulated tests returned 0x9 for mcause in the instruction at 0x8002f810.

I am using the latest chipyard to run the simulation, with Verilator 5.010 and a host gcc-10.5.0.

In the past, I've noticed divergences between verilator and verilator-debug simulations disappear after switching to a newer Verilator version. I can only assume this is due to some bug in Verilator.

bantierr commented 4 months ago

Thank you so much for you answer! I will double check my gcc version and get the latest verilator version.

Just out of curiosity, did you use the optimization flags from the repo I linked ? I noticed some differences in the simulation when I use different optimizations on my verilator version.

Best, Quentin