Merge branch 'chipsalliance:main' into change-coverage-report-structure

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.
 

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.

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.

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.
 

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,22 +148,22 @@ 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.
 This allows an external debugger to interact with the Debug Module when the core complex reset signal (rst_l) is still asserted.
 
 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.
 

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.

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)
 
 

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.

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.