Skip to content

[BUG][RV32E] Reserved x16-x31 encodings produce LSU side effects while taking an illegal-instruction trap #2553

Open

Description

@huntersubmit

Ibex is an exceptionally valuable contribution to the open-source hardware community, providing a high-quality and accessible implementation for learning, research, and verification.

I sincerely appreciate the considerable effort that the developers and maintainers have invested in designing, documenting, and continuously improving this project. Thank you for making this work openly available to the community.

Summary

With Ibex configured as RV32E=1 and WritebackStage=0, instruction encodings that reference the unavailable registers x16 through x31 raise an Illegal Instruction exception, but LSU operations decoded from the same instruction are not uniformly canceled.
Dynamic testing shows that a store referencing x18 modifies memory while raising the exception.

The RISC-V RV32E specification defines encodings that reference x16 through x31 as reserved, while the base specification defines the behavior of reserved instructions as UNSPECIFIED.
Given that illegal_reg_16 explicitly causes Ibex to raise an Illegal Instruction exception, should an instruction rejected in this way also be prevented from committing decoded LSU side effects, as other illegal instructions are?

Tested revision and configuration

  • Ibex commit: f4515520c0045bb8ef1e72d46ed82499a6ac5f18
  • Configuration: RV32E=1, WritebackStage=0, RegFile=ibex_pkg::RegFileFF
  • Simulation platform: ibex_simple_system with Verilator
  • Toolchain: riscv64-unknown-elf-gcc 14.2.0
  • Reference model: Spike commit 4c6a9bc79dab80616932949707e7c0471d8e9e54
  • fusesoc:
$ fusesoc --version
2.4.3

Command used to build the Ibex model:

# repo
cd ibex

fusesoc --cores-root=. run --target=sim --setup --build \
  --build-root=build/configs/illegal_store_side_effect \
  lowrisc:ibex:ibex_simple_system \
  --RV32E=1 --WritebackStage=0 --RegFile=ibex_pkg::RegFileFF

Reproduction

The test first initializes target_word to 0x11223344, then executes the raw instruction encoding 0x0122a023, which corresponds to sw x18, 0(x5). The trap handler checks mcause and then reads target_word to determine whether the store produced a side effect.

test.s

  .option norvc

  .section .text.init
  .globl _start
_start:
  la t0, trap_handler
  csrw mtvec, t0

  # Initialize the destination with a sentinel and give x2 a distinct value.
  la t0, target_word
  li t1, 0x11223344
  sw t1, 0(t0)
  li sp, 0x55667788

faulting_instruction:
  # sw x18, 0(x5). x18 is unavailable in RV32E, so this encoding is reserved and must trap without performing the store.
  .word 0x0122a023

  li a0, 2
  j finish

  .section .trap, "ax"
  .balign 256
trap_handler:
  csrr t1, mcause
  li a0, 3
  li t2, 2
  bne t1, t2, finish

  # A precise illegal-instruction trap must leave memory unchanged.
  la t0, target_word
  lw t1, 0(t0)
  li t2, 0x11223344
  li a0, 1
  bne t1, t2, finish

  li a0, 0

finish:
  # 1 means pass. Odd values greater than 1 encode failures.
  slli a0, a0, 1
  ori a0, a0, 1
  la t0, tohost
  sw a0, 0(t0)

  # Ibex simple_system terminates on this MMIO write.
  li t0, 0x20008
  sw a0, 0(t0)
1:
  j 1b

  .section .data
  .balign 4
target_word:
  .word 0

link.ld

OUTPUT_ARCH(riscv)
ENTRY(_start)

MEMORY {
  ram (rwx) : ORIGIN = 0x100000, LENGTH = 0x30000
}

SECTIONS {
  . = ORIGIN(ram);
  .vectors : { . = . + 0x80; } > ram
  .text : { *(.text.init) *(.text*) } > ram
  .trap : { *(.trap) } > ram
  .data : { *(.data*) } > ram
  .bss : { *(.bss*) *(COMMON) } > ram

  tohost = 0x12fff0;
  fromhost = 0x12fff8;
}
tohost Meaning
1 The handler is entered, mcause=2, and memory remains unchanged
3 The handler is entered and mcause=2, but memory has been modified
5 No exception occurs and execution continues past the faulting instruction
7 The handler is entered, but mcause is not 2

Compile the test case:

riscv64-unknown-elf-gcc -march=rv32e_zicsr -mabi=ilp32e -nostdlib -nostartfiles -static -Wl,-T,link.ld -Wl,--build-id=none \
  -o ./build/test.elf ./test.s

Run Spike:

spike -m0x100000:0x30000 --isa=rv32e_zicsr --priv=mu --log-commits ./build/test.elf 2> spike.log

Run Ibex:

model=/path/to/ibex/build/configs/illegal_store_side_effect/lowrisc_ibex_ibex_simple_system_0/sim-verilator/Vibex_simple_system

"${model}" --term-after-cycles=1000 --meminit=ram,"/path/to/build/test.elf" |& tee ibex.log

Compare the Spike and Ibex results:

#!/usr/bin/env bash
set -euo pipefail

spike_tohost=$(sed -n 's/.*mem 0x0012fff0 0x\([0-9a-fA-F]*\).*/\1/p' "./spike.log" | tail -n 1)

ibex_tohost=$(sed -n 's/.*PA:0x0012fff0 store:0x\([0-9a-fA-F]*\).*/\1/p' "./trace_core_00000000.log" | tail -n 1)

printf 'Spike tohost: 0x%s (expected 0x00000001: pass)\n' "${spike_tohost}"
printf 'Ibex  tohost: 0x%s (expected 0x00000003: memory side effect detected)\n' "${ibex_tohost}"

Both Spike and Ibex produce mcause=2 for this encoding. However, Spike preserves target_word=0x11223344 and writes tohost=1, whereas Ibex overwrites that memory location with 0 and writes tohost=3.

ibex.log:

Simulation running, end by pressing CTRL-c.
TOP.ibex_simple_system.u_top.u_ibex_tracer.unnamedblk2.unnamedblk3: Writing execution trace to trace_core_00000000.log
                  41: Illegal instruction (hart 0) at PC 0x001000a8: 0x0122a023
Terminating simulation by software request.

The Ibex trace_core_00000000.log also records the store and its architecturally visible result:

             44	        18	001000a8	0122a023	-->sw	x0,0(x0)	  x0:0x00000000  x0:0x00000000 PA:0x00100204 store:0x00000000
             64	        28	00100118	0002a303	lw	x6,0(x5)	  x5:0x00100204  x6=0x00000000 PA:0x00100204 load:0x00000000
             88	        40	00100140	00a2a023	sw	x10,0(x5)	  x5:0x0012fff0 x10:0x00000003 PA:0x0012fff0 store:0x00000003
Model mcause target_word read by the handler tohost
Spike 2 0x11223344 1
Ibex 2 0x00000000 3

Expected behavior / questions

I would appreciate clarification on the following point:

  • When Ibex raises an illegal-instruction exception, is the faulting instruction expected to produce no LSU side effects?

If the project explicitly permits these reserved encodings to produce side effects before entering the trap handler, then the current behavior is an allowed implementation choice and this report can instead serve as a confirmation and record of that behavior rather than as a bug report.

Activity

  1. h-filali commented on Nov 6, 2026

    @h-filali
    Contributor

    Hi @huntersubmit thanks for flagging this issue.
    This issue here seems to be related to #2547.

    RV32E with WritebackStage = 0 is currently not a tested or officially supported configuration for the core. As a result, this is a low priority issue for us right now.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Labels

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions