github-mirrors/ibex
1
0
Fork 0
mirror of https://github.com/lowRISC/ibex.git synced 2025-06-27 17:00:41 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

[doc] Fix typos

Browse source
This commit is contained in:
Elliot Baptist 2025-06-26 11:55:55 +01:00 • committed by Elliot Baptist
parent f0d408a546
commit 41c2fd8d90
7 changed files with 12 additions and 11 deletions
Download patch file Download diff file Expand all files Collapse all files

6
doc/02_user/integration.rst
View file

@ -34,7 +34,7 @@ Primitives
----------
Ibex uses a number of primitive modules (that are held outside the :file:`rtl/` which contains the Ibex RTL).
Full implementations of these primitives are provided in the Ibex repository but implementors may wish to provide their own implementations.
Full implementations of these primitives are provided in the Ibex repository but implementers may wish to provide their own implementations.
Some of the primitives are only used for specific Ibex configurations so can be ignored/removed if you're not using one of those configurations.
The mandatory primitives (used by all configurations) are:
@ -55,7 +55,7 @@ The configuration dependent primitives are:
Required where ``SecureIbex == 1``.
* ``prim_onehot_check`` - Checks a onehot signal is correct, for detecting fault injection attacks.
Required where ``SecureIbex == 1``.
* ``prim_secded_X`` - Various primitives to encode and decode SECDED (single error correct, double error detect) error detection and correction codes.
* ``prim_secded_X`` - Various primitives to encode and decode SECDED (Single Error Correct, Double Error Detect) error detection and correction codes.
Required where ``SecureIbex == 1``.
Primitives exclusively used by other primitives:
@ -207,7 +207,7 @@ Parameters
+------------------------------+---------------------+------------+-----------------------------------------------------------------------+
| ``ICache`` | bit | 0 | Enable instruction cache instead of prefetch buffer |
+------------------------------+---------------------+------------+-----------------------------------------------------------------------+
| ``ICacheECC`` | bit | 0 | Enable SECDED ECC protection in ICache (if ICache == 1) |
| ``ICacheECC`` | bit | 0 | Enable SECDED ECC protection in ICache (if ICache == 1) |
+------------------------------+---------------------+------------+-----------------------------------------------------------------------+
| ``ICacheScramble`` | bit | 0 | Enabling this parameter replaces tag and data RAMs of ICache with |
| | | | scrambling RAM primitives. |

2
doc/03_reference/exception_interrupts.rst
View file

@ -11,7 +11,7 @@ Interrupts are handled in vectored mode, i.e., the core jumps to the base addres
Upon executing an MRET instruction, the core jumps to the program counter previously saved in the ``mepc`` CSR and restores ``mstatus``.MPIE to ``mstatus``.MIE.
The base address of the vector table is initialized to the boot address (must be aligned to 256 bytes, i.e., its least significant byte must be 0x00) when the core is booting.
The base address can be changed after bootup by writing to the ``mtvec`` CSR.
The base address can be changed after boot-up by writing to the ``mtvec`` CSR.
For more information, see the :ref:`cs-registers` documentation.
The core starts fetching at the address made by concatenating the most significant 3 bytes of the boot address and the reset value (0x80) as the least significant byte.

4
doc/03_reference/icache.rst
View file

@ -64,7 +64,7 @@ The following table describes the available configuration parameters.
Performance notes
-----------------
Note that although larger cache line sizes allow for better area efficiency (lower tagram area overhead), there is a performance penalty.
Note that although larger cache line sizes allow for better area efficiency (lower tag-RAM area overhead), there is a performance penalty.
When the core branches to an address that is not aligned to the bottom of a cache line (and the request misses in the cache), the I$ will attempt to fetch this address first from the bus.
The I$ will then fetch the rest of the remaining beats of data in wrapping address order to complete the cache line (in order to allocate it to the cache).
While these lower addresses are being fetched, the core is starved of data.
@ -77,7 +77,7 @@ RAM Arrangement
---------------
The data RAMs are arranged as ``NumWays`` banks of ``LineSize`` width.
If ECC is configured, the tag and data banks will be wider to accomodate the extra checkbits.
If ECC is configured, the tag and data banks will be wider to accommodate the extra checkbits.
Indicative RAM sizes for common configurations are given in the table below:

2
doc/03_reference/performance_counters.rst
View file

@ -138,7 +138,7 @@ The remaining event selector CSRs are tied to 0, i.e., no events are counted by
FPGA Targets
------------
For FPGA targets the performance counters constitute a particularily large structure.
For FPGA targets the performance counters constitute a particularly large structure.
Implementing the maximum 29 event counters 32, 48 and 64 bit wide results in relative logic utilizations of the core of 100%, 111% and 129% respectively.
The relative numbers of flip-flops are 100%, 125% and 150%.
It is recommended to implement event counters of 32 bit width where possible.

3
doc/03_reference/register_file.rst
View file

@ -28,7 +28,8 @@ FPGA Register File
The FPGA register file leverages synchronous-write / asynchronous-read RAM design elements, where available on FPGA targets.
For Xilinx FPGAs, synthesis results in an implementation using RAM32M primitives. Using this design with a Xilinx Artya7-100 FPGA conserves around 600 Logic LUTs and 1000 flip-flops at the expense of 48 LUTRAMs for the 31-entry register file as compared to the flip-flop-based register file.
For Xilinx FPGAs, synthesis results in an implementation using RAM32M primitives.
Using this design with a Xilinx Arty A7-100 FPGA conserves around 600 Logic LUTs and 1000 flip-flops at the expense of 48 LUTRAMs for the 31-entry register file as compared to the flip-flop-based register file.
This makes it the **first choice for FPGA synthesis**.

2
doc/03_reference/security.rst
View file

@ -61,7 +61,7 @@ Other values of **dummy_instr_mask** are legal, but will have a less predictable
The interval between instruction insertion is randomized in the core using an LFSR.
The initial seed and output permutation for this LFSR can be set using parameters from the top-level of Ibex.
Sofware can periodically re-seed this LFSR with true random numbers (if available) via the **secureseed** CSR.
Software can periodically re-seed this LFSR with true random numbers (if available) via the **secureseed** CSR.
This will make the insertion interval of dummy instructions much harder for an attacker to predict.
Note that the dummy instruction feature inserts multiply and divide instructions.

4
doc/03_reference/verification_stages.rst
View file

@ -97,7 +97,7 @@ V2 Checklist
+---------------+-------------------------------------+------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Coverage | FPV_COI_COVERAGE_V2 | N/A | No formal applied for non-security features in Ibex. |
+---------------+-------------------------------------+------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Integration | PRE_VERIFIED_SUB_MODULES_V2 | Complete | ICache is verified in a seperate testbench. |
| Integration | PRE_VERIFIED_SUB_MODULES_V2 | Complete | ICache is verified in a separate testbench. |
+---------------+-------------------------------------+------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| Issues | NO_HIGH_PRIORITY_ISSUES_PENDING | Complete | |
+---------------+-------------------------------------+------------+----------------------------------------------------------------------------------------------------------------------------------------------------------------------+
@ -178,7 +178,7 @@ The mapping between countermeasures and tests is given below
| | This test produces double faults, which are checked by an assertion. |
| | ``chip_sw_rv_core_ibex_double_fault`` top-level test in OpenTitan demonstrates escalation on a double fault |
+--------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+
| ICACHE.MEM.SCRAMBLE | No explicit testing, the scrambling memory primitive is seperately verified within OpenTitan. |
| ICACHE.MEM.SCRAMBLE | No explicit testing, the scrambling memory primitive is separately verified within OpenTitan. |
| | Assertions in the OpenTitan specific ``rv_core_ibex`` wrapper ensure a newly requested scramble key is correctly applied to the scrambling memories. |
| | The ``rv_core_ibex_icache_invalidate_test`` OpenTitan top-level test covers assertions within the OpenTitan specific ``rv_core_ibex`` wrapper that check that a ``FENCE.I`` results in an icache scramble key request and that the returned key is correctly supplied to the scrambling memory primitives. |
+--------------------------------+------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------+