Doc: Fix typos

doc/instruction_fetch.rst

@@ -8,7 +8,7 @@ For optimal performance and timing closure reasons, a prefetcher is used which f
 
 The following table describes the signals that are used to fetch instructions.
 This interface is a simplified version of the interface used on the data interface as described in :ref:`load-store-unit`.
-The main difference is that the instruction interface does not allow for writes transcations and thus needs less signals.
+The main difference is that the instruction interface does not allow for write transactions and thus needs less signals.
 
 .. tabularcolumns:: |p{4cm}|l|p{9cm}|
 

doc/integration.rst

@@ -97,7 +97,7 @@ Interfaces
 +-------------------------+-------------------------+-----+                                        +
 | ``cluster_id_i``        | 6                       | in  |                                        |
 +-------------------------+-------------------------+-----+----------------------------------------+
-| ``boot_adr_i``          | 32                      | in  | First program counter after reset      |
+| ``boot_addr_i``         | 32                      | in  | First program counter after reset      |
 +-------------------------+-------------------------+-----+----------------------------------------+
 | ``instr_*``             | Instruction fetch interface, see :ref:`instruction-fetch`              |
 +-------------------------+------------------------------------------------------------------------+

doc/interrupts.rst

@@ -13,9 +13,9 @@ Communication with this event/interrupt controller is established through the fo
 +-------------------------+-----------+-----------------------------------------------+
 | ``irq_id_i[4:0]``       | in        | Interrupt ID                                  |
 +-------------------------+-----------+-----------------------------------------------+
-| ``irq_ack_o``           | out       | Interrupt acknowledgement                     |
+| ``irq_ack_o``           | out       | Interrupt acknowledgment                      |
 +-------------------------+-----------+-----------------------------------------------+
-| ``irq_id_o[4:0]``       | out       | Interrupt acknowledgement ID                  |
+| ``irq_id_o[4:0]``       | out       | Interrupt acknowledgment ID                   |
 +-------------------------+-----------+-----------------------------------------------+
 
 When external interrupts are enabled, the core will serve interrupt requests.
@@ -50,7 +50,7 @@ An example cycle is shown in :numref:`irq-processing-prio`.
 
 .. wavedrom::
    :name: irq-processing-prio
-   :caption: Interrupt processing with priorization. The processing of ``ID0`` has already started.
+   :caption: Interrupt processing with prioritization. The processing of ``ID0`` has already started.
 
    { "signal": [
      { "name": "clk_i",     "wave": "p...", "period": 2 },

doc/introduction.rst

@@ -56,7 +56,7 @@ History
 
 Ibex development started in 2015 under the name "Zero-riscy" as part of the `PULP platform <https://pulp-platform.org>`_ for energy-efficient computing.
 Much of the code was developed by simplifying the RV32 CPU core "RI5CY" to demonstrate how small a RISC-V CPU core could actually be `[1] <https://doi.org/10.1109/PATMOS.2017.8106976>`_.
-To make it even smaller, support for the "E" exension was added under the code name "Micro-riscy".
+To make it even smaller, support for the "E" extension was added under the code name "Micro-riscy".
 In the PULP ecosystem, the core is used as the control core for PULP, PULPino and PULPissimo.
 
 In December 2018 lowRISC took over the development of Zero-riscy and renamed it to Ibex.

doc/load_store_unit.rst

@@ -59,7 +59,7 @@ The protocol that is used by the LSU to communicate with a memory works as follo
 
 2. After receiving a grant, the address may be changed in the next cycle by the LSU. In addition, the ``data_wdata_o``, ``data_we_o`` and ``data_be_o`` signals may be changed as it is assumed that the memory has already processed and stored that information.
 
-3. The memory answers with a ``data_rvalid_i`` set high for exactly one cycle to signal the response from the bus or the memory using ``data_err_i`` and ``data_rdata_i`` (during the very same cycle). This may happen one or more cycles after the grant has been received. If ``data_err_i`` is low, the request could successfully be handled at the destination and in the case of a load, ``data_rdata_i`` contains valid data. If ``data_err_i`` is high, an error occured in the memory system and the core will raise an exception.
+3. The memory answers with a ``data_rvalid_i`` set high for exactly one cycle to signal the response from the bus or the memory using ``data_err_i`` and ``data_rdata_i`` (during the very same cycle). This may happen one or more cycles after the grant has been received. If ``data_err_i`` is low, the request could successfully be handled at the destination and in the case of a load, ``data_rdata_i`` contains valid data. If ``data_err_i`` is high, an error occurred in the memory system and the core will raise an exception.
 
 :numref:`timing1`, :numref:`timing2` and :numref:`timing3` show example-timing diagrams of the protocol.