Add decoder for C extension

[tandr3w]

Issue #239

Implemented decompression for all rv32 instructions other than F and D extension ones

Also added checking for illegal/reserved and unimplemented instructions though I don't think we have a way to handle that properly yet?

Note C.JAL and C.JALR need extra handling to work properly (I think)

[github-actions]

🔧 DE1-SoC Synthesis Report Summary Diff

• RV32I

  1. Fitter Summary

     @@ -1,4 +1,4 @@
     -Fitter Status : Successful - Tue Jun  9 23:39:28 2026
     +Fitter Status : Successful - Sun Jun 14 03:13:41 2026
      Quartus Prime Version : 25.1std.0 Build 1129 10/21/2025 SC Lite Edition
      Revision Name : utoss-risc-v
      Top-level Entity Name : top

  2. Fitter by entity
     No changes detected

  3. Timing
     No changes detected

• RV32IB

  1. Fitter Summary

     @@ -1,4 +1,4 @@
     -Fitter Status : Successful - Tue Jun  9 23:39:07 2026
     +Fitter Status : Successful - Sun Jun 14 03:13:41 2026
      Quartus Prime Version : 25.1std.0 Build 1129 10/21/2025 SC Lite Edition
      Revision Name : utoss-risc-v
      Top-level Entity Name : top

  2. Fitter by entity
     No changes detected

  3. Timing
     No changes detected

---

Comparing synthesis results from main branch vs. this PR

[TheDeepestSpace]

i think since there are a lot compositions here, im wondering if we can cook up a function here like build_<opcode>_instr that can be passed all the needed parameters for a particular opcode, and this would make things a bit more readable here + force a bit more wire width checking as part of compilation, i.e. in my head it looks like something along the lines of

Suggested change

	instr_out = {ciw_imm, 5'd2, 3'b000, rd_prime, IType_logic}; // C.ADDI4SPN
	instr_out = build_immlogic_instr( .imm (ciw_imm), .rs1 (5'd2), .funct3 (3'b000), .rd (rd_prime) ); // C.ADDI4SPN

[tandr3w]

Sure but we would probably need to add like 8 functions to get all the composition types

[TheDeepestSpace]

I think that's fine, we might be able to reuse them in tests maybe, but even if not -- there are essentially just for readability, and don't add any overhead at runtime.

[TheDeepestSpace]

i think we can just say its illegal in this case, since the spec does not even define 2'b11 as its own quadrant

[TheDeepestSpace]

can you point to the spec for this condition? i did not find it in C extension spec, might be elsewhere

[tandr3w]

I think it's because instr_c[12] represents shamt[5]
"For RV32C, shamt[5] must be zero; the code points with shamt[5]=1 are designated for custom extensions."