CSR
- Version: V2R2
- Status: OK
- Date: 2025/01/20
- Commit: xxx
Glossary
| Abbreviation | Full Name | Description |
|---|---|---|
| CSR | Control and Status Register | Control and status register |
| Trap | Trap | Trap, combined term for interrupt and exception |
| ROB | Reorder Buffer | Reorder buffer |
| PRVM | Privilege Mode | Privilege mode, including M, S, U |
| VM/V | Virtual Mode | Virtualization mode, has VS and VU privilege levels when in virtual mode |
| EX_II | Illegal Instruction Exception | Illegal Instruction Exception |
| EX_VI | Virtual Instruction Exception | Virtual Instruction Exception |
| TVEC | Trap Vector | Entry point configuration register for Trap handlers, independent for m/hs/vs modes |
| IMSIC | Incoming MSI Controller | Incoming MSI Controller, defined in The RISC-V Advanced Interrupt Architecture |
Design Specification
Supports executing CSR instructions
Supports executing CSR read-only instructions
Supports out-of-order execution of CSR read-only instructions
Supports executing system-level instructions such as mret, sret, ecall, ebreak, wfi
Supports receiving interrupts, selecting the highest priority interrupt and sending it to the ROB for processing
Supports generating EX_II and EX_VI exceptions
Supports receiving Trap (interrupt + exception) from ROB and handling Trap
Supports CSR implementation compliant with the riscv-privileged-spec
Supports interrupt and exception delegation
Supports Smaia and Ssaia extensions
Supports Sdtrig and Sdext extensions
Supports H extension
Supports virtualized interrupts
Supports receiving and processing external interrupts
Functionality
CSR acts as a Functional Unit (FU), located in the same ExeUnit within intExuBlock as fence and div. The CSR primarily contains four submodules: csrMod, trapInstMod, trapTvalMod, and imsic. csrMod is the main functional component of the CSR.
The trapTvalMod module is mainly used to manage and update the target value tval related to traps. It updates or clears tval based on input signals such as flush, targetPc, and clear, and ensures that tval is valid when cleared. The module also includes state logic to ensure tval is correctly updated under specific conditions. This module needs to select the source from targetPc emitted by csrMod and fullTarget from flush, and select whether to update or clear by comparing the order of robIdx. Finally, it outputs tval information.
The trapInstMod module is mainly used to manage and update trap instruction encoding information. It updates or clears trap instruction information based on input signals (such as flush, faultCsrUop, and readClear), and ensures trap instructions are correctly updated under specific conditions. The module also includes state logic to ensure trap instruction information is correctly updated under specific conditions. This module needs to select the source from instruction information from decode (including instruction encoding, FtqPtr, and FtqOffset), and instruction information for CSR instructions combined and concatenated by CSR itself. It selects whether to update or clear, and the source of the update, by comparing the order of FtqPtr and FtqOffset. It is set to invalid when flush or readClear is required. Finally, it outputs the trap-related instruction encoding and the corresponding FtqPtr and FtqOffset.
The imsic (Incoming MSI Controller) module is mainly used for csrMod to interact with the content of IMSIC when accessing it via indirect alias CSRs (mireg/sireg/vsireg). It inputs necessary information to imsic, such as the accessed CSR address, the current privilege mode, write data, etc., and then waits for the output return from imsic. If csrMod's own permission check has already determined that an exception should be generated, it will not send a request to imsic.
CSR is responsible for executing CSR category instructions and system category instructions such as mret, sret, ecall, ebreak, wfi. It receives instruction uops and data information from the Backend, and outputs data and jump addresses after execution is complete. If an exception occurs, it sets EX_II or EX_VI according to the rules.
CSR is responsible for receiving interrupt pending signals such as MSIP, MTIP, MEIP, SEIP, VSTIP, VSEIP from external interrupt controllers CLINT and IMSIC. It determines whether to respond based on the current privilege level and its global interrupt enable bit, sorts the corresponding interrupts by priority, and selects the highest priority interrupt to be processed by the ROB.
CSR is responsible for receiving Trap information from the ROB. Based on delegation conditions (m[e|i]deleg and h[e|i]deleg), it sets the Privilege Mode (PRVM) and Virtualization Mode (V) to the privilege level for handling the Trap, modifies the relevant CSR state, and changes the execution flow to the start address of the Trap Handler corresponding to TVEC.
CSR is responsible for storing configuration information that controls floating-point and vector execution (Frm, Vstart, Vl, Vtype, Vxrm, etc.), and storing additional results generated by floating-point and vector instruction execution (Fflags, Vxsat, etc.).
CSR is responsible for interacting with IMSIC via custom data lines to read and write parts of the registers configured in IMSIC for mireg, sireg, and vsireg (specifically, the external interrupts part).
CSR is responsible for configuring and updating TLB-related signals to ensure that the TLB can correctly perform virtual-to-physical address translation. This includes detecting changes in ASID and VMID, transferring values of registers such as satp/vsatp/hgatp, transferring permission and control bits such as mxr/sum in mstatus/vsstatus, and pmm in menvcfg/henvcfg, selecting the virtual memory mode, and configuring physical memory protection extensions. Through these configurations, the TLB can correctly perform address translation in different virtual memory modes.
CSR is responsible for setting and passing flags related to instruction decode for illegal instructions and virtual instructions, based on the current privilege mode and register state. These flags indicate whether certain instructions are illegal or virtual in specific privilege modes. Through these flags, the hardware can correctly handle these instructions during the instruction decode stage.
Custom CSRs
In addition to the CSRs defined in the RISC-V manual, we have also implemented 7 custom CSRs: sbpctl, spfctl, slvpredctl, smblockctl, srnctl, mcorepwr, and mflushpwr.
Among these, sbpctl, spfctl, slvpredctl, smblockctl, and srnctl are defined in HS mode, while mcorepwr and mflushpwr are defined in M mode.
Access to these custom CSRs not only follows the privilege level constraints (lower privilege cannot access higher privilege) but is also controlled by the C field in the Smstateen/Ssstateen extensions for accessing custom content.
The definitions of each custom CSR are as follows.
sbpctl
sbpctl (Speculative Branch Prediction Control register) has an address of 0x5C0 and is a read/write register defined in HS mode.
| Field Name | Field Position | Initial Value | Description |
|---|---|---|---|
| UBTB_ENABLE | 0 | 1 | UBTB_ENABLE set to 1 means uftb is enabled |
| BTB_ENABLE | 1 | 1 | BTB_ENABLE set to 1 means main ftb is enabled |
| BIM_ENABLE | 2 | 1 | BIM_ENABLE set to 1 means bim predictor is enabled |
| TAGE_ENABLE | 3 | 1 | TAGE_ENABLE set to 1 means TAGE predictor is enabled |
| SC_ENABLE | 4 | 1 | SC_ENABLE set to 1 means SC predictor is enabled |
| RAS_ENABLE | 5 | 1 | RAS_ENABLE set to 1 means RAS predictor is enabled |
| LOOP_ENABLE | 6 | 1 | LOOP_ENABLE set to 1 means loop predictor is enabled |
| [63:7] | 0 | Reserved |
spfctl
spfctl (Speculative Prefetch Control register) has an address of 0x5C1 and is a read/write register defined in HS mode.
| Field Name | Field Position | Initial Value | Description |
|---|---|---|---|
| L1I_PF_ENABLE | 0 | 1 | Controls L1 instruction prefetcher, set to 1 means prefetching is enabled |
| L2_PF_ENABLE | 1 | 1 | Controls L2 prefetcher, set to 1 means prefetching is enabled |
| L1D_PF_ENABLE | 2 | 1 | Controls SMS prefetcher, set to 1 means prefetching is enabled |
| L1D_PF_TRAIN_ON_HIT | 3 | 0 | Controls whether SMS prefetcher accepts training on hit, set to 1 means training is accepted on hit; set to 0 means training only on miss |
| L1D_PF_ENABLE_AGT | 4 | 1 | Controls the agt table of the SMS prefetcher, set to 1 means agt table is enabled |
| L1D_PF_ENABLE_PHT | 5 | 1 | Controls the pht table of the SMS prefetcher, set to 1 means pht table is enabled |
| L1D_PF_ACTIVE_THRESHOLD | [9:6] | 12 | Controls the active page threshold of the SMS prefetcher |
| L1D_PF_ACTIVE_STRIDE | [15:10] | 30 | Controls the active page stride of the SMS prefetcher |
| L1D_PF_ENABLE_STRIDE | 16 | 1 | Controls whether the SMS prefetcher enables stride |
| L2_PF_STORE_ONLY | 17 | 0 | Controls whether the L2 prefetcher only prefetches for stores |
| L2_PF_RECV_ENABLE | 18 | 1 | Controls whether the L2 prefetcher receives SMS prefetch requests |
| L2_PF_PBOP_ENABLE | 19 | 1 | Controls the enablement of L2 prefetcher PBOP |
| L2_PF_VBOP_ENABLE | 20 | 1 | Controls the enablement of L2 prefetcher VBOP |
| L2_PF_TP_ENABLE | 21 | 1 | Controls the enablement of L2 prefetcher TP |
| [63:22] | 0 | Reserved |
slvpredctl
slvpredctl (Speculative Load Violation Predictor Control register) has an address of 0x5C2 and is a read/write register defined in HS mode.
| Field Name | Field Position | Initial Value | Description |
|---|---|---|---|
| LVPRED_DISABLE | 0 | 0 | Controls whether the memory access violation predictor is disabled, set to 1 means disabled |
| NO_SPEC_LOAD | 1 | 0 | Controls whether the memory access violation predictor prohibits speculative execution of load instructions, set to 1 means prohibited |
| STORESET_WAIT_STORE | 2 | 0 | Controls whether the memory access violation predictor will block store instructions, set to 1 means it will block |
| STORESET_NO_FAST_WAKEUP | 3 | 0 | Controls whether the memory access violation predictor supports fast wakeup, set to 1 means it will not fast wakeup |
| LVPRED_TIMEOUT | [8:4] | 3 | The reset interval of the memory access violation predictor, setting this field to x means the interval is 2^(10+x) |
| [63:9] | 0 | Reserved |
smblockctl
smblockctl (Speculative Memory Block Control register) has an address of 0x5C3 and is a read/write register defined in HS mode.
| Field Name | Field Position | Initial Value | Description |
|---|---|---|---|
| SBUFFER_THRESHOLD | [3:0] | 7 | Controls the flush threshold of sbuffer |
| LDLD_VIO_CHECK_ENABLE | 4 | 1 | Controls whether ld-ld violation check is enabled, set to 1 means enabled |
| SOFT_PREFETCH_ENABLE | 5 | 1 | Controls whether soft prefetch is enabled, set to 1 means enabled |
| CACHE_ERROR_ENABLE | 6 | 1 | Controls whether cache ecc errors are reported, set to 1 means enabled |
| UNCACHE_WRITE_OUTSTANDING_ENABLE | 7 | 0 | Controls whether uncache outstanding access is supported, set to 1 means enabled |
| HD_MISALIGN_ST_ENABLE | 8 | 1 | Controls whether hardware misaligned store is enabled |
| HD_MISALIGN_LD_ENABLE | 9 | 1 | Controls whether hardware misaligned load is enabled |
| [63:10] | 0 | Reserved |
srnctl
srnctl (Speculative Runtime Control register) has an address of 0x5C4 and is a read/write register defined in HS mode.
| Field Name | Field Position | Initial Value | Description |
|---|---|---|---|
| FUSION_ENABLE | 0 | 1 | Is fusion decoder enabled? 1=enabled |
| 1 | 0 | Reserved | |
| WFI_ENABLE | 2 | 1 | Is wfi instruction enabled? 1=enabled |
| [63:3] | 0 | Reserved |
mcorepwr
mcorepwr (Core Power Down Status Enable) has an address of 0xBC0 and is a read/write register defined in M mode.
| Field Name | Field Position | Initial Value | Description |
|---|---|---|---|
| POWER_DOWN_ENABLE | 0 | 0 | 1 indicates that the core desires to enter a low-power mode when in WFI (Wait For Interrupt) state |
| [63:1] | 0 | Reserved |
mflushpwr
mflushpwr (Flush L2 Cache Enable) has an address of 0xBC1 and is a read/write register defined in M mode.
| Field Name | Field Position | Initial Value | Description |
|---|---|---|---|
| FLUSH_L2_ENABLE | 0 | 0 | 1 indicates that the core desires to flush the L2 cache and exit coherence state |
| L2_FLUSH_DONE | 1 | 0 | Read-only bit, 1 indicates L2 cache flush is complete and coherence state is exited |
| [63:2] | 0 | Reserved |
CSR Exception Check
Currently, the permission check module permitMod in CSR is divided into multiple submodules: xRetPermitMod, mLevelPermitMod, sLevelPermitMod, privilegePermitMod, virtualLevelPermitMod, and indirectCSRPermitMod. permitMod generates two types of exceptions: EX_II and EX_VI. Additionally, xRetPermitMod is different from the other submodules; it corresponds to exceptions generated when executing xret instructions, while the other submodules serve CSR access instructions. These two parts are mutually exclusive, meaning it is impossible to simultaneously generate an exception from executing an xret instruction and an exception from executing a CSR access instruction.
Among them, xRetPermitMod generates potential exceptions when executing mnret/mret/sret/dret instructions: EX_II and EX_VI.
mLevelPermitMod only generates EX_II. It performs several types of permission checks: writing to read-only CSRs; accessing floating-point/vector CSRs when fs/vs are not enabled; and a series of accesses to other lower-privilege CSRs controlled by M-mode CSRs (such as mstateen0 and menvcfg).
sLevelPermitMod also only generates EX_II. It performs a series of accesses to other lower-privilege CSRs controlled by HS-mode CSRs (such as sstateen0 and scounteren).
privilegePermitMod ensures that lower privilege modes cannot access higher privilege mode CSRs and generates EX_II and EX_VI exceptions based on the current privilege level and the target CSR's privilege level.
| M-Level CSR | H/VS-Level CSR | S-Level CSR | U-Level CSR | |
|---|---|---|---|---|
| MODE_M | OK | OK | OK | OK |
| MODE_VS | EX_II | EX_VI | OK | OK |
| MODE_VU | EX_II | EX_VI | EX_VI | OK |
| MODE_HS | EX_II | OK | OK | OK |
| MODE_HU | EX_II | EX_II | EX_II | OK |
virtualLevelPermitMod generates EX_II and EX_VI exceptions. It performs a series of accesses to other CSRs controlled by H-mode CSRs (such as hstateen0 and henvcfg).
indirectCSRPermitMod also generates EX_II and EX_VI exceptions. It performs a series of permission checks for accessing Alisa's alias CSRs (mireg, sireg, and vsireg).
Furthermore, for exceptions generated during CSR access, we prioritize the results from mLevelPermitMod, sLevelPermitMod, privilegePermitMod, and virtualLevelPermitMod, i.e., exceptions generated by direct access, and then consider the exception results from indirect access (indirectCSRPermitMod).
Among the exception results generated by direct access, we need to ensure that the result from mLevelPermitMod has the highest priority, followed by sLevelPermitMod, then privilegePermitMod, and finally virtualLevelPermitMod. This restriction also ensures that EX_II takes precedence over EX_VI.
CSR Read-Only Instruction Out-of-Order Execution
We also support out-of-order execution of CSR read-only instructions. We note that for most CSRs, the CSRR instruction does not need to wait for preceding instructions. For all CSRs, the CSRR instruction also does not need to block succeeding instructions. It should be noted that isCsrr includes not only CSRR instructions but also other CSR instructions that do not write to CSRs.
Currently, CSRR instructions executing on the following CSRs are required to wait for preceding instructions and execute in order: fflags, fcsr, vxsat, vcsr, vstart, mstatus, sstatus, hstatus, vsstatus, mnstatus, dcsr. Because these CSRs may be modified by user-level instructions without needing a fence, executing them out of order could lead to incorrect results. Therefore, CSRR instructions on these CSRs are required to execute in order.
Furthermore, since a fence instruction must be executed before reading any PMC CSR, there is no need for instructions on PMC CSRs to execute in order.
CSR instructions were previously executed without pipelining, so the CSR module internally did not require a state machine. With the addition of pipelining acceleration optimization for some CSR read-only instructions, a state machine is now required because the integer register file arbiter must allow write requests to succeed before the CSRR instruction executes.
This finite state machine has three states: Idle (s_idle), Waiting for IMSIC (s_waitIMSIC), and Finish (s_finish).
When the current state is s_idle, if there is valid input and a flush signal, the next state remains s_idle; if there is valid input and asynchronous access to AIA is required, the next state changes to s_waitIMSIC; if there is valid input, the next state changes to s_finish; otherwise, it remains s_idle.
When the current state is s_waitIMSIC, if there is a flush signal, the next state returns to s_idle; if a read valid signal is received from AIA and the output is ready, the next state returns to s_idle, otherwise if the output is not ready, the next state changes to s_finish, waiting for output; otherwise, it remains s_waitIMSIC.
When the current state is s_finish, if there is a flush signal or an output ready signal, the next state will return to s_idle; otherwise, it remains s_finish.