Simulate low power mode

[timsifive]

I'm not sure what the right place to discuss this is, so let's try here.

The Debug Spec allows a hart to be unavailable, which can be used by cores where harts can be powered down, or even hot plugged. This leads to all kinds of fun corner cases in the debugger. I'd like to support that in OpenOCD and write tests in riscv-tests/debug. That needs a target, though.

I'd like to somehow extend spike to support a low power mode. Unfortunately there is no RISC-V standard that mentions how this works. For my purposes:

1. Low-power mode can be equivalent to wfi, but it has to actually suspend instruction execution until an interrupt arrives. I remember reading something that makes it sound like wfi in spike might take some shortcuts where sometimes it will continue executing even if there was no interrupt taken. (Also halt request should be ignored when the hart is in low power mode.)
2. I need some way to put the hart into and out of low power mode. Easiest would be to add some custom Debug Module registers (which the spec leaves space for) that make this happen.

Would a change like this be accepted into spike, or is it getting too niche and non-standard?

[aswaterman]

Re: (1), the recently merged PR #1197 makes it so that WFI really does suppress instruction execution if no unmasked interrupt is pending. So presumably a low-power mode can either mimic or piggy-back onto that scheme.

Re: (2), adding custom registers seems like technical debt right out of the gate. Maybe just do this on a branch of Spike instead of upstreaming it?

[sifiverobert]

Hi Tim, Full support for this. Low-power is NOT 'niche' ...

Debugging in low-power conditions was never well defined in OLA ("Other Leading Architecture") and some SoC designers defined extra scan chains, so debugger could test power-down and even prevent true power-down ...

RISC-V Debug Spec at least provides good visibility into non-accessible state of core[s].

IMO having some (good?) model is important.

[sifiverobert]

@aswaterman - agree with (1), i.e. extending WFI handling into core being more 'dead' (debug not possible). As far as (2) it is IMO better to provide this on upstream, but guard it by an option. It could be a 'magic address' (defined by command line option ...) which, when written wakes up some cores.

[sifiverobert]

Depth of WFI may be also command line option (to be safe ...).

[aswaterman]

Sounds like a lot of baggage vs. the normal approach of attempting to standardize the feature before adding it to Spike.

[sifiverobert]

Debug spec (to be ratified ...) added standard way to report 'not available core'. Testing it is very hard ... I agree that power-management is SoC dependent, but it does not mean we should not create some 'model' for it. After thinking a bit, WFI is not good way to cause full power-down of a core as it must wake-up at next instruction. Full power-down means wake-up from reset as all core-registers are 'lost'. Said so I agree with you @aswaterman that this is NOT standard-enough (not yet ...).

[timsifive]

Re: (1), the recently merged PR #1197 makes it so that WFI really does suppress instruction execution if no unmasked > interrupt is pending. So presumably a low-power mode can either mimic or piggy-back onto that scheme.

In that case, I could just write my tests by causing one hart to execute wfi and use the other hart to generate an interrupt to the first hart somehow when I want it to wake up. The only thing that stops that from working is that spike (as required by the spec) interrupts wfi when the external debugger requests. This would likely be a change of a dozen lines (including command line option to enable the special behavior). Might that be little enough technical debt?

[aswaterman]

I think that would be OK, provided we can remove it if we ever add a standard low-power mode to Spike.

[timsifive]

Alright. I'll try that approach. I'm all in favor of removing it if we ever do better low-power mode in the future.