RISC V - low power instructions

[David Darmon (ddarmon)]

Hi

I do not see any specific instruction for low power usage as sleep/Hibernate etc… to enter the chip in low power mode ?

What is the RISC-V policy?


Regards,

David D

.

[Madhu Macaque Labs]

Power states and sleep modes are not really part of the ISA. I will
readily admit
this is just my opinion !
It is more of an implementation issue since different classes of cores will
have different sleep mode requirements though possibly some basic sleep
states can be made mandatory.

What constitutes RISC-V itself is an evolving concept ! There is the
core ISA and ABI.
Beyond that there are SoC frameworks like Rocket, LowRISC and Shakti
which will address issues like power management in greater detail.
Though it would make sense to have some consensus on this issue and define
standard sleep modes/power states for various core classes.

> --
> You received this message because you are subscribed to the Google Groups "RISC-V HW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an email to hw-dev+un...@groups.riscv.org.
> To post to this group, send email to hw-...@groups.riscv.org.
> Visit this group at https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
> To view this discussion on the web visit https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/de24331d54ca4374851c8c185409d609%40XCH-ALN-012.cisco.com.



--
Regards,
Madhu

[David Chisnall]

On 27 Feb 2017, at 15:16, Madhu Macaque Labs <ma...@macaque.in> wrote:
>
> Power states and sleep modes are not really part of the ISA. I will
> readily admit
> this is just my opinion !
> It is more of an implementation issue since different classes of cores will
> have different sleep mode requirements though possibly some basic sleep
> states can be made mandatory.
>
> What constitutes RISC-V itself is an evolving concept ! There is the
> core ISA and ABI.
> Beyond that there are SoC frameworks like Rocket, LowRISC and Shakti
> which will address issues like power management in greater detail.
> Though it would make sense to have some consensus on this issue and define
> standard sleep modes/power states for various core classes.

Note that RISC-V has a WFI instruction in the privileged spec which would allow a core to enter a low power (but fast wake) state when it has no pending work to do. Lower power states, I agree, are generally controlled by the firmware, rather than being directly embedded in the ISA.

David

[Michael Chapman]

We use WFI (wait for interrupt) in our implementations.

[Mauro Olivieri]

Hi,
I agree on citing WFI as a mean of suspending the execution and possibly entering a low-power idle mode.
Yet, it is reasonable that the ISA does not define power-mode primitives as it does not define other low level primitives such as "thread creation/completion".
An obvious idea for implementing multiple levels of power-down (typical of power-aware embedded applications) might be to define a non-standard CSR in the CSR address space.
Mauro

[David Horner]

Hardware can identify other opportunities for reducing power comsumption.

As David noted, WFI is currently speced for S-Mode: 

However, other opportunities include:
 loop-on-same-instruction with PC relative zero offset. 
   - JAL x0,0  - An effective Wait For Interrupt , that is power expensive on simplistic implementations. (C.J 0 is also a "valid" instruction)
   - JAL Xn,0 - consumes even more power for the register write on simplistic implementations and after the first iteration is idempotent.
   - all the branch with offset zero once the condition is met, these potential consumes even more power on simplistic implementations.
                (that continue to read two registers and compare them each )
   These perhaps should trap immediately, especially if watchdog is enabled.
   Note: the Compressed Instruction extension also allow zero offsets: for C.J, C.BEQZ, C.BNEZ.

Effective NOPs that do not change the machine state other than to advance the Program Counter.
  There are a multitude of these: all the OPs with X0 in the destination register.
   Note: the Compressed Instruction extension has identified most of these as "hint" instructions.
          In addition many other useless varients of base instructions have been remapped (e.g.  C.EBREAK and illegal instruction)

In the same way that C extension has annotated its instructions as hint NOPs should,
 the base instructions such as those above be annotated as variants for special hardware consideration?

[Madhu Macaque Labs]

I suspect that teh non-standard CSRs would become standard.
It would be better to anticipate that rather than passively
created de facto standards.
It is probably premature to worry about that now, but in the longer
run we should be prepared for adding more mechanisms.

> --
> You received this message because you are subscribed to the Google Groups
> "RISC-V HW Dev" group.
> To unsubscribe from this group and stop receiving emails from it, send an
> email to hw-dev+un...@groups.riscv.org.
> To post to this group, send email to hw-...@groups.riscv.org.
> Visit this group at
> https://groups.google.com/a/groups.riscv.org/group/hw-dev/.
> To view this discussion on the web visit

> https://groups.google.com/a/groups.riscv.org/d/msgid/hw-dev/2d59f69e-b521-41b2-97e9-9cdd0a3f13d0%40groups.riscv.org.



--
Regards,
Madhu