This document describes the RISC-V privileged architecture tailored for +OpenHW Group CV32A65X. +Not relevant parts (e.g. unsupported extensions) of the original +specification are replaced by placeholders.
+Contributors to all versions of the spec in alphabetical order (please contact +editors to suggest corrections): Krste Asanović, Peter Ashenden, Rimas +Avižienis, Jacob Bachmeyer, Allen J. Baum, Jonathan Behrens, Paolo Bonzini, Ruslan Bukin, +Christopher Celio, Chuanhua Chang, David Chisnall, Anthony Coulter, Palmer Dabbelt, Monte +Dalrymple, Paul Donahue, Greg Favor, Dennis Ferguson, Marc Gauthier, Andy Glew, +Gary Guo, Mike Frysinger, John Hauser, David Horner, Olof +Johansson, David Kruckemyer, Yunsup Lee, Daniel Lustig, Andrew Lutomirski, Prashanth Mundkur, +Jonathan Neuschäfer, Rishiyur +Nikhil, Stefan O’Rear, Albert Ou, John Ousterhout, David Patterson, Dmitri +Pavlov, Kade Phillips, Josh Scheid, Colin Schmidt, Michael Taylor, Wesley Terpstra, Matt Thomas, Tommy Thorn, Ray +VanDeWalker, Megan Wachs, Steve Wallach, Andrew Waterman, Claire Wolf, +and Reinoud Zandijk..
+This document is released under a Creative Commons Attribution 4.0 International License.
+This document is a derivative of the RISC-V +privileged specification version 1.9.1 released under following license: ©2010-2017 Andrew Waterman, Yunsup Lee, Rimas +Avižienis, +David Patterson, Krste Asanović. Creative Commons Attribution 4.0 International License.
+Contributors to CV32A65X versions of the spec in alphabetical order: +Jean-Roch Coulon, André Sintzoff.
+Preface
+Preface to Version for CV32A65X
+This document describes the RISC-V privileged architecture tailored for +OpenHW Group CV32A65X.
+Preface to Version 20240326
+This document describes the RISC-V privileged architecture. This +release, version 20240213, contains the following versions of the RISC-V ISA +modules:
+| Module | +Version | +Status | +
|---|---|---|
Machine ISA |
+1.13 |
+Draft |
+
The following changes have been made since version 1.13, which, while +not strictly backwards compatible, are not anticipated to cause software +portability problems in practice:
+-
+
-
+
The inclusion of all ratified extensions through March 2024.
+
+
Preface to Version 20240213
+This document describes the RISC-V privileged architecture. This +release, version 20240213, contains the following versions of the RISC-V ISA +modules:
+| Module | +Version | +Status | +
|---|---|---|
Machine ISA |
+1.13 |
+Draft |
+
The following changes have been made since version 1.12, which, while +not strictly backwards compatible, are not anticipated to cause software +portability problems in practice:
+-
+
-
+
Redefined
+misa.MXL to be read-only, making MXLEN a constant.
+ -
+
Added the constraint that SXLEN≥UXLEN.
+
+
Additionally, the following compatible changes have been made to the Machine ISA since +version 1.12:
+-
+
-
+
Transliterated the document from LaTeX into AsciiDoc.
+
+ -
+
Defined the
+misa.V field to reflect that the V extension has been +implemented.
+ -
+
Defined the RV32-only
+medeleghandhedeleghCSRs.
+ -
+
Defined the misaligned atomicity granule PMA, superseding the proposed Zam +extension.
+
+ -
+
Allocated interrupt 13 for Sscofpmf LCOFI interrupt.
+
+ -
+
Defined hardware error and software check exception codes.
+
+ -
+
Specified synchronization requirements when changing the PBMTE fields +in
+menvcfgandhenvcfg.
+ -
+
Incorporated Svade and Svadu extension specifications.
+
+ -
+
Clarified that "platform- or custom-use" interrupts are actually +"platform-use interrupts", where the platform can choose to make some custom.
+
+ -
+
Clarified semantics of explicit accesses to CSRs wider than XLEN bits.
+
+ -
+
Clarified that MXLEN≥SXLEN.
+
+ -
+
Clarified that WFI is not a HINT instruction.
+
+ -
+
Clarified that VS-stage page-table accesses set G-stage A/D bits.
+
+ -
+
Clarified ordering rules when PBMT=IO is used on main-memory regions.
+
+ -
+
Clarified ordering rules for hardware A/D bit updates.
+
+ -
+
Clarified that, for a given exception cause,
+xtvalmight sometimes +be set to a nonzero value but sometimes not.
+ -
+
Clarified exception behavior of unimplemented or inaccessible CSRs.
+
+ -
+
Clarified that Svpbmt allows implementations to override additional PMAs.
+
+ -
+
Exposed count-overflow interrups to VS-mode.
+
+
Preface to Version 20211203
+This document describes the RISC-V privileged architecture. This +release, version 20211203, contains the following versions of the RISC-V +ISA modules:
+| Module | +Version | +Status | +
|---|---|---|
Machine ISA |
+1.12 |
+Ratified |
+
The following changes have been made since version 1.11, which, while +not strictly backwards compatible, are not anticipated to cause software +portability problems in practice:
+-
+
-
+
Changed MRET and SRET to clear
+mstatus.MPRV when leaving M-mode.
+ -
+
Reserved additional
+satppatterns for future use.
+ -
+
Stated that the
+scauseException Code field must implement bits 4–0 +at minimum.
+ -
+
Relaxed I/O regions have been specified to follow RVWMO. The previous +specification implied that PPO rules other than fences and +acquire/release annotations did not apply.
+
+ -
+
Constrained the LR/SC reservation set size and shape when using +page-based virtual memory.
+
+ -
+
PMP changes require an SFENCE.VMA on any hart that implements +page-based virtual memory, even if VM is not currently enabled.
+
+ -
+
Allowed for speculative updates of page table entry A bits.
+
+ -
+
Clarify that if the address-translation algorithm non-speculatively +reaches a PTE in which a bit reserved for future standard use is set, a +page-fault exception must be raised.
+
+
Additionally, the following compatible changes have been made since +version 1.11:
+-
+
-
+
Removed the N extension.
+
+ -
+
Defined the mandatory RV32-only CSR
+mstatush, which contains most of +the same fields as the upper 32 bits of RV64’smstatus.
+ -
+
Defined the mandatory CSR
+mconfigptr, which if nonzero contains the +address of a configuration data structure.
+ -
+
Defined optional
+mseccfgandmseccfghCSRs, which control the +machine’s security configuration.
+ -
+
Defined
+menvcfg,henvcfg, andsenvcfgCSRs (and RV32-only +menvcfghandhenvcfghCSRs), which control various characteristics +of the execution environment.
+ -
+
Designated part of SYSTEM major opcode for custom use.
+
+ -
+
Permitted the unconditional delegation of less-privileged interrupts.
+
+ -
+
Added optional big-endian and bi-endian support.
+
+ -
+
Made priority of load/store/AMO address-misaligned exceptions +implementation-defined relative to load/store/AMO page-fault and +access-fault exceptions.
+
+ -
+
PMP reset values are now platform-defined.
+
+ -
+
An additional 48 optional PMP registers have been defined.
+
+ -
+
Slightly relaxed the atomicity requirement for A and D bit updates +performed by the implementation.
+
+ -
+
Clarify the architectural behavior of address-translation caches
+
+ -
+
Added Sv57 and Sv57x4 address translation modes.
+
+ -
+
Software breakpoint exceptions are permitted to write either 0 or the +
+pctoxtval.
+ -
+
Clarified that bare S-mode need not support the SFENCE.VMA +instruction.
+
+ -
+
Specified relaxed constraints for implicit reads of non-idempotent +regions.
+
+ -
+
Added the Svnapot Standard Extension, along with the N bit in Sv39, +Sv48, and Sv57 PTEs.
+
+ -
+
Added the Svpbmt Standard Extension, along with the PBMT bits in Sv39, +Sv48, and Sv57 PTEs.
+
+ -
+
Added the Svinval Standard Extension and associated instructions.
+
+
Finally, the hypervisor architecture proposal has been extensively +revised.
+Preface to Version 1.11
+This is version 1.11 of the RISC-V privileged architecture. The document +contains the following versions of the RISC-V ISA modules:
+| Module | +Version | +Status | +
|---|---|---|
Machine ISA |
+1.11 |
+Ratified |
+
Changes from version 1.10 include:
+-
+
-
+
Moved Machine and Supervisor spec to Ratified status.
+
+ -
+
Improvements to the description and commentary.
+
+ -
+
Added a draft proposal for a hypervisor extension.
+
+ -
+
Specified which interrupt sources are reserved for standard use.
+
+ -
+
Allocated some synchronous exception causes for custom use.
+
+ -
+
Specified the priority ordering of synchronous exceptions.
+
+ -
+
Added specification that xRET instructions may, but are not required +to, clear LR reservations if A extension present.
+
+ -
+
The virtual-memory system no longer permits supervisor mode to execute +instructions from user pages, regardless of the SUM setting.
+
+ -
+
Clarified that ASIDs are private to a hart, and added commentary about +the possibility of a future global-ASID extension.
+
+ -
+
SFENCE.VMA semantics have been clarified.
+
+ -
+
Made the
+mstatus.MPP field WARL, rather than WLRL.
+ -
+
Made the unused
+xipfields WPRI, rather than WIRI.
+ -
+
Made the unused
+misafields WARL, rather than WIRI.
+ -
+
Made the unused
+pmpaddrandpmpcfgfields WARL, rather than WIRI.
+ -
+
Required all harts in a system to employ the same PTE-update scheme as +each other.
+
+ -
+
Rectified an editing error that misdescribed the mechanism by which +
+mstatus.xIEis written upon an exception.
+ -
+
Described scheme for emulating misaligned AMOs.
+
+ -
+
Specified the behavior of the
+misaandxepcregisters in systems +with variable IALIGN.
+ -
+
Specified the behavior of writing self-contradictory values to the +
+misaregister.
+ -
+
Defined the
+mcountinhibitCSR, which stops performance counters from +incrementing to reduce energy consumption.
+ -
+
Specified semantics for PMP regions coarser than four bytes.
+
+ -
+
Specified contents of CSRs across XLEN modification.
+
+ -
+
Moved PLIC chapter into its own document.
+
+
Preface to Version 1.10
+This is version 1.10 of the RISC-V privileged architecture proposal. +Changes from version 1.9.1 include:
+-
+
-
+
The previous version of this document was released under a Creative +Commons Attribution 4.0 International License by the original authors, +and this and future versions of this document will be released under the +same license.
+
+ -
+
The explicit convention on shadow CSR addresses has been removed to +reclaim CSR space. Shadow CSRs can still be added as needed.
+
+ -
+
The
+mvendoridregister now contains the JEDEC code of the core +provider as opposed to a code supplied by the Foundation. This avoids +redundancy and offloads work from the Foundation.
+ -
+
The interrupt-enable stack discipline has been simplified.
+
+ -
+
An optional mechanism to change the base ISA used by supervisor and +user modes has been added to the
+mstatusCSR, and the field previously +called Base inmisahas been renamed toMXLfor consistency.
+ -
+
Clarified expected use of XS to summarize additional extension state +status fields in
+mstatus.
+ -
+
Optional vectored interrupt support has been added to the
+mtvecand +stvecCSRs.
+ -
+
The SEIP and UEIP bits in the
+mipCSR have been redefined to support +software injection of external interrupts.
+ -
+
The
+mbadaddrregister has been subsumed by a more generalmtval+register that can now capture bad instruction bits on an illegal +instruction fault to speed instruction emulation.
+ -
+
The machine-mode base-and-bounds translation and protection schemes +have been removed from the specification as part of moving the virtual +memory configuration to
+sptbr(nowsatp). Some of the motivation for +the base and bound schemes are now covered by the PMP registers, but +space remains available inmstatusto add these back at a later date +if deemed useful.
+ -
+
In systems with only M-mode, or with both M-mode and U-mode but +without U-mode trap support, the
+medelegandmidelegregisters now +do not exist, whereas previously they returned zero.
+ -
+
Virtual-memory page faults now have
+mcausevalues distinct from +physical-memory access faults. Page-fault exceptions can now be +delegated to S-mode without delegating exceptions generated by PMA and +PMP checks.
+ -
+
An optional physical-memory protection (PMP) scheme has been proposed.
+
+ -
+
The supervisor virtual memory configuration has been moved from the +
+mstatusregister to thesptbrregister. Accordingly, thesptbr+register has been renamed tosatp(Supervisor Address Translation and +Protection) to reflect its broadened role.
+ -
+
The SFENCE.VM instruction has been removed in favor of the improved +SFENCE.VMA instruction.
+
+ -
+
The
+mstatusbit MXR has been exposed to S-mode viasstatus.
+ -
+
The polarity of the PUM bit in
+sstatushas been inverted to shorten +code sequences involving MXR. The bit has been renamed to SUM.
+ -
+
Hardware management of page-table entry Accessed and Dirty bits has +been made optional; simpler implementations may trap to software to set +them.
+
+ -
+
The counter-enable scheme has changed, so that S-mode can control +availability of counters to U-mode.
+
+ -
+
H-mode has been removed, as we are focusing on recursive +virtualization support in S-mode. The encoding space has been reserved +and may be repurposed at a later date.
+
+ -
+
A mechanism to improve virtualization performance by trapping S-mode +virtual-memory management operations has been added.
+
+ -
+
The Supervisor Binary Interface (SBI) chapter has been removed, so +that it can be maintained as a separate specification.
+
+
Preface to Version 1.9.1
+This is version 1.9.1 of the RISC-V privileged architecture proposal. +Changes from version 1.9 include:
+-
+
-
+
Numerous additions and improvements to the commentary sections.
+
+ -
+
Change configuration string proposal to be use a search process that +supports various formats including Device Tree String and flattened +Device Tree.
+
+ -
+
Made
+misaoptionally writable to support modifying base and +supported ISA extensions. CSR address ofmisachanged.
+ -
+
Added description of debug mode and debug CSRs.
+
+ -
+
Added a hardware performance monitoring scheme. Simplified the +handling of existing hardware counters, removing privileged versions of +the counters and the corresponding delta registers.
+
+ -
+
Fixed description of SPIE in presence of user-level interrupts.
+
+
1. Introduction
+This document describes the RISC-V privileged architecture, which covers +all aspects of RISC-V systems beyond the unprivileged ISA, including +privileged instructions as well as additional functionality required for +running operating systems and attaching external devices.
+| + + | +
+
+
+Commentary on our design decisions is formatted as in this paragraph, +and can be skipped if the reader is only interested in the specification +itself. ++
+
+We briefly note that the entire privileged-level design described in +this document could be replaced with an entirely different +privileged-level design without changing the unprivileged ISA, and +possibly without even changing the ABI. In particular, this privileged +specification was designed to run existing popular operating systems, +and so embodies the conventional level-based protection model. Alternate +privileged specifications could embody other more flexible +protection-domain models. For simplicity of expression, the text is +written as if this was the only possible privileged architecture. + |
+
1.1. RISC-V Privileged Software Stack Terminology
+This section describes the terminology we use to describe components of +the wide range of possible privileged software stacks for RISC-V.
+Figure 1 shows some of the possible software stacks +that can be supported by the RISC-V architecture. The left-hand side +shows a simple system that supports only a single application running on +an application execution environment (AEE). The application is coded to +run with a particular application binary interface (ABI). The ABI +includes the supported user-level ISA plus a set of ABI calls to +interact with the AEE. The ABI hides details of the AEE from the +application to allow greater flexibility in implementing the AEE. The +same ABI could be implemented natively on multiple different host OSs, +or could be supported by a user-mode emulation environment running on a +machine with a different native ISA.
+| + + | +
+
+
+Our graphical convention represents abstract interfaces using black +boxes with white text, to separate them from concrete instances of +components implementing the interfaces. + |
+
+The middle configuration shows a conventional operating system (OS) that +can support multiprogrammed execution of multiple applications. Each +application communicates over an ABI with the OS, which provides the +AEE. Just as applications interface with an AEE via an ABI, RISC-V +operating systems interface with a supervisor execution environment +(SEE) via a supervisor binary interface (SBI). An SBI comprises the +user-level and supervisor-level ISA together with a set of SBI function +calls. Using a single SBI across all SEE implementations allows a single +OS binary image to run on any SEE. The SEE can be a simple boot loader +and BIOS-style IO system in a low-end hardware platform, or a +hypervisor-provided virtual machine in a high-end server, or a thin +translation layer over a host operating system in an architecture +simulation environment.
+| + + | +
+
+
+Most supervisor-level ISA definitions do not separate the SBI from the +execution environment and/or the hardware platform, complicating +virtualization and bring-up of new hardware platforms. + |
+
The rightmost configuration shows a virtual machine monitor +configuration where multiple multiprogrammed OSs are supported by a +single hypervisor. Each OS communicates via an SBI with the hypervisor, +which provides the SEE. The hypervisor communicates with the hypervisor +execution environment (HEE) using a hypervisor binary interface (HBI), +to isolate the hypervisor from details of the hardware platform.
+| + + | +
+
+
+The ABI, SBI, and HBI are still a work-in-progress, but we are now +prioritizing support for Type-2 hypervisors where the SBI is provided +recursively by an S-mode OS. + |
+
Hardware implementations of the RISC-V ISA will generally require +additional features beyond the privileged ISA to support the various +execution environments (AEE, SEE, or HEE).
+1.2. Privilege Levels
+At any time, a RISC-V hardware thread (hart) is running at some +privilege level encoded as a mode in one or more CSRs (control and +status registers). Three RISC-V privilege levels are currently defined +as shown in Table 1.
+| Level | +Encoding | +Name | +Abbreviation | +
|---|---|---|---|
0 |
+
|
+User/Application |
+U |
+
Privilege levels are used to provide protection between different +components of the software stack, and attempts to perform operations not +permitted by the current privilege mode will cause an exception to be +raised. These exceptions will normally cause traps into an underlying +execution environment.
+| + + | +
+
+
+In the description, we try to separate the privilege level for which +code is written, from the privilege mode in which it runs, although the +two are often tied. For example, a supervisor-level operating system can +run in supervisor-mode on a system with three privilege modes, but can +also run in user-mode under a classic virtual machine monitor on systems +with two or more privilege modes. In both cases, the same +supervisor-level operating system binary code can be used, coded to a +supervisor-level SBI and hence expecting to be able to use +supervisor-level privileged instructions and CSRs. When running a guest +OS in user mode, all supervisor-level actions will be trapped and +emulated by the SEE running in the higher-privilege level. + |
+
The machine level has the highest privileges and is the only mandatory +privilege level for a RISC-V hardware platform. Code run in machine-mode +(M-mode) is usually inherently trusted, as it has low-level access to +the machine implementation. M-mode can be used to manage secure +execution environments on RISC-V. User-mode (U-mode) and supervisor-mode +(S-mode) are intended for conventional application and operating system +usage respectively.
+Each privilege level has a core set of privileged ISA extensions with +optional extensions and variants. For example, machine-mode supports an +optional standard extension for memory protection. Also, supervisor mode +can be extended to support Type-2 hypervisor execution as described in +Chapter 13.
+Implementations might provide anywhere from 1 to 3 privilege modes +trading off reduced isolation for lower implementation cost, as shown in +Table 2.
+| Number of levels | +Supported Modes | +Intended Usage | +
|---|---|---|
1 |
+M |
+Simple embedded systems |
+
All hardware implementations must provide M-mode, as this is the only +mode that has unfettered access to the whole machine. The simplest +RISC-V implementations may provide only M-mode, though this will provide +no protection against incorrect or malicious application code.
+| + + | +
+
+
+The lock feature of the optional PMP facility can provide some limited +protection even with only M-mode implemented. + |
+
Many RISC-V implementations will also support at least user mode +(U-mode) to protect the rest of the system from application code. +Supervisor mode (S-mode) can be added to provide isolation between a +supervisor-level operating system and the SEE.
+A hart normally runs application code in U-mode until some trap (e.g., a +supervisor call or a timer interrupt) forces a switch to a trap handler, +which usually runs in a more privileged mode. The hart will then execute +the trap handler, which will eventually resume execution at or after the +original trapped instruction in U-mode. Traps that increase privilege +level are termed vertical traps, while traps that remain at the same +privilege level are termed horizontal traps. The RISC-V privileged +architecture provides flexible routing of traps to different privilege +layers.
+| + + | +
+
+
+Horizontal traps can be implemented as vertical traps that return +control to a horizontal trap handler in the less-privileged mode. + |
+
1.3. Debug Mode
+Implementations may also include a debug mode to support off-chip +debugging and/or manufacturing test. Debug mode (D-mode) can be +considered an additional privilege mode, with even more access than +M-mode. The separate debug specification proposal describes operation of +a RISC-V hart in debug mode. Debug mode reserves a few CSR addresses +that are only accessible in D-mode, and may also reserve some portions +of the physical address space on a platform.
+2. Control and Status Registers (CSRs)
+The SYSTEM major opcode is used to encode all privileged instructions in +the RISC-V ISA. These can be divided into two main classes: those that +atomically read-modify-write control and status registers (CSRs), which +are defined in the Zicsr extension, and all other privileged +instructions. The privileged architecture requires the Zicsr extension; +which other privileged instructions are required depends on the +privileged-architecture feature set.
+In addition to the unprivileged state described in Volume I of this +manual, an implementation may contain additional CSRs, accessible by +some subset of the privilege levels using the CSR instructions described +in Volume I. In this chapter, we map out the CSR address space. The +following chapters describe the function of each of the CSRs according +to privilege level, as well as the other privileged instructions which +are generally closely associated with a particular privilege level. Note +that although CSRs and instructions are associated with one privilege +level, they are also accessible at all higher privilege levels.
+Standard CSRs do not have side effects on reads but may have side +effects on writes.
+2.1. CSR Address Mapping Conventions
+The standard RISC-V ISA sets aside a 12-bit encoding space (csr[11:0])
+for up to 4,096 CSRs. By convention, the upper 4 bits of the CSR address
+(csr[11:8]) are used to encode the read and write accessibility of the
+CSRs according to privilege level as shown in Table 3. The top two bits (csr[11:10]) indicate whether the register is read/write (00,01, or 10) or read-only (11). The next two bits (csr[9:8]) encode the lowest privilege level that can access the CSR.
| + + | +
+
+
+The CSR address convention uses the upper bits of the CSR address to +encode default access privileges. This simplifies error checking in the +hardware and provides a larger CSR space, but does constrain the mapping +of CSRs into the address space. +
+
+Implementations might allow a more-privileged level to trap otherwise +permitted CSR accesses by a less-privileged level to allow these +accesses to be intercepted. This change should be transparent to the +less-privileged software. + |
+
Instructions that access a non-existent CSR are reserved. +Attempts to access a CSR without appropriate privilege level +raise illegal-instruction exceptions or, as described in +[sec:hcauses], virtual-instruction exceptions. +Attempts to write a read-only register raise illegal-instruction exceptions. +A read/write register might also contain some bits that are +read-only, in which case writes to the read-only bits are ignored.
+Table 3 also indicates the convention to +allocate CSR addresses between standard and custom uses. The CSR +addresses designated for custom uses will not be redefined by future +standard extensions.
+Machine-mode standard read-write CSRs 0x7A0-0x7BF are reserved for
+use by the debug system. Of these CSRs, 0x7A0-0x7AF are accessible
+to machine mode, whereas 0x7B0-0x7BF are only visible to debug mode.
+Implementations should raise illegal-instruction exceptions on
+machine-mode access to the latter set of registers.
| + + | +
+
+
+Effective virtualization requires that as many instructions run natively +as possible inside a virtualized environment, while any privileged +accesses trap to the virtual machine monitor. (Goldberg, 1974) CSRs that are read-only +at some lower privilege level are shadowed into separate CSR addresses +if they are made read-write at a higher privilege level. This avoids +trapping permitted lower-privilege accesses while still causing traps on +illegal accesses. Currently, the counters are the only shadowed CSRs. + |
+
2.2. CSR Listing
+Table 4-Table 8 list the CSRs that +have currently been allocated CSR addresses. The timers, counters, and +floating-point CSRs are standard unprivileged CSRs. The other registers +are used by privileged code, as described in the following chapters. +Note that not all registers are required on all implementations.
+CSR Address |
+Hex |
+Use and Accessibility |
+|||||
[11:10] |
+[9:8] |
+[7:4] |
+|||||
Unprivileged and User-Level CSRs |
+|||||||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Custom read/write |
+|||
|
+
|
+
|
+
|
+Standard read-only |
+|||
|
+
|
+
|
+
|
+Standard read-only |
+|||
|
+
|
+
|
+
|
+Custom read-only |
+|||
Supervisor-Level CSRs |
+|||||||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Custom read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Custom read/write |
+|||
|
+
|
+
|
+
|
+Standard read-only |
+|||
|
+
|
+
|
+
|
+Standard read-only |
+|||
|
+
|
+
|
+
|
+Custom read-only |
+|||
Hypervisor and VS CSRs |
+|||||||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Custom read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Custom read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Custom read/write |
+|||
Machine-Level CSRs |
+|||||||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write debug CSRs |
+|||
|
+
|
+
|
+
|
+Debug-mode-only CSRs |
+|||
|
+
|
+
|
+
|
+Custom read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Custom read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Standard read/write |
+|||
|
+
|
+
|
+
|
+Custom read/write |
+|||
| Number | +Privilege | +Name | +Description | +
|---|---|---|---|
Unprivileged Floating-Point CSRs |
+|||
|
+URW |
+
|
+Floating-Point Accrued Exceptions. |
+
Unprivileged Counter/Timers |
+|||
|
+URO |
+
|
+Cycle counter for RDCYCLE instruction. |
+
| Number | +Privilege | +Name | +Description | +
|---|---|---|---|
Supervisor Trap Setup |
+|||
|
+SRW |
+
|
+Supervisor status register. |
+
Supervisor Configuration |
+|||
|
+SRW |
+
|
+Supervisor environment configuration register. |
+
Supervisor Counter Setup |
+|||
|
+SRW |
+
|
+Supervisor counter-inhibit register. |
+
Supervisor Trap Handling |
+|||
|
+SRW |
+
|
+Scratch register for supervisor trap handlers. |
+
Supervisor Protection and Translation |
+|||
|
+SRW |
+
|
+Supervisor address translation and protection. |
+
Debug/Trace Registers |
+|||
|
+SRW |
+
|
+Supervisor-mode context register. |
+
Supervisor State Enable Registers |
+|||
|
+SRW |
+
|
+Supervisor State Enable 0 Register. |
+
| Number | +Privilege | +Name | +Description | +
|---|---|---|---|
Hypervisor Trap Setup |
+|||
|
+HRW |
+
|
+Hypervisor status register. |
+
Hypervisor Trap Handling |
+|||
|
+HRW |
+
|
+Hypervisor bad guest physical address. |
+
Hypervisor Configuration |
+|||
|
+HRW |
+
|
+Hypervisor environment configuration register. |
+
Hypervisor Protection and Translation |
+|||
|
+HRW |
+
|
+Hypervisor guest address translation and protection. |
+
Debug/Trace Registers |
+|||
|
+HRW |
+
|
+Hypervisor-mode context register. |
+
Hypervisor Counter/Timer Virtualization Registers |
+|||
|
+HRW |
+
|
+Delta for VS/VU-mode timer. |
+
Hypervisor State Enable Registers |
+|||
|
+HRW |
+
|
+Hypervisor State Enable 0 Register. |
+
Virtual Supervisor Registers |
+|||
|
+HRW |
+
|
+Virtual supervisor status register. |
+
| Number | +Privilege | +Name | +Description | +
|---|---|---|---|
Machine Information Registers |
+|||
|
+MRO |
+
|
+Vendor ID. |
+
Machine Trap Setup |
+|||
|
+MRW |
+
|
+Machine status register. |
+
Machine Trap Handling |
+|||
|
+MRW |
+
|
+Scratch register for machine trap handlers. |
+
Machine Configuration |
+|||
|
+MRW |
+
|
+Machine environment configuration register. |
+
Machine Memory Protection |
+|||
|
+MRW |
+
|
+Physical memory protection configuration. |
+
Machine State Enable Registers |
+|||
|
+MRW |
+
|
+Machine State Enable 0 Register. |
+
| Number | +Privilege | +Name | +Description | +
|---|---|---|---|
Machine Non-Maskable Interrupt Handling |
+|||
|
+MRW |
+
|
+Resumable NMI scratch register. |
+
Machine Counter/Timers |
+|||
|
+MRW |
+
|
+Machine cycle counter. |
+
Machine Counter Setup |
+|||
|
+MRW |
+
|
+Machine counter-inhibit register. |
+
Debug/Trace Registers (shared with Debug Mode) |
+|||
|
+MRW |
+
|
+Debug/Trace trigger register select. |
+
Debug Mode Registers |
+|||
|
+DRW |
+
|
+Debug control and status register. |
+
2.3. CSR Field Specifications
+The following definitions and abbreviations are used in specifying the +behavior of fields within the CSRs.
+2.3.1. Reserved Writes Preserve Values, Reads Ignore Values (WPRI)
+Some whole read/write fields are reserved for future use. Software +should ignore the values read from these fields, and should preserve the +values held in these fields when writing values to other fields of the +same register. For forward compatibility, implementations that do not +furnish these fields must make them read-only zero. These fields are +labeled WPRI in the register descriptions.
+| + + | +
+
+
+To simplify the software model, any backward-compatible future +definition of previously reserved fields within a CSR must cope with the +possibility that a non-atomic read/modify/write sequence is used to +update other fields in the CSR. Alternatively, the original CSR +definition must specify that subfields can only be updated atomically, +which may require a two-instruction clear bit/set bit sequence in +general that can be problematic if intermediate values are not legal. + |
+
2.3.2. Write/Read Only Legal Values (WLRL)
+Some read/write CSR fields specify behavior for only a subset of +possible bit encodings, with other bit encodings reserved. Software +should not write anything other than legal values to such a field, and +should not assume a read will return a legal value unless the last write +was of a legal value, or the register has not been written since another +operation (e.g., reset) set the register to a legal value. These fields +are labeled WLRL in the register descriptions.
+| + + | +
+
+
+Hardware implementations need only implement enough state bits to +differentiate between the supported values, but must always return the +complete specified bit-encoding of any supported value when read. + |
+
Implementations are permitted but not required to raise an +illegal-instruction exception if an instruction attempts to write a +non-supported value to a WLRL field. Implementations can return arbitrary +bit patterns on the read of a WLRL field when the last write was of an +illegal value, but the value returned should deterministically depend on +the illegal written value and the value of the field prior to the write.
+2.3.3. Write Any Values, Reads Legal Values (WARL)
+Some read/write CSR fields are only defined for a subset of bit +encodings, but allow any value to be written while guaranteeing to +return a legal value whenever read. Assuming that writing the CSR has no +other side effects, the range of supported values can be determined by +attempting to write a desired setting then reading to see if the value +was retained. These fields are labeled WARL in the register descriptions.
+Implementations will not raise an exception on writes of unsupported +values to a WARL field. Implementations can return any legal value on the +read of a WARL field when the last write was of an illegal value, but the +legal value returned should deterministically depend on the illegal +written value and the architectural state of the hart.
+2.4. CSR Field Modulation
+If a write to one CSR changes the set of legal values allowed for a
+field of a second CSR, then unless specified otherwise, the second CSR’s
+field immediately gets an UNSPECIFIED value from among its new legal values. This
+is true even if the field’s value before the write remains legal after
+the write; the value of the field may be changed in consequence of the
+write to the controlling CSR.
| + + | +
+
+
+As a special case of this rule, the value written to one CSR may control
+whether a field of a second CSR is writable (with multiple legal values)
+or is read-only. When a write to the controlling CSR causes the second
+CSR’s field to change from previously read-only to now writable, that
+field immediately gets an +
+
+Some CSR fields are, when writable, defined as aliases of other CSR
+fields. Let x be such a CSR field, and let y be the CSR field it aliases when writable. If a write to a controlling CSR causes field x to change from previously read-only to now writable, the new value of x is not |
+
A change to the value of a CSR for this reason is not a write to the +affected CSR and thus does not trigger any side effects specified for +that CSR.
+2.5. Implicit Reads of CSRs
+Implementations sometimes perform implicit reads of CSRs. (For
+example, all S-mode instruction fetches implicitly read the satp CSR.)
+Unless otherwise specified, the value returned by an implicit read of a
+CSR is the same value that would have been returned by an explicit read
+of the CSR, using a CSR-access instruction in a sufficient privilege
+mode.
2.6. CSR Width Modulation
+If the width of a CSR is changed (for example, by changing SXLEN or +UXLEN, as described in Section 3.1.6.2), the +values of the writable fields and bits of the new-width CSR are, +unless specified otherwise, determined from the previous-width CSR as +though by this algorithm:
+-
+
-
+
The value of the previous-width CSR is copied to a temporary register +of the same width.
+
+ -
+
For the read-only bits of the previous-width CSR, the bits at the same +positions in the temporary register are set to zeros.
+
+ -
+
The width of the temporary register is changed to the new width. If +the new width W is narrower than the previous width, the +least-significant W bits of the temporary register are +retained and the more-significant bits are discarded. If the new width +is wider than the previous width, the temporary register is +zero-extended to the wider width.
+
+ -
+
Each writable field of the new-width CSR takes the value of the bits +at the same positions in the temporary register.
+
+
Changing the width of a CSR is not a read or write of the CSR and thus +does not trigger any side effects.
+2.7. Explicit Accesses to CSRs Wider than XLEN
+If a standard CSR is wider than XLEN bits, then an explicit read +of the CSR returns the register’s least-significant XLEN bits, +and an explicit write to the CSR modifies only the register’s +least-significant XLEN bits, leaving the upper bits unchanged.
+Some standard CSRs, such as the counter CSRs of extension
+Zicntr, are always 64 bits, even when XLEN=32 (RV32).
+For each such 64-bit CSR (for example, counter time),
+a corresponding 32-bit high-half CSR is usually defined with
+the same name but with the letter ‘h’ appended at the end (timeh).
+The high-half CSR aliases bits 63:32 of its namesake
+64-bit CSR, thus providing a way for RV32 software
+to read and modify the otherwise-unreachable 32 bits.
Standard high-half CSRs are accessible only when +the base RISC-V instruction set is RV32 (XLEN=32). +For RV64 (when XLEN=64), the addresses of all standard high-half CSRs +are reserved, so an attempt to access a high-half CSR +typically raises an illegal-instruction exception.
+3. Machine-Level ISA, Version 1.13
+This chapter describes the machine-level operations available in +machine-mode (M-mode), which is the highest privilege mode in a RISC-V +hart. M-mode is used for low-level access to a hardware platform and +is the first mode entered at reset. M-mode can also be used to implement +features that are too difficult or expensive to implement in hardware +directly. The RISC-V machine-level ISA contains a common core that is +extended depending on which other privilege levels are supported and +other details of the hardware implementation.
+3.1. Machine-Level CSRs
+3.1.1. Machine ISA Register misa
+The misa CSR is a WARL read-write register reporting the ISA supported by the hart.
+[CVA6] The MXL (Machine XLEN) field encodes the native base integer ISA width as
+shown in Table 9. The MXL field is read-only.
+In CVA6, the misa register returns the MXL field which indicates the
+effective XLEN in M-mode, a constant termed MXLEN.
| MXL | +XLEN | +
|---|---|
1 |
+32 |
+
The misa CSR is MXLEN bits wide.
[CVA6] The Extensions field encodes the presence of the standard extensions, +with a single bit per letter of the alphabet (bit 0 encodes presence of +extension "A" , bit 1 encodes presence of extension "B", through to +bit 25 which encodes "Z"). The "I" bit will be set for RV32I, RV64I, +and RV128I base ISAs, and the "E" bit will be set for RV32E and RV64E. +In CVA6, the Extensions field is not writeable, the presence of standard extensions corresponds to the hardware reset value and cannot be modified by writing in the register.
+| Bit | +Character | +Description | +
|---|---|---|
0 |
+A |
+Atomic extension |
+
The "U" and "S" bits will be set if there is support for user and +supervisor modes respectively.
+The "X" bit will be set if there are any non-standard extensions.
+When "B" bit is 1, the implementation supports the instructions provided by the +Zba, Zbb, and Zbs extensions. When "B" bit is 0, it indicates that the +implementation may not support one or more of the Zba, Zbb, or Zbs extensions.
+3.1.2. Machine Vendor ID Register mvendorid
+[CVA6] The mvendorid CSR is a 32-bit read-only register providing the JEDEC
+manufacturer ID of the provider of the core. In CVA6, mvendorid is implemented and returns the commercial implementation id supplied to OpenHW Group organization, 0x602.
+mvendorid)3.1.3. Machine Architecture ID Register marchid
+[CVA6] The marchid CSR is an MXLEN-bit read-only register encoding the base
+microarchitecture of the hart. In CVA6, marchid is implemented and returns the base microarchitecture of the hart supplied to CVA6, 0x3.
+marchid)3.1.4. Machine Implementation ID Register mimpid
+The mimpid CSR provides a unique encoding of the version of the
+processor implementation.
[CVA6] The mimpid register is implemented and the return value is TODO.
+The Implementation value should reflect the design of the RISC-V
+processor itself and not any surrounding system.
+mimpid)3.1.5. Hart ID Register mhartid
+[CV32A65X] The mhartid CSR is an MXLEN-bit read-only register containing the
+integer ID of the hardware thread running the code. This register is
+readable. In CV32A65X-based system, only one hart is implemented.
+Hart ID is zero.
+mhartid)3.1.6. Machine Status Registers (mstatus and mstatush)
+[CV32A65X] The mstatus register is an MXLEN-bit read/write register formatted as
+shown in Figure 7. The mstatus register
+keeps track of and controls the hart’s current operating state.
+mstatus) for RV32[CV32A65X] mstatush is a 32-bit read/write register formatted as
+shown in Figure 8.
+mstatush) for RV32.3.1.6.1. Privilege and Global Interrupt-Enable Stack in mstatus register
+[CV32A65X] As only M-mode is implemented, the instructions and +registers related to less privilege modes are not implemented. +Global interrupt-enable bit, MIE, is provided for M-mode. +This bit is primarily used to guarantee atomicity with respect to +interrupt handlers in the current privilege mode.
+[CV32A65X] When a hart is executing in privilege mode M, interrupts are globally +enabled when MIE=1 and globally disabled when MIE=0.
+TODO
+[CV32A65X] An MRET instruction is used to return from a trap in M-mode. When +executing an MRET instruction, MIE is set to MPIE; MPIE is set to 1; +and MPP keeps M value.
+[CV32A65X] Privilege mode S and U are not implemented, MPP field is +WARL field that can hold only privilege mode M, 11 read only, and SPP +and UPP are read-only 0.
+3.1.6.2. Base ISA Control in mstatus Register
+[CV32A65X] The SXL and UXL fields do not exist.
+3.1.6.3. Memory Privilege in mstatus Register
+[CV32A65X] As the U-Mode is not implemented, MPRV is read-only 0. +Loads and stores behave as normal, using the translation and protection +mechanisms of the current privilege mode.
+3.1.6.4. Endianness Control in mstatus and mstatush Registers
+The MBE, SBE, and UBE bits in mstatus and mstatush are WARL fields that
+control the endianness of memory accesses other than instruction
+fetches. Instruction fetches are always little-endian.
MBE controls whether non-instruction-fetch memory accesses made from
+M-mode (assuming mstatus.MPRV=0) are little-endian (MBE=0) or
+big-endian (MBE=1).
It is always little-endian in M-Mode, the MBE is read-only zero.
+U-Mode and S-Mode are not implemented, UBE and SBE are read-only 0.
+3.1.6.5. Virtualization Support in mstatus Register
+The TVM (Trap Virtual Memory) bit is a WARL field that supports intercepting +supervisor virtual-memory management operations.
+S-Mode is not implemented, TVM is read-only 0.
+The TW (Timeout Wait) bit is a WARL field that supports intercepting the WFI +instruction (see Section 3.3.3).
+TW is read-only 0 because there are no modes less privileged +than M.
+The TSR (Trap SRET) bit is a WARL field that supports intercepting the +supervisor exception return instruction, SRET.
+As it does not implement S-Mode, TSR is read-only 0.
+3.1.6.6. Extension Context Status in mstatus Register
+Supporting substantial extensions is one of the primary goals of RISC-V, +and hence we define a standard interface to allow unchanged +privileged-mode code, particularly a supervisor-level OS, to support +arbitrary user-mode state extensions.
+[CV32A65X] The FS[1:0] and VS[1:0] WARL fields and the XS[1:0] read-only field are used +to reduce the cost of context save and restore by setting and tracking +the current state of the floating-point unit and any other user-mode +extensions respectively.
+As neither the F extension nor S-mode is implemented, then +FS is read-only zero.
+As neither the v registers nor S-mode is implemented, then
+VS is read-only zero.
As no additional user extensions require new state, the +XS field is read-only zero. TODO
+[CV32A65X] The SD bit is a read-only bit that summarizes whether either the FS, VS, +or XS fields signal the presence of some dirty state that will require +saving extended user context to memory.
+[CV32A65X] As FS, XS, and VS are all read-only zero, SD is also always +zero.
+[CV32A65X] When an extension’s status is set to Off, any instruction that attempts +to read or write the corresponding state will cause an +illegal-instruction exception.
+3.1.7. Machine Trap-Vector Base-Address Register (mtvec)
+The mtvec register is an MXLEN-bit WARL read/write register that holds
+trap vector configuration, consisting of a vector base address (BASE)
+and a vector mode (MODE).
+[CV32A65X] The mtvec register is writable. The value in the BASE field must
+always be aligned on a 4-byte boundary. mtvec is always accessed in
+Mode=Direct.
| Value | +Name | +Description | +
|---|---|---|
0 |
+Direct |
+All traps set |
+
The encoding of the MODE field is shown in
+Table 11. When MODE=Direct, all traps into
+machine mode cause the pc to be set to the address in the BASE field.
3.1.8. Machine Trap Delegation Registers (medeleg and mideleg)
+[CV32A65X] All traps at any privilege level are handled in machine +mode.
+[CV32A65X] As S-mode is not implemented, the medeleg and mideleg registers do not exist.
3.1.9. Machine Interrupt Registers (mip and mie)
+The mip register is an MXLEN-bit read/write register containing
+information on pending interrupts, while mie is the corresponding
+MXLEN-bit read/write register containing interrupt enable bits.
+Interrupt cause number i (as reported in CSR mcause,
+Section 3.1.15) corresponds with bit i in both mip and
+mie. Bits 15:0 are allocated to standard interrupt causes only, while
+bits 16 and above are designated for platform use.
+
+[CV32A65X] As only M-Mode is implemented, an interrupt i will trap
+to M-mode (causing the privilege mode to change to M-mode) if all of the
+following are true: (a) the MIE bit in the mstatus register is set;
+(b) bit i is set in both mip and mie.
[CV32A65X] These conditions for an interrupt trap to occur must be evaluated in a
+bounded amount of time from when an interrupt becomes, or ceases to be,
+pending in mip, and must also be evaluated immediately following the
+execution of an MRET instruction or an explicit write to a CSR on
+which these interrupt trap conditions expressly depend (including mip,
+mie, mstatus, and mideleg).
[CV32A65X] Each individual bit in register mip is read-only. If interrupt i
+can become pending but bit i in mip is read-only, the implementation
+must provide some other mechanism for clearing the pending interrupt.
[CV32A65X] TODO: A bit in mie must be writable if the corresponding interrupt can ever
+become pending. Bits of mie that are not writable must be read-only
+zero.
[CV32A65X] The standard portions (bits 15:0) of registers mip and mie are
+formatted as shown in Figure 12 and Figure 13 respectively.
+mip.
+mie.Bits mip.MEIP and mie.MEIE are the interrupt-pending and
+interrupt-enable bits for machine-level external interrupts. MEIP is
+read-only in mip, and is set and cleared by a platform-specific
+interrupt controller.
Bits mip.MTIP and mie.MTIE are the interrupt-pending and
+interrupt-enable bits for machine timer interrupts. MTIP is read-only in
+mip, and is cleared by writing to the memory-mapped machine-mode timer
+compare register.
As the system has only one hart then mip.MSIP and mie.MSIE are
+read-only zeros.
As supervisor mode is not implemented, bits SEIP, STIP, and SSIP of
+mip and SEIE, STIE, and SSIE of mie are read-only zeros.
As the Sscofpmf extension is not implemented, mip.LCOFIP and mie.LCOFIE are read-only zeros.
Multiple simultaneous interrupts destined for M-mode are handled in the +following decreasing priority order: MEI, MSI, MTI.
+As only S-Mode is not implemented, the corresponding bits in sip and sie are read-only zero.
3.1.10. Hardware Performance Monitor
+M-mode includes a basic hardware performance-monitoring facility. The
+mcycle CSR counts the number of clock cycles executed by the processor
+core on which the hart is running. The minstret CSR counts the number
+of instructions the hart has retired. The mcycle and minstret
+registers have 64-bit precision on all RV32 and RV64 harts.
The counter registers have an arbitrary value after the hart is reset,
+and can be written with a given value. Any CSR write takes effect after
+the writing instruction has otherwise completed. The mcycle CSR may be
+shared between harts on the same core, in which case writes to mcycle
+will be visible to those harts. The platform should provide a mechanism
+to indicate which harts share an mcycle CSR.
[CV32A65X] The hardware performance monitor includes 29 additional 64-bit event
+counters, mhpmcounter3-mhpmcounter31. The event selector CSRs,
+mhpmevent3-mhpmevent31, are 64-bit WARL registers that control which
+event causes the corresponding counter to increment. The meaning of
+these events is defined by the platform, but event 0 is defined to mean
+"no event." In CV32A65X all counters are implemented, but both the counter and its corresponding event
+selector are read-only 0.
+The mhpmcounters are WARL registers that support up to 64 bits of
+precision on RV32 and RV64.
When XLEN=32, reads of the mcycle, minstret, mhpmcountern, and mhpmeventn
+CSRs return bits 31-0 of the corresponding register, and writes change
+only bits 31-0; reads of the mcycleh, minstreth, and mhpmcounternh
+CSRs return bits 63-32 of the corresponding register, and writes change
+only bits 63-32.
+As the Sscofpmf extension is not implemented, the mhpmeventnh CSRs
+are not provided.
3.1.11. Machine Counter-Enable Register (mcounteren)
+The counter-enable register mcounteren is a 32-bit register that
+controls the availability of the hardware performance-monitoring
+counters to the next-lower privileged mode.
[CV32A65X] As U-mode is not implemented, the mcounteren register does not exist.
3.1.12. Machine Counter-Inhibit CSR (mcountinhibit)
+
+mcountinhibit[CV32A65X] The mcountinhibit register is not implemented, the implementation
+behaves as though the register were set to zero.
3.1.13. Machine Scratch Register (mscratch)
+The mscratch register is an MXLEN-bit read/write register dedicated
+for use by machine mode. Typically, it is used to hold a pointer to a
+machine-mode hart-local context space and swapped with a user register
+upon entry to an M-mode trap handler.
+3.1.14. Machine Exception Program Counter (mepc)
+mepc is an MXLEN-bit read/write register formatted as shown in
+Figure 17. The low bit of mepc (mepc[0]) is
+always zero.
mepc is a WARL register that must be able to hold all valid virtual
+addresses. It need not be capable of holding all possible invalid
+addresses. Prior to writing mepc, implementations may convert an
+invalid address into some other invalid address that mepc is capable
+of holding.
When a trap is taken into M-mode, mepc is written with the virtual
+address of the instruction that was interrupted or that encountered the
+exception. Otherwise, mepc is never written by the implementation,
+though it may be explicitly written by software.
+3.1.15. Machine Cause Register (mcause)
+The mcause register is an MXLEN-bit read-write register formatted as
+shown in Figure 18. When a trap is taken into
+M-mode, mcause is written with a code indicating the event that
+caused the trap. Otherwise, mcause is never written by the
+implementation, though it may be explicitly written by software.
The Interrupt bit in the mcause register is set if the trap was caused
+by an interrupt. The Exception Code field contains a code identifying
+the last exception or interrupt. Table 12 lists
+the possible machine-level exception codes. The Exception Code is a
+WLRL field, so is only guaranteed to hold supported exception codes.
+mcause.[CV32A65X] Note that load and load-reserved instructions generate load exceptions, +whereas store and store-conditional instructions generate +store exceptions.
+[CVA6] If an instruction may raise multiple synchronous exceptions, the
+decreasing priority order of
+Table 13 indicates which
+exception is taken and reported in mcause. The priority of any custom
+synchronous exceptions is implementation-defined. TODO
| Interrupt | +Exception Code | +Description | +
|---|---|---|
1 |
+0 |
+Reserved |
+
1 |
+4 |
+Reserved |
+
1 |
+8 |
+Reserved |
+
1 |
+12 |
+Reserved |
+
0 |
+0 |
+Instruction address misaligned |
+
| Priority | +Exc.Code | +Description | +
|---|---|---|
Highest |
+3 |
+Instruction address breakpoint |
+
| + | 12, 1 |
+During instruction address translation: |
+
| + | 1 |
+With physical address for instruction: |
+
| + | 2 |
+Illegal instruction |
+
| + | 4,6 |
+Optionally: |
+
| + | 13, 15, 5, 7 |
+During address translation for an explicit memory access: |
+
| + | 5,7 |
+With physical address for an explicit memory access: |
+
Lowest |
+4,6 |
+If not higher priority: |
+
[CV32A65X] Load/store address-misaligned exceptions may have either higher or +lower priority than load/store access-fault +exceptions. TODO
+3.1.16. Machine Trap Value Register (mtval)
+[CV32A65X] The mtval register is an MXLEN-bit read-only 0 register.
3.1.17. Machine Configuration Pointer Register (mconfigptr)
+mconfigptr is an MXLEN-bit read-only CSR that holds the physical
+address of a configuration data structure.
[CV32A65X] mconfigptr is implemented, but it is read-only 0 to indicate the
+configuration data structure does not exist.
3.1.18. Machine Environment Configuration Register (menvcfg)
+The menvcfg CSR is a 64-bit read/write register that controls
+certain characteristics of the execution environment for modes less
+privileged than M.
As XLEN=32, menvcfgh is a 32-bit read/write register
+that aliases bits 63:32 of menvcfg.
[CV32A65X] As U-mode is not supported, then registers menvcfg and menvcfgh do
+not exist.
3.1.19. Machine Security Configuration Register (mseccfg)
+mseccfg is an optional 64-bit read/write register,
+that controls security features.
As XLEN=32, mseccfgh is a 32-bit read/write register
+that aliases bits 63:32 of mseccfg.
[CV32A65X] As Zkr, Smepmp, and Smmpm extensions are not implemented,
+mseccfg and mseccfgh do not exist. TODO.
3.2. Machine-Level Memory-Mapped Registers
+3.2.1. Machine Timer Registers (mtime and mtimecmp)
+Platforms provide a real-time counter, exposed as a memory-mapped
+machine-mode read-write register, mtime. mtime must increment at
+constant frequency, and the platform must provide a mechanism for
+determining the period of an mtime tick. The mtime register will
+wrap around if the count overflows.
The mtime register has a 64-bit precision on all RV32 and RV64
+systems. Platforms provide a 64-bit memory-mapped machine-mode timer
+compare register (mtimecmp). A machine timer interrupt becomes pending
+whenever mtime contains a value greater than or equal to mtimecmp,
+treating the values as unsigned integers. The interrupt remains posted
+until mtimecmp becomes greater than mtime (typically as a result of
+writing mtimecmp). The interrupt will only be taken if interrupts are
+enabled and the MTIE bit is set in the mie register.
+
+Writes to mtime and mtimecmp are guaranteed to be reflected in MTIP
+eventually, but not necessarily immediately.
In RV32, memory-mapped writes to mtimecmp modify only one 32-bit part
+of the register. The following code sequence sets a 64-bit mtimecmp
+value without spuriously generating a timer interrupt due to the
+intermediate value of the comparand:
For RV64, naturally aligned 64-bit memory accesses to the mtime and
+mtimecmp registers are additionally supported and are atomic.
mtimecmp prevents mtimecmp from temporarily becoming smaller than the lesser of the old and new values.# New comparand is in a1:a0. + li t0, -1 + la t1, mtimecmp + sw t0, 0(t1) # No smaller than old value. + sw a1, 4(t1) # No smaller than new value. + sw a0, 0(t1) # New value.+
3.3. Machine-Mode Privileged Instructions
+3.3.1. Environment Call and Breakpoint
+
+[CV32A65X] The ECALL instruction is used to make a request to the supporting +execution environment. When executed M-mode, it +generates an environment-call-from-M-mode +exception, and performs no other operation.
+The EBREAK instruction is used by debuggers to cause control to be +transferred back to a debugging environment. It generates a breakpoint +exception and performs no other operation.
+ECALL and EBREAK cause the receiving privilege mode’s epc register to
+be set to the address of the ECALL or EBREAK instruction itself, not
+the address of the following instruction. As ECALL and EBREAK cause
+synchronous exceptions, they are not considered to retire, and should
+not increment the minstret CSR.
3.3.2. Trap-Return Instructions
+Instructions to return from trap are encoded under the PRIV minor +opcode.
+
+[CV32A65X] To return after handling a trap, there are separate trap return
+instructions per privilege level, MRET and SRET. MRET is always
+provided. In CV32A65X, SRET is not provided as supervisor mode is not supported, and
+raises an illegal-instruction exception. In addition to manipulating
+the privilege stack as described in Section 3.1.6.1,
+MRET sets the pc to the value stored in the mepc register.
3.3.3. Wait for Interrupt
+[CV32A65X] The Wait for Interrupt instruction (WFI) informs the
+implementation that the current hart can be stalled until an interrupt
+might need servicing. This instruction
+cannot raise an illegal-instruction exception because TW=0 in mstatus, as
+described in Section 3.1.6.5.
+If an enabled interrupt is present or later becomes present while the
+hart is stalled, the interrupt trap will be taken on the following
+instruction, i.e., execution resumes in the trap handler and mepc =
+pc + 4.
Implementations are permitted to resume execution for any reason, even if an +enabled interrupt has not become pending. Hence, a legal implementation is to +simply implement the WFI instruction as a NOP.
+[CV32A65X] The WFI instruction can also be executed when interrupts are disabled.
+The operation of WFI must be unaffected by the global interrupt bits in
+mstatus (MIE), but should
+honor the individual interrupt enables (e.g, MTIE) (i.e.,
+implementations should avoid resuming the hart if the interrupt is
+pending but not individually enabled). WFI is also required to resume
+execution for locally enabled interrupts pending,
+regardless of the global interrupt enable.
If the event that causes the hart to resume execution does not cause an
+interrupt to be taken, execution will resume at pc + 4, and software
+must determine what action to take, including looping back to repeat the
+WFI if there was no actionable event.
3.3.4. Custom SYSTEM Instructions
+The subspace of the SYSTEM major opcode shown in Figure 21 is designated for custom use. It is recommended that these instructions use bits 29:28 to designate the +minimum required privilege mode, as do other SYSTEM instructions.
+
+3.4. Reset
+[CV32A65X] Privilege mode is always M.
+As little-endian memory accesses are supported,
+the mstatus/mstatush field MBE is reset to 0.
+Upon reset, the mstatus fields MIE and MPRV are reset to 0.
+The misa register is set as described in Section 3.1.1.
+The pc is set to 0x80000000 reset vector. TODO
+The mcause register is set to a value indicating the cause of the reset.
+Writable PMP registers’ A and L fields are set to 0.
+No WARL field contains an illegal value. All other hart state is UNSPECIFIED.
As CV32A65X does not distinguished different reset conditions,
+The mcause returns 0 after reset.
3.5. Non-Maskable Interrupts
+Non-maskable interrupts (NMIs) are only used for hardware error
+conditions, and cause an immediate jump to an implementation-defined NMI
+vector running in M-mode regardless of the state of a hart’s interrupt
+enable bits. The mepc register is written with the virtual address of
+the instruction that was interrupted, and mcause is set to a value
+indicating the source of the NMI. The NMI can thus overwrite state in an
+active machine-mode interrupt handler.
[CV32A65X] Upon NMI, the high Interrupt bit of mcause is set to indicate
+that this was an interrupt. As CV32A65X does not distinguish sources
+of NMIs, the mcause register returns 0 in the Exception Code.
Unlike resets, NMIs do not reset processor state, enabling diagnosis, +reporting, and possible containment of the hardware error.
+3.6. Physical Memory Attributes
+The physical memory map for a complete system includes various address +ranges, some corresponding to memory regions, some to memory-mapped +control registers, and some to vacant holes in the address space. Some +memory regions might not support reads, writes, or execution; some might +not support subword or subblock accesses; some might not support atomic +operations; and some might not support cache coherence or might have +different memory models. Similarly, memory-mapped control registers vary +in their supported access widths, support for atomic operations, and +whether read and write accesses have associated side effects. In RISC-V +systems, these properties and capabilities of each region of the +machine’s physical address space are termed physical memory attributes +(PMAs). This section describes RISC-V PMA terminology and how RISC-V +systems implement and check PMAs.
+[CV32A65X] PMAs are inherent properties of the underlying hardware. The PMAs of +some memory regions are fixed at chip design time.
+[CV32A65X] Most systems will require that at least some PMAs are dynamically +checked in hardware later in the execution pipeline after the physical +address is known, as some operations will not be supported at all +physical memory addresses, and some operations require knowing the +current setting of a configurable PMA attribute. While many other +architectures specify some PMAs in the virtual memory page tables and +use the TLB to inform the pipeline of these properties, this approach +injects platform-specific information into a virtualized layer and can +cause system errors unless attributes are correctly initialized in each +page-table entry for each physical memory region. In addition, the +available page sizes might not be optimal for specifying attributes in +the physical memory space, leading to address-space fragmentation and +inefficient use of expensive TLB entries.
+[CV32A65X] For RISC-V, we separate out specification and checking of PMAs into a +separate hardware structure, the PMA checker. In many cases, the +attributes are known at system design time for each physical address +region, and can be hardwired into the PMA checker. Where the attributes +are run-time configurable, platform-specific memory-mapped control +registers can be provided to specify these attributes at a granularity +appropriate to each region on the platform (e.g., for an on-chip SRAM +that can be flexibly divided between cacheable and uncacheable uses). +PMAs are checked for any access to physical memory, including accesses +that have undergone virtual to physical memory translation. To aid in +system debugging, we strongly recommend that, where possible, RISC-V +processors precisely trap physical memory accesses that fail PMA checks. +Precisely trapped PMA violations manifest as instruction, load, or store +access-fault exceptions, distinct from virtual-memory page-fault +exceptions. Precise PMA traps might not always be possible, for example, +when probing a legacy bus architecture that uses access failures as part +of the discovery mechanism. In this case, error responses from +peripheral devices will be reported as imprecise bus-error interrupts.
+[CV32A65X] PMAs must also be readable by software to correctly access certain +devices or to correctly configure other hardware components that access +memory, such as DMA engines. As PMAs are tightly tied to a given +physical platform’s organization, many details are inherently +platform-specific, as is the means by which software can learn the PMA +values for a platform. Some devices, particularly legacy buses, do not +support discovery of PMAs and so will give error responses or time out +if an unsupported access is attempted. Typically, platform-specific +machine-mode code will extract PMAs and ultimately present this +information to higher-level less-privileged software using some standard +representation.
+3.6.1. Main Memory versus I/O versus Vacant Regions
+The most important characterization of a given memory address range is +whether it holds regular main memory, or I/O devices, or is vacant. +Regular main memory is required to have a number of properties, +specified below, whereas I/O devices can have a much broader range of +attributes. Memory regions that do not fit into regular main memory, for +example, device scratchpad RAMs, are categorized as I/O regions. Vacant +regions are also classified as I/O regions but with attributes +specifying that no accesses are supported.
+3.6.2. Supported Access Type PMAs
+Access types specify which access widths, from 8-bit byte to long +multi-word burst, are supported, and also whether misaligned accesses +are supported for each access width.
+Main memory regions always support read and write of all access widths +required by the attached devices, and can specify whether instruction +fetch is supported.
+I/O regions can specify which combinations of read, write, or execute +accesses to which data widths are supported.
+For systems with page-based virtual memory, I/O and memory regions can +specify which combinations of hardware page-table reads and hardware +page-table writes are supported.
+3.6.3. Atomicity PMAs
+[CV32A65X] Atomic extension is not implemented.
+3.6.3.1. AMO PMA
+[CV32A65X] Atomic extension is not implemented.
+3.6.3.2. Reservability PMA
+[CV32A65X] Atomic extension is not implemented.
+3.6.4. Misaligned Atomicity Granule PMA
+[CV32A65X] Atomic extension is not implemented.
+3.6.5. Memory-Ordering PMAs
+Regions of the address space are classified as either main memory or +I/O for the purposes of ordering by the FENCE instruction and +atomic-instruction ordering bits.
+Accesses by one hart to main memory regions are observable not only by +other harts but also by other devices with the capability to initiate +requests in the main memory system (e.g., DMA engines). Coherent main +memory regions always have either the RVWMO or RVTSO memory model. +Incoherent main memory regions have an implementation-defined memory +model.
+Accesses by one hart to an I/O region are observable not only by other +harts and bus mastering devices but also by the targeted I/O devices, +and I/O regions may be accessed with either relaxed or strong +ordering. Accesses to an I/O region with relaxed ordering are generally +observed by other harts and bus mastering devices in a manner similar to +the ordering of accesses to an RVWMO memory region, as discussed in +Section A.4.2 in Volume I of this specification. By contrast, accesses +to an I/O region with strong ordering are generally observed by other +harts and bus mastering devices in program order.
+Each strongly ordered I/O region specifies a numbered ordering channel, +which is a mechanism by which ordering guarantees can be provided +between different I/O regions. Channel 0 is used to indicate +point-to-point strong ordering only, where only accesses by the hart to +the single associated I/O region are strongly ordered.
+Channel 1 is used to provide global strong ordering across all I/O
+regions. Any accesses by a hart to any I/O region associated with
+channel 1 can only be observed to have occurred in program order by all
+other harts and I/O devices, including relative to accesses made by that
+hart to relaxed I/O regions or strongly ordered I/O regions with
+different channel numbers. In other words, any access to a region in
+channel 1 is equivalent to executing a fence io,io instruction before
+and after the instruction.
Other larger channel numbers provide program ordering to accesses by +that hart across any regions with the same channel number.
+Systems might support dynamic configuration of ordering properties on +each memory region.
+3.6.6. Coherence and Cacheability PMAs
+[CV32A65X] Write accesses are not cached. No cache-coherence scheme +is implemented.
+If a PMA indicates non-cacheability, then accesses to that region must +be satisfied by the memory itself, not by any caches.
+3.6.7. Idempotency PMAs
+Idempotency PMAs describe whether reads and writes to an address region +are idempotent. Main memory regions are assumed to be idempotent. For +I/O regions, idempotency on reads and writes can be specified separately +(e.g., reads are idempotent but writes are not). If accesses are +non-idempotent, i.e., there is potentially a side effect on any read or +write access, then speculative or redundant accesses must be avoided.
+For the purposes of defining the idempotency PMAs, changes in observed +memory ordering created by redundant accesses are not considered a side +effect.
+For non-idempotent regions, implicit reads and writes must not be +performed early or speculatively, with the following exceptions. When a +non-speculative implicit read is performed, an implementation (TODO) is +permitted to additionally read any of the bytes within a naturally +aligned power-of-2 region containing the address of the non-speculative +implicit read. Furthermore, when a non-speculative instruction fetch is +performed, an implementation is permitted to additionally read any of +the bytes within the next naturally aligned power-of-2 region of the +same size (with the address of the region taken modulo +2XLEN. The results of these additional reads +may be used to satisfy subsequent early or speculative implicit reads. +The size of these naturally aligned power-of-2 regions is +implementation-defined, but, for systems with page-based virtual memory, +must not exceed the smallest supported page size.
+3.7. Physical Memory Protection
+To support secure processing and contain faults, it is desirable to +limit the physical addresses accessible by software running on a hart. +An optional physical memory protection (PMP) unit provides per-hart +machine-mode control registers to allow physical memory access +privileges (read, write, execute) to be specified for each physical +memory region. The PMP values are checked in parallel with the PMA +checks described in Section 3.6.
+[CV32A65X] The granularity of PMP access control settings are as small as four bytes.
+[CV32A65X] PMP checks applies to M-mode accesses, in which case the PMP registers +themselves are locked, so that even M-mode software cannot change them +until the hart is reset. In effect, PMP can revoke permissions from +M-mode, which by default has full permissions.
+PMP violations are always trapped precisely at the processor.
+3.7.1. Physical Memory Protection CSRs
+PMP entries are described by an 8-bit configuration register and one +MXLEN-bit address register. Some PMP settings additionally use the +address register associated with the preceding PMP entry. 16 PMP +entries are implemented. The lowest-numbered PMP entries must be +implemented first. All PMP CSR fields are WARL and 8 upper entries are +read-only zero. PMP CSRs are only accessible to M-mode.
+[CV32A65X] The PMP configuration registers are densely packed into CSRs to minimize
+context-switch time. For CV32A65X with sixteen CSRs, pmpcfg0–pmpcfg15, hold
+the configurations as shown
+in Figure 22.
+[CV32A65X] The PMP address registers are CSRs named pmpaddr0-pmpaddr15. Each
+PMP address register encodes bits 33-2 of a 34-bit physical address for
+RV32, as shown in Figure 23. Not all
+physical address bits may be implemented, and so the pmpaddr registers
+are WARL. (TODO which bits are implemented)
+Figure 24 shows the layout of a PMP configuration +register. The R, W, and X bits, when set, indicate that the PMP entry +permits read, write, and instruction execution, respectively. When one +of these bits is clear, the corresponding access type is denied. The R, +W, and X fields form a collective WARL field for which the combinations with R=0 and W=1 are reserved. The remaining two fields, A and L, are described in the following sections.
+
+Attempting to fetch an instruction from a PMP region that does not have +execute permissions raises an instruction access-fault exception. +Attempting to execute a load or load-reserved instruction which accesses +a physical address within a PMP region without read permissions raises a +load access-fault exception. Attempting to execute a store, +store-conditional, or AMO instruction which accesses a physical address +within a PMP region without write permissions raises a store +access-fault exception.
+3.7.1.1. Address Matching
+The A field in a PMP entry’s configuration register encodes the +address-matching mode of the associated PMP address register. The +encoding of this field is shown in [pmpcfg-a].
+When A=0, this PMP entry is disabled and matches no addresses. Two other +address-matching modes are supported: naturally aligned power-of-2 +regions (NAPOT), including the special case of naturally aligned +four-byte regions (NA4); and the top boundary of an arbitrary range +(TOR). These modes support four-byte granularity.
+[CV32A65X] Two address-matching modes are supported: disabled and TOR.
+If TOR is selected, the associated address register forms the top of the
+address range, and the preceding PMP address register forms the bottom
+of the address range. If PMP entry i's A field is set to
+TOR, the entry matches any address y such that pmpaddri-1≤y<pmpaddri (irrespective of the value of pmpcfgi-1). If PMP entry 0’s A field is set to TOR, zero is used for the lower bound, and so it matches
+any address y<pmpaddr0.
[CV32A65X] Although the PMP mechanism supports regions as small as four bytes,
+platforms may specify coarser PMP regions. In general, the PMP grain is
+
bytes and must be the same across all PMP regions.
+When 
and
+
.A[1] is clear, i.e. the mode is OFF or TOR,
+then bits 
[G-1:0] read as all zeros. Bits
+[G-1:0] do not affect the TOR address-matching
+logic.
If the current XLEN is greater than MXLEN, the PMP address registers are +zero-extended from MXLEN to XLEN bits for the purposes of address +matching.
+3.7.1.2. Locking and Privilege Mode
+The L bit indicates that the PMP entry is locked, i.e., writes to the
+configuration register and associated address registers are ignored.
+Locked PMP entries remain locked until the hart is reset. If PMP entry
+i is locked, writes to pmpicfg and pmpaddri are ignored. Additionally, if PMP
+entry i is locked and pmpicfg.A is set
+to TOR, writes to pmpaddri-1 are ignored.
[CV32A65X] In addition to locking the PMP entry, the L bit indicates whether the +R/W/X permissions are enforced on M-mode accesses. When the L +bit is clear, any M-mode access matching the PMP entry will succeed.
+3.7.1.3. Priority and Matching Logic
+PMP entries are statically prioritized. The lowest-numbered PMP entry
+that matches any byte of an access determines whether that access
+succeeds or fails. The matching PMP entry must match all bytes of an
+access, or the access fails, irrespective of the L, R, W, and X bits.
+For example, if a PMP entry is configured to match the four-byte range
+0xC–0xF, then an 8-byte access to the range 0x8–0xF will fail,
+assuming that PMP entry is the highest-priority entry that matches those
+addresses.
If a PMP entry matches all bytes of an access, then the L, R, W, and X +bits determine whether the access succeeds or fails. If the L bit is +clear and the privilege mode of the access is M, the access succeeds.
+[CV32A65X] If no PMP entry matches an M-mode access, the access succeeds.
+On some implementations, misaligned loads, stores, and instruction +fetches may also be decomposed into multiple accesses, some of which may +succeed before an access-fault exception occurs. In particular, a +portion of a misaligned store that passes the PMP check may become +visible, even if another portion fails the PMP check. The same behavior +may manifest for stores wider than XLEN bits (e.g., the FSD instruction +in RV32D), even when the store address is naturally aligned.
+3.7.2. Physical Memory Protection and Paging
+[CV32A65X] As page-based virtual memory systems is not implemented, memory accesses +check the PMP settings synchronously.
+4. "Smstateen/Ssstateen" Extensions, Version 1.0.0
+CV32A65X: This extension is not supported.
+5. "Smcsrind/Sscsrind" Indirect CSR Access, Version 1.0.0
+CV32A65X: This extension is not supported.
+6. "Smepmp" Extension for PMP Enhancements for memory access and execution prevention in Machine mode, Version 1.0.0
+CV32A65X: This extension is not supported.
+7. "Smcntrpmf" Cycle and Instret Privilege Mode Filtering, Version 1.0.0
+CV32A65X: This extension is not supported.
+8. "Smrnmi" Extension for Resumable Non-Maskable Interrupts, Version 0.5
+CV32A65X: This extension is not supported.
+9. "Smcdeleg" Counter Delegation Extension, Version 1.0.0
+CV32A65X: This extension is not supported.
+10. Supervisor-Level ISA, Version 1.13
+CV32A65X: This extension is not supported.
+11. "Sstc" Extension for Supervisor-mode Timer Interrupts, Version 1.0.0
+CV32A65X: This extension is not supported.
+12. "Sscofpmf" Extension for Count Overflow and Mode-Based Filtering, Version 1.0.0
+CV32A65X: This extension is not supported.
+13. "H" Extension for Hypervisor Support, Version 1.0
+CV32A65X: This extension is not supported.
+14. RISC-V Privileged Instruction Set Listings
+This chapter presents instruction-set listings for all instructions +defined in the RISC-V Privileged Architecture.
+The instruction-set listings for unprivileged instructions, including +the ECALL and EBREAK instructions, are provided in Volume I of this +manual.
+
+15. History
+15.1. Research Funding at UC Berkeley
+Development of the RISC-V architecture and implementations has been +partially funded by the following sponsors.
+-
+
-
+
Par Lab: Research supported by Microsoft (Award #024263) and Intel +(Award #024894) funding and by matching funding by U.C. Discovery (Award +#DIG07-10227). Additional support came from Par Lab affiliates Nokia, +NVIDIA, Oracle, and Samsung.
+
+ -
+
Project Isis: DoE Award DE-SC0003624.
+
+ -
+
ASPIRE Lab: DARPA PERFECT program, Award HR0011-12-2-0016. DARPA +POEM program Award HR0011-11-C-0100. The Center for Future Architectures +Research (C-FAR), a STARnet center funded by the Semiconductor Research +Corporation. Additional support from ASPIRE industrial sponsor, Intel, +and ASPIRE affiliates, Google, Huawei, Nokia, NVIDIA, Oracle, and +Samsung.
+
+
The content of this paper does not necessarily reflect the position or +the policy of the US government and no official endorsement should be +inferred.
+