github-mirrors/ibex
1
0
Fork 0
mirror of https://github.com/lowRISC/ibex.git synced 2025-04-20 11:57:12 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

Doc: Update and cleanup

Browse source
This commit is contained in:
Pirmin Vogel 2019-06-05 18:46:26 +01:00
parent d77bc49595
commit 5c4e6cb4e3
10 changed files with 157 additions and 112 deletions
Download patch file Download diff file Expand all files Collapse all files

35
doc/cs_registers.rst
View file

@ -8,7 +8,7 @@ Ibex implements all the Control and Status Registers (CSRs) listed in the follow
+---------+--------------------+--------+-----------------------------------------------+
| Address | Name | Access | Description |
+=========+====================+========+===============================================+
| 0x300 | ``mstatus`` | RW | Machine Status |
| 0x300 | ``mstatus`` | WARL | Machine Status |
+---------+--------------------+--------+-----------------------------------------------+
| 0x301 | ``misa`` | WARL | Machine ISA and Extensions |
+---------+--------------------+--------+-----------------------------------------------+
@ -65,19 +65,20 @@ CSR Address: ``0x300``
Reset Value: ``0x0000_1800``
+-------+-----+------------------------------------------------------------------+
| Bit# | R/W | Description |
+-------+-----+------------------------------------------------------------------+
| 12:11 | R | **MPP:** Statically 2’b11 and cannot be altered (read-only). |
+-------+-----+------------------------------------------------------------------+
| 7 | RW | **Previous Interrupt Enable:** When an exception is encountered, |
| | | MPIE will be set to IE. When the mret instruction is executed, |
| | | the value of MPIE will be stored to IE. |
+-------+-----+------------------------------------------------------------------+
| 3 | RW | **Interrupt Enable:** If you want to enable interrupt handling |
| | | in your exception handler, set the Interrupt Enable to 1’b1 |
| | | inside your handler code. |
+-------+-----+------------------------------------------------------------------+
+-------+-----+---------------------------------------------------------------------------------+
| Bit# | R/W | Description |
+-------+-----+---------------------------------------------------------------------------------+
| 12:11 | R | **MPP:** Statically 2'b11 and cannot be altered (read-only). |
+-------+-----+---------------------------------------------------------------------------------+
| 7 | RW | **Previous Interrupt Enable (MPIE)**, i.e., before entering exception handling. |
+-------+-----+---------------------------------------------------------------------------------+
| 3 | RW | **Interrupt Enable (MIE):** If set to 1'b1, interrupts are globally enabled. |
+-------+-----+---------------------------------------------------------------------------------+
When an exception is encountered, MPIE will be set to MIE.
When the ``mret`` instruction is executed, the value of MPIE will be stored back to IE.
If you want to enable interrupt handling in your exception handler, set MIE to 1'b1 inside your handler code.
Machine Trap-Vector Base Address (mtvec)
@ -85,8 +86,8 @@ Machine Trap-Vector Base Address (mtvec)
CSR Address: ``0x305``
When an exception is encountered, the core jumps to the corresponding handler using the content of the ``mtvec`` as base address.
It is a read-only register which contains the boot address.
When an exception is encountered, the core jumps to the corresponding handler using the content of ``mtvec`` as base address.
It is a read-only register which contains the boot address.
Machine Exception PC (mepc)
@ -97,7 +98,7 @@ CSR Address: ``0x341``
Reset Value: ``0x0000_0000``
When an exception is encountered, the current program counter is saved in ``mepc``, and the core jumps to the exception address.
When an ``mret`` instruction is executed, the value from ``mepc`` replaces the current program counter.
When an MRET instruction is executed, the value from ``mepc`` replaces the current program counter.
Machine Cause (mcause)

36
doc/debug.rst
View file

@ -1,28 +1,28 @@
.. _debug-unit:
.. _debug-support:
Debug Unit
==========
Debug Support
=============
Ibex implements execution-based debug according to the RISC-V Debug Specification, version 0.13.
Ibex offers support for execution-based debug according to the RISC-V Debug Specification, version 0.13.
Interface
---------
+-------------------------+-----------+----------------------------------------------+
| Signal | Direction | Description |
+=========================+===========+==============================================+
| ``debug_req_i`` | input | Request to enter debug mode |
+-------------------------+-----------+----------------------------------------------+
+-----------------+-----------+-----------------------------+
| Signal | Direction | Description |
+=================+===========+=============================+
| ``debug_req_i`` | input | Request to enter debug mode |
+-----------------+-----------+-----------------------------+
``debug_req_i`` is the "debug interrupt", issued by the debug module when the core should enter debug mode.
Parameters
----------
+--------------------------------------------------------------------------------------------+
| Parameter | Description |
+==========================+=================================================================+
| ``DM_HALT_ADDRESS`` | Address to jump to when entering debug mode |
+--------------------------+-----------------------------------------------------------------+
| ``DM_EXCEPTION_ADDRESS`` | Address to jump to when an exception occurs while in debug mode |
+--------------------------+-----------------------------------------------------------------+
``debug_req_i`` is the "debug interrupt", issued by the debug module when the core should enter debug mode.
+---------------------+-----------------------------------------------------------------+
| Parameter | Description |
+=====================+=================================================================+
| ``DmHaltAddr`` | Address to jump to when entering debug mode |
+---------------------+-----------------------------------------------------------------+
| ``DmExceptionAddr`` | Address to jump to when an exception occurs while in debug mode |
+---------------------+-----------------------------------------------------------------+

29
doc/exception_interrupts.rst
View file

@ -3,7 +3,13 @@
Exceptions and Interrupts
=========================
Ibex supports interrupts, exceptions on illegal instructions.
Ibex currently implements a free-form vectored trap handler mechanism for interrupts and exceptions.
The base address of the interrupt vector table is given by the boot address (must be aligned to 256 bytes, i.e., its least significant byte must be 0x00).
The most significant 3 bytes of the boot address given to the core are used for the first instruction fetch of the core and as the basis of the interrupt vector table.
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.
The boot address can be changed after the first instruction was fetched to change the interrupt vector table address.
It is assumed that the boot address is supplied via a register to avoid long paths to the instruction fetch unit.
The table below lists the supported interrupts and exceptions and the corresponding address offset in the interrupt vector table.
+------------+-----------------------------+
| Address | Description |
@ -20,26 +26,29 @@ Ibex supports interrupts, exceptions on illegal instructions.
| **0x8C** | LSU Error |
+------------+-----------------------------+
The base address of the interrupt vector table is given by the boot address (must be aligned to 256 bytes, i.e., its least significant byte must be 0x00). The most significant 3 bytes of the boot address given to the core are used for the first instruction fetch of the core and as the basis of the interrupt vector table. 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. The boot address can be changed after the first instruction was fetched to change the interrupt vector table address. It is assumed that the boot address is supplied via a register to avoid long paths to the instruction fetch unit.
Interrupts
----------
Interrupts can only be enabled/disabled on a global basis and not individually. It is assumed that there is an event/interrupt controller outside of the core that performs masking and buffering of the interrupt lines. The global interrupt enable is done via the CSR register MSTATUS.
Multiple interrupts requests are assumed to be handled by event/interrupt controller. When an interrupt is taken, the core gives an acknowledge signal to the event/interrupt controller as well as the interrupt id taken.
Interrupts can only be enabled/disabled on a global basis and not individually.
The global interrupt enable is done via the ``mstatus`` CSR.
It is assumed that there is a separate event/interrupt controller outside of the core that performs masking and buffering of multiple interrupt requests.
When an interrupt is taken, the core gives an acknowledge signal to the external event/interrupt controller as well as the interrupt ID taken.
Check :ref:`interrupts` for more details.
Exceptions
----------
The illegal instruction exception, LSU error exceptions and ecall instruction exceptions cannot be disabled and are always active.
The illegal instruction exception, LSU error exceptions and ECALL instruction exceptions cannot be disabled and are always active.
Handling
--------
Ibex does support nested interrupt/exception handling. Exceptions inside interrupt/exception handlers cause another exception, thus exceptions during the critical part of your exception handlers, i.e. before having saved the MEPC and MESTATUS registers, will cause those register to be overwritten. Interrupts during interrupt/exception handlers are disabled by default, but can be explicitly enabled if desired.
Ibex does support nested interrupt/exception handling.
Exceptions inside interrupt/exception handlers cause another exception.
Thus, exceptions during the critical part of your exception handlers, i.e. before having saved the ``mepc`` and ``mstatus``, will cause those CSRs to be overwritten.
Interrupts during interrupt/exception handlers are disabled by default, but can be explicitly enabled if desired.
Upon executing an mret instruction, the core jumps to the program counter saved in the CSR register MEPC and restores the MPIE value of the register MSTATUS to IE. When entering an interrupt/exception handler, the core sets MEPC to the current program counter and saves the current value of MIE in MPIE of the MSTATUS register.
Upon executing an MRET instruction, the core jumps to the program counter saved in the ``mepc`` CSR and restores the MPIE value of the ``mstatus`` CSR to IE.
When entering an interrupt/exception handler, the core sets ``mepc`` to the current program counter and saves the current value of MIE in MPIE of the ``mstatus``.

6
doc/index.rst
View file

@ -1,5 +1,5 @@
Ibex: User Manual
=======================
Ibex User Manual
================
.. toctree::
:maxdepth: 2
@ -11,9 +11,9 @@ Ibex: User Manual
load_store_unit
register_file
cs_registers
interrupts
performance_counters
exception_interrupts
interrupts
debug
rvfi

42
doc/instruction_fetch.rst
View file

@ -3,46 +3,50 @@
Instruction Fetch
=================
The instruction fetcher of the core is able to supply one instruction to the ID stage per cycle if the instruction cache or the instruction memory is able to serve one instruction per cycle. The instruction address must be half-word-aligned due to the support of compressed instructions. It is not possible to jump to instruction addresses that have the LSB bit set.
The Instruction-Fetch (IF) stage of the core is able to supply one instruction to the Instruction-Decode (ID) stage per cycle if the instruction cache or the instruction memory is able to serve one instruction per cycle.
The instruction address must be half-word-aligned due to the support of compressed instructions.
It is not possible to jump to instruction addresses that have the LSB bit set.
For optimal performance and timing closure reasons, a prefetcher is used which fetches instruction from the instruction memory, or instruction cache.
The following table describes the signals that are used to fetch instructions. This interface is a simplified version that is used by the LSU that is described in :ref:`load-store-unit`. The difference is that no writes are possible and thus it needs less signals.
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.
.. tabularcolumns:: |p{4cm}|l|p{9cm}|
+-------------------------+-----------+-----------------------------------------------+
| Signal | Direction | Description |
+=========================+===========+===============================================+
| ``instr_req_o`` | output | Request ready, must stay high until |
| ``instr_req_o`` | output | Request valid, must stay high until |
| | | ``instr_gnt_i`` is high for one cycle |
+-------------------------+-----------+-----------------------------------------------+
| ``instr_addr_o[31:0]`` | output | Address |
+-------------------------+-----------+-----------------------------------------------+
| ``instr_rdata_i[31:0]`` | input | Data read from memory |
| ``instr_gnt_i`` | input | The other side accepted the request. |
| | | ``instr_req_o`` may be deasserted in the next |
| | | cycle. |
+-------------------------+-----------+-----------------------------------------------+
| ``instr_rvalid_i`` | input | ``instr_rdata_is`` holds valid data when |
| ``instr_rvalid_i`` | input | ``instr_rdata_i`` holds valid data when |
| | | ``instr_rvalid_i`` is high. This signal will |
| | | be high for exactly one cycle per request. |
+-------------------------+-----------+-----------------------------------------------+
| ``instr_gnt_i`` | input | The other side accepted the request. |
| | | ``instr_addr_o`` may change in the next cycle |
| ``instr_rdata_i[31:0]`` | input | Data read from memory |
+-------------------------+-----------+-----------------------------------------------+
Protocol
--------
The protocol used to communicate with the instruction cache or the instruction memory is the same as the protocol used by the LSU. See the description of the LSU in :ref:`LSU Protocol<lsu-protocol>` for details about the protocol.
The protocol used to communicate with the instruction cache or the instruction memory is very similar to the protocol used by the LSU on the data interface of Ibex.
See the description of the LSU in :ref:`LSU Protocol<lsu-protocol>` for details about this protocol.
.. caution::
The instruction fetch interface differs from the LSU interface in that the address can change
while the request is valid. This is because it can update the instructions to fetch when a
branch occurs. As depicted in :numref:`if_timing_difference` care has to be taken when
working with the address. The data returned must of course match the address during the grant
cycle.
The IF protocol differs from the LSU protocol in that the address can change while the request is valid (``instr_req_o`` is high).
This allows the core to immediately update the instruction fetch address when a branch occurs.
As depicted in :numref:`if_timing_difference`, care has to be taken when working with the address.
The data returned must match the address during the grant cycle.
.. wavedrom::
:name: if_timing_difference
@ -51,11 +55,11 @@ The protocol used to communicate with the instruction cache or the instruction m
{"signal":
[
{"name": "clk", "wave": "p......"},
{"name": "data_addr_o", "wave": "x===xxx", "data": ["Address", "Address", "Address"]},
{"name": "data_req_o", "wave": "01..0.."},
{"name": "data_gnt_i", "wave": "0..10.."},
{"name": "data_rvalid_i", "wave": "0....10"},
{"name": "data_rdata_i", "wave": "xxxxx=x", "data": ["RData"]}
{"name": "instr_req_o", "wave": "01..0.."},
{"name": "instr_addr_o", "wave": "x=.=xxx", "data": ["Addr1", "Addr2"]},
{"name": "instr_gnt_i", "wave": "0..10.."},
{"name": "instr_rvalid_i", "wave": "0....10"},
{"name": "instr_rdata_i", "wave": "xxxxx=x", "data": ["RData2"]}
],
"config": { "hscale": 2 }
}

28
doc/integration.rst
View file

@ -1,7 +1,10 @@
.. _core-integration:
Core Integration
================
The main module is named ``ibex_core`` and can be found in ``ibex_core.sv``. In the following the instantiation template is given and the parameters and interfaces are described.
The main module is named ``ibex_core`` and can be found in ``ibex_core.sv``.
Below, the instantiation template is given and the parameters and interfaces are described.
Instantiation Template
----------------------
@ -9,12 +12,12 @@ Instantiation Template
.. code-block:: verilog
ibex_core #(
.NumMHPMCounters (8),
.WidthMHPMCounters (40),
.RV32E (0),
.RV32M (1),
.DmHaltAddr (32'h1A110800),
.DmExceptionAddr (32'h1A110808)
.MHPMCounterNum (8),
.MHPMCounterWidth (40),
.RV32E (0),
.RV32M (1),
.DmHaltAddr (32'h1A110800),
.DmExceptionAddr (32'h1A110808)
) u_core (
// Clock and reset
.clk_i (),
@ -50,7 +53,7 @@ Instantiation Template
.irq_ack_o (),
.irq_id_o (),
// Debug Interface
// Debug interface
.debug_req_i (),
// Special control signal
@ -63,9 +66,9 @@ Parameters
+-----------------------+-------------+------------+-----------------------------------------------------------------+
| Name | Type/Range | Default | Description |
+=======================+=============+============+=================================================================+
| ``NumMHPMCounters`` | int (0..29) | 8 | Number of performance monitor event counters |
| ``MHPMCounterNum`` | int (0..29) | 8 | Number of performance monitor event counters |
+-----------------------+-------------+------------+-----------------------------------------------------------------+
| ``WidthMHPMCounters`` | int (64..32)| 40 | Bit width of performance monitor event counters |
| ``MHPMCounterWidth`` | int (64..32)| 40 | Bit width of performance monitor event counters |
+-----------------------+-------------+------------+-----------------------------------------------------------------+
| ``RV32E`` | bit | 0 | RV32E mode enable (16 integer registers only) |
+-----------------------+-------------+------------+-----------------------------------------------------------------+
@ -80,7 +83,6 @@ Parameters
Interfaces
----------
+-------------------------+-------------------------+-----+----------------------------------------+
| Signal(s) | Width | Dir | Description |
+=========================+=========================+=====+========================================+
@ -91,7 +93,7 @@ Interfaces
| ``test_en_i`` | 1 | in | Test input, enables clock |
+-------------------------+-------------------------+-----+----------------------------------------+
| ``core_id_i`` | 4 | in | Core ID, usually static, can be read |
| | | | from :ref:`csr-mhartid` |
| | | | from :ref:`csr-mhartid` CSR |
+-------------------------+-------------------------+-----+ +
| ``cluster_id_i`` | 6 | in | |
+-------------------------+-------------------------+-----+----------------------------------------+
@ -103,7 +105,7 @@ Interfaces
+-------------------------+------------------------------------------------------------------------+
| ``irq_*`` | Interrupt interface, see :ref:`interrupts` |
+-------------------------+------------------------------------------------------------------------+
| ``debug_*`` | Debug interface, see :ref:`debug-unit` |
| ``debug_*`` | Debug interface, see :ref:`debug-support` |
+-------------------------+-------------------------+-----+----------------------------------------+
| ``fetch_enable_i`` | 1 | in | Enable the core, won't fetch when 0 |
+-------------------------+-------------------------+-----+----------------------------------------+

16
doc/interrupts.rst
View file

@ -3,7 +3,8 @@
Interrupts
==========
Interrupts are signaled via the external core interface:
Ibex requires a separate event/interrupt controller outside of the core that performs masking and buffering of multiple interrupt requests.
Communication with this event/interrupt controller is established through the following external core interface:
+-------------------------+-----------+-----------------------------------------------+
| Signal | Direction | Description |
@ -17,9 +18,11 @@ Interrupts are signaled via the external core interface:
| ``irq_id_o[4:0]`` | out | Interrupt acknowledgement ID |
+-------------------------+-----------+-----------------------------------------------+
When external interrupts are enabled, the core will serve interrupt requests. An interrupt is signaled as asserted high level at the ``irq_i`` signal. The interrupt ID determines the interrupt vector ID (0 to 31).
When external interrupts are enabled, the core will serve interrupt requests.
An interrupt request is signaled with ``irq_i`` being high.
The interrupt ID is signaled by ``irq_id_i`` and determines the address offset in the interrupt vector table of the core (see :ref:`exceptions-interrupts`).
Once the interrupt processing is completed, the core will assert ``irq_ack_o`` for one clock cycle along with the identifier that has been completed.
Once the interrupt processing is completed, the core asserts ``irq_ack_o`` for one clock cycle and signals the identifier that has been completed in ``irq_id_o``.
.. important::
@ -40,11 +43,14 @@ Once the interrupt processing is completed, the core will assert ``irq_ack_o`` f
]
}
As the interrupt identifier is registered once it is handled, it is allowed that the interrupt identifier at the input changes. This behavior can be used to handle interrupt priorities. But as the core may already have started interrupt processing, it is necessary to check the acknowledged ID. An example cycle is shown in :numref:`irq-processing-prio`.
As the interrupt identifier is registered once it is handled, it is allowed that the interrupt identifier at the input changes.
This behavior can be used to handle interrupt priorities.
But as the core may already have started interrupt processing, it is necessary to check the acknowledged ID.
An example cycle is shown in :numref:`irq-processing-prio`.
.. wavedrom::
:name: irq-processing-prio
:caption: Typical interrupt processing with priorization on the interface. Here the processing of ``ID0`` has already started.
:caption: Interrupt processing with priorization. The processing of ``ID0`` has already started.
{ "signal": [
{ "name": "clk_i", "wave": "p...", "period": 2 },

50
doc/introduction.rst
View file

@ -6,42 +6,62 @@ Introduction
Block Diagram
Ibex is a 2-stage in-order 32b RISC-V processor core. Ibex has been designed to be small and efficient. Via two parameters, the core is configurable to support four ISA configurations. :numref:`blockdiagram` shows a block diagram of the core.
Ibex is a 2-stage in-order 32b RISC-V processor core.
Ibex has been designed to be small and efficient.
Via two parameters, the core is configurable to support four ISA configurations.
:numref:`blockdiagram` shows a block diagram of the core.
Supported Instruction Set
-------------------------
Ibex supports the following instructions:
Ibex supports the following instruction sets and extensions:
* Full support for RV32I Base Integer Instruction Set
* Full support for RV32E Base Integer Instruction Set
* Full support for RV32C Standard Extension for Compressed Instructions
* Full support for RV32M Integer Multiplication and Division Instruction Set Extension
* Full support for RV32M Integer Multiplication and Division Instruction Set Extension
The RV32M and RV32E can be enable and disable using two parameters.
Support for RV32M and RV32E can be enabled or disabled using two separate configuration parameters.
ASIC Synthesis
--------------
ASIC synthesis is supported for Ibex. The whole design is completely synchronous and uses positive-edge triggered flip-flops, except for the register file, which can be implemented either with latches or with flip-flops. See Chapter 4 for more details about the register file. The core occupies an area of about 18.9 kGE when the latch based register file and the RV32IMC ISA is used or 11.6 kGE when the RV32EC is used .
ASIC synthesis is supported for Ibex.
The whole design is completely synchronous and uses positive-edge triggered flip-flops, except for the register file, which can be implemented either with latches or with flip-flops.
See :ref:`register-file` for more details.
The core occupies an area of roughly 18.9 kGE when using the latch-based register file and implementing the RV32IMC ISA, or 11.6 kGE when implementing the RV32EC ISA.
FPGA Synthesis
--------------
FPGA synthesis is supported for Ibex when the flip-flop based register file is used. Since latches are not well supported on FPGAs, it is crucial to select the flip-flop based register file.
FPGA synthesis is supported for Ibex when the flip-flop based register file is used.
Since latches are not well supported on FPGAs, it is crucial to select the flip-flop based register file.
Contents
--------
:ref:`core-integration` provides the instantiation template and gives descriptions of the design parameters as well as the input and output ports.
The instruction and data interfaces of Ibex are explained in :ref:`instruction-fetch` and :ref:`load-store-unit`, respectively.
The two register-file flavors are described in :ref:`register-file`.
The control and status registers are explained in :ref:`cs-registers`.
:ref:`performance-counters` gives an overview of the performance monitors and event counters available in Ibex.
:ref:`exceptions-interrupts` deals with the infrastructure for handling exceptions and interrupts,
:ref:`debug-support` gives a brief overview on the debug infrastructure.
Outline
-------
This document summarizes all the functionality of the Ibex core in more detail. First, the instruction and data interfaces are explained in :ref:`instruction-fetch` and :ref:`load-store-unit`. :ref:`register-file` explains the register file. Control and status registers are explained in :ref:`cs-registers` and Chapter :ref:`performance-counters` gives an overview of all performance counters. Chapter :ref:`exceptions-interrupts` deals with exceptions and interrupts, and finally Chapter :ref:`debug-unit` summarizes the accessible debug registers.
History
-------
Ibex development started in 2015 under the name "ZERO-RISCY" as part of the `PULP platform <http://pulp.ethz.ch/>`_ for
energy-efficient computing.
Much of the code was developed by simplifying the RV32 CPU core "RI5CY" to show how small a RISC-V CPU core could be.
To make it even smaller, support for the ``E`` exension was added under the code name "MICRO-RISCY".
Within PULP the core is used as the control core for PULP and PULPino.
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".
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.
In December 2018 lowRISC took over the development of Zero-riscy and renamed it to Ibex.
References
----------
1. `Schiavone, Pasquale Davide, et al. "Slow and steady wins the race? A comparison of ultra-low-power RISC-V cores for Internet-of-Things applications." 27th International Symposium on Power and Timing Modeling, Optimization and Simulation (PATMOS 2017) <https://doi.org/10.1109/PATMOS.2017.8106976>`_

15
doc/load_store_unit.rst
View file

@ -1,16 +1,17 @@
.. _load-store-unit:
Load-Store-Unit (LSU)
=====================
Load-Store Unit
===============
The LSU of the core takes care of accessing the data memory. Load and stores on words (32 bit), half words (16 bit) and bytes (8 bit) are supported.
The Load-Store Unit (LSU) of the core takes care of accessing the data memory.
Loads and stores of words (32 bit), half words (16 bit) and bytes (8 bit) are supported.
Signals that are used by the LSU:
+-------------------------+-----------+-----------------------------------------------+
| Signal | Direction | Description |
+=========================+===========+===============================================+
| ``data_req_o`` | output | Request ready, must stay high until |
| ``data_req_o`` | output | Request valid, must stay high until |
| | | ``data_gnt_i`` is high for one cycle |
+-------------------------+-----------+-----------------------------------------------+
| ``data_addr_o[31:0]`` | output | Address |
@ -43,7 +44,9 @@ Signals that are used by the LSU:
Misaligned Accesses
-------------------
The LSU is able to perform misaligned accesses, meaning accesses that are not aligned on natural word boundaries. However, it needs to perform two separate word-aligned accesses internally. This means that at least two cycles are needed for misaligned loads and stores.
The LSU is able to perform misaligned accesses, meaning accesses that are not aligned on natural word boundaries.
However, it needs to perform two separate word-aligned accesses internally.
This means that at least two cycles are needed for misaligned loads and stores.
.. _lsu-protocol:
@ -120,5 +123,3 @@ The protocol that is used by the LSU to communicate with a memory works as follo
],
"config": { "hscale": 2 }
}

12
doc/register_file.rst
View file

@ -3,19 +3,21 @@
Register File
=============
Ibex has 31 or 15 32-bit wide registers depending if the RV32E extension is enabled. Register x0 is statically bound to 0 and can only be read, it does not contain any sequential logic.
Ibex has either 31 or 15 32-bit registers if the RV32E extension is disabled or enabled, respectively.
Register ``x0`` is statically bound to 0 and can only be read, it does not contain any sequential logic.
There are two flavors of register file available:
1. Latch-based
1. Latch based
2. Flip-flop based
While the latch-based register file is recommended for ASICs, the flip-flop based register file is recommended for FPGA synthesis, although both are compatible with either synthesis target. Note the flip-flop based register file is significantly larger than the latch-based register-file for an ASIC implementation.
While the latch-based register file is recommended for ASICs, the flip-flop-based register file is recommended for FPGA synthesis, although both are compatible with either synthesis target.
Note the flip-flop-based register file is significantly larger than the latch-based register-file for an ASIC implementation.
Latch-based Register File
Latch-Based Register File
-------------------------
The latch based register file contains manually instantiated clock gating cells to keep the clock inactive when the latches are not written.
The latch-based register file contains manually instantiated clock gating cells to keep the clock inactive when the latches are not written.
It is assumed that there is a clock gating cell for the target technology that is wrapped in a module called ``prim_clock_gating`` and has the following ports: