Vector VM: SoftVector integration

[JoGei]

Currently, ETISS does not integrate a full virtual machine for vector extension. A "softvector" module similar to "softfloat" would be necessary to have somewhat performant vector processor simulation.

Past Efforts:

There have been efforts to integrate such things into ETISS in the past:

• Add RISC-V Vector Extension Support #76 -> never merged
• A prototype implementation tum-ei-eda/softvector targeting RISC-V Vector v0.9 for academic purpose on Crypto Acceleration https://ieeexplore.ieee.org/abstract/document/9424273

Promising Third-Party Effort

A new promising effort is put forward by this repo: minres/softvector
Since it's used in the DBT-RISE-RISCV, it might be a good fit for ETISS.

Challenges

Unique challenge for ETISS in order to integrate such efforts:

• ETISS JIT needs a trampoline into softvector from within the JIT compiled Dynamic Binary Translated (DBT) code.
  • minres/softvector vector processor is templated, e.g., VLEN, such that our C-only JIT code would need some "help"...
• Dispatch functions have to be implemented in the CoreDSL sources for a large number of vector instructions
  • Support in RISC-V Architecture sources tum-ei-eda/etiss_arch_riscv.
    • Per OpCode count of working solution in dbt-rise-riscv, an estimated 626 RVV vector instructions would have to be implemented
  • Support in M2-ISA-R CoreDSL->ArchImpl generator tum-ei-eda/M2-ISA-R
• ...

[PhilippvK]

For reference, the current work-in-progress ETISS RVV support developed @ TUW:

• ETISS Fork: https://github.com/danielschloms/etiss/commits/daniel-dev/
• CoreDSL Code: https://github.com/danielschloms/RISCV_ISA_CoreDSL/blob/daniel-dev/RVV.core_desc
• Softvector Fork: https://github.com/danielschloms/softvector/tree/daniel-dev/src/target/riscv

[PhilippvK]

I do not see any issues with regard to the CoreDSL integration. MINRES softvector lib uses a similar style based on extern functions. Our approach uses one function per instruction, will minres/softvector is of course more reuse-focussed.

But the behavior is quite similar in the end:

        extern void vector_imm_op(unsigned<VLEN> V[32], unsigned<6> funct6, unsigned<3> funct3, unsigned<64> vl, unsigned<64> vstart, unsigned<64> vtype, unsigned<1> vm, unsigned<5> vd, unsigned<5> vs2, signed<64> imm, unsigned<3> sew);
        ...
        VADD__VI {
            encoding: 6'b000000 :: vm[0:0] :: vs2[4:0] :: simm[4:0] :: 3'b011 :: vd[4:0] :: 7'b1010111;
            assembly: "{vname(vd)}, {vname(vs2)}, {simm}, {vm}";
            behavior: {
                if(illegal_normal(vd, vm)) raise(0, RV_CAUSE_ILLEGAL_INSTRUCTION);
                else {
                    if(vl > vstart)
                        vector_imm_op(V, 6'b000000, 3'b011, vl, vstart, vtype, vm, vd, vs2, (signed<ELEN>)(signed<5>)simm, sew());
                    vstart = 0;
                }
            }
        }

vs.

        extern unsigned<8> vadd_vi(char* pV, unsigned<16> pVTYPE, unsigned<8> pVm, unsigned<8> pVd, unsigned<8> pVs2, unsigned<8> pVimm, unsigned<16> pVSTART, unsigned<16> pVLEN, unsigned<16> pVL);
        ...
        VADD_VI {
            encoding: 6'b000000 :: vm[0:0] :: vs2[4:0] :: simm5[4:0] :: 3'b011 :: vd[4:0] :: 7'b1010111;
            assembly: "{name(vd)}, {name(vs1)}, {imm}, {name(vm)}";
            behavior: {
                unsigned<XLEN> _vtype = CSR[VTYPE_ADDR];
                unsigned<XLEN> _vstart = CSR[VSTART_ADDR];
                unsigned<XLEN> _vl = CSR[VL_ADDR];
                unsigned<XLEN> _vlen = CSR[VLENB_ADDR]*8;

                unsigned<XLEN> ret = vadd_vi(V, _vtype, vm, vd, vs2, simm5, _vstart, _vlen, _vl);
                if(ret != 0){
                    CSR[VSTART_ADDR] = ret >> 8;
                    raise(0, 2);
                } else{
                    CSR[VSTART_ADDR] = 0;
                }
            }
        }

The error handling of course need some work as well as adding support for passing the pointer to V with the correct data type in M2-ISA-R (which currently needs manual fixes (etiss_uint8 -> void*)).

We might need to come up with some C-level handlers to deal with the C++ templates but that should be doable...

softvector_vector_imm_op_vlen1024_8b -> softvector::vector_imm_op<${vlen}, uint8_t>
softvector_vector_imm_op_vlen1024_16b -> softvector::vector_imm_op<${vlen}, uint16_t>
...

I am unsure on how to generate automatically with M2-ISA-R, but doing it manually should be very straightforward...