[rgiunti]

Fix vector configuration instructions and vtype handling

This PR fixes several RVV 1.0 compliance issues in how Spatz handles the configuration-setting instructions (vsetvli, vsetivli, vsetvl) and the resulting vtype state.

Changes

1. Read vtype.vill at bit XLEN-1
csrr vtype returned the packed vtype_t struct, so vill appeared at bit 8. RVV requires vill at bit XLEN-1. The CSR read now returns vill at bit 31, bits [30:8] as zero, and vma/vta/vsew/vlmul in [7:0].

2. vsetivli with uimm = 0
The rs1 == x0 special cases (AVL = VLMAX when rd != x0, keep vl when rd == x0) were also applied to vsetivli. For vsetivli, bits [19:15] are a 5-bit immediate AVL, not a register index. vsetivli rd, 0, ... now sets vl = 0 as the spec requires.

3. Support LMUL = 1/8 and fix the SEW/LMUL legality check

• LMUL_F8 was always flagged as illegal. It is now accepted, and VLMAX is computed with >> 3.
• The SEW <= LMUL * ELEN check compared log2(LMUL) + log2(ELEN) against the vsew encoding instead of log2(SEW) = vsew + 3. As a result, illegal combinations such as e64, mf2 with ELEN = 64 were accepted. The check now sets vill for them.

4. Check vill for vmv.x.s / vfmv.f.s
These instructions are marked is_scalar, so the issue stage skipped the vill check and executed them with an illegal vtype. VFU instructions that are is_scalar but read vs2 are now rejected as illegal when vill = 1.

5. Reserved vtype bits
Non-zero reserved bits now produce vill = 1 and vl = 0:

• vsetvli: zimm[10:8] (instr[30:28])
• vsetivli: zimm[9:8] (instr[29:28])
• vsetvl: rs2[XLEN-1:8], which also covers a vill bit already set in rs2

The controller treats an incoming vtype with vill set as illegal.

Testing

This features have been verified with the tests included in the PR 168 of the spatz cluster repo

[rgiunti]

Hi @Navaneeth-KunhiPurayil I've just rebased and updated the bender lock in PR #168 could you please run the CI? Thanks!

[Navaneeth-KunhiPurayil]

Thanks, LGTM, i will trigger a CI check