Repository navigation
Description
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_systemwith 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::RegFileFFReproduction
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 0link.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.sRun Spike:
spike -m0x100000:0x30000 --isa=rv32e_zicsr --priv=mu --log-commits ./build/test.elf 2> spike.logRun 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.logCompare 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
h-filali commentedon Nov 6, 2026
Hi @huntersubmit thanks for flagging this issue.
This issue here seems to be related to #2547.
RV32EwithWritebackStage = 0is currently not a tested or officially supported configuration for the core. As a result, this is a low priority issue for us right now.