Interrupt from HWPE

[christian-lanius]

I want to add an accelerator in the SoC, so I enable the HWPE with the respective flag in the testbench and I can successfully run the example accelerator as well as the datamover example (with some minor changes), however, the wait for the accelerator does not work as far as I can tell:
In the example HWMAC code (https://github.com/pulp-platform/hwpe-tb/blob/master/sw/tb_hwpe.c#L73) a wfi instruction is used to pause the program until the accelerator is done. However, in my case the code never continues beyond that point. I see the insn in the tracer appear before the event triggers, but then nothing happens.

This happens with the example code and the MAC engine, as well as with a minimal example with the datamover example.
My understanding from the RISC-V spec is that I don't have to enable any interrupts or anything for this to work: "The Wait for Interrupt instruction (WFI) provides a hint to the implementation that the current hart can be stalled until an interrupt might need servicing [...] The WFI instruction can also be executed when interrupts are disabled."
Even forcing the irq_i input of the core to a non zero value, the core does not continue execution and the interrupt is not acknowledged by the core.
Additionally, just looking at the code, it appears as if the HWPE interrupt reside in the s_events vector in soc_peripherals at 140+141 code. However the soc_event_generator is parameterized to expect them at location 7+8 code as far as I can tell, or is that a misunderstanding?

Is there an example piece of code or some kind of test I can perform to see how interrupts are working?

[christian-lanius]

I have found a way to wait for the interrupt, specifically what needs to be done is:

• Enable the interrupt in the c-code (itc_mask_set_set(ARCHI_FC_ITC_ADDR, 0x40000000);)
• There is a difference between the documentation p.9 and the pulp runtime link, where to interrupt controller is actually located in the memory map. The value from the documentation seems to be correct (0x00009000), so I changed that in the memory_map.h file
• Change in the verilog code the parameter pointing to the index of the hwpe in the event vector from 7 to 140 link
• Set the mie_bypass signal so that the interrupt actually propagates into the core

The naive way to do the last thing was for me:

asm volatile (" \
    li t2, 0x40000000; \
	CSRRW x0, mie, t2"
  );

@bluewww can you check if my assessment of the 2 issues (wrong offfset in the memory_map.h file and wrong parameter is the soc_peripherals.sv) is correct? If wanted, I can prepare pull requests for the issues in the respective repos then.

[christian-lanius]

So after further testing, I am a little bit stumped: It apparently does not matter if ARCHI_FC_ITC_ADDR is correct or not, as long as I write to it. I tested offsets

• 0x00009000 (from documentation)
• 0x00009800 (current value)
• 0x00009100
• 0x00009140
• 0x00009160: Does not work
• 0x00009144: Does not work

Thus, I believe this is happening because of address aliasing. It is probably best to either fix the pdf file or the c-header to be aligned with each other.

[bluewww]

The FC_ITC (apb_interrupt_cntrl) is visible from two addresses due to aliasing that is right. I think we often used 0x00009800 but looking at the rtl 0x00009000 makes more sense. Both should work.