[test-triage] FPGA chip_power_sleep_load stuck at wait_for_interrupt

[moidx]

Hierarchy of regression failure

Chip Level

Failure Description

The test currently gets stuck in the FPGA right after entering wfi via wait_for_interrupt() call.

I00000 ottf_main.c:126] Running sw/device/tests/chip_power_sleep_load.c
I00001 chip_power_sleep_load.c:136] Running CHIP Power Sleep Load test
I00002 chip_power_sleep_load.c:154] GPIO active
I00003 chip_power_sleep_load.c:161] wakeup type:0. wakeup reason: 0x00
I00004 chip_power_sleep_load.c:200] RV Timer active
I00005 chip_power_sleep_load.c:260] Alert ping is active
I00006 chip_power_sleep_load.c:323] PWM active
I00007 chip_power_sleep_load.c:336] OTP periodic checks active
I00008 chip_power_sleep_load.c:359] AON Timer active
I00009 chip_power_sleep_load.c:378] Power Manage configured
I00010 chip_power_sleep_load.c:381] all HW is active
-- Test timed out at 2022-11-22 00:51:37 UTC --

TIMEOUT: //sw/device/tests:chip_power_sleep_load_fpga_cw310_rom (Summary)

Steps to Reproduce

./bazelisk.sh test   --define DISABLE_VERILATOR_BUILD=true   \
    --test_tag_filters=cw310   \
    --test_output=streamed   \
    //sw/device/tests:chip_power_sleep_load

Tests with similar or related failures

• chip_power_idle_load (this test is currently not using wfi to avoid this problem)

[moidx]

The test should pass by increasing the timer count by x100.

[a-will]

Might also eliminate the race if we have the NMI handler trigger a software interrupt from the PLIC. We could leave the global interrupt-enable disabled, but unmask the software interrupt-enable. Then, we shouldn't get stuck at WFI.

I'm not totally sure if there is a valid pwrmgr configuration for which that doesn't work, though.

[a-will]

Did this get fixed by #16518 ? Can it be closed?

[a-will]

I tested this on the FPGA, and the behavior appears to be fixed. The tests pass on both test ROM and ROM (as long as I don't use a bitstream from before d7a31b5 and splice a ROM from after, but that's not related, hehe).