Reserved compressed instructions do not trigger illegal instruction exception

[mikaelsky]

Describe the bug
When we hit the core with a reserved compressed instruction it doesn't trigger an illegal instruction exception.
This behavior in the RISCV spec is undefined/up to the implementer.

RISCV spec Vol I chapter 2.2.

From what I can gather from the non-compressed instruction behavior when the decoder hits reserved/unspecified space an illegal instruction exception is indeed triggered.
Hence the assumption that this is unintended behavior.

To Reproduce
This is the randomized code stream from riscvDV.

    42c2:	01a212a3          	sh	s10,5(tp) # 5 <_start+0x5>
    42c6:	00009e7d          	.word	0x00009e7d
                  .4byte 0x9e7d # kReservedCompressedInstr kReservedC1
                  lh           s11, -43(t1)
    42ca:	fd531d83          	lh	s11,-43(t1)

The ref vs dut comparison showing that the ref takes an illegal instruction trap, but the dut just rolls on and tries to execute the undefined instruction.

Warning (RISCV_UDEC) CPU 'refRoot/cpu' 0x000042c6 9e7d     undef: Undecoded instruction
Info (IDV) Instruction executed prior to mismatch '0x42c2(main_113_0_t+39e): 01a212a3 sh      x26,5(x4)'
Error (IDV) PC mismatch (HartId:0, PC:0x0000eed4 mtvec_handler+0):
Error (IDV) Mismatch 0>
Error (IDV)   . dut:0x000042c6 main_113_0_t+3a2
Error (IDV)   . ref:0x0000eed4 mtvec_handler+0
Error (IDV) Insn. bit pattern mismatch (HartId:0, PC:0x0000eed4 mtvec_handler+0):
Error (IDV) Mismatch 1>
Error (IDV)   . dut:9e7d     undef
Error (IDV)   . ref:12f1     addi    x5,x5,-4
Error (IDV) GPR register value mismatch (HartId:0, PC:0x0000eed4 mtvec_handler+0):
Error (IDV) Mismatch 2> GPR x5
Error (IDV)   . dut:0x0001cce4 (not updated)
Error (IDV)   . ref:0x0001cce0
Error (IDV) tb.riscv_tb.idv_trace2api.state_compare @ 1316380.00 ns: MISMATCH

Expected behavior
From the behavior of the rest of the core I would expect the reserved instruction to trip an illegal instruction, I could be wrong though.

Screenshots
NA

Environment:

• OS: RHEL 7
• GCC Version 13.2
• Libraries used newlib

Hardware:

• Hardware version (1.9.3.0) - patched with submitted bug fixes

Additional context
0x9E7D

1001_1110_0111_1101

OP: 01 -> CB, CI, CJ, or CS type instructions

funct3: 100 ->

• c.srli, c.srai, c.andi both are defined as funct3 100_x00/x01/x10
• c.and/or/xor/sub which are defined as funct3 100_01111/01110/01101/01100
  expanding funct3 to match the extended decoding we get:
• 100_111 where 111/11100 falls outside the 2 MSBs being x0 or 01 as the 2 MSBs are 11.

Looking at the compressed instruction decoder OP = "01" we get:
when others => -- 100: C.SRLI, C.SRAI, C.ANDI, C.SUB, C.XOR, C.OR, C.AND, reserved

In here we only check bits 11:10 ignoring bit 12
case ci_instr16_i(11 downto 10) is

From a quick handy decoder we get:

Where it seems that bit 12 for non c.srli/c.srai/c.andi we assume its an alu operation
when others => -- "11" = register-register operation
If we want to generate and illegal instruction here we should add:

                if (ci_instr16_i(12) = '1') then -- reserved instruction space
                  illegal <= '1';
                end if;

from the c.srli/c.srai decoding path.

[mikaelsky]

I do have small local patch that fixes the issue that I can quickly create a PR for. Just want to be sure we agree on the expected behavior as it is undefined.

[stnolting]

Hey @mikaelsky

Just want to be sure we agree on the expected behavior as it is undefined.

One of the core's core principles (😅) is the trapping on any kind of illegal, unsupported or malformed instruction words. So yeah, we should close this instruction decoding loophole.

I do have small local patch that fixes the issue that I can quickly create a PR for.

Your fix looks good. So, go for it! 👍

[mikaelsky]

PR created.

[mikaelsky]

Note: the fix passes a couple of seeds of our randomly generated riscvDV undefined compressed instruction test so seems good.