BUG with Packed Load Upper Immediate Instructions (Incorrect immediate width)

[mattiamirigaldi]

PLUI.H, PLUI.W: Packed Load Upper Immediate (Halfword and Word).
Spike incorrectly processes the 10-bit immediate for the plui instructions. It applies the wrong shift amount (appearing to shift an 8-bit value by 8 or 24, rather than shifting a 10-bit value by 6 or 22).
Furthermore Spike fails to properly sign-extend 10-bit immediates when the MSB (bit 9) is set.

Example 1: plui.h (Positive Immediate)

• Input: imm = 0xCC
• Operation: imm[9:0] << 6 → 0xCC << 6 = 0x3300
• Expected result: 0x3300330033003300
• Spike result: 0xcc00cc00cc00cc00

Example 2: plui.h (Sign-Extended Immediate)

• Input: imm = 0x3CC
• Operation: sign_extend(16, 0x3CC << 6) → sign_extend(16, 0xF300) = 0xF300
• Expected result: 0xf300f300f300f300
• Spike result: 0xccc0ccc0ccc0ccc0

Example 3: plui.w (Positive Immediate)

• Input: imm = 0xCC
• Operation: imm[9:0] << 22 → 0xCC << 22 = 0x33000000
• Expected result: 0x3300000033000000
• Spike result: 0xcc000000cc000000

Example 4: plui.w (Sign-Extended Immediate)

• Input: imm = 0x3CC
• Operation: sign_extend(32, 0x3CC << 22) → sign_extend(32, 0xF3000000) = 0xF3000000
• Expected result: 0xf3000000f3000000
• Spike result: 0xccc00000ccc00000

Possible Cause: Spike is treating the immediate as an 8-bit value rather than a 10-bit value.

---

Spike hash : de82903

[aswaterman]

@chihminchao @binno

[mattiamirigaldi]

Update: re-tested these instructions against a newer Spike commit : b2d6fbf
I can confirm that this issue has not yet been resolved. Spike is still failing to properly process the 10-bit immediate.

Here are the latest test results verifying that Spike is still generating the incorrect 0xccc0... pattern instead of the correctly shifted and sign-extended 0xf300... pattern.

Failed plui.h Test (Instruction: 0xf1ccae1b, Immediate: 0x3cc)

[FAIL] Tx #1) rs1=0xe29034a401aa237a, rs2=0xcef61afc7e2f91f6, rd=0x64d3a2252598bd8a (instr ->  plui.h : 0xf1ccae1b)
  Expected (Spike): 0xccc0ccc0ccc0ccc0 
  Got (DUT):        0xf300f300f300f300 

Failed plui.w Test (Instruction: 0xf3ccae1b, Immediate: 0x3cc)

[FAIL] Tx #8) rs1=0xd632cff494aa4a10, rs2=0xb333306b1fa2cdee, rd=0xf1d8c885e028ad2a (instr ->  plui.w : 0xf3ccae1b)
  Expected (Spike): 0xccc00000ccc00000 
  Got (DUT):        0xf3000000f3000000 

The underlying cause appears to be the same: Spike is still truncating the immediate to 8 bits and applying the wrong shift amounts, failing to account for the full 10-bit width and bit 9 sign-extension defined in the ISA proposal.

[aswaterman]

Hmm, looks like Spike is doing the right thing here. From the spec, the value to be loaded for PLUI.H takes instruction bit 24 (== 0x1) and places it in bit 6 and takes instruction bits 23:15 (== 0x199) and place them into bits 15:7, giving us (0x199 << 7) + (0x1 << 6) == 0xccc0.

There is a flaw in the spec that the pseudocode and the instruction encoding diagram don't match each other: the instruction diagram describes the immediate as being 16 bits (with bits 5:0 implicitly 0), whereas the pseudocode describes it as being 10 bits, hence needing a left shift. The diagram is more consistent with how the base ISA spec describes the LUI instruction. The pseudocode should be changed to delete the declaration of imm_h and simply assign imm to each piece of the result.

You might want to file an issue on the P spec repo accordingly.

Also, sign extension is a red herring because the immediate is specified to include the sign bit, so there's nothing to extend.