You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
When executing the MIbench/telecomm/crc benchmark or any other benchmark in Mibench on the RISC-V ISA simulator (Spike), the execution log shows a repetitive pattern of two identical instructions, specifically load and branch instructions. It is observed that these instructions are originating from HTIF (Host-Target Interface) and not from the ELF file being executed. I have tried to trace it down I found that this pattern begins from mret and continues till sret. So, the Spike enters the machine mode to supervisor mode because of a trap but how can we avoid this? Or it's just the part of Spike.
Questions:
Expected Behavior: Is the repetition of identical load and branch instructions from HTIF expected behavior in the Spike simulator when running the MIbench benchmark?
Mitigation: How can these redundant load and branch instructions from HTIF be avoided in order to improve the accuracy and efficiency of the simulation? Are there specific configurations or settings that need to be adjusted?
PK uses the HTIF interface for syscalls. The HTIF interface is through polling reads and writes to special memory addresses (tohost/fromhost). You are likely seeing polling on fromhost due to some syscalls from your target benchmark.
If you are evaluating some benchmark using PK, you must be careful that there are no syscalls in the region of interest in the benchmark.
Thanks a lot for your reply, For that, I have marked the whole PK as a junkROI and If I'm inside the PK(i.e- Junk Region in my case) I don't update the stats or trace. Even with this, I see a lot of Instructions that are not from the binary that I'm executing. Is there a way to get PC(IP) in the trace that is only in the binary that I'm executing?
I've observed a comparable trace as well. I suspect this occurs for any trap involving syscalls. The behavior is consistent even when running a complete Linux environment on Spike. Given that the Linux setup is expected to support all syscalls, could this behavior occur due to other traps, like misaligned memory access?
When executing the MIbench/telecomm/crc benchmark or any other benchmark in Mibench on the RISC-V ISA simulator (Spike), the execution log shows a repetitive pattern of two identical instructions, specifically load and branch instructions. It is observed that these instructions are originating from HTIF (Host-Target Interface) and not from the ELF file being executed. I have tried to trace it down I found that this pattern begins from mret and continues till sret. So, the Spike enters the machine mode to supervisor mode because of a trap but how can we avoid this? Or it's just the part of Spike.
Questions:
Expected Behavior: Is the repetition of identical load and branch instructions from HTIF expected behavior in the Spike simulator when running the MIbench benchmark?
Mitigation: How can these redundant load and branch instructions from HTIF be avoided in order to improve the accuracy and efficiency of the simulation? Are there specific configurations or settings that need to be adjusted?
Environment:
Host Operating System: Fedora workstation 37
Target Architecture: RISC-V
Benchmark: MIbench/telecomm/crc
Additional Information: I have generated the log, below is a small part of the log(I get the same pattern for millions of iterations):
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4
core 0: 0xffffffc000004ea0 (0x00043703) ld a4, 0(s0)
core 0: 0xffffffc000004ea4 (0xfe070ee3) beqz a4, pc - 4`
Thank you for your assistance in addressing this issue.
The text was updated successfully, but these errors were encountered: