Bug Report: With WritebackStage=1, a write of minstreth/minstret drops the minstret update of the older instruction retiring in WB

Abierto
  • ¿Algo no está bien?
#2,573 0 comentarios 0 reacciones 0 asignados Ver en GitHub

Los mantenedores suelen responder en 2 días

Nadie ha tomado este issue todavía.

Evaluación

Dificultad
4/5
Tiempo estimado
3-5 días
Aptitud para principiantes
55/100
Tipo de issue
Error
Claridad
Bien especificado
Estado de actividad
Activo
Área
backend

Línea de trabajo

Start with rtl/ibex_counter.sv and the retirement path in rtl/ibex_cs_registers.sv; the report identifies how a same-cycle counter write overrides the older instruction’s retirement increment. Reproduce cases A and E using the attached bench and scripts, then inspect the counter update logic and existing counter tests. Done when the affected cases retain the older instruction’s increment and carry while the writing instruction remains uncounted.

Escrito por el modelo de indexación a partir del texto del issue.

Descripción

Type:Bug

Hello, I believe I have found a bug in this core.

Observed Behavior

With WritebackStage = 1, a write of minstreth (or minstret) drops the minstret increment of the older instruction retiring in WB in the same cycle. The CSR write happens in ID/EX while the increment of that cycle belongs to the older instruction:

  • a minstreth write keeps the old lower half, so the lower half misses the older instruction (cases A and B below);
  • a minstret write keeps the old upper half, so the older instruction's carry into minstreth is lost (case E).

This happens for any instruction directly followed by such a CSR write. #2446 fixed the writing instruction's own increment; this is the older instruction's.

case expected CHERIoT On RV32E WritebackStage = 0 (RV32E)
A: addi, then csrw minstreth, read minstret 1 0x0 0x0 0x1
B: c.nop, then csrw minstreth, read minstret 1 0x0 0x0 0x1
C (control): nothing in between 0 0x0 0x0 0x0
D (control): addi, then csrw minstret, x0 0 0x0 0x0 0x0
E: carry of the addi into minstreth, read minstreth 1 0x0 0x0 0x1

BranchTargetALU = 1 (the opentitan / maxperf* setting) gives the same as the default build.

Cause: ibex_counter loads the other half from the counter register without the same-cycle increment, and the write takes priority over that increment.

what where
a write replaces the counter's next value (we = either half written) rtl/ibex_counter.sv:35
a minstret (low) write keeps the old upper half rtl/ibex_counter.sv:36
a minstreth (high) write keeps the old lower half rtl/ibex_counter.sv:40
the write takes priority over the increment of the same cycle rtl/ibex_counter.sv:44
minstret increments on instr_ret_i, the WB-stage retirement rtl/ibex_cs_registers.sv:1586

Attached: simulation logs (evidence/shipped_*.log) and a formal counterexample (waveform/formal_cex.vcd, depth 4): csrrsi x8, minstreth, 1 writes minstreth in ID/EX while an older addi x0, x0, 0 retires in WB, and minstret goes from 9 to 0x1_0000_0009 instead of 0x1_0000_000a.

Expected Behavior

Case A reads minstret = 1 and case E reads minstreth = 1, as with WritebackStage = 0. RISC-V Privileged Specification:

The minstret CSR counts the number of instructions the hart has retired.

When XLEN=32, [...] writes change only bits 31-0; reads of the mcycleh, minstreth, mhpmcounternh, and mhpmeventnh CSRs return bits 63-32 of the corresponding register, and writes change only bits 63-32.

A possible fix: in ibex_counter, let a write replace only the half it writes and keep the same-cycle increment in the other half:

    counter_load[63:32] = counter_inc_i ? counter_upd[63:32] : counter[63:32];   // minstret (low) write: keep the carry
    counter_load[31:0]  = counter_val_i;
    if (counterh_we_i) begin
      counter_load[63:32] = counter_val_i;
      counter_load[31:0]  = counter_inc_i ? counter_upd[31:0] : counter[31:0];  // minstreth (high) write: keep the increment
    end

For a counter narrower than 64 bits the upper slice needs zero extension. This also changes mcycleh writes (the low half then counts the write cycle). The writing instruction stays uncounted (ibex_id_stage.sv:1209-1211).

Steps to reproduce the issue

Parameters: ibex_top with BaseIsa = ibex_pkg::BaseIsaRV32IorCHERIoT, RV32E = 1, WritebackStage = 1, other parameters at their defaults; cheriot_enable_i held On (CHERIoT mode) and, in a second run, Off (RV32E mode). Only WritebackStage = 1 is needed. ibex_configs.yaml sets it in opentitan, maxperf* and experimental-branch-predictor.

The upstream Simple System ties cheriot_enable_i off, so the attached bench tb_ibex_cheriot.sv instantiates ibex_top directly (see README.txt; +define+AB_WB0 builds WritebackStage = 0, +define+AB_BTALU builds BranchTargetALU = 1).

minstreth_wr.S (with crt.S, common.h, link.ld), case A:

  csrw minstreth, x0
  csrw minstret, x0
  addi x9, x0, 5            # older instruction, retires in WB ...
  csrw minstreth, x0        # ... in the cycle this one writes minstreth in ID/EX
  csrr x10, minstret        # expected 1

Case B uses c.nop instead of addi; C and D are controls; E writes minstret = 0xffffffff, retires an addi, writes minstret = 0 and reads minstreth.

  1. git clone https://github.com/lowRISC/ibex && cd ibex && git checkout 626034d7
  2. Run the attached script, which assembles the program, builds the bench with Verilator (+define+SYNTHESIS) and runs it in both modes: 
    sh run.sh <ibex checkout>
# assembles with: riscv32-unknown-elf-gcc -march=rv32emc_zicsr_zifencei_zcb -mabi=ilp32e -nostdlib -nostartfiles -T link.ld crt.S minstreth_wr.S
  3. Each SIG line is one case (A-E). Output: 
    CHERIoT mode:
SIG 00000000
SIG 00000000
SIG 00000000
SIG 00000000
SIG 00000000
RV32E mode:
SIG 00000000
SIG 00000000
SIG 00000000
SIG 00000000
SIG 00000000
    The WritebackStage = 0 build prints 1, 1, 0, 0, 1.

No changes to the Ibex source code.

My Environment

EDA tool and version:
Verilator 5.044 (simulation); riscv32-unknown-elf-gcc 16.1.0.

Operating system:
Red Hat Enterprise Linux 8.10

Version of the Ibex source code:
626034d7557ab85a6d989b13011b44296bad26fa (master, 2026-11-06), unmodified.

All of the relevant materials pertaining to the bug:

MINSTRETH_INC_bug.zip

Lenguaje dominante
SystemVerilog
Estrellas
2.2k
Forks
836
Merge medio
5 d 8 h
PR fusionados (30 d)
22

Preparar el entorno

Primeros pasos

  1. Lee el issue completo y luego la guía de contribución del proyecto.
  2. Comenta en el issue que vas a ocuparte — evita que dos personas hagan lo mismo.
  3. Haz un fork del repositorio y trabaja en una rama.
  4. Abre un pull request que haga referencia al número del issue.

Más de lowRISC/ibex

Todos los issues de lowRISC/ibex

Issues similares

Más issues de Backend & API Design

Recibe los nuevos issues en tu correo

Un resumen breve de issues de GitHub para principiantes.