[TASK] LINT: P2 - MMU - Value of mtval is not being properly handled

[mustafa7755]

Is there an existing CVA6 task for this?

• [X] I have searched the existing task issues

Task Description

While going through the lint warnings i have found that value of mtval is not assigned correctly.

RTL reference:

• Following code checks for ITLB hit, if hit:
  • it then check for current privilege mode access, if access is not given we get a instruction page fault
  • if access to current privilege mode is given, then it checks whether we have pmp permissions to access that address or not, if not, then it generates instruction access fault.

            // ---------
            // ITLB Hit
            // --------
            // if we hit the ITLB output the request signal immediately
            if (itlb_lu_hit) begin
                icache_areq_o.fetch_valid = icache_areq_i.fetch_req;
                // we got an access error
                if (iaccess_err) begin
                    // throw a page fault
                    icache_areq_o.fetch_exception = {riscv::INSTR_PAGE_FAULT, {{riscv::XLEN-riscv::VLEN{1'b0}}, icache_areq_i.fetch_vaddr}, 1'b1};
                end else if (!pmp_instr_allow) begin
                    icache_areq_o.fetch_exception = {riscv::INSTR_ACCESS_FAULT, {{riscv::XLEN-riscv::PLEN{1'b0}}, icache_areq_i.fetch_vaddr}, 1'b1};
                end
            end

• fetch_exception is 129 bits long i.e., 64 + 64 + 1

    // Only use struct when signals have same direction
    // exception
    typedef struct packed {
         riscv::xlen_t       cause; // cause of exception
         riscv::xlen_t       tval;  // additional information of causing exception (e.g.: instruction causing it),
                             // address of LD/ST fault
         logic        valid;
    } exception_t;

• But, in the case where pmp permission are not given, value assigned to mtval is not properly handled

icache_areq_o.fetch_exception = {riscv::INSTR_ACCESS_FAULT, {{riscv::XLEN-riscv::PLEN{1'b0}}, icache_areq_i.fetch_vaddr}, 1'b1};

• Verilator complains that value generated by RHS is 137 bits, i.e.,

%Warning-WIDTHTRUNC: /home/umerimran/Music/cva6/core/mmu_sv39/mmu.sv:248:51: Operator ASSIGN expects 129 bits on the Assign RHS, but Assign RHS's REPLICATE generates 137 bits.
                                                                           : ... In instance ariane_testharness.i_ariane.i_cva6.ex_stage_i.lsu_i.gen_mmu_sv39.i_cva6_mmu
  248 |                     icache_areq_o.fetch_exception = {riscv::INSTR_ACCESS_FAULT, {{riscv::XLEN-riscv::PLEN{1'b0}}, icache_areq_i.fetch_vaddr}, 1'b1};
      |

• Two possible solutions here:

  • RTL should be using VLEN instead of PLEN, i.,e like this:

  icache_areq_o.fetch_exception = {riscv::INSTR_ACCESS_FAULT, {{riscv::XLEN-riscv::VLEN{1'b0}}, icache_areq_i.fetch_vaddr}, 1'b1};
  

  • or it should be using icache_areq_o.fetch_paddr instead of icache_areq_i.fetch_vaddr i.e., like this:

  icache_areq_o.fetch_exception = {riscv::INSTR_ACCESS_FAULT, {{riscv::XLEN-riscv::VLEN{1'b0}}, icache_areq_o.fetch_paddr}, 1'b1};
  

• RISC-V spec says:

If mtval is written with a nonzero value when a misaligned load or store causes an access-fault or
page-fault exception, then mtval will contain the virtual address of the portion of the access that
caused the fault.

• I might be wrong but in my opinion changing PLEN to VLEN would be the correct solution

Description of Done

When concerned RTL line would get fixed.

Associated PRs

No response

[JeanRochCoulon]

Sorry for the huge delay and thank for the detailed explanation. Yes, I agree "changing PLEN to VLEN would be the correct solution". A PR can be submitted