Hi, I encountered a problem with the integration of the cv34e40p core into Pulpissimo.
The cv32e40p core features a 32 bit input irq_i. According to the core's documentation, the individual bits of irq_i match the mapping of the MIE (machine interrupt enable) CSR, e.g., irq_i[11] indicates an machine external interrupt. If an interrupt is triggered, the corresponding bit of irq_i is compared with the bit in MIE to check if the interrupt is enabled.
However, in Pulpissimo, the irq_i input is directly connected to the core_irq_x vector, which expands the interrupt ID assigned in the event unit to positions in core_irq_x (E.g.: interrupt ID 10 results in _core_irq_x = 32'h0000000a). This is not compliant with the irq_i input of the cv32e40p core. A compliant instantiation would map all external (machine-level) interrupts to irq_i[11]. If individual external interrupt sources have to be distinguished from each other (and enabled individually) inside the core, this could (possibly?) be done by mapping the IDs into irq_i[31:16]. Some other cores provide features like a custom IRQ-X CSR for this purpose.
I encountered this behavior when running the pulp-freertos port. There, the timer low peripheral is used to create periodic interrupts for preemptive scheduling. The corresponding interrupt line is assigned the ID 10. Like described above, this results in checking if MIE[10] is set. However, according to the ISA and the cv32e40p implementation, MIE[10] is reserved/always 0 and should not have any effect.
In case you want to re-create the issue, I used the blinky template (hello_world won't show the issue, because it does not schedule preemptively) and simulated with QuestaSim 2020.4_4 I created a provisionally software fix for my experiments, but this could also be fixed by adjusting the instantiation in fc_subsystem.sv.
Hi, I encountered a problem with the integration of the cv34e40p core into Pulpissimo.
The cv32e40p core features a 32 bit input
irq_i. According to the core's documentation, the individual bits ofirq_imatch the mapping of the MIE (machine interrupt enable) CSR, e.g.,irq_i[11]indicates an machine external interrupt. If an interrupt is triggered, the corresponding bit ofirq_iis compared with the bit in MIE to check if the interrupt is enabled.However, in Pulpissimo, the
irq_iinput is directly connected to thecore_irq_xvector, which expands the interrupt ID assigned in the event unit to positions incore_irq_x(E.g.: interrupt ID 10 results in _core_irq_x = 32'h0000000a). This is not compliant with theirq_iinput of the cv32e40p core. A compliant instantiation would map all external (machine-level) interrupts toirq_i[11]. If individual external interrupt sources have to be distinguished from each other (and enabled individually) inside the core, this could (possibly?) be done by mapping the IDs intoirq_i[31:16]. Some other cores provide features like a custom IRQ-X CSR for this purpose.I encountered this behavior when running the pulp-freertos port. There, the timer low peripheral is used to create periodic interrupts for preemptive scheduling. The corresponding interrupt line is assigned the ID 10. Like described above, this results in checking if
MIE[10]is set. However, according to the ISA and the cv32e40p implementation,MIE[10]is reserved/always 0 and should not have any effect.In case you want to re-create the issue, I used the blinky template (hello_world won't show the issue, because it does not schedule preemptively) and simulated with QuestaSim 2020.4_4 I created a provisionally software fix for my experiments, but this could also be fixed by adjusting the instantiation in fc_subsystem.sv.
Best regards, Johannes