[HW] Floating-point compare instructions

[rgiunti]

PR purpose

This PR implements the HW support for the vmfne, vmfeq, vmfle, vmflt, vmfge, vmfgt instructions.

Main HW changes

• Add decode entries for vmfne.vv/vmfne.vf using RUP as rounding mode encoding to signal boolean result inversion to the VFU
• Add VFCMP result compaction logic in align_result: extract bit 0 from each SEW-wide FPU result slot and pack them contiguously into the vrf data output
• Add selective byte-enable for VFCMP in operand_req_proc: only enable vl/8 bytes rounded to higher integer to preserve tail-undisturbed bits in the destination register, with saturation check

[DiyouS]

Looks good to me and seems only with tiny hardware overhead. Let's wait CI passed and merge it
Out of curiosity, have you tried backend for the changes?

[rgiunti]

Looks good to me and seems only with tiny hardware overhead. Let's wait CI passed and merge it Out of curiosity, have you tried backend for the changes?

Yes I performed a synthesis in gf22. From the area report it seems that the VFU area is almost the same. Regarding the CI failure I can't check the ETH pipeline but I'm pretty sure that it fails for a test of vmfne. It is for a known bug in the pulp0.1.3 version that is used by Spatz. I opened a PR in the cvfpu pulp repo for fixing it.

[Navaneeth-KunhiPurayil]

Looks good to me and seems only with tiny hardware overhead. Let's wait CI passed and merge it Out of curiosity, have you tried backend for the changes?

Yes I performed a synthesis in gf22. From the area report it seems that the VFU area is almost the same. Regarding the CI failure I can't check the ETH pipeline but I'm pretty sure that it fails for a test of vmfne. It is for a known bug in the pulp0.1.3 version that is used by Spatz. I opened a PR in the cvfpu pulp repo for fixing it.

Yes, this is the only test that is failing, we could comment the specific test case that is failing for now and then enable it again later after bumping fpnew.

[Navaneeth-KunhiPurayil]

Hi @rgiunti @DiyouS ,
I believe we can merge this PR, since it looks good and can pass CI.

However, there is an edge case, for largest vector length i.e. LMUL=8 and SEW=8-bit which requires 2 x 256-bit word writes to VRF. But since currently write enable depends on the result_tag.last only one write is written.

I suggest we merge this PR, since anyways there needs to be a FPU bump to fix a failing test case these can be done together later.

What do you think?

[DiyouS]

Can we remove these trailing space found by the robot before merging?

[DiyouS]

GitLab CI failed due to some internal network issues. I re-ran it on GitLab and it passed without problem. I think we can merge it @Navaneeth-KunhiPurayil

[Navaneeth-KunhiPurayil]

The CI passes, @rgiunti let's merge