| Line 1... |
Line 1... |
:sectnums:
|
:sectnums:
|
== NEORV32 Central Processing Unit (CPU)
|
== NEORV32 Central Processing Unit (CPU)
|
|
|
image::riscv_logo.png[width=350,align=center]
|
image::neorv32_cpu_block.png[width=600,align=center]
|
|
|
**Key Features**
|
**Key Features**
|
|
|
* 32-bit multi-cycle in-order `rv32` RISC-V CPU
|
* 32-bit multi-cycle in-order `rv32` RISC-V CPU
|
* Optional RISC-V extensions:
|
* Optional RISC-V extensions:
|
| Line 18... |
Line 18... |
** `Zicsr` - control and status register access (privileged architecture)
|
** `Zicsr` - control and status register access (privileged architecture)
|
** `Zicntr` - CPU base counters
|
** `Zicntr` - CPU base counters
|
** `Zihpm` - hardware performance monitors
|
** `Zihpm` - hardware performance monitors
|
** `Zifencei` - instruction stream synchronization
|
** `Zifencei` - instruction stream synchronization
|
** `Zmmul` - integer multiplication hardware
|
** `Zmmul` - integer multiplication hardware
|
|
** `Zxcfu` - custom instructions extension
|
** `PMP` - physical memory protection
|
** `PMP` - physical memory protection
|
** `Debug` - debug mode
|
** `Debug` - debug mode (part of the on.chip debugger) including hardware trigger module
|
* Compatible to the RISC-V user specifications and a subset of the RISC-V privileged architecture specifications - passes the official RISC-V Architecture Tests (v2+)
|
* Compatible to the RISC-V user specifications and a subset of the RISC-V privileged architecture specifications - passes the official RISC-V Architecture Tests (v2+)
|
* Official RISC-V open-source architecture ID
|
* Official RISC-V open-source architecture ID
|
* Standard RISC-V interrupts (_external_, _timer_, _software_) plus 16 _fast_ interrupts
|
* Standard RISC-V interrupts (_external_, _timer_, _software_) plus 16 _fast_ interrupts
|
* Supports _all_ of the machine-level traps from the RISC-V specifications (including bus access exceptions and all unimplemented/illegal/malformed instructions)
|
* Supports _all_ of the machine-level traps from the RISC-V specifications (including bus access exceptions and all unimplemented/illegal/malformed instructions)
|
** This is a special aspect on _execution safety_ by <<_full_virtualization>>
|
** This is a special aspect on _execution safety_ by <<_full_virtualization>>
|
| Line 87... |
Line 88... |
|
|
// ####################################################################################################################
|
// ####################################################################################################################
|
:sectnums:
|
:sectnums:
|
=== Full Virtualization
|
=== Full Virtualization
|
|
|
Just like the RISC-V ISA the NEORV32 aims to provide _maximum virtualization_ capabilities on CPU _and_ SoC level to
|
Just like the RISC-V ISA the NEORV32 aims to provide _maximum virtualization_ capabilities on CPU and SoC level to
|
allow a high standard of **execution safety**. The CPU supports **all** traps specified by the official RISC-V specifications.
|
allow a high standard of **execution safety**. The CPU supports **all** traps specified by the official RISC-V specifications.
|
footnote:[If the `Zicsr` CPU extension is enabled (implementing the full set of the privileged architecture).]
|
footnote:[If the `Zicsr` CPU extension is enabled (implementing the full set of the privileged architecture).]
|
Thus, the CPU provides defined hardware fall-backs via traps for any expected and unexpected situation (e.g. executing an
|
Thus, the CPU provides defined hardware fall-backs via traps for any expected and unexpected situation (e.g. executing a
|
malformed instruction word or accessing a not-allocated memory address). For any kind of trap the core is always in a
|
malformed instruction or accessing a non-allocated memory address). For any kind of trap the core is always in a
|
defined and fully synchronized state throughout the whole architecture (i.e. there are no out-of-order operations that
|
defined and fully synchronized state throughout the whole architecture (i.e. there are no out-of-order operations that
|
might have to reverted). This allows predictable execution behavior at any time improving overall _execution safety_.
|
might have to be reverted). This allows a defined and predictable execution behavior at any time improving overall execution safety.
|
|
|
**Execution Safety - NEORV32 Virtualization Features**
|
**Execution Safety - NEORV32 Virtualization Features**
|
|
|
* Due to the acknowledged memory accesses the CPU is _always_ sync with the memory system
|
* Due to the acknowledged memory accesses the CPU is _always_ sync with the memory system
|
(i.e. there is no speculative execution / no out-of-order states).
|
(i.e. there is no speculative execution / no out-of-order states).
|
* The CPU supports _all_ RISC-V compatible bus exceptions including access exceptions, which are triggered if an
|
* The CPU supports _all_ RISC-V compatible bus exceptions including access exceptions, which are triggered if an
|
accessed address does not respond or encounters an internal error during access.
|
accessed address does not respond or encounters an internal device error during access.
|
* Accessed memory addresses (plain memory, but also memory-mapped devices) need to respond within a fixed time
|
* Accessed memory addresses (plain memory, but also memory-mapped devices) need to respond within a fixed time
|
window. Otherwise a bus access exception is raised.
|
window. Otherwise a bus access exception is raised.
|
* The RISC-V specs. state that executing an malformed instruction results in unpredictable behavior. As an additional
|
* The RISC-V specs. state that executing an malformed instruction results in unpredictable behavior. As an additional
|
execution safety feature the NEORV32 CPU ensures that _all_ unimplemented/malformed/illegal instructions do raise an
|
execution safety feature the NEORV32 CPU ensures that _all_ unimplemented/malformed/illegal instructions do raise an
|
illegal instruction exceptions and do not commit any state-changing operation (like writing registers or triggering
|
illegal instruction exceptions and do not commit any state-changing operation (like writing registers or triggering
|
| Line 253... |
Line 254... |
This list shows the currently identified issues regarding full RISC-V-compatibility. More specific information
|
This list shows the currently identified issues regarding full RISC-V-compatibility. More specific information
|
can be found in section <<_instruction_sets_and_extensions>>.
|
can be found in section <<_instruction_sets_and_extensions>>.
|
|
|
.Read-Only "Read-Write" CSRs
|
.Read-Only "Read-Write" CSRs
|
[IMPORTANT]
|
[IMPORTANT]
|
The `misa` and `mtval` CSRs in the NEORV32 are _read-only_.
|
The <<_misa>> and <<_mtval>> CSRs in the NEORV32 are _read-only_.
|
Any machine-mode write access to them is ignored and will _not_ cause any exceptions or side-effects to maintain
|
Any machine-mode write access to them is ignored and will _not_ cause any exceptions or side-effects to maintain
|
RISC-V compatibility.
|
RISC-V compatibility.
|
|
|
.Physical Memory Protection
|
.Physical Memory Protection
|
[IMPORTANT]
|
[IMPORTANT]
|
| Line 336... |
Line 337... |
The _specific_ generics are listed below.
|
The _specific_ generics are listed below.
|
|
|
[cols="4,4,2"]
|
[cols="4,4,2"]
|
[frame="all",grid="none"]
|
[frame="all",grid="none"]
|
|======
|
|======
|
| **CPU_BOOT_ADDR** | _std_ulogic_vector(31 downto 0)_ | 0x00000000
|
| **CPU_BOOT_ADDR** | _std_ulogic_vector(31 downto 0)_ | -
|
3+| This address defines the reset address at which the CPU starts fetching instructions after reset. In terms of the NEORV32 processor, this
|
3+| This address defines the reset address at which the CPU starts fetching instructions after reset. In terms of the NEORV32 processor, this
|
generic is configured with the base address of the bootloader ROM (default) or with the base address of the processor-internal instruction
|
generic is configured with the base address of the bootloader ROM (default) or with the base address of the processor-internal instruction
|
memory (IMEM) if the bootloader is disabled (_INT_BOOTLOADER_EN_ = _false_). See section <<_address_space>> for more information.
|
memory (IMEM) if the bootloader is disabled (_INT_BOOTLOADER_EN_ = _false_). See section <<_address_space>> for more information.
|
|======
|
|======
|
|
|
[cols="4,4,2"]
|
[cols="4,4,2"]
|
[frame="all",grid="none"]
|
[frame="all",grid="none"]
|
|======
|
|======
|
| **CPU_DEBUG_ADDR** | _std_ulogic_vector(31 downto 0)_ | 0x00000000
|
| **CPU_DEBUG_ADDR** | _std_ulogic_vector(31 downto 0)_ | -
|
3+| This address defines the entry address for the "execution based" on-chip debugger. By default, this generic is configured with the base address
|
3+| This address defines the entry address for the "execution based" on-chip debugger. By default, this generic is configured with the base address
|
of the debugger memory. See section <<_on_chip_debugger_ocd>> for more information.
|
of the debugger memory. See section <<_on_chip_debugger_ocd>> for more information.
|
|======
|
|======
|
|
|
[cols="4,4,2"]
|
[cols="4,4,2"]
|
[frame="all",grid="none"]
|
[frame="all",grid="none"]
|
|======
|
|======
|
| **CPU_EXTENSION_RISCV_DEBUG** | _boolean_ | false
|
| **CPU_EXTENSION_RISCV_DEBUG** | _boolean_ | -
|
3+| Implement RISC-V-compatible "debug" CPU operation mode. See section <<_cpu_debug_mode>> for more information.
|
3+| Implement RISC-V-compatible "debug" CPU operation mode. See section <<_cpu_debug_mode>> for more information.
|
|======
|
|======
|
|
|
|
|
|
|
| Line 368... |
Line 369... |
The basic NEORV32 is a RISC-V `rv32i` architecture that provides several _optional_ RISC-V CPU and ISA
|
The basic NEORV32 is a RISC-V `rv32i` architecture that provides several _optional_ RISC-V CPU and ISA
|
(instruction set architecture) extensions. For more information regarding the RISC-V ISA extensions please
|
(instruction set architecture) extensions. For more information regarding the RISC-V ISA extensions please
|
see the the _RISC-V Instruction Set Manual - Volume I: Unprivileged ISA_ and _The RISC-V Instruction Set Manual
|
see the the _RISC-V Instruction Set Manual - Volume I: Unprivileged ISA_ and _The RISC-V Instruction Set Manual
|
Volume II: Privileged Architecture_, which are available in the projects `docs/references` folder.
|
Volume II: Privileged Architecture_, which are available in the projects `docs/references` folder.
|
|
|
|
.Discovering ISA Extensions
|
[TIP]
|
[TIP]
|
The CPU can discover available ISA extensions via the <<_misa>> CSR and the
|
The CPU can discover available ISA extensions via the <<_misa>> & <<_mxisa>> CSRs
|
`CPU` <<_system_configuration_information_memory_sysinfo, SYSINFO>> register
|
or by executing an instruction and checking for an _illegal instruction exception_
|
or by executing an instruction and checking for an _illegal instruction exception_.
|
(-> <<_full_virtualization>>). +
|
|
+
|
[NOTE]
|
|
Executing an instruction from an extension that is not supported yet or that is currently not enabled
|
Executing an instruction from an extension that is not supported yet or that is currently not enabled
|
(via the according top entity generic) will raise an _illegal instruction_ exception.
|
(via the according top entity generic) will raise an illegal instruction exception.
|
|
|
|
|
==== **`A`** - Atomic Memory Access
|
==== **`A`** - Atomic Memory Access
|
|
|
Atomic memory access instructions allow more sophisticated memory operations like implementing semaphores and mutexes.
|
Atomic memory access instructions allow more sophisticated memory operations like implementing semaphores and mutexes.
|
The RICS-C specs. defines a specific _atomic_ extension that provides instructions for atomic memory accesses. The `A`
|
The RICS-C specs. defines a specific _atomic_ extension that provides instructions for atomic memory accesses. The `A`
|
ISA extension is enabled if the `CPU_EXTENSION_RISCV_A` configuration generic is _true_.
|
ISA extension is enabled if the <<_cpu_extension_riscv_a>> configuration generic is _true_.
|
In this case the following additional instructions are available:
|
In this case the following additional instructions are available:
|
|
|
* `lr.w`: load-reservate
|
* `lr.w`: load-reservate
|
* `sc.w`: store-conditional
|
* `sc.w`: store-conditional
|
|
|
| Line 412... |
Line 413... |
|
|
|
|
==== **`B`** - Bit-Manipulation Operations
|
==== **`B`** - Bit-Manipulation Operations
|
|
|
The `B` ISA extension adds instructions for bit-manipulation operations. This extension is enabled if the
|
The `B` ISA extension adds instructions for bit-manipulation operations. This extension is enabled if the
|
`CPU_EXTENSION_RISCV_B` configuration generic is _true_.
|
<<_cpu_extension_riscv_b>> configuration generic is _true_.
|
The official RISC-V specifications can be found here: https://github.com/riscv/riscv-bitmanip
|
The official RISC-V specifications can be found here: https://github.com/riscv/riscv-bitmanip
|
A copy of the spec is also available in `docs/references`.
|
A copy of the spec is also available in `docs/references`.
|
|
|
The NEORV32 `B` ISA extension includes the following sub-extensions (according to the RISC-V
|
The NEORV32 `B` ISA extension includes the following sub-extensions (according to the RISC-V
|
bit-manipulation spec. v.093) and their corresponding instructions:
|
bit-manipulation spec. v.093) and their corresponding instructions:
|
| Line 452... |
Line 453... |
|
|
|
|
==== **`C`** - Compressed Instructions
|
==== **`C`** - Compressed Instructions
|
|
|
The _compressed_ ISA extension provides 16-bit encodings of commonly used instructions to reduce code space size.
|
The _compressed_ ISA extension provides 16-bit encodings of commonly used instructions to reduce code space size.
|
The `C` extension is available when the `CPU_EXTENSION_RISCV_C` configuration generic is _true_.
|
The `C` extension is available when the <<_cpu_extension_riscv_c>> configuration generic is _true_.
|
In this case the following instructions are available:
|
In this case the following instructions are available:
|
|
|
* `c.addi4spn` `c.lw` `c.sw` `c.nop` `c.addi` `c.jal` `c.li` `c.addi16sp` `c.lui` `c.srli` `c.srai` `c.andi` `c.sub`
|
* `c.addi4spn` `c.lw` `c.sw` `c.nop` `c.addi` `c.jal` `c.li` `c.addi16sp` `c.lui` `c.srli` `c.srai` `c.andi` `c.sub`
|
`c.xor` `c.or` `c.and` `c.j` `c.beqz` `c.bnez` `c.slli` `c.lwsp` `c.jr` `c.mv` `c.ebreak` `c.jalr` `c.add` `c.swsp`
|
`c.xor` `c.or` `c.and` `c.j` `c.beqz` `c.bnez` `c.slli` `c.lwsp` `c.jr` `c.mv` `c.ebreak` `c.jalr` `c.add` `c.swsp`
|
|
|
| Line 468... |
Line 469... |
|
|
|
|
==== **`E`** - Embedded CPU
|
==== **`E`** - Embedded CPU
|
|
|
The embedded CPU extensions reduces the size of the general purpose register file from 32 entries to 16 entries to
|
The embedded CPU extensions reduces the size of the general purpose register file from 32 entries to 16 entries to
|
decrease physical hardware requirements (for example block RAM). This extensions is enabled when the `CPU_EXTENSION_RISCV_E`
|
decrease physical hardware requirements (for example block RAM). This extensions is enabled when the <<_cpu_extension_riscv_e>>
|
configuration generic is _true_. Accesses to registers beyond `x15` will raise and _illegal instruction exception_.
|
configuration generic is _true_. Accesses to registers beyond `x15` will raise and _illegal instruction exception_.
|
This extension does not add any additional instructions or features.
|
This extension does not add any additional instructions or features.
|
|
|
[NOTE]
|
[NOTE]
|
Due to the reduced register file size an alternate toolchain ABI (**`ilp32e`**) is required.
|
Due to the reduced register file size an alternate toolchain ABI (**`ilp32e`**) is required.
|
| Line 504... |
Line 505... |
|
|
|
|
==== **`M`** - Integer Multiplication and Division
|
==== **`M`** - Integer Multiplication and Division
|
|
|
Hardware-accelerated integer multiplication and division operations are available when the
|
Hardware-accelerated integer multiplication and division operations are available when the
|
`CPU_EXTENSION_RISCV_M` configuration generic is _true_. In this case the following instructions are
|
<<_cpu_extension_riscv_m>> configuration generic is _true_. In this case the following instructions are
|
available:
|
available:
|
|
|
* multiplication: `mul` `mulh` `mulhsu` `mulhu`
|
* multiplication: `mul` `mulh` `mulhsu` `mulhu`
|
* division: `div` `divu` `rem` `remu`
|
* division: `div` `divu` `rem` `remu`
|
|
|
| Line 523... |
Line 524... |
|
|
This is a _sub-extension_ of the `M` ISA extension. It implements the multiplication-only operations
|
This is a _sub-extension_ of the `M` ISA extension. It implements the multiplication-only operations
|
of the `M` extensions and is intended for size-constrained setups that require hardware-based
|
of the `M` extensions and is intended for size-constrained setups that require hardware-based
|
integer multiplications but not hardware-based divisions, which will be computed entirely in software.
|
integer multiplications but not hardware-based divisions, which will be computed entirely in software.
|
This extension requires only ~50% of the hardware utilization of the "full" `M` extension.
|
This extension requires only ~50% of the hardware utilization of the "full" `M` extension.
|
|
It is implemented if the <<_cpu_extension_riscv_zmmul>> configuration generic is _true_.
|
|
|
* multiplication: `mul` `mulh` `mulhsu` `mulhu`
|
* multiplication: `mul` `mulh` `mulhsu` `mulhu`
|
|
|
If `Zmmul` is enabled, executing any division instruction from the `M` ISA extension (`div`, `divu`, `rem`, `remu`)
|
If `Zmmul` is enabled, executing any division instruction from the `M` ISA extension (`div`, `divu`, `rem`, `remu`)
|
will raise an _illegal instruction exception_.
|
will raise an _illegal instruction exception_.
|
| Line 540... |
Line 542... |
|
|
|
|
==== **`U`** - Less-Privileged User Mode
|
==== **`U`** - Less-Privileged User Mode
|
|
|
In addition to the basic (and highest-privileged) machine-mode, the _user-mode_ ISA extensions adds a second less-privileged
|
In addition to the basic (and highest-privileged) machine-mode, the _user-mode_ ISA extensions adds a second less-privileged
|
operation mode. It is implemented if the `CPU_EXTENSION_RISCV_U` configuration generic is _true_.
|
operation mode. It is implemented if the <<_cpu_extension_riscv_u>> configuration generic is _true_.
|
Code executed in user-mode cannot access machine-mode CSRs. Furthermore, user-mode access to the address space (like
|
Code executed in user-mode cannot access machine-mode CSRs. Furthermore, user-mode access to the address space (like
|
peripheral/IO devices) can be constrained via the physical memory protection (_PMP_).
|
peripheral/IO devices) can be constrained via the physical memory protection (_PMP_).
|
Any kind of privilege rights violation will raise an exception to allow full virtualization.
|
Any kind of privilege rights violation will raise an exception to allow <<_full_virtualization>>.
|
|
|
|
|
==== **`X`** - NEORV32-Specific (Custom) Extensions
|
==== **`X`** - NEORV32-Specific (Custom) Extensions
|
|
|
The NEORV32-specific extensions are always enabled and are indicated by the set `X` bit in the `misa` CSR.
|
The NEORV32-specific extensions are always enabled and are indicated by the set `X` bit in the <<_misa>> CSR.
|
|
|
The most important points of the NEORV32-specific extensions are:
|
The most important points of the NEORV32-specific extensions are:
|
* The CPU provides 16 _fast interrupt_ interrupts (`FIRQ)`, which are controlled via custom bits in the `mie`
|
* The CPU provides 16 _fast interrupt_ interrupts (`FIRQ)`, which are controlled via custom bits in the `mie`
|
and `mip` CSR. This extension is mapped to CSR bits, that are available for custom use (according to the
|
and <<_mip>> CSR. This extension is mapped to CSR bits, that are available for custom use (according to the
|
RISC-V specs). Also, custom trap codes for `mcause` are implemented.
|
RISC-V specs). Also, custom trap codes for <<_mcause>> are implemented.
|
* All undefined/unimplemented/malformed/illegal instructions do raise an illegal instruction exception (see <<_full_virtualization>>).
|
* All undefined/unimplemented/malformed/illegal instructions do raise an illegal instruction exception (see <<_full_virtualization>>).
|
|
* There are <<_neorv32_specific_csrs>>.
|
|
|
|
|
==== **`Zfinx`** Single-Precision Floating-Point Operations
|
==== **`Zfinx`** Single-Precision Floating-Point Operations
|
|
|
The `Zfinx` floating-point extension is an _alternative_ of the standard `F` floating-point ISA extension.
|
The `Zfinx` floating-point extension is an _alternative_ of the standard `F` floating-point ISA extension.
|
| Line 570... |
Line 573... |
|
|
[NOTE]
|
[NOTE]
|
The NEORV32 floating-point unit used by the `Zfinx` extension is compatible to the _IEEE-754_ specifications.
|
The NEORV32 floating-point unit used by the `Zfinx` extension is compatible to the _IEEE-754_ specifications.
|
|
|
The `Zfinx` extensions only supports single-precision (`.s` instruction suffix), so it is a direct alternative
|
The `Zfinx` extensions only supports single-precision (`.s` instruction suffix), so it is a direct alternative
|
to the `F` extension. The `Zfinx` extension is implemented when the `CPU_EXTENSION_RISCV_Zfinx` configuration
|
to the `F` extension. The `Zfinx` extension is implemented when the <<_cpu_extension_riscv_zfinx>> configuration
|
generic is _true_. In this case the following instructions and CSRs are available:
|
generic is _true_. In this case the following instructions and CSRs are available:
|
|
|
* conversion: `fcvt.s.w` `fcvt.s.wu` `fcvt.w.s` `fcvt.wu.s`
|
* conversion: `fcvt.s.w` `fcvt.s.wu` `fcvt.w.s` `fcvt.wu.s`
|
* comparison: `fmin.s` `fmax.s` `feq.s` `flt.s` `fle.s`
|
* comparison: `fmin.s` `fmax.s` `feq.s` `flt.s` `fle.s`
|
* computational: `fadd.s` `fsub.s` `fmul.s`
|
* computational: `fadd.s` `fsub.s` `fmul.s`
|
* sign-injection: `fsgnj.s` `fsgnjn.s` `fsgnjx.s`
|
* sign-injection: `fsgnj.s` `fsgnjn.s` `fsgnjx.s`
|
* number classification: `fclass.s`
|
* number classification: `fclass.s`
|
|
|
* additional CSRs: `fcsr` `frm` `fflags`
|
* additional CSRs: <<_fcsr>>, <<_frm>>, <<_fflags>>
|
|
|
[WARNING]
|
[WARNING]
|
Fused multiply-add instructions `f[n]m[add/sub].s` are not supported!
|
Fused multiply-add instructions `f[n]m[add/sub].s` are not supported!
|
Division `fdiv.s` and square root `fsqrt.s` instructions are not supported yet!
|
Division `fdiv.s` and square root `fsqrt.s` instructions are not supported yet!
|
|
|
| Line 601... |
Line 604... |
|
|
|
|
==== **`Zicsr`** Control and Status Register Access / Privileged Architecture
|
==== **`Zicsr`** Control and Status Register Access / Privileged Architecture
|
|
|
The CSR access instructions as well as the exception and interrupt system (= the privileged architecture)
|
The CSR access instructions as well as the exception and interrupt system (= the privileged architecture)
|
is implemented when the `CPU_EXTENSION_RISCV_Zicsr` configuration generic is _true_.
|
is implemented when the <<_cpu_extension_riscv_zicsr>> configuration generic is _true_.
|
|
|
[IMPORTANT]
|
[IMPORTANT]
|
If the `Zicsr` extension is disabled the CPU does not provide any _privileged architecture_ features at all!
|
If the `Zicsr` extension is disabled the CPU does not provide any _privileged architecture_ features at all!
|
In order to provide the full set of privileged functions that are required to run more complex tasks like
|
In order to provide the full set of privileged functions that are required to run more complex tasks like
|
operating system and to allow a secure execution environment the `Zicsr` extension should be always enabled.
|
operating system and to allow a secure execution environment the `Zicsr` extension should be always enabled.
|
| Line 621... |
Line 624... |
(the RISC-V spec. state that these combinations "_shall_ not cause any side-effects").
|
(the RISC-V spec. state that these combinations "_shall_ not cause any side-effects").
|
|
|
[NOTE]
|
[NOTE]
|
The "wait for interrupt instruction" `wfi` acts like a sleep command. When executed, the CPU is
|
The "wait for interrupt instruction" `wfi` acts like a sleep command. When executed, the CPU is
|
halted until a valid interrupt request occurs. To wake up again, the according interrupt source has to
|
halted until a valid interrupt request occurs. To wake up again, the according interrupt source has to
|
be enabled via the `mie` CSR and the global interrupt enable flag in `mstatus` has to be set.
|
be enabled via the <<_mie>> CSR and the global interrupt enable flag in <<_mstatus>> has to be set.
|
The `wfi` instruction may also be executed in user-mode without causing an exception as <<_mstatus>> bit
|
The `wfi` instruction may also be executed in user-mode without causing an exception as <<_mstatus>> bit
|
`TW` (timeout wait) is _hardwired_ to zero.
|
`TW` (timeout wait) is _hardwired_ to zero.
|
|
|
|
|
|
|
| Line 646... |
Line 649... |
==== **`Zihpm`** Hardware Performance Monitors
|
==== **`Zihpm`** Hardware Performance Monitors
|
|
|
In additions to the base cycle, instructions-retired and time counters the NEORV32 CPU provides
|
In additions to the base cycle, instructions-retired and time counters the NEORV32 CPU provides
|
up to 29 hardware performance monitors (HPM 3..31), which can be used to benchmark applications. Each HPM consists of an
|
up to 29 hardware performance monitors (HPM 3..31), which can be used to benchmark applications. Each HPM consists of an
|
N-bit wide counter (split in a high-word 32-bit CSR and a low-word 32-bit CSR), where N is defined via the top's
|
N-bit wide counter (split in a high-word 32-bit CSR and a low-word 32-bit CSR), where N is defined via the top's
|
`HPM_CNT_WIDTH` generic (0..64-bit) and a corresponding event configuration CSR. The event configuration
|
<<_hpm_cnt_width>> generic (0..64-bit) and a corresponding event configuration CSR. The event configuration
|
CSR defines the architectural events that lead to an increment of the associated HPM counter.
|
CSR defines the architectural events that lead to an increment of the associated HPM counter.
|
|
|
The HPM counters are available if the `Zihpm` ISA extensions is enabled via the <<_cpu_extension_riscv_zihpm>> generic.
|
The HPM counters are available if the `Zihpm` ISA extensions is enabled via the <<_cpu_extension_riscv_zihpm>> generic.
|
|
|
Depending on the configuration the following additional CSR are available:
|
Depending on the configuration the following additional CSR are available:
|
|
|
* counters: `mhpmcounter*[h]` (3..31, depending on `HPM_NUM_CNTS`)
|
* counters: `mhpmcounter*[h]` (3..31, depending on `HPM_NUM_CNTS`)
|
* event configuration: `mhpmevent*` (3..31, depending on `HPM_NUM_CNTS`)
|
* event configuration: `mhpmevent*` (3..31, depending on `HPM_NUM_CNTS`)
|
|
|
[IMPORTANT]
|
[IMPORTANT]
|
The HPM counter CSR can only be accessed in machine-mode. Hence, the according `mcounteren` CSR bits
|
The HPM counter CSR can only be accessed in machine-mode. Hence, the according <<_mcounteren>> CSR bits
|
are always zero and read-only. Any access from less-privileged modes will raise an illegal instruction
|
are always zero and read-only. Any access from less-privileged modes will raise an illegal instruction
|
exception.
|
exception.
|
|
|
[TIP]
|
[TIP]
|
Auto-increment of the HPMs can be individually deactivated via the `mcountinhibit` CSR.
|
Auto-increment of the HPMs can be individually deactivated via the <<_mcountinhibit>> CSR.
|
|
|
[TIP]
|
[TIP]
|
For a list of all HPM-related CSRs and all provided event configurations
|
For a list of all HPM-related CSRs and all provided event configurations
|
see section <<_hardware_performance_monitors_hpm>>.
|
see section <<_hardware_performance_monitors_hpm>>.
|
|
|
|
|
==== **`Zifencei`** Instruction Stream Synchronization
|
==== **`Zifencei`** Instruction Stream Synchronization
|
|
|
The `Zifencei` CPU extension is implemented if the `CPU_EXTENSION_RISCV_Zifencei` configuration
|
The `Zifencei` CPU extension is implemented if the <<_cpu_extension_riscv_zifencei>> configuration
|
generic is _true_. It allows manual synchronization of the instruction stream via the following instruction:
|
generic is _true_. It allows manual synchronization of the instruction stream via the following instruction:
|
|
|
* `fence.i`
|
* `fence.i`
|
|
|
The `fence.i` instruction resets the CPU's front-end (instruction fetch) and flushes the prefetch buffer.
|
The `fence.i` instruction resets the CPU's front-end (instruction fetch) and flushes the prefetch buffer.
|
This allows a clean re-fetch of modified instructions from memory. Also, the top's `i_bus_fencei_o` signal is set
|
This allows a clean re-fetch of modified instructions from memory. Also, the top's `i_bus_fencei_o` signal is set
|
high for one cycle to inform the memory system (like the i-cache to perform a flush/reload.
|
high for one cycle to inform the memory system (like the i-cache to perform a flush/reload.
|
Any additional flags within the `fence.i` instruction word are ignore by the hardware.
|
Any additional flags within the `fence.i` instruction word are ignore by the hardware.
|
|
|
|
|
|
==== **`Zxcfu`** Custom Instructions Extension (CFU)
|
|
|
|
The `Zxcfu` presents a NEORV32-specific _custom RISC-V_ ISA extension (`Z` = sub-extension, `x` = platform-specific
|
|
custom extension, `cfu` = name of the custom extension). When enabled via the <<_cpu_extension_riscv_zxcfu>> configuration
|
|
generic, this ISA extensions adds the <<_custom_functions_unit_cfu>> to the CPU core. The CFU is a module that
|
|
allows to add **custom RISC-V instructions** to the processor core.
|
|
|
|
The CPU is implemented as ALU co-processor and is integrated right into the CPU's pipeline providing minimal data
|
|
transfer latency as it has direct access to the core's register file. Up to 1024 custom instructions can be
|
|
implemented within the CFU. These instructions are mapped to an OPCODE space that has been explicitly reserved by
|
|
the RISC-V spec for custom extensions.
|
|
|
|
Software can utilize the custom instructions by using _intrinsic functions_, which are inline assembly functions that
|
|
behave like "regular" C functions.
|
|
|
|
[TIP]
|
|
For more information regarding the CFU see section <<_custom_functions_unit_cfu>>.
|
|
|
|
[TIP]
|
|
The CFU / `Zxcfu` ISA extension is intended for application-specific _instructions_.
|
|
If you like to add more complex accelerators or interfaces that can also operate independently of
|
|
the CPU take a look at the memory-mapped <<_custom_functions_subsystem_cfs>>.
|
|
|
|
|
==== **`PMP`** Physical Memory Protection
|
==== **`PMP`** Physical Memory Protection
|
|
|
The NEORV32 physical memory protection (PMP) is compatible to the RISC-V PMP specifications. It can be used
|
The NEORV32 physical memory protection (PMP) is compatible to the RISC-V PMP specifications. It can be used
|
to constrain memory read/write/execute rights for each available privilege level.
|
to constrain memory read/write/execute rights for each available privilege level.
|
|
|
| Line 794... |
Line 821... |
| Bit-manipulation - shifts | `B(Zbb)` | `cpop` | 3 + 32
|
| Bit-manipulation - shifts | `B(Zbb)` | `cpop` | 3 + 32
|
| Bit-manipulation - shifts | `B(Zbb)` | `rol` `ror` `rori` | 3 + SA
|
| Bit-manipulation - shifts | `B(Zbb)` | `rol` `ror` `rori` | 3 + SA
|
| Bit-manipulation - single-bit | `B(Zbs)` | `sbset[i]` `sbclr[i]` `sbinv[i]` `sbext[i]` | 3
|
| Bit-manipulation - single-bit | `B(Zbs)` | `sbset[i]` `sbclr[i]` `sbinv[i]` `sbext[i]` | 3
|
| Bit-manipulation - shifted-add | `B(Zba)` | `sh1add` `sh2add` `sh3add` | 3
|
| Bit-manipulation - shifted-add | `B(Zba)` | `sh1add` `sh2add` `sh3add` | 3
|
| Bit-manipulation - carry-less multiply | `B(Zbc)` | `clmul` `clmulh` `clmulr` | 3 + 32
|
| Bit-manipulation - carry-less multiply | `B(Zbc)` | `clmul` `clmulh` `clmulr` | 3 + 32
|
|
| CFU: custom instructions | `Zxcfu` | - | min. 4
|
|=======================
|
|=======================
|
|
|
[NOTE]
|
[NOTE]
|
The presented values of the *floating-point execution cycles* are average values - obtained from
|
The presented values of the *floating-point execution cycles* are average values - obtained from
|
4096 instruction executions using pseudo-random input values. The execution time for emulating the
|
4096 instruction executions using pseudo-random input values. The execution time for emulating the
|
| Line 818... |
Line 846... |
|
|
* _interrupts_ = asynchronous exceptions
|
* _interrupts_ = asynchronous exceptions
|
* _exceptions_ = synchronous exceptions
|
* _exceptions_ = synchronous exceptions
|
* _traps_ = exceptions + interrupts (synchronous or asynchronous exceptions)
|
* _traps_ = exceptions + interrupts (synchronous or asynchronous exceptions)
|
|
|
Whenever an exception or interrupt is triggered, the CPU transfers control to the address stored in `mtvec`
|
Whenever an exception or interrupt is triggered, the CPU transfers control to the address stored in <<_mtvec>>
|
CSR. The cause of the according interrupt or exception can be determined via the content of `mcause`
|
CSR. The cause of the according interrupt or exception can be determined via the content of <<_mcause>>
|
CSR. The address that reflects the current program counter when a trap was taken is stored to `mepc` CSR.
|
CSR. 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 `mtval` CSR and the processor's
|
Additional information regarding the cause of the trap can be retrieved from <<_mtval>> CSR and the processor's
|
<<_internal_bus_monitor_buskeeper>> (for memory access exceptions)
|
<<_internal_bus_monitor_buskeeper>> (for memory access exceptions)
|
|
|
The traps are prioritized. If several _synchronous exceptions_ occur at once only the one with highest priority is triggered
|
The traps are prioritized. If several _synchronous exceptions_ occur at once only the one with highest priority is triggered
|
while all remaining exceptions are ignored. If several _asynchronous exceptions_ (interrupts) trigger at once, the one with highest priority
|
while all remaining exceptions are ignored. If several _asynchronous exceptions_ (interrupts) trigger at once, the one with highest priority
|
is serviced first while the remaining ones stay _pending_. After completing the interrupt handler the interrupt with
|
is serviced first while the remaining ones stay _pending_. After completing the interrupt handler the interrupt with
|
| Line 837... |
Line 865... |
until it is explicitly acknowledged by the CPU software (for example by writing to a specific memory-mapped register).
|
until it is explicitly acknowledged by the CPU software (for example by writing to a specific memory-mapped register).
|
|
|
.Interrupt Signal Requirements - Fast Interrupt Requests
|
.Interrupt Signal Requirements - Fast Interrupt Requests
|
[IMPORTANT]
|
[IMPORTANT]
|
The NEORV32-specific FIRQ request lines are triggered by a one-shot high-level (i.e. rising edge). Each request is buffered in the CPU control
|
The NEORV32-specific FIRQ request lines are triggered by a one-shot high-level (i.e. rising edge). Each request is buffered in the CPU control
|
unit until the channel is either disabled (by clearing the according `mie` CSR bit) or the request is explicitly cleared (by setting
|
unit until the channel is either disabled (by clearing the according <<_mie>> CSR bit) or the request is explicitly cleared (by setting
|
the according `mip` CSR bit).
|
the according <<_mip>> CSR bit).
|
|
|
.Instruction Atomicity
|
.Instruction Atomicity
|
[NOTE]
|
[NOTE]
|
All instructions execute as atomic operations - interrupts can only trigger _between_ two instructions.
|
All instructions execute as atomic operations - interrupts can only trigger _between_ two instructions.
|
So even if there is a permanent interrupt request, exactly one instruction from the interrupt program will be executed before
|
So even if there is a permanent interrupt request, exactly one instruction from the interrupt program will be executed before
|
| Line 860... |
Line 888... |
|
|
:sectnums:
|
:sectnums:
|
==== Custom Fast Interrupt Request Lines
|
==== Custom Fast Interrupt Request Lines
|
|
|
As a custom extension, the NEORV32 CPU features 16 fast interrupt request (FIRQ) lines via the `firq_i` CPU top
|
As a custom extension, the NEORV32 CPU features 16 fast interrupt request (FIRQ) lines via the `firq_i` CPU top
|
entity signals. These interrupts have custom configuration and status flags in the `mie` and `mip` CSRs and also
|
entity signals. These interrupts have custom configuration and status flags in the <<_mie>> and <<_mip>> CSRs and also
|
provide custom trap codes in `mcause`. These FIRQs are reserved for NEORV32 processor-internal usage only.
|
provide custom trap codes in <<_mcause>>. These FIRQs are reserved for NEORV32 processor-internal usage only.
|
|
|
|
|
|
|
|
|
// ####################################################################################################################
|
// ####################################################################################################################
|
| Line 874... |
Line 902... |
|
|
The following table shows all traps that are currently supported by the NEORV32 CPU. It also shows the prioritization
|
The following table shows all traps that are currently supported by the NEORV32 CPU. It also shows the prioritization
|
and the CSR side-effects. A more detailed description of the actual trap triggering events is provided in a further table.
|
and the CSR side-effects. A more detailed description of the actual trap triggering events is provided in a further table.
|
|
|
[NOTE]
|
[NOTE]
|
_Asynchronous exceptions_ (= interrupts) set the MSB of `mcause` while _synchronous exception_ (= "software exception")
|
_Asynchronous exceptions_ (= interrupts) set the MSB of <<_mcause>> while _synchronous exception_ (= "software exception")
|
clear the MSB.
|
clear the MSB.
|
|
|
**Table Annotations**
|
**Table Annotations**
|
|
|
The "Prio." column shows the priority of each trap. The highest priority is 1. The "`mcause`" column shows the
|
The "Prio." column shows the priority of each trap. The highest priority is 1. The "`mcause`" column shows the
|
cause ID of the according trap that is written to `mcause` CSR. The "[RISC-V]" columns show the interrupt/exception code value from the
|
cause ID of the according trap that is written to <<_mcause>> CSR. The "[RISC-V]" columns show the interrupt/exception code value from the
|
official RISC-V privileged architecture manual. The "[C]" names are defined by the NEORV32 core library (the runtime environment _RTE_) and can
|
official RISC-V privileged architecture manual. The "[C]" names are defined by the NEORV32 core library (the runtime environment _RTE_) and can
|
be used in plain C code. The "`mepc`" and "`mtval`" columns show the value written to
|
be used in plain C code. The "`mepc`" and "`mtval`" columns show the value written to
|
`mepc` and `mtval` CSRs when a trap is triggered:
|
<<_mepc>> and <<_mtval>> CSRs when a trap is triggered:
|
|
|
* _I-PC_ - address of interrupted instruction (instruction has not been execute/completed yet)
|
* _I-PC_ - address of interrupted instruction (instruction has not been execute/completed yet)
|
* _B-ADR_- bad memory access address that cause the trap
|
* _B-ADR_- bad memory access address that cause the trap
|
* _PC_ - address of instruction that caused the trap
|
* _PC_ - address of instruction that caused the trap
|
* _0_ - zero
|
* _0_ - zero
|
| Line 951... |
Line 979... |
| _TRAP_CODE_MEI_ | user-defined processor-external source (via dedicated top-entity signal)
|
| _TRAP_CODE_MEI_ | user-defined processor-external source (via dedicated top-entity signal)
|
| _TRAP_CODE_MSI_ | user-defined processor-external source (via dedicated top-entity signal)
|
| _TRAP_CODE_MSI_ | user-defined processor-external source (via dedicated top-entity signal)
|
| _TRAP_CODE_MTI_ | processor-internal machine timer overflow OR user-defined processor-external source (via dedicated top-entity signal)
|
| _TRAP_CODE_MTI_ | processor-internal machine timer overflow OR user-defined processor-external source (via dedicated top-entity signal)
|
|=======================
|
|=======================
|
|
|
.Instruction Address Misaligned Exception
|
.Misaligned Instruction Address Exception
|
[NOTE]
|
[NOTE]
|
For 32-bit-only instructions (= no `C` extension) the misaligned instruction exception
|
For 32-bit-only instructions (= no `C` extension) the misaligned instruction exception
|
is raised if bit 1 of the fetch address is set (i.e. not on a 32-bit boundary). If the `C` extension is implemented
|
is raised if bit 1 of the fetch address is set (i.e. not on a 32-bit boundary). If the `C` extension is implemented
|
there will never be a misaligned instruction exception _at all_.
|
there will never be a misaligned instruction exception _at all_.
|
In both cases bit 0 of the program counter (and all related registers) is hardwired to zero.
|
In both cases bit 0 of the program counter (and all related CSRs) is hardwired to zero.
|
|
|
|
|
|
|
// ####################################################################################################################
|
// ####################################################################################################################
|
:sectnums:
|
:sectnums:
|
==== Bus Interface
|
==== Bus Interface
|
|
|
The CPU provides two independent bus interfaces: One for fetching instructions (`i_bus_*`) and one for
|
The NEORV32 CPU implements a 32-bit machine with separated instruction and data interfaces making the CPU a
|
accessing data (`d_bus_*`) via load and store operations. Both interfaces use the same interface protocol.
|
**Harvard Architecture**: the _instruction fetch interface_ (`i_bus_*`) is used for fetching instruction and the
|
|
_data access interface_ (`d_bus_*`) is used to access data via load and store operations.
|
:sectnums:
|
Each of this interfaces can access an address space of up to 2^32^ bytes (4GB).
|
===== Address Space
|
The following table shows the signals of the data and instruction interfaces as seen from the CPU (`*_o` signals are driven
|
|
by the CPU / outputs, `*_i` signals are read by the CPU / inputs). Both interfaces use the same protocol.
|
The CPU is a 32-bit architecture with separated instruction and data interfaces making it a Harvard
|
|
Architecture. Each of this interfaces can access an address space of up to 2^32^ bytes (4GB). The memory
|
|
system is based on 32-bit words with a minimal granularity of 1 byte. Please note, that the NEORV32 CPU
|
|
does not support unaligned memory accesses _in hardware_ - however, a software-based handling can be
|
|
implemented as any unaligned memory access will trigger an according exception.
|
|
|
|
:sectnums:
|
|
===== Interface Signals
|
|
|
|
The following table shows the signals of the data and instruction interfaces seen from the CPU
|
|
(`*_o` signals are driven by the CPU / outputs, `*_i` signals are read by the CPU / inputs).
|
|
|
|
.CPU bus interface
|
.CPU bus interfaces ()
|
[cols="<2,^1,<7"]
|
[cols="<2,^1,^1,<6"]
|
[options="header",grid="rows"]
|
[options="header",grid="rows"]
|
|=======================
|
|=======================
|
| Signal | Size | Function
|
| Signal | Width | Direction | Description
|
| `bus_addr_o` | 32 | access address
|
| `i/d_bus_addr_o` | 32 | out | access address
|
| `bus_rdata_i` | 32 | data input for read operations
|
| `i/d_bus_rdata_i` | 32 | in | data input for read operations
|
| `bus_wdata_o` | 32 | data output for write operations
|
| `i/d_bus_wdata_o` | 32 | out | data output for write operations
|
| `bus_ben_o` | 4 | byte enable signal for write operations
|
| `i/d_bus_ben_o` | 4 | out | byte enable signal for write operations
|
| `bus_we_o` | 1 | bus write access
|
| `i/d_bus_we_o` | 1 | out | bus write access (always zero for instruction fetches)
|
| `bus_re_o` | 1 | bus read access
|
| `i/d_bus_re_o` | 1 | out | bus read access
|
| `bus_lock_o` | 1 | exclusive access request
|
| `i/d_bus_lock_o` | 1 | out | exclusive access request
|
| `bus_ack_i` | 1 | accessed peripheral indicates a successful completion of the bus transaction
|
| `i/d_bus_ack_i` | 1 | in | accessed peripheral indicates a successful completion of the bus transaction
|
| `bus_err_i` | 1 | accessed peripheral indicates an error during the bus transaction
|
| `i/d_bus_err_i` | 1 | in | accessed peripheral indicates an error during the bus transaction
|
| `bus_fence_o` | 1 | this signal is set for one cycle when the CPU executes a data/instruction fence operation
|
| `i/d_bus_fence_o` | 1 | out | this signal is set for one cycle when the CPU executes an instruction/data fence operation
|
| `bus_priv_o` | 2 | current CPU privilege level
|
| `i/d_bus_priv_o` | 2 | out | current CPU privilege level
|
|=======================
|
|=======================
|
|
|
|
.Pipelined Transfers
|
[NOTE]
|
[NOTE]
|
Currently, there a no pipelined or overlapping operations implemented within the same bus interface.
|
Currently, there a no pipelined or overlapping operations implemented within the same bus interface.
|
So only a single transfer request can be "on the fly" (pending) at once.
|
So only a single transfer request can be "on the fly" (pending) at once. However, this is no real drawback. The
|
|
minimal possible latency for a single access is two cycles, which equals the CPU's minimal execution latency
|
|
for a single instruction.
|
|
|
|
.Unaligned Memory Accesses
|
|
[NOTE]
|
|
Please note, that the NEORV32 CPU does not support the handling of unaligned memory accesses _in hardware_. Any
|
|
unaligned memory access will raise an exception that can can be used to handle such accesses in _software_.
|
|
|
|
|
:sectnums:
|
:sectnums:
|
===== Protocol
|
===== Protocol
|
|
|
A bus request is triggered either by the `bus_re_o` signal (for reading data) or by the `bus_we_o` signal (for
|
An actual bus request is triggered either by the `*_bus_re_o` signal (for reading data) or by the `*_bus_we_o` signal
|
writing data). These signals are active for exactly one cycle and initiate either a read or a write transaction. The transaction is
|
(for writing data). In case of a request, one of these signals is high for exactly one cycle. The transaction is
|
completed when the accessed peripheral either sets the `bus_ack_i` signal (-> successful completion) or the
|
completed when the accessed peripheral/memory either sets the `*_bus_ack_i` signal (-> successful completion) or the
|
`bus_err_i` signal is set (-> failed completion). All these control signals are only active (= high) for one
|
`*_bus_err_i` signal (-> failed completion). These bus response signal are also set only for one cycle active.
|
single cycle. An error indicated via the `bus_err_i` signal during a transfer will trigger the according instruction bus
|
An error indicated by the `*_bus_err_i` signal will raise the according "instruction bus access fault" or
|
access fault or load/store bus access fault exception.
|
"load/store bus access fault" exception.
|
|
|
[NOTE]
|
**Minimal Response Latency**
|
The transfer can be completed directly in the same cycle as it was initiated (via the `bus_re_o` or `bus_we_o`
|
|
signal) if the peripheral sets `bus_ack_i` or `bus_err_i` high for one cycle. However, in order to shorten the critical path such "asynchronous"
|
The transfer can be completed directly in the same cycle as it was initiated (via the `*_bus_re_o` or `*_bus_we_o`
|
completion should be avoided. The default processor-internal module provide exactly **one cycle delay** between initiation and completion of transfers.
|
signal) if the peripheral sets `*_bus_ack_i` or `*_bus_err_i` high for one cycle. However, in order to shorten the
|
|
critical path such "asynchronous" completion should be avoided. The default NEORV32 processor-internal modules provide
|
.Bus Keeper: Processor-internal memories and memory-mapped devices with variable / high latency
|
exactly **one cycle delay** between initiation and completion of transfers.
|
[IMPORTANT]
|
|
Processor-internal peripherals or memories do not have to respond within one cycle after the transfer initiation (= latency > 1 cycle).
|
**Maximal Response Latency**
|
However, the bus transaction has to be completed (= acknowledged) within a certain **response time window**. This time window is defined
|
|
by the global `max_proc_int_response_time_c` constant (default = 15 cycles) from the processor's VHDL package file (`rtl/neorv32_package.vhd`).
|
Processor-internal peripherals or memories do not have to respond within one cycle after a bus request has been initiated.
|
It defines the maximum number of cycles after which an _unacknowledged_ processor-internal bus transfer will timeout and raise a **bus fault exception**.
|
However, the bus transaction has to be completed (= acknowledged) within a certain **response time window**. This time window
|
The _BUSKEEPER_ hardware module (see section <<_internal_bus_monitor_buskeeper>>) keeps track of all _internal_ bus transactions. If any bus operations times out
|
is defined by the global `max_proc_int_response_time_c` constant (default = 15 cycles; processor's VHDL package file `rtl/neorv32_package.vhd`).
|
(for example when accessing "address space holes") this unit will issue a bus error to the CPU that will raise the according instruction fetch or data access bus exception.
|
It defines the maximum number of cycles after which an _unacknowledged_ (`*_bus_ack_i` or `*_bus_err_i` both not set) processor-internal bus
|
Note that **the bus keeper does not track external accesses via the external memory bus interface**. However, the external memory bus interface also provides
|
transfer will time out and raises a **bus fault exception**. The <<_internal_bus_monitor_buskeeper>> keeps track of all _internal_ bus
|
an _optional_ bus timeout (see section <<_processor_external_memory_interface_wishbone_axi4_lite>>).
|
transactions to enforce this time window.
|
|
|
|
If any bus operations times out (for example when accessing "address space holes") the BUSKEEPER will issue a bus
|
|
error to the CPU that will raise the according instruction fetch or data access bus exception.
|
|
Note that **the bus keeper does not track external accesses via the external memory bus interface**. However,
|
|
the external memory bus interface also provides an _optional_ bus timeout (see section <<_processor_external_memory_interface_wishbone_axi4_lite>>).
|
|
|
**Exemplary Bus Accesses**
|
**Exemplary Bus Accesses**
|
|
|
.Example bus accesses: see read/write access description below
|
.Example bus accesses: see read/write access description below
|
[cols="^2,^2"]
|
[cols="^2,^2"]
|
| Line 1043... |
Line 1074... |
| Read access | Write access
|
| Read access | Write access
|
|=======================
|
|=======================
|
|
|
**Write Access**
|
**Write Access**
|
|
|
For a write access, the accessed address (`bus_addr_o`), the data to be written (`bus_wdata_o`) and the byte
|
For a write access, the access address (`bus_addr_o`), the data to be written (`bus_wdata_o`) and the byte
|
enable signals (`bus_ben_o`) are set when bus_we_o goes high. These three signals are kept stable until the
|
enable signals (`bus_ben_o`) are set when bus_we_o goes high. These three signals are kept stable until the
|
transaction is completed. In the example the accessed peripheral cannot answer directly in the next
|
transaction is completed. In the example the accessed peripheral cannot answer directly in the next
|
cycle after issuing. Here, the transaction is successful and the peripheral sets the `bus_ack_i` signal several
|
cycle after issuing. Here, the transaction is successful and the peripheral sets the `bus_ack_i` signal several
|
cycles after issuing.
|
cycles after issuing.
|
|
|
| Line 1090... |
Line 1121... |
For more information regarding the SoC-level behavior and requirements of atomic operations see
|
For more information regarding the SoC-level behavior and requirements of atomic operations see
|
section <<_processor_external_memory_interface_wishbone_axi4_lite>>.
|
section <<_processor_external_memory_interface_wishbone_axi4_lite>>.
|
|
|
**Memory Barriers**
|
**Memory Barriers**
|
|
|
Whenever the CPU executes a fence instruction, the according interface signal is set high for one cycle
|
Whenever the CPU executes a _fence_ instruction, the according interface signal is set high for one cycle
|
(`d_bus_fence_o` for a _fence_ instruction; `i_bus_fence_o` for a _fencei_ instruction). It is the task of the
|
(`d_bus_fence_o` for a `fence` instruction; `i_bus_fence_o` for a `fencei` instruction). It is the task of the
|
memory system to perform the necessary operations (like a cache flush and refill).
|
memory system to perform the necessary operations (for example a cache flush and refill).
|
|
|
|
|
|
|
|
|
// ####################################################################################################################
|
// ####################################################################################################################
|
| Line 1126... |
Line 1157... |
pipeline register will get initialized by the CPU's internal state machines, which are initialized from the main
|
pipeline register will get initialized by the CPU's internal state machines, which are initialized from the main
|
control engine that actually features a defined reset. The initialization of most of the CPU's core CSRs (like
|
control engine that actually features a defined reset. The initialization of most of the CPU's core CSRs (like
|
interrupt control) is done by the software (to be more specific, this is done by the `crt0.S` start-up code).
|
interrupt control) is done by the software (to be more specific, this is done by the `crt0.S` start-up code).
|
|
|
During the very early boot process (where `crt0.S` is running) there is no chance for undefined behavior due to
|
During the very early boot process (where `crt0.S` is running) there is no chance for undefined behavior due to
|
the lack of dedicated hardware resets of certain CSRs. For example the machine interrupt-enable CSR (`mie`)
|
the lack of dedicated hardware resets of certain CSRs. For example the machine interrupt-enable CSR <<_mie>>
|
does not provide a dedicated reset. The value after reset of this register is uncritical as interrupts cannot fire
|
does not provide a dedicated reset. The value after reset of this register is uncritical as interrupts cannot fire
|
because the global interrupt enabled flag in the status register (`mstatsus(mie)`) _do_ provide a dedicated
|
because the global interrupt enabled flag in the status register (`mstatsus(mie)`) _do_ provide a dedicated
|
hardware reset setting this bit to low (globally disabling interrupts).
|
hardware reset setting this bit to low (globally disabling interrupts).
|
|
|
**Reset Configuration**
|
**Reset Configuration**
|
|
|
Most CPU-internal register do provide an asynchronous reset in the VHDL code, but the "don't care" value
|
Most CPU-internal register do provide an asynchronous reset in the VHDL code, but the "don't care" value
|
(VHDL `'-'`) is used for initialization of all uncritical registers, effectively generating a flip-flop without a
|
(VHDL `'-'`) is used for initialization of all uncritical registers, effectively generating a flip-flop without a
|
reset. However, certain applications or situations (like advanced gate-level / timing simulations) might
|
reset. However, certain applications or situations (like advanced gate-level / timing simulations) might
|
require a more deterministic reset state. For this case, a defined reset level (reset-to-low) of all CPU registers can
|
require a more deterministic reset state. For this case, a defined reset level (reset-to-low) of all CPU registers can
|
be enabled ba enabling a constant in the main VHDL package file (`rtl/core/neorv32_package.vhd`):
|
be enabled by enabling a constant in the main VHDL package file (`rtl/core/neorv32_package.vhd`):
|
|
|
[source,vhdl]
|
[source,vhdl]
|
----
|
----
|
-- "critical" number of PMP regions --
|
-- use dedicated hardware reset value for UNCRITICAL registers --
|
constant dedicated_reset_c : boolean := false; -- use dedicated hardware reset value for UNCRITICAL registers (FALSE=reset value is irrelevant (might simplify HW), default; TRUE=defined LOW reset value)
|
-- FALSE=reset value is irrelevant (might simplify HW), default; TRUE=defined LOW reset value
|
|
constant dedicated_reset_c : boolean := false;
|
----
|
----
|
|
|
|
|
|
|
|
// ####################################################################################################################
|
|
|
|
include::cpu_cfu.adoc[]
|
