Hazard3 implements a small number of custom extensions. All are optional: custom extensions are only included if the relevant feature flags are set to 1 when instantiating the processor (<<config-parameters-section>>). Hazard3 is always a _conforming_ RISC-V implementation, and when these extensions are disabled it is also a _standard_ RISC-V implementation.
If any one of these extensions is enabled, the `x` bit in <<reg-misa>> is set to indicate the presence of a nonstandard extension.
This is a lightweight extension to control up to 512 external interrupts, with up to 16 levels of preemption.
This extension does not add any instructions, but does add several CSRs:
* <<reg-meiea>>
* <<reg-meipa>>
* <<reg-meifa>>
* <<reg-meipra>>
* <<reg-meinext>>
* <<reg-meicontext>>
If this extension is disabled then Hazard3 supports a single external interrupt input (or multiple inputs that it simply ORs together in an uncontrolled fashion), so an external PLIC can be used for standard interrupt support.
Note that, besides the additional CSRs, this extension is effectively a slightly more complicated way of driving the standard `mip.meip` flag (<<reg-mip>>). The RISC-V trap handling CSRs themselves are always completely standard.
[[extension-xh3pmpm-section]]
=== Xh3pmpm: M-mode PMP regions
This extension adds a new M-mode CSR, <<reg-pmpcfgm0>>, which allows a PMP region to be enforced in M-mode without locking the region.
This is useful when the PMP is used for non-security-related purposes such as stack guarding, or trapping and emulation of peripheral accesses.
This extension adds a new M-mode CSR (<<reg-msleep>>), and two new hint instructions, `h3.block` and `h3.unblock`, in the `slt` nop-compatible custom hint space.
The `msleep` CSR controls how deeply the processor sleeps in the WFI sleep state. By default, a WFI is implemented as a normal pipeline stall. By configuring `msleep` appropriately, the processor can gate its own clock when asleep or, with a simple 4-phase req/ack handshake, negotiate power up/down of external hardware with an external power controller. These options can improve the sleep current at the cost of greater wakeup latency.
The hints allow processors to sleep until woken by other processors in a multiprocessor environment. They are implemented on top of the standard WFI state, which means they interact in the same way with external debug, and benefit from the same deep sleep states in `msleep`.
Enter a WFI sleep state until either an unblock signal is received, or an interrupt is asserted that would cause a WFI to exit.
If `mstatus.tw` is set, attempting to execute this instruction in privilege modes lower than M-mode will generate an illegal instruction exception.
If an unblock signal has been received in the time since the last `h3.block`, this instruction executes as a `nop`, and the processor does not enter the sleep state. Conceptually, the sleep state falls through immediately because the corresponding unblock signal has already been received.
An unblock signal is received when a neighbouring processor (the exact definition of "neighbouring" being left to the implementor) executes an `h3.unblock` instruction, or for some other platform-defined reason.
This instruction is encoded as `slt x0, x0, x0`, which is part of the custom nop-compatible hint encoding space.
Example C macro:
----
#define __h3_block() asm ("slt x0, x0, x0")
----
Example assembly macro:
----
.macro h3.block
slt x0, x0, x0
.endm
----
==== h3.unblock
Post an unblock signal to other processors in the system. For example, to notify another processor that a work queue is now nonempty.
If `mstatus.tw` is set, attempting to execute this instruction in privilege modes lower than M-mode will generate an illegal instruction exception.
This instruction is encoded as `slt x0, x0, x1`, which is part of the custom nop-compatible hint encoding space.
