cv32e41p_interrupt.md

Interrupts management in the CV32E41P

In the CV32E41P current code, interrupts are mapped in a 32-bit signal. https://github.com/litex-hub/pythondata-cpu-cv32e41p/blob/master/pythondata_cpu_cv32e41p/system_verilog/rtl/cv32e41p_core.sv#L85

This interrupt signal goes into the mip CSR: https://github.com/litex-hub/pythondata-cpu-cv32e41p/blob/master/pythondata_cpu_cv32e41p/system_verilog/rtl/cv32e41p_int_controller.sv#L59-L70

LiteX software layer uses two fast interrupts (timer at index 1, uart at index 0). It must be mapped on bits 17 and 16 (the 2 first fast interrupts). => Added a 16-bit padding vector.

Why did it work with the CV32E40P?

Hardware interface of the CV32E40P included in LiteX is a bit different: https://github.com/litex-hub/pythondata-cpu-cv32e40p/blob/f66110f2e53f4d07b175582ba562027a4b6b0508/pythondata_cpu_cv32e40p/system_verilog/rtl/riscv_core.sv#L116-L121

input  logic        irq_software_i,
input  logic        irq_timer_i,
input  logic        irq_external_i,
input  logic [14:0] irq_fast_i,
input  logic        irq_nmi_i,
input  logic [31:0] irq_fastx_i,

The layout of the mip CSR in this older CPU is:

• 15 fast interrupts (not 16 like in the CV32E41P).
• 1 external interrupt.
• 1 timer interrupt.
• 1 software interrupt.
• Other bits are not used.

The interrupt signal in the LiteX Python wrapper is directly mapped on the irq_fast_i signal: https://github.com/pcotret/litex/blob/cv32e41p_patch/litex/soc/cores/cpu/cv32e40p/core.py#L437 Therefore, for the mip register, we have a direct wire : https://github.com/litex-hub/pythondata-cpu-cv32e40p/blob/master/pythondata_cpu_cv32e40p/system_verilog/rtl/riscv_cs_registers.sv#L324-L331