Hazard3: Design Guide and Reference Manual

Hazard3 communicates with system hardware using the following groups of signals:

See Interfaces (Top-level Ports) for a full description of these interfaces.

The diagram shows how hardware components are distributed through three pipeline stages. A dotted outline means an optional component. Dotted vertical lines are clock boundaries between stages; blocks that straddle these lines are synchronous elements, either registers or bus signals that are notionally registered outside the core. Dependencies (and time) flow from left to right.

The three stages are:

The instruction fetch address phase is best thought of as residing in stage X. The 2-cycle feedback loop between jump/branch decode into address issue in stage X, and the fetch data phase in stage F, is what defines Hazard3’s jump/branch performance.

This document often refers to F, X and M as stages 1, 2 and 3 respectively. This numbering is useful when describing dependencies between values held in different pipeline stages, as it makes the direction and distance of the dependency more apparent.

Hazard3 implements either one or two AHB5 bus manager ports. The dual-port configuration adds a dedicated port for instruction fetch. Use the single-port configuration when ease of integration is a priority, since it supports simpler bus topologies. The dual-port configuration supports higher maximum frequency and greater clock-for-clock performance provided you either have a split (Harvard) bus architecture, or can handle multiple AHB5 managers on the same bus.

One of the key additions to AHB5 over older AHB versions is exclusive accesses, using the HEXCL and HEXOKAY signals. Exclusive accesses enable an ordered read-modify-write sequence with the guarantee that no other processor has written to the same memory location in between the read and write. Hazard3 uses AHB5 exclusives to implement multiprocessor support for the A (atomics) extension. Single-processor support for the A extension does not require these additional signals.

AHB5 is one of the two protocols described in the AMBA 5 AHB protocol specification. Its full name is (perhaps surprisingly) AMBA 5 AHB5. Refer to the protocol specification for more information about this standard bus protocol.

For minimal M-extension support, as enabled by EXTENSION_M, Hazard3 instantiates a sequential multiply/divide circuit (restoring divide, naive repeated-addition multiply). Instructions stall in stage X until the multiply/divide completes. Optionally, the circuit can be unrolled by a small factor to produce multiple bits ber clock. A throughput of one, two or four bits per cycle is achievable in practice, with the internal logic delay becoming quite significant at four.

Set MUL_FAST to instantiate the single-cycle multiplier circuit. The fast multiplier returns results either to stage 3 or stage 2, depending on the MUL_FASTER parameter.

By default the single-cycle multiplier only supports 32-bit mul, which is by far the most common of the four multiply instructions. The remaining instructions still execute on the sequential multiply/divide circuit. Set the MULH_FAST parameter to add single-cycle support for the high-half instructions (mulh, mulhu and mulhsu), at the cost of additional logic delay and area.

The single-cycle multiplier is implemented as a simple * behavioural multiply, so that your tools can infer the best multiply circuit for your platform. For example, Yosys infers DSP tiles on iCE40 UP5k FPGAs. The multiplier is a self-contained module (in hdl/arith/hazard3_mul_fast.v), so you can replace its implementation if you know of a faster or lower-area method for your platform.

Hazard3 supports Zkt constant-time execution in the following configurations:

The source of data-dependent timing is conditional sign correction in the mulh and mulhsu instructions when executed on the sequential multiply/divide circuit. You can avoid this by configuring these instructions to execute on the single-cycle multiplier instead. The remaining Zkt instructions are constant-time for all configurations.

Constant-time here refers to data-independent timing. Execution time can still be affected by other factors such as instruction alignment and external bus stalls.

Software can read the Zkt bit in h3.misa to check whether a given implementation has constant execution time for the Zkt instruction list.

Generally the register file should be synthesised. Synthesised register files offer the best portability and the most flexibility during layout. However there may be an area advantage to implementing the register file using a hard layout macro.

Hazard3 supports the use of register file or SRAM macros, by modifying hazard3_regfile_1w2r.v to instantiate the appropriate macros. The configuration should be one of the following:

The memory dimensions are:

When a write and a read simultaneously occur at the same address, the write must succeed. The read data in this case is don’t-care.

The read data from address 0 is don’t-care, because the special case for register x0 is handled in the register bypass logic. This means a full 32-row or 16-row RAM can be used.

These signals are used in the implementation of internal sleep states as configured by the h3.msleep csr. They are used only when the Xh3power extension is enabled.

Also see Memory Ordering for Loads and Stores for more information on Hazard3’s memory model.

All Debug Module signals should be connected to the signal with the matching name on the Hazard3 Debug Module implementation (hazard3_dm).

This subordinate bus port allows the standard System Bus Access (SBA) feature of the Debug Module to share bus access with the core. Alternatively, use the standalone hazard3_sbus_to_ahb adapter to provide dedicated SBA access from the Debug Module to the system bus.

All interrupts are level-sensitive and synchronous to clk. Asynchronous interrupts must be synchronised externally before entering the processor. You must use the ungated version of clk (clk_always_on) for synchronisation if you use the interrupt to wake from sleep states.

Briefly asserting then deasserting an interrupt signal is not guaranteed to cause the processor to enter the relevant handler; the processor ignores interrupts it is not able to take at that time, for example when interrupts are disabled via mstatus.mie. There is also no guarantee that the processor will not take such an interrupt. Peripherals and software should follow these guidelines for reliable interrupt handling:

This wrapper (hazard3_cpu_1port) adds a single standard AHB5 manager port. See the AMBA 5 AHB specification from Arm for definitions of these signals in the context of the bus protocol.

This wrapper (hazard3_cpu_2port) adds two standard AHB5 manager ports, with signals prefixed i_ for instruction and d_ for data. See the AMBA 5 AHB specification from Arm for definitions of these signals in the context of the bus protocol.

The I port only generates word-aligned word-sized read accesses. It does not use AHB5 exclusives.

When shared System Bus Access (SBA) is used, the SBA bus accesses are routed through the D port.

Address: 0xf11

Vendor identifier. Read-only, configurable constant. Should contain either all-zeroes, or a valid JEDEC JEP106 vendor ID using the encoding in the RISC-V specification. The MVENDORID_VAL parameter sets the value.

Address: 0xf12

Architecture identifier for Hazard3. Read-only, constant.

Address: 0xf13

Implementation identifier. Most of this register is hardwired to indicate the release version of the Hazard3 RTL.

This should match the version of the Github release of the processor’s source code. For example, version 1.0.2 would have a major of 1, minor of 0 and patch of 2.

eco is connected to the eco_version input port at Hazard3 top level; the implementer may connect this to metal tie cells in their integration so that they can increment the ECO (engineering change order) number with metal revisions that affect the processor, or may simply tie it to 0. See Identification Signals.

Address: 0xf14

Hart identification register. Read-only.

The value of this register is configured by the mhartid_val input port (see Identification Signals). In a correctly configured system, the value of mhartid is unique on each hart, and one hart has an ID of all-zeroes. There is no strict requirement to assign hart IDs consecutively, but there may be performance or memory usage advantages to doing so on certain operating systems.

Address: 0xf15

Pointer to configuration data structure. Read-only, configurable constant.

Address: 0x301

Read-only, constant. Value depends on which ISA extensions Hazard3 is configured with. The table below lists the fields which are not always hardwired to 0:

Address: 0x300

The below table lists the fields which are not hardwired to 0:

Address: 0x310

Hardwired to 0.

Address: 0x302

Unimplemented, as neither U-mode traps nor S-mode are supported. Access will cause an illegal instruction exception.

Address: 0x303

Unimplemented, as neither U-mode traps nor S-mode are supported. Access will cause an illegal instruction exception.

Address: 0x304

Interrupt enable register. This is not to be confused with mstatus.mie, which is a global enable, and has the final say in whether any interrupt which is both enabled in mie and pending in mip will actually cause the processor to transfer control to a handler.

The table below lists the fields which are not hardwired to 0:

Address: 0x344

Interrupt pending register. Read-only.

The table below lists the fields which are not hardwired to 0:

Address: 0x305

Trap vector base address. Read-write. Exactly which bits of mtvec can be modified (possibly none) is configurable when instantiating the processor, but by default the entire register is writable. The reset value of mtvec is also configurable.

Address: 0x340

Read-write 32-bit register. No specific hardware function — available for software to swap with a register when entering a trap handler.

Address: 0x341

Exception program counter. When entering a trap, the current value of the program counter is recorded here. When executing an mret, the processor jumps to mepc. Can also be read and written by software.

On Hazard3, bits 31:2 of mepc are capable of holding all 30-bit values. Bit 1 is writable only if the C extension is implemented, and is otherwise hardwired to 0. Bit 0 is hardwired to 0, as per the specification.

All traps on Hazard3 are precise. For example, a load/store bus error will set mepc to the exact address of the load/store instruction which encountered the fault.

Address: 0x342

Exception cause. Set when entering a trap to indicate the reason for the trap. Readable and writable by software.

The most significant bit of mcause is set to 1 to indicate an interrupt cause, and 0 to indicate an exception cause. The following interrupt causes may be set by Hazard3 hardware:

The following exception causes may be set by Hazard3 hardware:

Address: 0x343

Hardwired to 0.

Address: 0x306

Counter enable. Control access to counters from U-mode. Not to be confused with mcountinhibit.

This register only exists if U-mode is supported.

Address: 0x3a0 through 0x3a3

Configuration registers for up to 16 physical memory protection regions. Only present if PMP support is configured. If so, all 4 registers are present, but some registers may be partially/completely hardwired depending on the number of PMP regions present.

By default, M-mode has full permissions (RWX) on all of memory, and U-mode has no permissions. A PMP region can be configured to alter this default within some range of addresses. For every memory location executed, loaded or stored, the processor looks up the lowest active region that overlaps that memory location, and applies its permissions to determine whether this access is allowed. The full description can be found in the RISC-V privileged ISA manual.

Each pmpcfg register divides into four identical 8-bit chunks, each corresponding to one region, and laid out as below:

Address: 0x3b0 through 0x3bf

Address registers for up to 16 physical memory protection regions. Only present if PMP support is configured. If so, all 16 registers are present, but some may fully/partially hardwired.

pmpaddr registers express addresses in units of 4 bytes, so on Hazard3 (a 32-bit processor with no virtual address support) only the lower 30 bits of each address register are implemented.

The interpretation of the pmpaddr bits depends on the A mode configured in the corresponding pmpcfg register field:

Address: 0xb00

Lower half of the 64-bit cycle counter. Readable and writable by software. Increments every cycle, unless mcountinhibit.cy is 1, or the processor is in Debug Mode (as dcsr.stopcount is hardwired to 1).

If written with a value n and read on the very next cycle, the value read will be exactly n. The RISC-V spec says this about mcycle: "Any CSR write takes effect after the writing instruction has otherwise completed."

Address: 0xb80

Upper half of the 64-bit cycle counter. Readable and writable by software. Increments on cycles where mcycle has the value 0xffffffff, unless mcountinhibit.cy is 1, or the processor is in Debug Mode.

This includes when mcycle is written on that same cycle, since RISC-V specifies the CSR write takes place after the increment for that cycle.

Address: 0xb02

Lower half of the 64-bit instruction retire counter. Readable and writable by software. Increments with every instruction executed, unless mcountinhibit.ir is 1, or the processor is in Debug Mode (as dcsr.stopcount is hardwired to 1).

If some value n is written to minstret, and it is read back by the very next instruction, the value read will be exactly n. This is because the CSR write logically takes place after the instruction has otherwise completed.

Address: 0xb82

Upper half of the 64-bit instruction retire counter. Readable and writable by software. Increments when the core retires an instruction and the value of minstret is 0xffffffff, unless mcountinhibit.ir is 1, or the processor is in Debug Mode.

Address: 0xb03 through 0xb1f

Hardwired to 0.

Address: 0xb83 through 0xb9f

Hardwired to 0.

Address: 0x320

Counter inhibit. Read-write. The table below lists the fields which are not hardwired to 0:

Address: 0x323 through 0x33f

Hardwired to 0.

Address: 0x7a0

Select a trigger for configuration. The selected trigger is described in tinfo and can be configured through tdata1 and tdata2. See Trigger Module for an overview of Hazard3’s trigger capabilities.

This register implements exactly enough bits to index the configured number of triggers. Remaining bits are hardwired to zero.

Address: 0x7a1

Configure the trigger selected by tselect.

The layout of bits 26:0 of this register depends on the value of type.

Address: 0x7a2

The interpretation of this CSR depends on the type field of tdata1:

Address: 0x7a3

Hardwired to zero.

Address: 0x7a4

Lists the capabilities of the trigger currently selected by tselect. This takes the form of a bitmap of values supported by tdata1.type. For example, bit 2 being set (a value of 0x4) indicates the trigger supports type = 2, "address/data match".

Hazard3 triggers support only a single type each. Therefore tinfo always has exactly one bit set, and the tdata1.type field is read-only.

If bit 0 is set, and no other bit is set, there is no trigger corresponding to the current value of tselect. There are also no triggers at higher values of tselect; trigger enumeration terminates at this point.

Address: 0x7b0

Debug control and status register. Access outside of Debug Mode will cause an illegal instruction exception. Relevant fields are implemented as follows:

Fields not mentioned above are hardwired to 0.

Hazard3 may set the following dcsr.cause values on entry to Debug Mode:

Cause 5 (resethaltreq) is never set by hardware. This event is reported as a normal halt, cause 3.

Address: 0x7b1

Debug program counter. When entering Debug Mode, dpc samples the current program counter, e.g. the address of an ebreak which caused Debug Mode entry. When leaving debug mode, the processor jumps to dpc. The host may read/write this register whilst in Debug Mode.

Address: 0x7b2

Not implemented. Access will cause an illegal instruction exception.

To provide data exchange between the Debug Module and the core, the Debug Module’s data0 register is mapped into the core’s CSR space at a read/write M-custom address — see [reg-dmdata0].

Address: 0x7b3

Not implemented. Access will cause an illegal instruction exception.

Address: 0xbff

The Debug Module’s internal data0 register is mapped to this CSR address when the core is in debug mode. At any other time, access to this CSR address will cause an illegal instruction exception.

The Debug Module uses this mapping to exchange data with the core by injecting csrr/csrw instructions into the prefetch buffer. This in turn is used to implement the Abstract Access Register command. See Debug.

This CSR address is given by the dataaddress field of the Debug Module’s hartinfo register, and hartinfo.dataaccess is set to 0 to indicate this is a CSR mapping, not a memory mapping.

Address: 0xbe0

External interrupt enable array. Contains a read-write bit for each external interrupt request: a 1 bit indicates that interrupt is currently enabled. At reset, all external interrupts are disabled.

If enabled, an external interrupt can cause assertion of the standard RISC-V machine external interrupt pending flag (mip.meip), and therefore cause the processor to enter the external interrupt vector. See h3.meipa.

There are up to 512 external interrupts. The upper half of this register contains a 16-bit window into the full 512-bit vector. The window is indexed by the 5 LSBs of the write data. For example:

The purpose of this scheme is to allow software to index an array of interrupt enables (something not usually possible in the CSR space) without introducing a stateful CSR index register which may have to be saved/restored around IRQs.

Address: 0xbe1

External interrupt pending array. Contains a read-only bit for each external interrupt request. Similarly to h3.meiea, this register is a window into an array of up to 512 external interrupt flags. The status appears in the upper 16 bits of the value read from h3.meipa, and the lower 5 bits of the value written by the same CSR instruction (or 0 if no write takes place) select a 16-bit window of the full interrupt pending array.

A 1 bit indicates that interrupt is currently asserted. IRQs are assumed to be level-sensitive, and the relevant h3.meipa bit is cleared by servicing the requester so that it deasserts its interrupt request.

When any interrupt of sufficient priority is both set in h3.meipa and enabled in h3.meiea, the standard RISC-V external interrupt pending bit mip.meip is asserted. In other words, h3.meipa is filtered by h3.meiea to generate the standard mip.meip flag. So, an external interrupt is taken when all of the following are true:

In this case, the processor jumps to either:

Address: 0xbe2

External interrupt force array. Contains a read-write bit for every interrupt request. Writing a 1 to a bit in the interrupt force array causes the corresponding bit to become pending in h3.meipa. Software can use this feature to manually trigger a particular interrupt.

There are no restrictions on using h3.meifa inside of an interrupt. The more useful case here is to schedule some lower-priority handler from within a high-priority interrupt, so that it will execute before the core returns to the foreground code. Implementers may wish to reserve some external IRQs with their external inputs tied to 0 for this purpose.

Bits can be cleared by software, and are cleared automatically by hardware upon a read of h3.meinext which returns the corresponding IRQ number in h3.meinext.irq (no matter whether h3.meinext.update is written).

h3.meifa implements the same array window indexing scheme as h3.meiea and h3.meipa.

Address: 0xbe3

External interrupt priority array. Each interrupt has an (up to) 4-bit priority value associated with it, and each access to this register reads and/or writes a 16-bit window containing four such priority values. When less than 16 priority levels are available, the LSBs of the priority fields are hardwired to 0.

When an interrupt’s priority is lower than the current preemption priority h3.meicontext.preempt, it is treated as not being pending. The pending bit in h3.meipa will still assert, but the machine external interrupt pending bit mip.meip will not, so the processor will ignore this interrupt. See h3.meicontext.

Address: 0xbe4

Get next interrupt. Contains the index of the highest-priority external interrupt which is both asserted in h3.meipa and enabled in h3.meiea, left-shifted by 2 so that it can be used to index an array of 32-bit function pointers. If there is no such interrupt, the MSB is set.

When multiple interrupts of the same priority are both pending and enabled, the lowest-numbered wins. Interrupts with priority less than h3.meicontext.ppreempt — the previous preemption priority — are treated as though they are not pending. This is to ensure that a preempting interrupt frame does not service interrupts which may be in progress in the frame that was preempted.

Address: 0xbe5

External interrupt context register. Configures the priority level for interrupt preemption, and helps software track which interrupt it is currently in. The latter is useful when a common interrupt service routine handles interrupt requests from multiple instances of the same peripheral.

A three-level stack of preemption priorities is maintained in the preempt, ppreempt and pppreempt fields. The priority stack is saved when hardware enters the external interrupt vector, and restored by an mret instruction if h3.meicontext.mreteirq is set.

The top entry of the priority stack, preempt, is used by hardware to ensure that only higher-priority interrupts can preempt the current interrupt. The next entry, ppreempt, is used to avoid servicing interrupts which may already be in progress in a frame that was preempted. The third entry, pppreempt, has no hardware effect, but ensures that preempt and ppreempt can be correctly saved/restored across arbitrary levels of preemption.

The following is an example of an external interrupt vector (mip.meip) which implements nested, prioritised interrupt dispatch using h3.meicontext and h3.meinext:

Address: 0xbd0

PMP M-mode configuration. One bit per PMP region. Setting a bit makes the corresponding region apply to M-mode (like the pmpcfg.L bit) but does not lock the region.

PMP is useful for non-security-related purposes, such as stack guarding and peripheral emulation. This extension allows M-mode to freely use any currently unlocked regions for its own purposes, without the inconvenience of having to lock them.

Note that this does not grant any new capabilities to M-mode, since in the base standard it is already possible to apply unlocked regions to M-mode by locking them. In general, PMP regions should be locked in ascending region number order so they can’t be subsequently overridden by currently unlocked regions.

Note also that this is not the same as the "rule locking bypass" bit in the ePMP extension, which does not permit locked and unlocked M-mode regions to coexist.

Address: 0xbf0

M-mode sleep control register. Resets to all-zeroes.

Address: 0xbf1

M-mode ISA identification register.

The h3.misa register provides a simple list of which standard RISC-V ISA extensions are supported. It is conceptually similar to the standard misa register, but stores a larger bit array, sufficient to enumerate all standard extensions. This register comprises the entirety of the Xh3misa extension, as described in Xh3misa: Hazard3 ISA identification register.

The bit assignment is provided by the RISC-V C API documentation here: https://github.com/riscv-non-isa/riscv-c-api-doc/blob/main/src/c-api.adoc#extension-bitmask-definitions. The latest assignment can always be found in the upstream documentation, but at time of writing the following bits are assigned:

The bit index within the h3.misa bitmap can be calculated as 64 * groupid + bit position. A read from h3.misa returns a 32-bit slice of the bitmap, indexed by the write data of the same CSR instruction. For example, Zcmp is at bit index 74, which is bit 10 of word 2.

The implementation is not required to decode all bits of the index. The length of the bitmap can be checked by reading from the special index 0x400. Software should ignore data from bit indices higher than the indicated bitmap length.

The following is an example of testing for an extension based on the groupid and bit_position from the RISC-V C API documentation:

Index 0x401 contains the length in words of the custom extension listing, which starts from index 0x500.

Indices 0x500 onward contain versions of custom Hazard3 extensions:

The custom extension entries have the same major.minor.patch format as mimpid:

A value of all-zeroes indicates the custom extension is not implemented.

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 implementer) 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:

Example assembly macro:

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.

Example C macro:

Example assembly macro:

"Bit extract multiple", a multi-bit version of the bext instruction from Zbs. Perform a right-shift followed by a mask of 1-8 LSBs.

Encoding (R-type):

Example C macro (using GCC statement expressions):

Example assembly macro:

Immediate variant of h3.bextm.

Encoding (I-type):

Example C macro (using GCC statement expressions):

Example assembly macro:

The BREAKPOINT_TRIGGERS parameter configures the trigger unit with 0 or more hardware breakpoint comparators, assigned tselect indices 0 through BREAKPOINT_TRIGGERS - 1. Each comparator continuously monitors the program counter for an exact match for its programmed address. When the comparator matches, the core takes a trap with dpc or mepc equal to the programmed breakpoint address.

In standard RISC-V terms, these are instruction address match triggers, with the following characteristics as described by hardwired fields in mcontrol (aka tdata1):

The mcontrol.u and mcontrol.m bits are fully implemented, and determine in which privilege modes the trigger will fire.

The mcontrol.action field can be programmed with the value 0 or 1, indicating a break to M-mode or D-mode respectively. D-mode breaks are taken only when mcontrol.dmode is set.

tdata2 contains the address to be matched on. The LSB of this register is hardwired to zero, as the RISC-V program counter never contains odd addresses. When compressed instruction support is disabled (EXTENSION_C is 0), bit 1 is also hardwired to zero.

The mcontrol.execute flag enables and disables the trigger (1/0).

Hazard3 implements a single instruction count trigger, assigned tselect index BREAKPOINT_TRIGGERS. For example, if no breakpoint triggers are configured, it is accessed at tselect = 0.

This trigger is hardwired with a count of 1, and is intended to be a lightweight feature to support self-hosted M-mode single-stepping. Debug Mode already has this capability in the form of the dcsr.step flag, so the instruction count trigger supports action = 0 only (break to M-mode).

The following configuration bits in tdata1 are not hardwired:

The trigger fires after one instruction successfully executes. mepc points to the next instruction in program order. Since icount.count is hardwired to 1, hardware clears both the m and u flags after the trigger fires, to avoid repeat fires.

To single-step a U-mode context from M-mode, set icount.u before returning to U-mode via mret. The U-mode context will trap back out after executing one instruction.

To single-step an M-mode target, clear tcontrol.mte, then set tcontrol.mpte and icount.m before returning to an M-mode context via mret. The trigger is enabled after the return completes (via mpte shifting to mte), and the core traps back to the M-mode handler after executing one instruction in the M-mode returnee. The handler executes normally, because mte is cleared by the trap, and icount.m is cleared by the trigger match.

To support the above behaviour, hardware does not clear icount.m or icount.u while tcontrol.mte is clear. See discussion here.

Hazard3 implements a single interrupt trigger, assigned tselect index BREAKPOINT_TRIGGERS + 1. For example, if no breakpoint triggers are configured, it is accessed at tselect = 1.

This trigger fires on a configurable subset of the interrupt cause values listed in the mcause register description. tdata2 contains a bitmap with one bit per cause value. The break is taken after the hardware interrupt entry sequence has taken place (e.g. the setting of mcause), but before the first instruction in the interrupt handler executes. dpc points to the first instruction in the interrupt handler.

action is hardwired to 1 (Debug Mode entry), because all interrupts on Hazard3 target M-mode, so a breakpoint exception triggered by interrupt entry would make it impossible to return from the interrupt.

The implemented bits are 11, 7 and 3, corresponding to mip.meip, mip.mtip and mip.msip respectively.

Hazard3 implements a single exception trigger, assigned tselect index BREAKPOINT_TRIGGERS + 2. For example, if no breakpoint triggers are configured, it is accessed at tselect = 2.

This trigger fires on a configurable subset of the exception cause values listed in the mcause register description. tdata2 contains a bitmap with one bit per cause value. The break is taken after the hardware exception entry sequence has taken place (e.g. the setting of mcause) but before the first instruction in the exception handler executes. dpc points to the first instruction in the exception handler.

action is hardwired to 1 (Debug Mode entry) because all exceptions on Hazard3 target M-mode, so a breakpoint exception triggered by another exception would always make the original exception unrecoverable.

Bits corresponding to causes impossible on a given Hazard3 implementation are hardwired to zero. For example, bit 0 (mcause = 0, fetch alignment exception) is not implemented when EXTENSION_C is 1, because there are no fetch alignment exceptions if compressed instructions are implemented.

Bit 3 (ebreak) is also unimplemented. To catch ebreak execution from an external debugger, use the dcsr.ebreakm and dcsr.ebreaku flags.