decoder: reject reserved same-format FP conversions

[124107157-KV]

• I have searched for similar pull requests
• I am a human engaging in an interpersonal interaction. During this interaction, my words are my own and are not generated. If relevant, I provide links to my sources.

Why is this PR needed?

The scalar FCVT_F2F decode path validates the source and destination
floating-point formats independently, but it does not reject conversions
where the source and destination formats are the same.

As a result, reserved same-format encodings such as the equivalent of
fcvt.s.s and fcvt.d.d are accepted by CVA6 instead of being rejected
by the decoder.

Spike treats these encodings as illegal instructions, so executing them
causes CVA6 and Spike to diverge during ISS co-simulation.

What does this PR change?

Add an additional legality check in the scalar FCVT_F2F decoder path
that rejects an instruction when its source floating-point format matches
its destination format.

A directed regression test, fcvt-same-format-rv64, is also added. It
checks that:

• legal fcvt.s.d remains accepted;
• legal fcvt.d.s remains accepted;
• reserved same-format S-to-S encoding raises an illegal-instruction
  exception;
• reserved same-format D-to-D encoding raises an illegal-instruction
  exception;
• reserved FP16-to-FP16 encoding raises an illegal-instruction exception;
• reserved FP16ALT-to-FP16ALT encoding raises an illegal-instruction exception;
• FP16-to-FP16ALT and FP16ALT-to-FP16 cross-format conversions remain accepted.

The test also verifies the exception cause and the address of each
faulting instruction.

Verification

Tested with:

cv64a6_imafdc_sv39

Before the RTL fix:

• fcvt-same-format-rv64
  • CVA6: failed with tohost = 1
  • Spike: raised illegal-instruction exceptions for both reserved
    same-format encodings

After the RTL fix:

• fcvt-same-format-rv64
  • PASS
  • 136 instructions matched between CVA6 and Spike

Existing floating-point conversion regressions:

• rv64uf-p-fcvt

  • PASS
  • 76 instructions matched

• rv64ud-p-fcvt

  • PASS
  • 104 instructions matched

XF16/XF16ALT-specific verification:

• FP16 -> FP16ALT: accepted
• FP16ALT -> FP16: accepted
• FP16 -> FP16: illegal instruction
• FP16ALT -> FP16ALT: illegal instruction
• test completed with tohost = 0

Final local regression report:

• 6 PASSED
• 0 FAILED

Additional checks:

• verible-verilog-format --inplace core/decoder.sv
• git diff --check

Fixes #3494

[IhsaneTahir]

Hi @124107157-KV,

I understand that XF16ALT has a special encoding that differs from the other formats. But why isn't there a second arm that raises an illegal_instr when a same-format conversion in XF16ALT happens?

[124107157-KV]

Hi @124107157-KV,

I understand that XF16ALT has a special encoding that differs from the other formats. But why isn't there a second arm that raises an illegal_instr when a same-format conversion in XF16ALT happens?

Good point. I followed the issue's suggested patch, which intentionally left XF16ALT unchanged. Since XF16ALT uses fmt=10/rm=101 for the destination and rs2[22:20]=110 for the source, I'll add the equivalent ALT-to-ALT rejection and a regression while keeping FP16↔FP16ALT conversions legal.