1. Messages
  2. Disabling and re-enabling extensions

Re: Disabling and re-enabling extensions

Allen Baum
 

I thought there was already a speced requirement that, at reset, all extensions are enabled.:
    "At reset, the Extensions field shall contain the maximal set of supported extensions, and I shall be selected over E if both are available."

And then there are the corner cases: if there are no misa bits for subsets (e.g Zbb, Zv<whatever>), then they can't be enabled or disabled.
So, why should misa. bits for the full extensions allow enabling/disabling?
What does it mean for misa.G to be enabled or disabled? misa.I ?(if misa.E isn't also present)?

Has anyone identified use cases for turning extensions on and off? (as opposed to FP-like disabled state to save power).
Has anyone ever implemented RW misa bits?
IF not: why not just require those MISA bits to be RdOnly?


On Thu, Sep 10, 2020 at 10:44 AM Greg Favor <gfavor@...> wrote:
A potential second general requirement for all Priv extensions:

- The hart reset state must be fully specified and should generally be UNSPECIFIED except for any key control/status bits that need to be in a specific state.  (This minimizes hardware cost and leaves probably the large majority of state to be initialized by software.)

- The reset state should also specify one of:
    a) The extension is "disabled" (and most, if not all, other extension state is don't care).

    b) The extension is "enabled" and any key control/status bits are initialized to specific values as necessary (with all the rest UNSPECIFIED and left to be initialized by software).

Greg
Join {tech-privileged@lists.riscv.org to automatically receive all group messages.