c.srli HINT flagged as illegal

[mikaelsky]

Describe the bug
The c.srli HINT instruction variant is being flagged as illegal. Probably a follow on to the decompressor bug fix.

                -- Shift amount of 0 is not illegal but represent a HINT instruction
                -- if ((ci_instr16_i(12) or or_reduce_f(ci_instr16_i(6 downto 2))) = '0') then -- nzuimm = 0 -> RV32 custom / illegal
                if (ci_instr16_i(12) = '1') then -- shamt(5) /= 0 -> RV32 custom / illegal
                  illegal <= '1';
                end if;

To Reproduce
Inject the following code from riscvDV HINT test stream.

     6ae:	8281                	.short	0x8281
                  .2byte 0x8281 # kHintInstr

This one turns into c.srli x5,0 which on RV32C is a HINT instruction.

Expected behavior
A clear and concise description of what you expected to happen.

Screenshots
If applicable, add screenshots to help explain your problem.

Environment:

• OS
• GCC Version (RISC-V and native)
• Libraries used (clib, newlib, ...)

Hardware:

• Hardware version (x.x.x.x)
• Implemented CPU extensions, peripherals, ...
• Hardware modifications

Additional context
Add any other context about the problem here.

[stnolting]

Maybe I have messed this up during the last decompressor fix... 🤔
Anyway, thanks for identifying this loophole! I'll take care of that (after #794 is done 😉).

[mikaelsky]

No worries. The HINT test wasn't failing prior to the fix, so something changed somewhere :)

Right now have 1 randomly failing illegal instruction test that I'm trying to root source. Its a tad tricky to recreate though.

[stnolting]

Right now have 1 randomly failing illegal instruction test that I'm trying to root source. Its a tad tricky to recreate though.

In which instruction class? Also a compressed instruction?

[mikaelsky]

Right now have 1 randomly failing illegal instruction test that I'm trying to root source. Its a tad tricky to recreate though.

In which instruction class? Also a compressed instruction?

It seems to be in RV32I. From my first "decode" it seems the core is doing the right thing and performing a trap, but our reference is not.
All part of debugging. Sometimes the bug is not in the DUT :)

Its an SLLI instruction with imm[11:5] /= 0, which is an illegal instruction.

ASM snippet

    97f4:       cbcc95a3                sh      t3,-853(s9)
    97f8:       49011793                .word   0x49011793
                  .4byte 0x49011793 # kIllegalFunc7
                  la           a2, region_1+142 #start load_store_instr_stream_1

RISCV spec snippet from SLLI that states imm[11:5] must be 0.

[mikaelsky]

Welp the above has been resolved. No error on either side. The two cores weren't configured identically.