diff --git a/docs/source/1-overview.md b/docs/source/1-overview.md
index 8d1edb49185..92c08c2d3dc 100644
--- a/docs/source/1-overview.md
+++ b/docs/source/1-overview.md
@@ -1,4 +1,4 @@
-# 1 Veer El2 Core Overview
+# 1 VeeR EL2 Core Overview
This chapter provides a high-level overview of the VeeR EL2 core and core complex. VeeR EL2 is a machinemode (M-mode) only, 32-bit CPU small core which supports RISC-V's integer (I), compressed instruction \(C\), multiplication and division (M), and instruction-fetch fence, CSR, and subset of bit manipulation instructions (Z) extensions. The core contains a 4-stage, scalar, in-order pipeline.
diff --git a/docs/source/10-core-control.md b/docs/source/10-core-control.md
index 5b3361e6f8e..011733b66c3 100644
--- a/docs/source/10-core-control.md
+++ b/docs/source/10-core-control.md
@@ -12,7 +12,7 @@ A summary of platform-specific control/status registers in CSR space:
All reserved and unused bits in these control/status registers must be hardwired to '0'.
Unless otherwise noted, all read/write control/status registers must have WARL (Write Any value, Read Legal value) behavior.
-### 10.1.1 Feature Disable Control Register (Mfdc)
+### 10.1.1 Feature Disable Control Register (mfdc)
The mfdc register hosts low-level core control bits to disable specific features.
This may be useful in case a feature intended to increase core performance should prove to have problems.
@@ -48,7 +48,7 @@ This register is mapped to the non-standard read/write CSR address space.
:::
-### 10.1.2 Clock Gating Control Register (Mcgc)
+### 10.1.2 Clock Gating Control Register (mcgc)
The mcgc register hosts low-level core control bits to override clock gating for specific units.
This may be useful in case a unit intended to be clock gated should prove to have problems when in lower power mode.
diff --git a/docs/source/11-adaptations.md b/docs/source/11-adaptations.md
index 44ae58f1644..3c101d8af8e 100644
--- a/docs/source/11-adaptations.md
+++ b/docs/source/11-adaptations.md
@@ -1,4 +1,4 @@
-# 11 Standard Risc-V Csrs With Core-Specific Adaptations
+# 11 Standard RISC-V CSRs with Core-Specific Adaptations
A summary of standard RISC-V control/status registers in CSR space with platform-specific adaptations:
@@ -9,7 +9,7 @@ A summary of standard RISC-V control/status registers in CSR space with platform
All reserved and unused bits in these control/status registers must be hardwired to '0'.
Unless otherwise noted, all read/write control/status registers must have WARL (Write Any value, Read Legal value) behavior.
-## 11.1 Machine Interrupt Enable (Mie) And Machine Interrupt Pending (Mip) Registers
+## 11.1 Machine Interrupt Enable (mie) and Machine Interrupt Pending (mip) Registers
The standard RISC-V mie and mip registers hold the machine interrupt enable and interrupt pending bits, respectively.
Since VeeR EL2 only supports machine mode, all supervisor- and user-specific bits are not implemented.
@@ -59,7 +59,7 @@ All M-mode interrupt pending bits of the read/write mip register are read-only.
:::
-## 11.2 Machine Cause Register (Mcause)
+## 11.2 Machine Cause Register (mcause)
The standard RISC-V mcause register indicates the cause for a trap as shown in Table 11-3, including standard exceptions/interrupts, platform-specific local interrupts (with light gray background), and NMI causes (with dark gray background).
@@ -102,7 +102,7 @@ This register is a standard read/write CSR.
All other values are reserved.
:::
-## 11.3 Machine Hardware Thread Id Register (Mhartid)
+## 11.3 Machine Hardware Thread ID Register (mhartid)
The standard RISC-V mhartid register provides the integer ID of the hardware thread running the code.
Hart IDs must be unique.
diff --git a/docs/source/12-csrs.md b/docs/source/12-csrs.md
index 1a27f1d15db..478a7ec75a4 100644
--- a/docs/source/12-csrs.md
+++ b/docs/source/12-csrs.md
@@ -1,6 +1,6 @@
-# 12 Csr Address Map
+# 12 CSR Address Map
-## 12.1 Standard Risc-V Csrs
+## 12.1 Standard RISC-V CSRs
Table 12-1 lists the VeeR EL2 core-specific standard RISC-V Machine Information CSRs.
@@ -55,7 +55,7 @@ Table 12-2 lists the VeeR EL2 standard RISC-V CSR address map.
:::
-## 12.2 Non-Standard Risc-V Csrs
+## 12.2 Non-Standard RISC-V CSRs
Table 12-3 summarizes the VeeR EL2 non-standard RISC-V CSR address map.
diff --git a/docs/source/14-clocks.md b/docs/source/14-clocks.md
index 345815dc1d6..ff1e92df264 100644
--- a/docs/source/14-clocks.md
+++ b/docs/source/14-clocks.md
@@ -37,7 +37,7 @@ Figure 14-1 Conceptual Clock, Clock-Enable, and Data Timing Relationship
Note that the clock net is not explicitly buffered, as the clock tree is expected to be synthesized during place-androute.
The achievable clock frequency depends on the configuration, the sizes and configuration of I-cache and I/DCCMs, and the silicon implementation technology.
-### 14.2.2 System Bus-To-Core Clock Ratios
+### 14.2.2 System Bus-to-Core Clock Ratios
Figure 14-2 to Figure 14-9 depict the timing relationships of clock, clock-enable, and data for the supported system bus clock ratios from 1:1 (i.e. the system bus and core run at the same rate) to 1:8 (i.e. the system bus runs eight times slower than the core).
@@ -126,7 +126,7 @@ Shorter pulses might be dropped by the synchronizer circuit.
The VeeR EL2 core complex provides two reset signals, the core complex reset (see Section 14.3.1) and the Debug Module reset (see Section 14.3.2).
-### 14.3.1 Core Complex Reset (Rst_L)
+### 14.3.1 Core Complex Reset (rst_l)
As shown in Figure 14-10, the core complex reset signal (rst_l) is active-low, may be asynchronously asserted, but must be synchronously deasserted to avoid any glitches.
The rst_l input signal is not synchronized to the core clock (clk) inside the core complex logic.
@@ -148,7 +148,7 @@ From a backend perspective, care should be taken during place-and-route optimiza
The core complex reset signal resets the entire VeeR EL2 core complex, except the Debug Module.
:::
-### 14.3.2 Debug Module Reset (Dbg_Rst_L)
+### 14.3.2 Debug Module Reset (dbg_rst_l)
The Debug Module reset signal (dbg_rst_l) is an active-low signal which resets the VeeR EL2 core complex's Debug Module as well as the synchronizers between the JTAG interface and the core complex.
The Debug Module reset signal may be connected to the power-on reset signal of the SoC.
@@ -156,14 +156,14 @@ This allows an external debugger to interact with the Debug Module when the core
If this layered reset functionality is not required, the dbg_rst_l signal may be tied to the rst_l signal outside the core complex.
-### 14.3.3 Debugger Initiating Reset Via Jtag Interface
+### 14.3.3 Debugger Initiating Reset via JTAG Interface
A debugger may also initiate a reset of the core complex logic via the JTAG interface.
Note that such a reset assertion is not visible to the SoC.
Resetting the core complex while the core is accessing any SoC memory locations may result in unpredictable behavior.
Recovery may require an assertion of the SoC master reset.
-### 14.3.4 Core Complex Reset To Debug Mode
+### 14.3.4 Core Complex Reset to Debug Mode
The RISC-V Debug specification [3] states a requirement that the debugger must be able to be in control from the first executed instruction of a program after a reset.
diff --git a/docs/source/15-complex-ports.md b/docs/source/15-complex-ports.md
index 69e4d8d7a11..c35a20d5542 100644
--- a/docs/source/15-complex-ports.md
+++ b/docs/source/15-complex-ports.md
@@ -1,4 +1,4 @@
-# 15 Veer El2 Core Complex Port List
+# 15 VeeR EL2 Core Complex Port List
Table 15-1 lists the core complex signals.
Not all signals are present in a given instantiation.
diff --git a/docs/source/16-build-args.md b/docs/source/16-build-args.md
index 9ef245d3cdd..5f6b2ea1c13 100644
--- a/docs/source/16-build-args.md
+++ b/docs/source/16-build-args.md
@@ -1,5 +1,5 @@
-# 16 Veer El2 Core Build Arguments
+# 16 VeeR EL2 Core Build Arguments
## 16.1 Memory Protection Build Arguments
### 16.1.1 Memory Protection Build Argument Rules
@@ -26,7 +26,7 @@ The rules for valid memory protection address (INST/DATA_ACCESS_ADDRx) and mask
## 16.2 Core Memory-Related Build Arguments
-### 16.2.1 Core Memories And Memory-Mapped Register Blocks Alignment Rules
+### 16.2.1 Core Memories and Memory-Mapped Register Blocks Alignment Rules
Placement of VeeR EL2's core memories and memory-mapped register blocks in the 32-bit address range is very flexible.
Each memory or register block may be assigned to any region and within the region's 28-bit address range to any start address on a naturally aligned power-of-two address boundary relative to its own size (i.e., *start_address* = *n × size*, whereas n is a positive integer number).
@@ -42,7 +42,7 @@ The start address of the memory or register block is specified with an offset re
This offset must follow the rules described above.
### 16.2.2 Memory-Related Build Arguments
-* **ICCM **
+* **ICCM**
* Enable (RV_ICCM_ENABLE): 0, 1 (0 = no ICCM; 1 = ICCM enabled)
* Region (RV_ICCM_REGION): 0..15
* Offset (RV_ICCM_OFFSET): (offset in bytes from start of region satisfying rules in Section 16.2.1)
@@ -52,10 +52,12 @@ This offset must follow the rules described above.
* Offset (RV_DCCM_OFFSET): *(offset in bytes from start of region satisfying rules in Section 16.2.1)*
* Size (RV_DCCM_SIZE): 4, 8, 16, 32, 48, 64, 128, 256, 512 *(in KB)*
* **I-Cache**
- * Enable (RV_ICACHE_ENABLE): 0, 1 *(0 = no I-cache; 1 = I-cache enabled)* o Size (RV_ICACHE_SIZE): 16, 32, 64, 128, 256 *(in KB)*
+ * Enable (RV_ICACHE_ENABLE): 0, 1 *(0 = no I-cache; 1 = I-cache enabled)*
+ * Size (RV_ICACHE_SIZE): 16, 32, 64, 128, 256 *(in KB)*
* Protection (RV_ICACHE_ECC): 0, 1 *(0 = parity; 1 = ECC)*
* **PIC Memory-mapped Control Registers**
- * Region (RV_PIC_REGION): 0..15 o Offset (RV_PIC_OFFSET): *(offset in bytes from start of region satisfying rules in Section 16.2.1)*
+ * Region (RV_PIC_REGION): 0..15
+ * Offset (RV_PIC_OFFSET): *(offset in bytes from start of region satisfying rules in Section 16.2.1)*
* Size (RV_PIC_SIZE): 32, 64, 128, 256 (in KB)
diff --git a/docs/source/17-tests.md b/docs/source/17-tests.md
index 1d65ed53c7f..894130c8afd 100644
--- a/docs/source/17-tests.md
+++ b/docs/source/17-tests.md
@@ -1,44 +1,44 @@
-# 17 Veer El2 Compliance Test Suite Failures
+# 17 VeeR EL2 Compliance Test Suite Failures
-## 17.1 I-Misalign_Ldst-01
+## 17.1 I-MISALIGN_LDST-01
-* Test Location: [https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32i/src/I-MISALIGN_LDST-01.S](https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32i/src/I-MISALIGN_LDST-01.S)
-* Reason for Failure:
+* **Test Location**: [https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32i/src/I-MISALIGN_LDST-01.S](https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32i/src/I-MISALIGN_LDST-01.S)
+* **Reason for Failure**:
* The VeeR EL2 core supports unaligned accesses to memory addresses which are not marked as having side effects (i.e., to idempotent memory).
Load and store accesses to non-idempotent memory addresses take misalignment exceptions.
* Note that this is a known issue with the test suite ([https://github.com/riscv/riscv-compliance/issues/22](https://github.com/riscv/riscv-compliance/issues/22)) and is expected to eventually be fixed.
-* Workaround:
+* **Workaround**:
* Configure the address range used by this test to "non-idempotent" in the mrac register.
-## 17.2 I-Misalign_Jmp-01 Test Location:
+## 17.2 I-MISALIGN_JMP-01
-* Test location: [https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32i/src/I-MISALIGN_JMP-01.S](https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32i/src/I-MISALIGN_JMP-01.S)
-* Reason for Failure:
+* **Test location**: [https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32i/src/I-MISALIGN_JMP-01.S](https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32i/src/I-MISALIGN_JMP-01.S)
+* **Reason for Failure**:
* The VeeR EL2 core supports the standard "C" 16-bit compressed instruction extension.
Compressed instruction execution cannot be turned off.
Therefore, branch and jump instructions to 16-bit aligned memory addresses do not trigger misalignment exceptions.
* Note that this is a known issue with the test suite ([https://github.com/riscv/riscv-compliance/issues/16](https://github.com/riscv/riscv-compliance/issues/16)) and is expected to eventually be fixed.
-* Workaround:
+* **Workaround**:
* None.
-## 17.3 I-Fence.I-01 And Fence_I Test Location:
+## 17.3 I-FENCE.I-01 and fence_i
-* Test location:
+* **Test location**:
* [https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32Zifencei/src/I-FENCE.I-01.S](https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32Zifencei/src/I-FENCE.I-01.S) and
* [https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32ui/src/fence_i.S](https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32ui/src/fence_i.S)
-* Reason for Failure:
+* **Reason for Failure**:
* The VeeR EL2 core implements separate instruction and data buses to the system interconnect (i.e., Harvard architecture).
The latencies to memory through the system interconnect may be different for the two interfaces and the order is therefore not guaranteed.
-* Workaround:
+* **Workaround**:
* Configuring the address range used by this test to "non-idempotent" in the mrac register forces the core to wait for a write response before fetching the updated line.
Alternatively, the system interconnect could provide ordering guarantees between requests sent to the instruction fetch and load/store bus interfaces (e.g., matching latencies through the interconnect).
## 17.4 Breakpoint
-* Test Location:
+* **Test Location**:
* [https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32mi/src/breakpoint.S](https://github.com/riscv/riscv-compliance/blob/master/riscv-test-suite/rv32mi/src/breakpoint.S)
-* Reason for Failure:
+* **Reason for Failure**:
* The VeeR EL2 core disables breakpoints when the *mie* bit in the standard mstatus register is cleared.
* Note that this behavior is compliant with the RISC-V External Debug Support specification, Version 0.13.2. See Section 5.1, 'Native M-Mode Triggers' in [3] for more details.
-* Workaround:
+* **Workaround**:
* None.
diff --git a/docs/source/18-errata.md b/docs/source/18-errata.md
index 78b1d310060..8ce1306a817 100644
--- a/docs/source/18-errata.md
+++ b/docs/source/18-errata.md
@@ -1,20 +1,20 @@
-# 18 Veer El2 Errata
-## 18.1 Back-To-Back Write Transactions Not Supported On Ahb-Lite Bus Description:
+# 18 VeeR EL2 Errata
+## 18.1 Back-To-Back Write Transactions Not Supported on AHB-Lite Bus
+* **Description**:
The AHB-Lite bus interface for LSU is not optimized for write performance.
Each aligned store is issued to the bus as a single write transaction followed by an idle cycle.
Each unaligned store is issued to the bus as multiple backto-back byte write transactions followed by an idle cycle.
These idle cycles limit the achievable bus utilization for writes.
+* **Symptoms**: Potential performance impact for writes with AHB-Lite bus.
+* **Workaround**: None.
-* Symptoms: Potential performance impact for writes with AHB-Lite bus.
-* Workaround: None.
-
-## 18.2 Debug Abstract Command Register May Return Non-Zero Value On Read Description:
+## 18.2 Debug Abstract Command Register May Return Non-Zero Value On Read
+* **Description**:
The RISC-V External Debug specification specifies the abstract command (command) register as write-only (see Section 3.14.7 in [3]).
However, the VeeR EL2 implementation supports write as well as read operations to this register.
This may help a debugger's feature discovery process, but is not fully compliant with the RISC-V External Debug specification.
Because the expected return value for reading this register is always zero, it is unlikely that a debugger expecting a zero value would attempt to read it.
-
-* Symptoms: Reading the debug abstract command (command) register may return a non-zero value.
-* Workaround: A debugger should avoid reading the abstract command register if it cannot handle non-zero data.
+* **Symptoms**: Reading the debug abstract command (command) register may return a non-zero value.
+* **Workaround**: A debugger should avoid reading the abstract command register if it cannot handle non-zero data.
diff --git a/docs/source/2-memory-map.md b/docs/source/2-memory-map.md
index 618db809741..2eed20e8b21 100644
--- a/docs/source/2-memory-map.md
+++ b/docs/source/2-memory-map.md
@@ -34,13 +34,14 @@ Their respective sizes (4, 8, 16, 32, 48[9], 64, 128, 256, or 512KB) are set as
To provide control for regular operation, the core requires a number of memory-mapped control/status registers.
For example, some external interrupt functions are controlled and serviced with accesses to various registers while the system is running.
-### 2.3.2 Accessed Via System Bus
-
-#### 2.3.2.1 System ROMs The SoC may host ROMs which are mapped to the core's memory address range and accessed via the system bus.
+### 2.3.2 Accessed via System Bus
+#### 2.3.2.1 System ROMs
+The SoC may host ROMs which are mapped to the core's memory address range and accessed via the system bus.
Both instruction and data accesses are supported to system ROMs.
-#### 2.3.2.2 System SRAMs The SoC hosts a variety of SRAMs which are mapped to the core's memory address range and accessed via the system bus.
+#### 2.3.2.2 System SRAMs
+The SoC hosts a variety of SRAMs which are mapped to the core's memory address range and accessed via the system bus.
#### 2.3.2.3 System Memory-Mapped I/O
@@ -82,7 +83,7 @@ Some memory-mapped I/O and control/status registers may have no side effects (i.
Loads and stores to system bus-attached memory (i.e. accesses with no side effects, idempotent) and devices (i.e. accesses with potential side effects, non-idempotent) pass through a unified read/write buffer.
The buffer is implemented as a FIFO.
-### 2.5.1 Load-To-Load And Store-To-Store Ordering
+### 2.5.1 Load-To-Load and Store-To-Store Ordering
All loads are sent to the system bus interface in program order. Also, all stores are sent to the system bus interface in program order.
@@ -203,7 +204,7 @@ A local-to-the-core interrupt for correctable errors has pending (*mceip*) and e
The priority is lower than the RISC-V External interrupt, but higher than the RISC-V Software and Timer interrupts (see Table 13-1).
The correctable error local interrupt has an mcause value of 0x8000_001E (see Table 11-3).
-### 2.7.3 Rules For Core-Local Memory Accesses
+### 2.7.3 Rules for Core-Local Memory Accesses
The rules for instruction fetch and load/store accesses to core-local memories are:
@@ -260,8 +261,9 @@ A mismatch of the predicted and the actual destination (i.e., a core-local or a
14: AMO refers to the RISC-V "A" (atomics) extension, which is not implemented in VeeR EL2.
-### 2.7.6 Misaligned Accesses General notes:
+### 2.7.6 Misaligned Accesses
+General notes:
* The core performs a misalignment check during the address calculation.
* Accesses across region boundaries always cause a misaligned exception.
* Splitting a load/store from/to an address with no side effects (i.e., idempotent) is not of concern for VeeR EL2.
@@ -361,7 +363,7 @@ A summary of platform-specific control/status registers in CSR space:
All reserved and unused bits in these control/status registers must be hardwired to '0'. Unless otherwise noted, all read/write control/status registers must have WARL (Write Any value, Read Legal value) behavior.
-### 2.8.1 Region Access Control Register (Mrac)
+### 2.8.1 Region Access Control Register (mrac)
A single region access control register is sufficient to provide independent control for 16 address regions.
@@ -389,7 +391,7 @@ This register is mapped to the non-standard read/write CSR address space.
|cacheableY|Y*2|Caching control for region Y: 0: Caching not allowed 1: Caching allowed|R/W|0|
:::
-### 2.8.2 Memory Synchronization Trigger Register (Dmst)
+### 2.8.2 Memory Synchronization Trigger Register (dmst)
The dmst register provides triggers to force the synchronization of memory accesses. Specifically, it allows a debugger to initiate operations that are equivalent to the fence.i (see Section 2.5.3.1) and fence (see Section 2.5.3.2) instructions.
@@ -412,7 +414,7 @@ This register is mapped to the non-standard read/write CSR address space.
:::
-### 2.8.3 D-Bus First Error Address Capture Register (Mdseac)
+### 2.8.3 D-Bus First Error Address Capture Register (mdseac)
The address of the first occurrence of a store or non-blocking load error on the D-bus is captured in the mdseac register. Latching the address also locks the register. While the mdseac register is locked, subsequent D-bus errors are gated (i.e., they do not cause another NMI), but NMI requests originating external to the core are still honored.
@@ -442,7 +444,7 @@ This register is mapped to the non-standard read-only CSR address space.
| erraddr | 31:0 | Address of first occurrence of D-bus store or non-blocking load error | R | 0 |
:::
-### 2.8.4 D-Bus Error Address Unlock Register (Mdeau)
+### 2.8.4 D-Bus Error Address Unlock Register (mdeau)
Writing to the mdeau register unlocks the mdseac register (see Section 2.8.3) after a D-bus error address has been captured.
This write access also reenables the signaling of an NMI for a subsequent D-bus error.
@@ -464,7 +466,7 @@ This register is mapped to the non-standard read/write CSR address space.
|erraddr|31:0|Address of first occurrence of D-bus store or non-blocking load error|R|0|
:::
-### 2.8.5 Machine Secondary Cause Register (Mscause)
+### 2.8.5 Machine Secondary Cause Register (mscause)
The mscause register, in conjunction with the standard RISC-V mcause register (see Section 11.2), allows the determination of the exact cause of a trap for cases where multiple, different conditions share a single trap code.
The standard RISC-V mcause register provides the trap code and the mscause register provides supporting information about the trap to disambiguate different sources.
@@ -568,7 +570,7 @@ Table 2-11 summarizes an example of the VeeR EL2 memory address map, including r
|0xF|0xF000_0000|0xFFFF_FFFF||
:::
-## 2.10 Behavior Of Loads To Side-Effect Addresses
+## 2.10 Behavior of Loads to Side-Effect Addresses
Loads with potential side-effects do not stall the pipeline and may be committed before the data is returned from the system bus.
Other loads and stores in the pipeline continue to be executed unless an instruction uses data from a pending side-effect load.
@@ -582,7 +584,7 @@ Rules for partial writes handling are:
* **SoC addresses:** The core indicates the valid bytes for each bus write transaction.
The addressed SoC memory or device performs a read-modify-write operation and updates its ECC.
-## 2.12 Expected Soc Behavior For Accesses
+## 2.12 Expected SoC Behavior for Accesses
The VeeR EL2 core expects that the SoC responds to all system bus access requests it receives from the core.
System bus accesses include instruction fetches, load/store data accesses as well as debug system bus accesses.
@@ -615,7 +617,7 @@ Writing a '1' to the *bpd* bit in the mfdc register (see Table 10-1) disables br
The VeeR EL2 core does not issue any speculative data accesses on the LSU bus interface.
-## 2.14 Dma Slave Port
+## 2.14 DMA Slave Port
The Direct Memory Access (DMA) slave port is used for read/write accesses to core-local memories initiated by external masters.
For example, external masters could be DMA controllers or other CPU cores located in the SoC.
@@ -642,12 +644,12 @@ For example, if *dqc* is 0, a DMA access requests a bubble immediately (i.e., in
For a DMA access to the ICCM, it may take up to 3 additional cycles25 before the access is granted.
Similarly, for a DMA access to the DCCM, it may take up to 4 additional cycles before the access is granted.
-### 2.14.4 Ordering Of Core And Dma Accesses
+### 2.14.4 Ordering Of Core and DMA Accesses
Accesses to the DCCM or ICCM by the core and the DMA slave port are asynchronous events relative to one another.
There are no ordering guarantees between the core and the DMA slave port accessing the same or different addresses.
-## 2.15 Reset Signal And Vector
+## 2.15 Reset Signal and Vector
The core provides a 31-bit wide input bus at its periphery for a reset vector.
The SoC must provide the reset vector on the rst_vec[31:1] bus, which could be hardwired or from a register.
@@ -659,7 +661,7 @@ Note that the applied reset vector must be pointing to the ICCM, if enabled, or
The core's 31 general-purpose registers (x1 - x31) are cleared on reset.
:::
-## 2.16 Non-Maskable Interrupt (Nmi) Signal And Vector
+## 2.16 Non-Maskable Interrupt (NMI) Signal and Vector
The core provides a 31-bit wide input bus at its periphery for a non-maskable interrupt (NMI) vector.
The SoC must provide the NMI vector on the nmi_vec[31:1] bus, either hardwired or sourced from a register.
diff --git a/docs/source/3-error-protection.md b/docs/source/3-error-protection.md
index 5929a6dbb5c..145f21def01 100644
--- a/docs/source/3-error-protection.md
+++ b/docs/source/3-error-protection.md
@@ -10,7 +10,7 @@ For even parity, the data is deemed to be correct if the total count is an even
Similarly, for odd parity if the total count is an odd number. Note that double-bit errors cannot be detected.
-### 3.1.2 Error Correcting Code (Ecc)
+### 3.1.2 Error Correcting Code (ECC)
A robust memory hierarchy design often includes ECC functions to detect and, if possible, correct corrupted data.
@@ -36,7 +36,7 @@ Figure 3-1 Conceptual Block Diagram – ECC in a Memory System
:::
-## 3.2 Selecting The Proper Error Protection Level
+## 3.2 Selecting the Proper Error Protection Level
Choosing a protection level that is too weak might lead to loss of data or silent data corrupted, choosing a level that is too strong incurs additional chip die area (i.e., cost) and power dissipation.
Supporting multiple protection schemes for the same design increases the design and verification effort.
@@ -81,7 +81,7 @@ Table 3-1 summarizes the components of the VeeR EL2 memory hierarchy and their r
protection. Therefore, SEDDED ECC protection is optionally provided in VeeR EL2 as well, selectable as a core build argument.
Note that the I-cache area increases significantly if ECC protection is used.
-## 3.4 Error Detection And Handling
+## 3.4 Error Detection and Handling
Table 3-2 summarizes the detection of errors, the recovery steps taken, and the logging of error events for each of the VeeR EL2 memories.
@@ -143,7 +143,7 @@ A summary of platform-specific core error counter/threshold control/status regis
All read/write control/status registers must have WARL (Write Any value, Read Legal value) behavior.
-### 3.5.1 I-Cache Error Counter/Threshold Register (Micect)
+### 3.5.1 I-Cache Error Counter/Threshold Register (micect)
The micect register holds the I-cache error counter and its threshold.
The *count* field of the micect register is incremented, if a parity/ECC error is detected on any of the cache line tags of the set or the instructions fetched from the I-cache.
@@ -175,7 +175,7 @@ This register is mapped to the non-standard read/write CSR address space.
| count | 26:0 | Counter incremented if I-cache parity/ECC error(s) detected. If count[thresh] transitions from '0' to '1', signal correctable error local interrupt (see Section 2.7.2). | R/W | 0 |
:::
-### 3.5.2 Iccm Correctable Error Counter/Threshold Register (Miccmect)
+### 3.5.2 Iccm Correctable Error Counter/Threshold Register (miccmect)
The miccmect register holds the ICCM correctable error counter and its threshold.
The *count* field of the miccmect register is incremented, if a correctable ECC error is detected on either an instruction fetch or a DMA read from the ICCM.
@@ -213,7 +213,7 @@ This register is mapped to the non-standard read/write CSR address space.
:::
-### 3.5.3 Dccm Correctable Error Counter/Threshold Register (Mdccmect)
+### 3.5.3 Dccm Correctable Error Counter/Threshold Register (mdccmect)
The mdccmect register holds the DCCM correctable error counter and its threshold.
The *count* field of the mdccmect register is incremented, if a correctable ECC error is detected on either a retired load/store instruction or a DMA read access to the DCCM.
diff --git a/docs/source/4-timers.md b/docs/source/4-timers.md
index ad5582a3a46..6f61d546518 100644
--- a/docs/source/4-timers.md
+++ b/docs/source/4-timers.md
@@ -65,7 +65,7 @@ A summary of platform-specific internal timer control/status registers in CSR sp
All reserved and unused bits in these control/status registers must be hardwired to '0'.
Unless otherwise noted, all read/write control/status registers must have WARL (Write Any value, Read Legal value) behavior.
-### 4.4.1 Internal Timer Counter 0 / 1 Register (Mitcnt0/1)
+### 4.4.1 Internal Timer Counter 0 / 1 Register (mitcnt0/1)
The mitcnt0 and mitcnt1 registers are the counters of the internal timer 0 and 1, respectively.
@@ -91,7 +91,7 @@ These registers are mapped to the non-standard read/write CSR address space.
| count | 31:0 | Counter | R/W | 0 |
:::
-### 4.4.2 Internal Timer Bound 0 / 1 Register (Mitb0/1)
+### 4.4.2 Internal Timer Bound 0 / 1 Register (mitb0/1)
The mitb0 and mitb1 registers hold the upper bounds of the internal timer 0 and 1, respectively.
@@ -105,7 +105,7 @@ These registers are mapped to the non-standard read/write CSR address space.
:::
-### 4.4.3 Internal Timer Control 0 / 1 Register (Mitctl0/1)
+### 4.4.3 Internal Timer Control 0 / 1 Register (mitctl0/1)
The mitctl0 and mitctl1 registers provide the control bits of the internal timer 0 and 1, respectively.
diff --git a/docs/source/5-power.md b/docs/source/5-power.md
index 2bce1554993..7124b8cbead 100644
--- a/docs/source/5-power.md
+++ b/docs/source/5-power.md
@@ -1,4 +1,4 @@
-# 5 Power Management And Multi-Core Debug Control
+# 5 Power Management and Multi-Core Debug Control
This chapter specifies the power management and multi-core debug control functionality provided or supported by the VeeR EL2 core. Also documented in this chapter is how debug may interfere with core power management.
@@ -178,7 +178,7 @@ Once the debugger has control of the core, it may read a status register (see Se
This feature is targeted at allowing a debugger to take control of a hung core. Therefore, the timeout period should be set high enough to cover any reasonable delay incurred by any access to SoC memory locations and devices. This should include potential additional delays due to congestion in the interconnect and other possible temporary conditions. If the timeout period is long enough for all outstanding transactions to gracefully finish, program execution may be resumed after debugging has been performed. However, if any outstanding transactions are prematurely forced to terminate, successfully resuming program execution after debug should not be expected because the data of terminated transactions may have been lost and possibly even a reset of the SoC might be necessary to bring the system back into a consistent state.
:::
-### 5.4.2 Core Power And Multi-Core Debug Control And Status Signals
+### 5.4.2 Core Power and Multi-Core Debug Control and Status Signals
Figure 5-2 depicts the power and multi-core debug control and status signals which connect the VeeR EL2 core to the PMU and MPC IPs.
Signals from the PMU and MPC to the core are asynchronous and must be synchronized to the core clock domain.
@@ -194,7 +194,7 @@ The synchronizer of the cpu_run_req signal may not be clock-gated. Otherwise, th
Figure 5-2 VeeR EL2 Power and Multi-Core Debug Control and Status Signals
:::
-#### 5.4.2.1 Power Control And Status Signals
+#### 5.4.2.1 Power Control and Status Signals
There are three types of signals between the Power Management Unit and the VeeR EL2 core, as described in Table 5-3. All signals are active-high.
@@ -221,7 +221,7 @@ Figure 5-3 depicts conceptual timing diagrams of a halt and a run request. Note
Figure 5-3 VeeR EL2 Power Control and Status Interface Timing Diagrams
:::
-#### 5.4.2.2 Multi-Core Debug Control And Status Signals
+#### 5.4.2.2 Multi-Core Debug Control and Status Signals
There are five types of signals between the Multi-Processor Controller and the VeeR EL2 core, as described in Table 5-4. All signals are active-high.
@@ -344,7 +344,7 @@ If desired, these signals can be routed through the PMU and further qualified th
The firmware running on the core may also initiate a halt by writing a '1' to the *halt* field of the mpmc register (see Section 5.5.1).
The core is quiesced before indicating that it has gracefully halted.
-### 5.4.6 Dma Operations While Halted
+### 5.4.6 DMA Operations While Halted
When the core is halted in the 'pmu/fw-halt' or the 'db-halt' state, DMA operations are supported.
@@ -365,7 +365,7 @@ A summary of platform-specific control/status registers in CSR space:
All reserved and unused bits in these control/status registers must be hardwired to '0'.
Unless otherwise noted, all read/write control/status registers must have WARL (Write Any value, Read Legal value) behavior.
-### 5.5.1 Power Management Control Register (Mpmc)
+### 5.5.1 Power Management Control Register (mpmc)
The mpmc register provides core power management control functionality.
It allows the firmware running on the core to initiate a transition to the Halted (pmu/fw-halt) state.
@@ -398,7 +398,7 @@ This register is mapped to the non-standard read/write CSR address space.
| halt | 0 | Initiate core halt (i.e., transition to Halted (pmu/fw-halt) state) Note: Write ignored if in Debug Mode | R0/W1 | 0 |
:::
-### 5.5.2 Core Pause Control Register (Mcpc)
+### 5.5.2 Core Pause Control Register (mcpc)
The mcpc register supports functions to temporarily stop the core from executing instructions.
This helps to save core power since busy-waiting loops can be avoided in the firmware.
@@ -441,7 +441,7 @@ This register is mapped to the non-standard read/write CSR address space.
| pause | 31:0 | Pause execution for number of core clock cycles specified Note: pause is decremented by 1 for each core clock cycle. Execution continues either when pause is 0 or any interrupt is received. | R0/W | 0 |
:::
-### 5.5.3 Forced Debug Halt Threshold Register (Mfdht)
+### 5.5.3 Forced Debug Halt Threshold Register (mfdht)
The mfdht register hosts the enable bit of the forced debug halt mechanism as well as the power-of-two exponent of the timeout threshold.
When enabled, if a debug halt request is received and LSU and/or IFU bus transactions are pending, an internal timeout counter starts incrementing with each core clock and keeps incrementing until the Debug Halt *(db-halt)* state is entered.
@@ -468,7 +468,7 @@ This register is mapped to the non-standard read/write CSR address space.
| enable | 0 | Enable/disable forced debug halt timeout: 0: Timeout mechanism disabled (default) 1: Timeout mechanism enabled | R/W | 0 |
:::
-### 5.5.4 Forced Debug Halt Status Register (Mfdhs)
+### 5.5.4 Forced Debug Halt Status Register (mfdhs)
The mfdhs register provides status information if any LSU and/or IFU bus transactions have been prematurely terminated when the Debug Halt (db-halt) state has been entered.
A debugger may read this register to inquire if any bus transactions have been terminated and data may have been lost while entering the Debug Halt state.
diff --git a/docs/source/6-interrupts.md b/docs/source/6-interrupts.md
index d64570a92d0..9679923defd 100644
--- a/docs/source/6-interrupts.md
+++ b/docs/source/6-interrupts.md
@@ -22,7 +22,9 @@ The PIC provides these core-level external interrupt features:
* Support for interrupt chaining and nested interrupts
* Power reduction feature for disabled external interrupts
-## 6.2 Naming Convention 6.2.1 Unit, Signal, And Register Naming
+## 6.2 Naming Convention
+
+### 6.2.1 Unit, Signal, and Register Naming
**S suffix:** Unit, signal, and register names which have an S suffix indicate an entity specific to an interrupt source.
@@ -36,7 +38,9 @@ The PIC provides these core-level external interrupt features:
**Register in CSR address space:** Register which is mapped to RISC-V's 12-bit CSR address space.
-## 6.3 Overview Of Major Functional Units 6.3.1 External Interrupt Source
+## 6.3 Overview of Major Functional Units
+
+### 6.3.1 External Interrupt Source
All functional units on the chip which generate interrupts to be handled by the RISC-V core are referred to as external interrupt sources.
External interrupt sources indicate an interrupt request by sending an asynchronous signal to the PIC.
@@ -88,7 +92,7 @@ Different levels in the evaluation tree may be staged wherever necessary to meet
The interrupt target is a specific RISC-V hart context. For the VeeR EL2 core, the interrupt target is the M privilege mode of the hart.
-## 6.4 Pic Block Diagram
+## 6.4 PIC Block Diagram
Figure 6-1 depicts a high-level view of the PIC.
A simple gateway for asynchronous, level-triggered interrupt sources is shown in Figure 6-2, whereas Figure 6-3 depicts conceptually the internal functional blocks of a configurable gateway.
@@ -181,7 +185,7 @@ A step-by-step description of interrupt control and delivery:
1. If there are no further interrupts pending, enabled, and with a priority level higher than prithresh field of the meipt and currpri field of the meicurpl registers, mexintirq is deasserted.
21. Firmware may update the content of the meihap and meicidpl registers by writing to the meicpct register to trigger a new capture.
-## 6.6 Support For Vectored External Interrupts
+## 6.6 Support for Vectored External Interrupts
:::{note}
The RISC-V standard defines support for vectored interrupts down to an interrupt class level (i.e., timer, software, and external interrupts for each privilege level), but not to the granularity of individual external interrupt sources (as described in this section).
@@ -387,7 +391,7 @@ For approximately every halving of the number of interrupt sources, it would be
However, the overall reduction in logic is quite small, so it might not be worth the effort.
-## 6.12 Pic Control/Status Registers
+## 6.12 PIC Control/Status Registers
A summary of the PIC control/status registers in CSR address space:
@@ -419,7 +423,7 @@ All memory-mapped control/status register accesses must be word-sized and word-a
Accessing unused addresses within the 32KB PIC address range do not trigger an unmapped address exception. Reads to unmapped addresses return 0, writes to unmapped addresses are silently dropped.
:::
-### 6.12.1 Pic Configuration Register (Mpiccfg)
+### 6.12.1 PIC Configuration Register (mpiccfg)
The PIC configuration register is used to select the operational parameters of the PIC.
@@ -434,7 +438,7 @@ This 32-bit register is an idempotent memory-mapped control register.
:::
-### 6.12.2 External Interrupt Priority Level Registers (Meipls)
+### 6.12.2 External Interrupt Priority Level Registers (meipls)
There are 255 priority level registers, one for each external interrupt source.
Implementing individual priority level registers allows a debugger to autonomously discover how many priority level bits are supported for this interrupt source.
@@ -457,7 +461,7 @@ These 32-bit registers are idempotent memory-mapped control registers.
:::
-### 6.12.3 External Interrupt Pending Registers (Meipx)
+### 6.12.3 External Interrupt Pending Registers (meipx)
Eight external interrupt pending registers are needed to report the current status of up to 255 independent external interrupt sources.
Each bit of these registers corresponds to an interrupt pending indication of a single external interrupt source.
@@ -484,7 +488,7 @@ These 32-bit registers are idempotent memory-mapped status registers.
|Reserved|0|Reserved|R|0|
:::
-### 6.12.4 External Interrupt Enable Registers (Meies)
+### 6.12.4 External Interrupt Enable Registers (meies)
Each of the up to 255 independently controlled external interrupt sources has a dedicated interrupt enable register.
@@ -504,7 +508,7 @@ These 32-bit registers are idempotent memory-mapped control registers.
| inten | 0 | External interrupt enable for interrupt source ID S: 0: Interrupt disabled 1: Interrupt enabled | R/W | 0 |
:::
-### 6.12.5 External Interrupt Priority Threshold Register (Meipt)
+### 6.12.5 External Interrupt Priority Threshold Register (meipt)
The meipt register is used to set the interrupt target's priority threshold.
Interrupt notifications are sent to a target only for external interrupt sources with a priority level strictly higher than this target's threshold.
@@ -525,7 +529,7 @@ This 32-bit register is mapped to the non-standard read/write CSR address space.
| prithresh | 3:0 | External interrupt priority threshold: RISC-V standard compliant priority order: 0: No interrupts masked 1..14: Mask interrupts with priority strictly lower than or equal to this threshold 15: Mask all interrupts Reverse priority order: 15: No interrupts masked 14..1: Mask interrupts with priority strictly lower than or equal to this threshold 0: Mask all interrupts | R/W | 0 |
:::
-### 6.12.6 External Interrupt Vector Table Register (Meivt)
+### 6.12.6 External Interrupt Vector Table Register (meivt)
The meivt register is used to set the base address of the external vectored interrupt address table.
The value written to the *base* field of the meivt register appears in the *base* field of the meihap register.
@@ -540,7 +544,7 @@ This 32-bit register is mapped to the non-standard read-write CSR address space.
| Reserved | 9:0 | Reserved | R | 0 |
:::
-### 6.12.7 External Interrupt Handler Address Pointer Register (Meihap)
+### 6.12.7 External Interrupt Handler Address Pointer Register (meihap)
The meihap register provides a pointer into the vectored external interrupt table for the highest-priority pending external interrupt.
The winning claim ID is captured in the *claimid* field of the meihap register when firmware writes to the meicpct register to claim an external interrupt.
@@ -569,7 +573,7 @@ This 32-bit register is mapped to the non-standard read-only CSR address space.
| 00 | 1:0 | Must read as '00' | R | 0 |
:::
-### 6.12.8 External Interrupt Claim Id / Priority Level Capture Trigger Register (Meicpct)
+### 6.12.8 External Interrupt Claim ID / Priority Level Capture Trigger Register (meicpct)
The meicpct register is used to trigger the simultaneous capture of the currently highest-priority interrupt source ID (in the *claimid* field of the meihap register) and its corresponding priority level (in the *clidpri* field of the meicidpl register) by writing to this register.
Since the PIC core is constantly evaluating the currently highest-priority pending interrupt, this mechanism provides a consistent snapshot of the highest-priority source requesting an interrupt and its associated priority level.
@@ -596,7 +600,7 @@ This 32-bit register is mapped to the non-standard read/write CSR address space.
|Reserved|31:0|Reserved|R0/WA|0|
:::
-### 6.12.9 External Interrupt Claim Id'S Priority Level Register (Meicidpl)
+### 6.12.9 External Interrupt Claim ID's Priority Level Register (meicidpl)
The meicidpl register captures the priority level corresponding to the interrupt source indicated in the *claimid* field of the meihap register when firmware writes to the meicpct register.
Since the PIC core is constantly evaluating the currently highest-priority pending interrupt, this mechanism provides a consistent snapshot of the highest-priority source requesting an interrupt and its associated priority level.
@@ -617,7 +621,7 @@ This 32-bit register is mapped to the non-standard read/write CSR address space.
|clidpri|3:0|Priority level of preempting external interrupt source (corresponding to source ID read from claimid field of meihap register)|R/W|0|
:::
-### 6.12.10 External Interrupt Current Priority Level Register (Meicurpl)
+### 6.12.10 External Interrupt Current Priority Level Register (meicurpl)
The meicurpl register is used to set the interrupt target's priority threshold for nested interrupts.
Interrupt notifications are signaled to the core only for external interrupt sources with a priority level strictly higher than the thresholds indicated in this register and the meipt register.
@@ -691,7 +695,7 @@ These 32-bit registers are idempotent memory-mapped control registers.
:::
-## 6.13 Pic Csr Address Map
+## 6.13 PIC CSR Address Map
Table 6-13 summarizes the PIC non-standard RISC-V CSR address map.
@@ -708,7 +712,7 @@ Table 6-13 summarizes the PIC non-standard RISC-V CSR address map.
:::
-## 6.14 Pic Memory-Mapped Register Address Map
+## 6.14 PIC Memory-Mapped Register Address Map
:::{table} Table 6-14 summarizes the PIC memory-mapped register address map.
diff --git a/docs/source/7-performance.md b/docs/source/7-performance.md
index bfba523e316..070c0d4600b 100644
--- a/docs/source/7-performance.md
+++ b/docs/source/7-performance.md
@@ -14,7 +14,9 @@ VeeR EL2 provides these performance monitoring features:
* Standard retired instructions counter
* Support for standard SoC-based machine timer registers
-## 7.2 Control/Status Registers 7.2.1 Standard Risc-V Registers
+## 7.2 Control/Status Registers
+
+### 7.2.1 Standard RISC-V Registers
A list of performance monitoring-related standard RISC-V CSRs with references to their definitions:
diff --git a/docs/source/8-cache.md b/docs/source/8-cache.md
index 7056927710f..1fad80938e4 100644
--- a/docs/source/8-cache.md
+++ b/docs/source/8-cache.md
@@ -68,7 +68,7 @@ The following steps must be performed to read a 64-bit chunk of instruction data
2. Read the dicago register which causes a read access from the I-cache data array at the location selected by the dicawics register.
3. Read the dicad0 and dicad0h registers to get the selected 64-bit cache line chunk (instr fields), and read the dicad1 register to get the associated parity/ECC bits (parity0/1/2/3 / ecc fields).
-### 8.4.2 Write A Chunk Of An I-Cache Cache Line
+### 8.4.2 Write a Chunk of an I-Cache Cache Line
The following steps must be performed to write a 64-bit chunk of instruction data and its associated 4 parity / 7 ECC bits in an I-cache cache line:
1. Write array/way/address information which location to access in the I-cache to the dicawics register:
@@ -78,7 +78,7 @@ The following steps must be performed to write a 64-bit chunk of instruction dat
2. Write the new instruction data to the *instr* fields of the dicad0 and dicad0h registers, and write the calculated correct instruction parity/ECC bits (unless error injection should be performed) to the *parity0/1/2/3* / *ecc* and fields of the dicad1 register.
3. Write a '1' to the go field of the dicago register which causes a write access to the I-cache data array copying the information stored in the dicad0/0h/1 registers to the location selected by the dicawics register.
-### 8.4.3 Read Or Write A Full I-Cache Cache Line
+### 8.4.3 Read or Write a Full I-Cache Cache Line
The following steps must be performed to read or write instruction data and associated parity/ECC bits of a full Icache cache line:
@@ -97,7 +97,7 @@ The following steps must be performed to read the tag, tag's parity/ECC bit(s),
2. Read the dicago register which causes a read access from the I-cache tag array and status bits at the location selected by the dicawics register.
3. Read the dicad0 register to get the selected cache line's tag (tag field) and valid bit (valid field) as well as the set's LRU bits (lru field), and read the dicad1 register to get the tag's parity/ECC bit(s) (parity0 / ecc field).
-### 8.4.5 Write A Tag And Status Information Of An I-Cache Cache Line
+### 8.4.5 Write a Tag and Status Information of an I-Cache Cache Line
The following steps must be performed to write the tag, tag's parity/ECC bit, and status information of an I-cache cache line:
@@ -120,7 +120,7 @@ A summary of the I-cache control/status registers in CSR address space:
All reserved and unused bits in these control/status registers must be hardwired to '0'.
Unless otherwise noted, all read/write control/status registers must have WARL (Write Any value, Read Legal value) behavior.
-### 8.5.1 I-Cache Array/Way/Index Selection Register (Dicawics)
+### 8.5.1 I-Cache Array/Way/Index Selection Register (dicawics)
The dicawics register is used to select a specific location in either the data array or the tag array / status of the Icache.
In addition to selecting the array, the location in the array must be specified by providing the way, and index.
@@ -155,7 +155,7 @@ This register is mapped to the non-standard read-write CSR address space.
Each way is subdivided into 2 banks, and each bank is 8 bytes wide.
A bank is selected by index[3], and index[2:0] address a byte of the 8-byte wide bank.
-### 8.5.2 I-Cache Array Data 0 Register (Dicad0)
+### 8.5.2 I-Cache Array Data 0 Register (dicad0)
The dicad0 register, in combination with the dicad0h/1 registers (see Sections 8.5.3 and 8.5.4), is used to store information read from or to be written to the I-cache array location specified with the dicawics register (see Section 8.5.1).
Triggering a read or write access of the I-cache array is controlled by the dicago register (see Section 8.5.5).
@@ -189,7 +189,7 @@ This register is mapped to the non-standard read-write CSR address space.
:::
-### 8.5.3 I-Cache Array Data 0 High Register (Dicad0H)
+### 8.5.3 I-Cache Array Data 0 High Register (dicad0h)
The dicad0h register, in combination with the dicad0 and dicad1 registers (see Sections 8.5.2 and 8.5.4), is used to store information read from or to be written to the I-cache array location specified with the dicawics register (see Section 8.5.1).
Triggering a read or write access of the I-cache array is controlled by the dicago register (see Section 8.5.5).
@@ -214,7 +214,7 @@ This register is mapped to the non-standard read-write CSR address space.
| instr | 31:0 | Instruction data 31:16: instruction data bytes 7/6 (protected by parity3 / ecc) 15:0: instruction data bytes 5/4 (protected by parity2 / ecc) | R/W | 0 |
:::
-### 8.5.4 I-Cache Array Data 1 Register (Dicad1)
+### 8.5.4 I-Cache Array Data 1 Register (dicad1)
The dicad1 register, in combination with the dicad0/0h registers (see Section 8.5.2 and 8.5.3), is used to store information read from or to be written to the I-cache array location specified with the dicawics register (see Section 8.5.1).
Triggering a read or write access of the I-cache array is controlled by the dicago register (see Section 8.5.5).
@@ -257,7 +257,7 @@ This register is mapped to the non-standard read-write CSR address space.
:::
-### 8.5.5 I-Cache Array Go Register (Dicago)
+### 8.5.5 I-Cache Array Go Register (dicago)
The dicago register is used to trigger a read from or write to the I-cache array location specified with the dicawics register (see Section 8.5.1).
Reading the dicago register populates the dicad0/dicad0h/dicad1 registers (see Sections 8.5.2, 8.5.3, and 8.5.4) with the information read from the I-cache array.
diff --git a/docs/source/9-debugging.md b/docs/source/9-debugging.md
index 90f1415a70b..a35d45961b8 100644
--- a/docs/source/9-debugging.md
+++ b/docs/source/9-debugging.md
@@ -1,4 +1,4 @@
-# 9 Veer El2 Debug Support
+# 9 VeeR EL2 Debug Support
The VeeR EL2 core conforms to the "RISC-V Debug Specification 0.13.2, with JTAG DTM" document [3].
This chapter provides a description of the implemented debug-related control and status register definitions.
@@ -12,7 +12,7 @@ The registers associated with these three address spaces are described in the fo
* Control/Status Registers in Debug Module Interface Address Space (see Section 9.1.2)
* Control/Status Registers in RISC-V CSR Address Space (see Section 9.1.3)
-### 9.1.1 Control/Status Registers In Jtag Address Space
+### 9.1.1 Control/Status Registers in JTAG Address Space
Table 9-1 summarizes the control/status registers in the JTAG Debug Transport Module address space.
@@ -33,7 +33,7 @@ The core complex clock (clk) frequency must be at least twice the JTAG clock (jt
| 0x1F | BYPASS | JTAG BYPASS | 9.1.1.4 |
:::
-#### 9.1.1.1 Idcode Register (Idcode)
+#### 9.1.1.1 IDCODE Register (IDCODE)
The IDCODE register is a standard JTAG register.
It is selected in the JTAG TAP controller's IR register when the TAP state machine is reset.
@@ -53,7 +53,7 @@ This register is mapped to the 5-bit JTAG address space.
| 1 | 0 | Must be '1' | R | 1 |
:::
-#### 9.1.1.2 Dtm Control And Status Register (Dtmcs)
+#### 9.1.1.2 DTM Control and Status Register (dtmcs)
The dtmcs register controls and provides status of the Debug Transport Module (DTM).
@@ -73,7 +73,7 @@ This register is mapped to the 5-bit JTAG address space.
|version|3:0|Conforming to RISC-V Debug specification Version 0.13.2|R|1|
:::
-#### 9.1.1.3 Debug Module Interface Access Register (Dmi)
+#### 9.1.1.3 Debug Module Interface Access Register (dmi)
The dmi register allows access to the Debug Module Interface (DMI).
In the JTAG TAP controller's Update-DR state, the DTM starts the operation specified in the op field.
@@ -94,7 +94,7 @@ This register is mapped to the 5-bit JTAG address space.
|op|1:0|For write:
0: Ignore data and address (nop)
1: Read from address (read)
2: Write data to address (write)
3: Not implemented (do not use)
For read:
0: Previous operation completed successfully
1..3: Not implemented (DMI accesses always succeed)|R/W|0|
:::
-#### 9.1.1.4 Bypass Register (Bypass)
+#### 9.1.1.4 BYPASS Register (BYPASS)
The BYPASS register is a standard JTAG register.
It is implemented as a 1-bit register which has no functional effect, except adding a 1-bit delay.
@@ -114,7 +114,7 @@ This register is mapped to the 5-bit JTAG address space.
:::
-### 9.1.2 Control/Status Registers In Debug Module Interface Address Space
+### 9.1.2 Control/Status Registers in Debug Module Interface Address Space
Table 9-6 Summarizes The Control/Status Registers In The Debug Module Interface Address Space.
@@ -146,7 +146,7 @@ Addresses shown below are offsets relative to the Debug Module base address. Vee
ICCM, DCCM, and PIC memory ranges are only accessible using the access memory abstract command.
:::
-### 9.1.2.1 Debug Module Control Register (Dmcontrol)
+### 9.1.2.1 Debug Module Control Register (dmcontrol)
The dmcontrol register controls the overall Debug Module as well as the hart.
@@ -175,7 +175,7 @@ This register is mapped to the Debug Module Interface address space.
|dmactive|0|Reset signal for Debug Module (DM): 0:
Module's state takes its reset values
Note: Only dmactive bit may be written to value other than its reset value. Writes to all other bits of this register are ignored.
1: Module functions normally
Debugger may pulse this bit low to get Debug Module into known state.
Note: The core complex’s dbg_rst_l signal (see Table 15-1) resets the Debug Module. It should only be used to reset the Debug Module at power up or possibly with a global reset signal which resets the entire platform.|R/W|0|
:::
-#### 9.1.2.2 Debug Module Status Register (Dmstatus)
+#### 9.1.2.2 Debug Module Status Register (dmstatus)
The dmstatus register reports status for the overall Debug Module as well as the hart.
@@ -209,7 +209,7 @@ This register is mapped to the Debug Module Interface address space.
| version | 3:0 | Debug Module present, conforming to RISC-V Debug specification Version 0.13.2 | R | 2 |
:::
-#### 9.1.2.3 Halt Summary 0 Register (Haltsum0)
+#### 9.1.2.3 Halt Summary 0 Register (haltsum0)
Each bit in the haltsum0 register indicates whether a specific hart is halted or not.
Since VeeR EL2 is singlethreaded, only one bit is implemented.
@@ -230,7 +230,7 @@ This register is mapped to the Debug Module Interface address space.
| halted | 0 | '1' when hart halted | R | 0 |
:::
-#### 9.1.2.4 Abstract Control And Status Register (Abstractcs)
+#### 9.1.2.4 Abstract Control and Status Register (abstractcs)
The abstractcs register provides status information of the abstract command interface and enables clearing of detected command errors.
@@ -254,7 +254,7 @@ This register is mapped to the Debug Module Interface address space.
|datacount|3:0|2 data registers implemented as part of abstract command interface|R|2|
:::
-### 9.1.2.5 Abstract Command Register (Command)
+### 9.1.2.5 Abstract Command Register (command)
Writes to the command register cause the corresponding abstract command to be executed.
@@ -302,7 +302,7 @@ This register is mapped to the Debug Module Interface address space.
41 The RISC-V Debug specification [3] states that an implementation must fail accesses that it does not support.
However, the Debug Task Group community agreed in an email exchange on the group’s reflector as well as in a group meeting that not reporting an error is acceptable for implementations without address translation (i.e., the physical address equals the virtual address).
-#### 9.1.2.6 Abstract Command Autoexec Register (Abstractauto)
+#### 9.1.2.6 Abstract Command Autoexec Register (abstractauto)
The abstractauto register controls if reading or writing the data0/1 registers (see Section 9.1.2.7) automatically triggers the next execution of the abstract command in the command register (see Section 9.1.2.5).
This feature allows more efficient burst accesses.
@@ -320,7 +320,7 @@ This register is mapped to the Debug Module Interface address space.
|autoexecdata0|0|Auto-execution control for data0 register: 0: No automatic triggering of abstract command execution 1: Reading or writing data0 causes abstract command to be executed again|R/W|0| | | |
:::
-### 9.1.2.7 Abstract Data 0 / 1 Registers (Data0/1)
+### 9.1.2.7 Abstract Data 0 / 1 Registers (data0/1)
The data0/1 registers are basic read/write registers which may be read or changed by abstract commands.
@@ -352,7 +352,7 @@ These registers are mapped to the Debug Module Interface address space.
| data | 31:0 | Abstract command data: data0: data value (access register and access memory command) data1: address (access memory command) | R/W | 0 |
:::
-#### 9.1.2.8 System Bus Access Control And Status Register (Sbcs)
+#### 9.1.2.8 System Bus Access Control and Status Register (sbcs)
The sbcs register provides controls and status information of the system bus access interface.
@@ -388,7 +388,7 @@ This register is mapped to the Debug Module Interface address space.
:::
-#### 9.1.2.9 System Bus Address 31:0 Register (Sbaddress0)
+#### 9.1.2.9 System Bus Address 31:0 Register (sbaddress0)
The sbaddress0 register provides the address of the system bus access.
@@ -412,7 +412,7 @@ This register is mapped to the Debug Module Interface address space.
:::
-#### 9.1.2.10 System Bus Data 31:0 Register (Sbdata0)
+#### 9.1.2.10 System Bus Data 31:0 Register (sbdata0)
The sbdata0 register holds the right-justified lower bits for system bus read and write accesses.
@@ -446,7 +446,7 @@ This register is mapped to the Debug Module Interface address space.
|data|31:0|System bus data[31:0] for system bus read and write accesses|R/W|0|
:::
-#### 9.1.2.11 System Bus Data 63:32 Register (Sbdata1)
+#### 9.1.2.11 System Bus Data 63:32 Register (sbdata1)
The sbdata1 register holds the upper 32 bits of the 64-bit wide system bus for read and write accesses.
@@ -463,7 +463,9 @@ This register is mapped to the Debug Module Interface address space.
|data|31:0|System bus data[63:32] for system bus read and write accesses|R/W|0|
:::
-### 9.1.3 Control/Status Registers in RISC-V CSR Address Space A summary of standard RISC-V control/status registers with platform-specific adaptations in CSR space:
+### 9.1.3 Control/Status Registers in RISC-V CSR Address Space
+
+A summary of standard RISC-V control/status registers with platform-specific adaptations in CSR space:
* Trigger Select Register (tselect) (see Section 9.1.3.1)
* Trigger Data 1 Register (tdata1) (see Section 9.1.3.2)
@@ -491,7 +493,7 @@ This register is mapped to the standard read/write CSR address space.
| index | 1:0 | Index of trigger 0..3 Note: Triggers 0 and 2 may be chained, triggers 1 and 3 not. | R/W | 0 |
:::
-#### 9.1.3.2 Trigger Data 1 Register (Tdata1)
+#### 9.1.3.2 Trigger Data 1 Register (tdata1)
This register is mapped to the standard read/write CSR address space.
@@ -503,7 +505,7 @@ This register is mapped to the standard read/write CSR address space.
| dmode | 27 | See Table 9-20, "Match Control Register (mcontrol, at CSR 0x7A1)" below. | See Table 9-20, "Match Control Register (mcontrol, at CSR 0x7A1)" below. | See Table 9-20, "Match Control Register (mcontrol, at CSR 0x7A1)" below. |
:::
-#### 9.1.3.3 Match Control Register (Mcontrol)
+#### 9.1.3.3 Match Control Register (mcontrol)
:::{note}
VeeR EL2 does not support triggering on the data of a load or on the opcode of an executed instruction.
@@ -540,7 +542,7 @@ This register is mapped to the standard read/write CSR address space.
43 Bit 0 of tdata2 register is ignored for instruction address matches.
-#### 9.1.3.4 Trigger Data 2 Register (Tdata2)
+#### 9.1.3.4 Trigger Data 2 Register (tdata2)
This register is mapped to the standard read/write CSR address space.
@@ -551,7 +553,7 @@ This register is mapped to the standard read/write CSR address space.
| value | 31:0 | Match value:
- Address or data value for match:
- Address of load, store, or executed instruction43
- Data value of store
- Match mask (see match field of mcontrol register (Table 9-20) set to '1') | R/W | 0 |
:::
-#### 9.1.3.5 Debug Control And Status Register (Dcsr)
+#### 9.1.3.5 Debug Control and Status Register (dcsr)
The dcsr register controls the behavior and provides status of the hart in Debug Mode.
@@ -586,7 +588,7 @@ This register is mapped to the standard read/write CSR address space.
| prv | 1:0 | Indicates privilege level hart was operating in when Debug Mode was entered (3 = M-mode) | R | 3 |
:::
-#### 9.1.3.6 Debug Pc Register (Dpc)
+#### 9.1.3.6 Debug PC Register (dpc)
The dpc register provides the debugger information about the program counter (PC) when entering Debug Mode and control where to resume (RISC-V Debug specification [3], Section 4.8.2).