mirror of
https://github.com/stnolting/neorv32.git
synced 2025-04-24 14:17:51 -04:00
[docs] minor edits and fixes
This commit is contained in:
parent
254b76b19f
commit
8f39d92bc5
3 changed files with 20 additions and 8 deletions
|
@ -1,3 +1,4 @@
|
||||||
|
:author: Stephan Nolting (M.Sc.)
|
||||||
:keywords: neorv32, risc-v, riscv, rv32, fpga, soft-core, vhdl, microcontroller, cpu, soc, processor, gcc, openocd, gdb
|
:keywords: neorv32, risc-v, riscv, rv32, fpga, soft-core, vhdl, microcontroller, cpu, soc, processor, gcc, openocd, gdb
|
||||||
:description: A size-optimized, customizable and highly extensible MCU-class 32-bit RISC-V soft-core CPU and microcontroller-like SoC written in platform-independent VHDL.
|
:description: A size-optimized, customizable and highly extensible MCU-class 32-bit RISC-V soft-core CPU and microcontroller-like SoC written in platform-independent VHDL.
|
||||||
:revnumber: v1.7.9
|
:revnumber: v1.7.9
|
||||||
|
|
|
@ -105,10 +105,10 @@ micro-operations. In order to increase performance, the CPU's front-end (instruc
|
||||||
(instruction execution) are de-couples via a FIFO. Therefore, the front-end can already fetch new instructions while
|
(instruction execution) are de-couples via a FIFO. Therefore, the front-end can already fetch new instructions while
|
||||||
the back-end is still processing the previously-fetched instruction.
|
the back-end is still processing the previously-fetched instruction.
|
||||||
|
|
||||||
Basically, the NEORV32 CPU is somewhere between a classical pipelined architecture, where each stage
|
Basically, the CPU's micro architecture is somewhere between a classical pipelined architecture, where each stage
|
||||||
requires exactly one processing cycle (if not stalled) and a classical multi-cycle architecture, which executes
|
requires exactly one processing cycle (if not stalled) and a classical multi-cycle architecture, which executes
|
||||||
every single instruction (_including_ fetch) in a series of consecutive micro-operations. The combination of
|
every single instruction (_including_ fetch) in a series of consecutive micro-operations. The combination of
|
||||||
these two classical design paradigms allows an increased instruction execution in contrast to a pure multi-cycle
|
these two design paradigms allows an increased instruction execution in contrast to a pure multi-cycle
|
||||||
approach (due to overlapping operation of fetch and execute) at a reduced hardware footprint (due to the
|
approach (due to overlapping operation of fetch and execute) at a reduced hardware footprint (due to the
|
||||||
multi-cycle concept).
|
multi-cycle concept).
|
||||||
|
|
||||||
|
@ -117,6 +117,10 @@ these two bus interfaces are merged into a single processor-internal bus via a p
|
||||||
have higher priority). Hence, _all_ memory addresses including peripheral devices are mapped to a single unified 32-bit
|
have higher priority). Hence, _all_ memory addresses including peripheral devices are mapped to a single unified 32-bit
|
||||||
address space.
|
address space.
|
||||||
|
|
||||||
|
[NOTE]
|
||||||
|
The CPU does not perform any out-of-order operations. Hence, it is not vulnerable to security issues
|
||||||
|
caused by speculative execution (e.g. Spectre an Meltdown).
|
||||||
|
|
||||||
|
|
||||||
:sectnums:
|
:sectnums:
|
||||||
==== CPU Register File
|
==== CPU Register File
|
||||||
|
@ -175,18 +179,20 @@ The control unit is based on several modules (also called "engines").
|
||||||
|
|
||||||
**Front-End**
|
**Front-End**
|
||||||
|
|
||||||
The front-end is responsible for fetching instruction data in chunks of 32-bits. This can be one aligned 32-bit instruction,
|
The front-end is responsible for fetching instruction data in chunks of 32-bits. This can be a single aligned 32-bit instruction,
|
||||||
two aligned 16-bit instructions or a mixture if 32-bit instructions are not aligned to 32-bit boundaries. The instruction
|
two aligned 16-bit instructions or a mixture of those. The instruction data including control and exception information is stored
|
||||||
data including control and exception information is stored to a FIFO queue - the instruction prefetch buffer (IPB). The depth
|
to a FIFO queue - the instruction prefetch buffer (IPB). The depth of this FIFO can be configured by the <<_cpu_ipb_entries>> top
|
||||||
of this FIFO can be configured by the <<_cpu_ipb_entries>> top generic.
|
generic.
|
||||||
|
|
||||||
The FIFO allows the front-end to do "speculative" instruction fetches, as it keeps fetching the next consecutive instruction
|
The FIFO allows the front-end to do "speculative" instruction fetches, as it keeps fetching the next consecutive instruction
|
||||||
all the time. This also allows to decouple front-end (instruction fetch) and back-end (instruction execution) so both modules
|
all the time. This also allows to decouple front-end (instruction fetch) and back-end (instruction execution) so both modules
|
||||||
can operate in parallel to increase performance.
|
can operate in parallel to increase performance. However, all potential side effects that are caused by this "speculative"
|
||||||
|
instruction fetch are already handled by the CPU front-end ensuring a defined execution stage while preventing security
|
||||||
|
side attacks (like Spectre and Meltdown).
|
||||||
|
|
||||||
.Branch Prediction
|
.Branch Prediction
|
||||||
[NOTE]
|
[NOTE]
|
||||||
The front-end implements a very simple branch prediction (predict = always taken) that stops fetching further instruction while
|
The front-end implements a very simple branch prediction (predict = always taken) that **stops** fetching further instruction while
|
||||||
a branch/jump/call operation is in progress.
|
a branch/jump/call operation is in progress.
|
||||||
|
|
||||||
|
|
||||||
|
|
|
@ -539,6 +539,11 @@ The two MSBs of each `pmpaddr` are hardwired to zero (= bits 33:32 of the physic
|
||||||
[NOTE]
|
[NOTE]
|
||||||
When implemented (by enabling the `Zicntr` ISA extension) the standard CPU counters are always 64-bit wide (low-word + high-word).
|
When implemented (by enabling the `Zicntr` ISA extension) the standard CPU counters are always 64-bit wide (low-word + high-word).
|
||||||
|
|
||||||
|
.Instruction Retired Counter Increment
|
||||||
|
[NOTE]
|
||||||
|
The `[m]instret[h]` counter always increments when a instruction enters the pipeline's execute stage no matter
|
||||||
|
if this instruction is meant to retire or if it causes an exception.
|
||||||
|
|
||||||
|
|
||||||
:sectnums!:
|
:sectnums!:
|
||||||
===== **`cycle[h]`**
|
===== **`cycle[h]`**
|
||||||
|
|
Loading…
Add table
Add a link
Reference in a new issue