Doc ds fixes (#1178)

docs/datasheet/cpu.adoc

@@ -41,7 +41,7 @@ instruction exception (see section <<_full_virtualization>>).
 .`time[h]` CSRs (Wall Clock Time)
 [IMPORTANT]
 The NEORV32 does not implement the `time[h]` registers. Any access to these registers will trap. It is
-recommended that the trap handler software provides a means of accessing the the machine timer of the
+recommended that the trap handler software provides a means of accessing the machine timer of the
 <<_core_local_interruptor_clint>>.
 
 .No Hardware Support of Misaligned Memory Accesses
@@ -606,7 +606,7 @@ The "compressed" ISA extension provides 16-bit encodings of commonly used instru
 ==== `E` ISA Extension
 
 The "embedded" ISA extensions reduces the size of the general purpose register file from 32 entries to 16 entries to
-shrink hardware size. It provides the same instructions as the the base `I` ISA extensions.
+shrink hardware size. It provides the same instructions as the base `I` ISA extensions.
 
 .Alternative MABI
 [NOTE]
@@ -1199,7 +1199,7 @@ available at https://github.com/riscv-non-isa/riscv-trace-spec):
 * **trap**: the transfer of control to a trap handler caused by either an _exception_ or an _interrupt_
 
 Whenever an exception or interrupt is triggered, the CPU switches to machine-mode (if not already in machine-mode)
-and continues operation at the address being stored in the <<_mtvec>> CSR. The cause of the the trap can be determined via the
+and continues operation at the address being stored in the <<_mtvec>> CSR. The cause of the trap can be determined via the
 <<_mcause>> CSR. A list of all implemented `mcause` values and the according description can be found below in section
 <<_neorv32_trap_listing>>. The address that reflects the current program counter when a trap was taken is stored to
 <<_mepc>> CSR. Additional information regarding the cause of the trap can be retrieved from the <<_mtval>> and <<_mtinst>> CSRs.

docs/datasheet/cpu_csr.adoc

@@ -307,7 +307,7 @@ As software does not need to determine the interrupt cause the reduction in late
 |=======================
 
 .`mcounteren` CSR bits
-[cols="^1,^1,<8"]
+[cols="^1,^3,^1,<8"]
 [options="header",grid="rows"]
 |=======================
 | Bit | Name [C] | R/W | Function
@@ -587,7 +587,7 @@ implementation of the according modes.
 |=======================
 
 .`pmpaddr*` CSR Bits
-[cols="^1,^2,^1,<11"]
+[cols="^1,^1,<11"]
 [options="header",grid="rows"]
 |=======================
 | Bit   | R/W | Description
@@ -681,7 +681,7 @@ These registers are read/write only for machine-mode software
 
 .Instruction Retiring
 [IMPORTANT]
-Note that **all** executed instruction do increment the `[m]instret`[h] counters even if they do not retire
+Note that **all** executed instruction do increment the `[m]instret[h]` counters even if they do not retire
 (e.g. if the instruction causes an exception).
 
 

docs/datasheet/cpu_dual_core.adoc

@@ -83,7 +83,7 @@ The ICC communication links are accessed via two NEORV32-specific CSRs. Hence, t
 by the CPU core itself and cannot be accessed by the DMA or any other CPU core.
 
 The <<_mxiccsreg>> provides read-only status information about the core's ICC links: bit 0 becomes set if
-there is RX data available for _this_ core (send from the the other core). Bit 1 is set as long there is
+there is RX data available for _this_ core (send from the other core). Bit 1 is set as long there is
 free space in _this_ core's TX data FIFO. The <<_mxiccdata>> CSR is used for actual data send/receive operations.
 Writing this register will put the according data word into the TX link FIFO of _this_ core. Reading this CSR
 will return a data word from the RX FIFO of _this_ core.

docs/datasheet/soc.adoc

@@ -296,7 +296,7 @@ The generic type "`suv(x:y)`" is an abbreviation for "`std_ulogic_vector(x downt
 | `IO_CFS_IN_SIZE`        | natural   | 32            | Size of the <<_custom_functions_subsystem_cfs>> input signal conduit (`cfs_in_i`).
 | `IO_CFS_OUT_SIZE`       | natural   | 32            | Size of the <<_custom_functions_subsystem_cfs>> output signal conduit (`cfs_out_o`).
 | `IO_NEOLED_EN`          | boolean   | false         | Implement the <<_smart_led_interface_neoled>>.
-| `IO_NEOLED_TX_FIFO`     | natural   | 1             | TX FIFO depth of the the <<_smart_led_interface_neoled>>. Has to be a power of two, min 1, max 32768.
+| `IO_NEOLED_TX_FIFO`     | natural   | 1             | TX FIFO depth of the <<_smart_led_interface_neoled>>. Has to be a power of two, min 1, max 32768.
 | `IO_GPTMR_EN`           | boolean   | false         | Implement the <<_general_purpose_timer_gptmr>>.
 | `IO_ONEWIRE_EN`         | boolean   | false         | Implement the <<_one_wire_serial_interface_controller_onewire>>.
 | `IO_ONEWIRE_FIFO`       | natural   | 1             | Depth of the <<_one_wire_serial_interface_controller_onewire>> FIFO. Has to be a power of two, min 1, max 32768.

docs/datasheet/soc_neoled.adoc

@@ -141,7 +141,7 @@ The data transfer size (`NEOLED_MODE_EN`) can be modified at any time since this
 in the FIFO. This allows an arbitrary mix of RGB and RGBW LEDs in the chain.
 
 Software can check the FIFO fill level via the control register's `NEOLED_CTRL_TX_EMPTY`, `NEOLED_CTRL_TX_HALF`
-and `NEOLED_CTRL_TX_FULL` flags. The `NEOLED_CTRL_TX_BUSY` flags provides additional information if the the serial
+and `NEOLED_CTRL_TX_FULL` flags. The `NEOLED_CTRL_TX_BUSY` flags provides additional information if the serial
 transmit engine is still busy sending data.
 
 [WARNING]

docs/datasheet/soc_slink.adoc

@@ -53,7 +53,7 @@ The SLINK interface consists of four signals for each channel:
 [NOTE]
 The interface names (except for `src` and `dst`) and the underlying protocol is compatible to the AXI4-Stream protocol standard.
 A processor top entity with a AXI4-Stream-compatible interfaces can be found in `rtl/system_inegration`.
-More information regarding this alternate top entity can be found in in the user guide:
+More information regarding this alternate top entity can be found in the user guide:
 https://stnolting.github.io/neorv32/ug/#_packaging_the_processor_as_vivado_ip_block
 
 

docs/datasheet/soc_xbus.adoc

@@ -44,14 +44,14 @@ see section <<_address_space>>) are **redirected** to the external bus interface
 .AXI4-Lite Interface Bridge
 [TIP]
 A simple bridge that converts the processor's XBUS into an AXI4-lite-compatible host interface can
-be found in in `rtl/system_inegration` (`xbus2axi4lite_bridge.vhd`). Note that the AXI specifications
+be found in `rtl/system_inegration` (`xbus2axi4lite_bridge.vhd`). Note that the AXI specifications
 do not allow any bus timeouts. Hence, `XBUS_TIMEOUT` should be set to zero (disabling the bus timeout)
 when using the XBUS-AXI bridge.
 
 .AHB3-Lite Interface Bridge
 [TIP]
 A simple bridge that converts the processor's XBUS into an AHB3-lite-compatible host interface can
-be found in in `rtl/system_inegration` (`xbus2ahblite_bridge.vhd`). Note that the AHB specifications
+be found in `rtl/system_inegration` (`xbus2ahblite_bridge.vhd`). Note that the AHB specifications
 do not allow any bus timeouts. Hence, `XBUS_TIMEOUT` should be set to zero (disabling the bus timeout)
 when using the XBUS-AHB bridge.
 
@@ -107,7 +107,7 @@ being initiated.
 **Access Tag**
 
 The XBUS tag signal `xbus_tag_o(0)` provides additional information about the current access cycle.
-It compatible to the the AXI4 `ARPROT` and `AWPROT` signals.
+It compatible to the AXI4 `ARPROT` and `AWPROT` signals.
 
 * `xbus_tag_o(0)` **P**: access is performed from **privileged** mode (machine-mode) when set
 * `xbus_tag_o(1)` **NS**: this bit is hardwired to `0` indicating a **secure** access