github-mirrors/neorv32
1
0
Fork 0
mirror of https://github.com/stnolting/neorv32.git synced 2025-04-24 22:27:21 -04:00
Code Issues Projects Releases Packages Wiki Activity Actions

[docs] typo fixes

Browse source
This commit is contained in:
stnolting 2021-10-21 07:35:43 +02:00
parent 3cbf78056a
commit c2f8bab4f7
13 changed files with 32 additions and 34 deletions
Download patch file Download diff file Expand all files Collapse all files

10
README.md
View file

@ -254,11 +254,11 @@ Compiler flags: default, see makefile; optimization -O3
Results generated for hardware version [`1.5.7.10`](https://github.com/stnolting/neorv32/blob/master/CHANGELOG.md).
| CPU Configuration | CoreMark Score | CoreMarks/MHz | Average CPI |
|:-----------------------------------------------|:--------------:|:-------------:|:-----------:|
| _small_ (`rv32i_Zicsr`) | 33.89 | **0.3389** | **4.04** |
| _medium_ (`rv32imc_Zicsr`) | 62.50 | **0.6250** | **5.34** |
| _performance_(`rv32imc_Zicsr` + perf. options) | 95.23 | **0.9523** | **3.54** |
| CPU Configuration | CoreMark Score | CoreMarks/MHz | Average CPI |
|:------------------------------------------------|:--------------:|:-------------:|:-----------:|
| _small_ (`rv32i_Zicsr`) | 33.89 | **0.3389** | **4.04** |
| _medium_ (`rv32imc_Zicsr`) | 62.50 | **0.6250** | **5.34** |
| _performance_ (`rv32imc_Zicsr` + perf. options) | 95.23 | **0.9523** | **3.54** |
:information_source: More information regarding the CPU performance can be found in the
[online documentation - _"CPU Performance"_](https://stnolting.github.io/neorv32/#_cpu_performance).

2
docs/datasheet/cpu.adoc
View file

@ -1049,7 +1049,7 @@ after power-up is not relevant for a defined CPU boot process.
A good example to illustrate the concept of uncritical registers is a pipelined processing engine. Each stage
of the engine features an N-bit _data register_ and a 1-bit _status register_. The status register is set when the
data in the according data register is valid. At the end of the pipeline the status register might trigger a writeback
data in the according data register is valid. At the end of the pipeline the status register might trigger a write-back
of the processing result to some kind of memory. The initial status of the data registers after power-up is
irrelevant as long as the status registers are all reset to a defined value that indicates there is no valid data in
the pipeline’s data register. Therefore, the pipeline data register do no require a dedicated reset as they do not

2
docs/datasheet/cpu_csr.adoc
View file

@ -447,7 +447,7 @@ The NEORV32 `mtval` CSR is read-only. However, a write access will _NOT_ raise a
3+| Reset value: _0x00000000_
3+| The `mip` CSR is compatible to the RISC-V specifications and also provides custom extensions. It shows currently _pending_ interrupts.
Since this register is read-only, pending interrupts of processor-internal modules can only be cleared by acknowledging the interrupt-causing
device. However, pending interrupts can be ignored by clearing the accordind <<_mie>> register bits.
device. However, pending interrupts can be ignored by clearing the according <<_mie>> register bits.
The following CSR bits are implemented (all remaining bits are always zero and are read-only).
|======

2
docs/datasheet/on_chip_debugger.adoc
View file

@ -358,7 +358,7 @@ hart's GPRs (abstract command register index `0x1000` - `0x101f`).
| 31:24 | `cmdtype` | -/w | `00000000` to indicate "access register" command
| 23 | _reserved_ | -/w | reserved, has to be `0` when writing
| 22:20 | `aarsize` | -/w | `010` to indicate 32-bit accesses
| 21 | `aarpostincrement` | -/w | `0`, postincrement is not supported
| 21 | `aarpostincrement` | -/w | `0`, post-increment is not supported
| 18 | `postexec` | -/w | if set the program buffer is executed _after_ the command
| 17 | `transfer` | -/w | if set the operation in `write` is conducted
| 16 | `write` | -/w | `1`: copy `data0` to `[regno]`; `0` copy `[regno]` to `data0`

19
docs/datasheet/overview.adoc
View file

@ -148,12 +148,11 @@ For more in-depth details regarding the feature provided by he hardware see the
neorv32 - Project home folder
│
├docs - Project documentation
│├datasheet - .adoc sources for NEORV32 data sheet
│├doxygen_build - Software framework documentation (generated by doxygen)
│├datasheet - AsciiDoc sources for the NEORV32 data sheet
│├figures - Figures and logos
│├icons - Misc. symbols
│├references - Data sheets and RISC-V specs.
│└src_adoc - AsciiDoc sources for this document
│└userguide - AsciiDoc sources for the NEORV32 user guide
│
├rtl - VHDL sources
│├core - Core sources of the CPU & SoC
@ -168,14 +167,14 @@ neorv32 - Project home folder
├sim - Simulation files (see User Guide)
│
└sw - Software framework
├bootloader - Sources and scripts for the NEORV32 internal bootloader
├common - Linker script and crt0.S start-up code
├bootloader - Sources of the processor-internal bootloader
├common - Linker script, crt0.S start-up code and central makefile
├example - Various example programs
│└...
├isa-test
│├riscv-arch-test - RISC-V spec. compatibility test framework (submodule)
│└port-neorv32 - Port files for the official RISC-V architecture tests
├ocd_firmware - source code for on-chip debugger's "park loop"
├ocd_firmware - Source code for on-chip debugger's "park loop"
├openocd - OpenOCD on-chip debugger configuration files
├image_gen - Helper program to generate NEORV32 executables
└lib - Processor core library
@ -372,10 +371,10 @@ defined as CoreMark score divided by the CPU's clock frequency in MHz.
[cols="<4,^1,^1,^1"]
[options="header",grid="rows"]
|=======================
| CPU | CoreMark Score | CoreMarks/Mhz | Average CPI
| _small_ (`rv32i_Zicsr`) | 33.89 | **0.3389** | **4.04**
| _medium_ (`rv32imc_Zicsr`) | 62.50 | **0.6250** | **5.34**
| _performance_(`rv32imc_Zicsr` + perf. options) | 95.23 | **0.9523** | **3.54**
| CPU | CoreMark Score | CoreMarks/MHz | Average CPI
| _small_ (`rv32i_Zicsr`) | 33.89 | **0.3389** | **4.04**
| _medium_ (`rv32imc_Zicsr`) | 62.50 | **0.6250** | **5.34**
| _performance_ (`rv32imc_Zicsr` + perf. options) | 95.23 | **0.9523** | **3.54**
|=======================
[NOTE]

7
docs/datasheet/soc.adoc
View file

@ -1017,7 +1017,7 @@ specifications. However, bare-metal system can also repurpose these interrupts.
.Trigger type
[IMPORTANT]
The fast interrupt request channel trigger on **high-level** and have to stay asserted until explicitly acknowledged
by the software (for example by writing to a specifc memory-mapped register). Hence, pending interrupts remain pending
by the software (for example by writing to a specific memory-mapped register). Hence, pending interrupts remain pending
as long as the interrupt-causing device's state fulfills it's interrupt condition(s).
@ -1076,7 +1076,7 @@ the according FIRQ priority; 0 = highest, 15 = lowest):
.Trigger type
[IMPORTANT]
The fast interrupt request channel trigger on **high-level** and have to stay asserted until explicitly acknowledged
by the software (for example by writing to a specifc memory-mapped register). Hence, pending interrupts remain pending
by the software (for example by writing to a specific memory-mapped register). Hence, pending interrupts remain pending
as long as the interrupt-causing device's state fulfills it's interrupt condition(s).
@ -1387,8 +1387,7 @@ application start-up code `crt0.S`.
Most peripheral/IO devices provide some kind of interrupt (for example to signal available incoming data). These
interrupts are entirely mapped to the CPU's <<_custom_fast_interrupt_request_lines>>. Note that all these
interrupt lines are triggered by a "one-shot" signal (hich for exactly one cycle) and _do not_ require any
explicit acknowledgment.
interrupt lines are high-active and are permanently triggered until the IRQ-causing condition is resolved.
**Nomenclature for the Peripheral / IO Devices Listing**

2
docs/datasheet/soc_imem.adoc
View file

@ -11,7 +11,7 @@
| Top entity port: | none |
| Configuration generics: | _MEM_INT_IMEM_EN_ | implement processor-internal IMEM when _true_
| | _MEM_INT_IMEM_SIZE_ | IMEM size in bytes
| | _INT_BOOTLOADER_EN_ | use internal bootlodaer when _true_ (implements IMEM as _uninitialized_ RAM)
| | _INT_BOOTLOADER_EN_ | use internal bootloader when _true_ (implements IMEM as _uninitialized_ RAM)
| CPU interrupts: | none |
|=======================

2
docs/datasheet/soc_pwm.adoc
View file

@ -43,7 +43,7 @@ _**Intensity~x~**_ = `DUTY[y](i*8+7 downto i*8)` / (2^8^)
The base frequency of the generated PWM signals is defined by the PWM core clock. This clock is derived
from the main processor clock and divided by a prescaler via the 3-bit PWM_CTRL_PRSCx in the unit's control
register. The following prescalers are available:
register. The following pre-scalers are available:
.PWM prescaler configuration
[cols="<4,^1,^1,^1,^1,^1,^1,^1,^1"]

2
docs/datasheet/soc_twi.adoc
View file

@ -72,7 +72,7 @@ _**f~SCL~**_ = _f~main~[Hz]_ / (4 * `clock_prescaler`)
**Interrupt**
The TWI module provides a single interrupt to singal _idle state_ (= read for new transmission) to the CPU. Whenever TWI SPI module
The TWI module provides a single interrupt to signal _idle state_ (= read for new transmission) to the CPU. Whenever TWI SPI module
is currently idle (and enabled), the interrupt request is active. A pending interrupt request is cleared
by triggering a new TWI transmission or by disabling the device.

4
docs/datasheet/soc_uart.adoc
View file

@ -38,7 +38,7 @@ framework (including the bootloader and the runtime environment) use the primary
**Theory of Operation**
UART0 is enabled by setting the _UART_CTRL_EN_ bit in the UART0 control register `CTRL`. The Baudrate
UART0 is enabled by setting the _UART_CTRL_EN_ bit in the UART0 control register `CTRL`. The Baud rate
is configured via a 12-bit _UART_CTRL_BAUDxx_ baud prescaler (`baud_prsc`) and a 3-bit _UART_CTRL_PRSCx_
clock prescaler (`clock_prescaler`) that scales the processor's primary clock (_f~main~_).
@ -50,7 +50,7 @@ clock prescaler (`clock_prescaler`) that scales the processor's primary clock (_
| Resulting `clock_prescaler` | 2 | 4 | 8 | 64 | 128 | 1024 | 2048 | 4096
|=======================
_**Baudrate**_ = (_f~main~[Hz]_ / `clock_prescaler`) / (`baud_prsc` + 1)
_**Baud rate**_ = (_f~main~[Hz]_ / `clock_prescaler`) / (`baud_prsc` + 1)
A new transmission is started by writing the data byte to be send to the lowest byte of the `DATA` register. The
transfer is completed when the _UART_CTRL_TX_BUSY_ control register flag returns to zero. A new received byte

2
docs/datasheet/soc_wdt.adoc
View file

@ -39,7 +39,7 @@ _WDT_CTRL_CLK_SELx_ prescaler:
Whenever the internal timer overflows the watchdog executes one of two possible actions: Either a hard
processor reset is triggered or an interrupt is requested at CPU's fast interrupt channel #0. The
WDT_CTRL_MODE bit definess the action to be taken on an overflow: When cleared, the Watchdog will assert an
WDT_CTRL_MODE bit defines the action to be taken on an overflow: When cleared, the Watchdog will assert an
IRQ, when set the WDT will cause a system reset. The configured action can also be triggered manually at
any time by setting the _WDT_CTRL_FORCE_ bit. The watchdog is reset by setting the _WDT_CTRL_RESET_ bit.

4
docs/datasheet/software.adoc
View file

@ -204,7 +204,7 @@ The following default compiler flags are used for compiling an application. Thes
| `-lm` | Include/link with `math.h`.
| `-lc` | Search for the standard C library when linking.
| `-lgcc` | Make sure we have no unresolved references to internal GCC library subroutines.
| `-mno-fdiv` | Use builtin software functions for floating-point divisions and square roots (since the according instructions are not supported yet).
| `-mno-fdiv` | Use built-in software functions for floating-point divisions and square roots (since the according instructions are not supported yet).
| `-falign-functions=4` .4+| Force a 32-bit alignment of functions and labels (branch/jump/call targets). This increases performance as it simplifies instruction fetch when using the C extension. As a drawback this will also slightly increase the program code.
| `-falign-labels=4`
| `-falign-loops=4`
@ -580,7 +580,7 @@ handlers.
After the initial setup of the RTE, each entry in the trap handler's look-up table is initialized with a debug
handler, that outputs detailed hardware information via the **primary UART (UART0)** when triggered. This
is intended as a fall-back for debugging or for accidentally-triggered exceptions/interrupts.
For instance, an illegal instruction exception catched by the RTE debug handler might look like this in the UART0 output:
For instance, an illegal instruction exception caught by the RTE debug handler might look like this in the UART0 output:
[source]
----

8
docs/userguide/content.adoc
View file

@ -272,7 +272,7 @@ you can advance to one of these chapters to learn how to get a software executab
To allow executables to be _actually executed_ on the NEORV32 Processor the configuration of the software framework
has to be aware to the hardware configuration. This guide focuses on the memory configuration. To enabled
certain CPU ISA festures refer to the <<_enabling_risc_v_cpu_extensions>> section.
certain CPU ISA features refer to the <<_enabling_risc_v_cpu_extensions>> section.
[TIP]
If you have **not** changed the _default_ memory configuration in section <<_general_hardware_setup>>
@ -335,7 +335,7 @@ neorv32/sw/example/blink_led$ make clean_all exe
----
[start=3]
. We are using the `clean_all` taret to make sure everything is re-build.
. We are using the `clean_all` target to make sure everything is re-build.
. This will compile and link the application sources together with all the included libraries. At the end,
your application is transformed into an ELF file (`main.elf`). The _NEORV32 image generator_ (in `sw/image_gen`)
takes this file and creates a final executable. The makefile will show the resulting memory utilization and
@ -569,7 +569,7 @@ NEORV32 PROCESSOR CONFIG NOTE: Implementing processor-internal IMEM as ROM (3176
. The easiest way of creating a _new_ software application project is to copy an _existing_ one. This will keep all
file dependencies. For example you can copy `sw/example/blink_led` to `sw/example/flux_capacitor`.
. If you want to place you application somewhere outside `sw/example` you need to adapt the application's makefile.
In the makefile you will find a variable that keeps the relative or absolute path to the NEORV32 repo home
In the makefile you will find a variable that keeps the relative or absolute path to the NEORV32 repository home
folder. Just modify this variable according to your new project's home location:
[source,makefile]
@ -1258,7 +1258,7 @@ for abstracting away bit-toggling when verifying standard interfaces such as Wis
Testbench sources in `sim` (such as `sim/neorv32_tb.vhd` and `sim/uart_rx*.vhd`) use VUnit's VHDL libraries for testing
NEORV32 and peripherals.
The entrypoint for executing the tests is `sim/run.py`.
The entry-point for executing the tests is `sim/run.py`.
[source, bash]
----