| Line 11... |
Line 11... |
|
|
1. Download and _build_ the official RISC-V GNU toolchain yourself
|
1. Download and _build_ the official RISC-V GNU toolchain yourself
|
2. Download and install a prebuilt version of the toolchain; this might also done via the package manager / app store of your OS
|
2. Download and install a prebuilt version of the toolchain; this might also done via the package manager / app store of your OS
|
|
|
[TIP]
|
[TIP]
|
The default toolchain prefix for this project is **`riscv32-unknown-elf`**. Of course you can use any other RISC-V
|
The default toolchain prefix for this project is **`riscv32-unknown-elf-`**. Of course you can use any other RISC-V
|
toolchain (like `riscv64-unknown-elf`) that is capable to emit code for a `rv32` architecture. Just change the _RISCV_TOOLCHAIN_ variable in the application
|
toolchain (like `riscv64-unknown-elf-`) that is capable to emit code for a `rv32` architecture. Just change the _RISCV_PREFIX_ variable in the application
|
makefile(s) according to your needs or define this variable when invoking the makefile.
|
makefile(s) according to your needs or define this variable when invoking the makefile.
|
|
|
[IMPORTANT]
|
[IMPORTANT]
|
Keep in mind that – for instance – a rv32imc toolchain only provides library code compiled with
|
Keep in mind that – for instance – a rv32imc toolchain only provides library code compiled with
|
compressed (_C_) and `mul`/`div` instructions (_M_)! Hence, this code cannot be executed (without
|
compressed (_C_) and `mul`/`div` instructions (_M_)! Hence, this code cannot be executed (without
|
| Line 569... |
Line 569... |
----
|
----
|
<1> MARCH = Machine architecture ("ISA string")
|
<1> MARCH = Machine architecture ("ISA string")
|
<2> MABI = Machine binary interface
|
<2> MABI = Machine binary interface
|
|
|
For example, if you enable the RISC-V `C` extension (16-bit compressed instructions) via the `CPU_EXTENSION_RISCV_C`
|
For example, if you enable the RISC-V `C` extension (16-bit compressed instructions) via the `CPU_EXTENSION_RISCV_C`
|
generic (set `true`) you need to add the 'c' extension also to the `MARCH` ISA string in order to make the compiler
|
generic (set `true`) you need to add the `c` extension also to the `MARCH` ISA string in order to make the compiler
|
emit compressed instructions.
|
emit compressed instructions.
|
|
|
|
.Privileged Architecture Extensions
|
|
[IMPORTANT]
|
|
Privileged architecture extensions like `Zicsr` or `Zifencei` are "used" _implicitly_ by the compiler. Hence, according
|
|
instruction will only be generated when "encoded" via inline assembly or when linking according libraries. In this case,
|
|
these instruction will _always_ be emitted (even if the according extension is not specified in `MARCH`). +
|
|
**I recommend to _not_ specify any privileged architecture extensions in `MARCH`.**
|
|
|
[WARNING]
|
[WARNING]
|
ISA extension enabled in hardware can be a superset of the extensions enabled in software, but not the other way
|
ISA extension enabled in hardware can be a superset of the extensions enabled in software, but not the other way
|
around. For example generating compressed instructions for a CPU configuration that has the `c` extension disabled
|
around. For example generating compressed instructions for a CPU configuration that has the `c` extension disabled
|
will cause _illegal instruction exceptions_ at runtime.
|
will cause _illegal instruction exceptions_ at runtime.
|
|
|
| Line 585... |
Line 592... |
----
|
----
|
$ make MARCH=-march=rv32ic clean_all all
|
$ make MARCH=-march=rv32ic clean_all all
|
----
|
----
|
|
|
[NOTE]
|
[NOTE]
|
The RISC-V ISA string (for _MARCH_) follows a certain _canonical_ structure:
|
The RISC-V ISA string for `MARCH` follows a certain _canonical_ structure:
|
`rev32[i/e][m][a][f][d][g][q][c][b][v][n]...` For example `rv32imac` is valid while `rv32icma` is not valid.
|
`rev32[i/e][m][a][f][d][g][q][c][b][v][n]...` For example `rv32imac` is valid while `rv32icma` is not.
|
|
|
|
|
|
|
|
|
// ####################################################################################################################
|
// ####################################################################################################################
|
| Line 784... |
Line 791... |
|
|
// ####################################################################################################################
|
// ####################################################################################################################
|
:sectnums:
|
:sectnums:
|
== Packaging the Processor as IP block for Xilinx Vivado Block Designer
|
== Packaging the Processor as IP block for Xilinx Vivado Block Designer
|
|
|
.WORK IN PROGRESS
|
[start=1]
|
[WARNING]
|
. Import all the core files from `rtl/core` and assign them to a _new_ design library `neorv32`.
|
This Section Is Under Construction! +
|
. Instantiate the `rtl/wrappers/neorv32_top_axi4lite.vhd` module.
|
+
|
. Then either directly use that module in a new block-design ("Create Block Design", right-click -> "Add Module",
|
FIXME!
|
thats easier for a first try) or package it ("Tools", "Create and Package new IP") for the use in other projects.
|
|
. Connect your AXI-peripheral directly to the core's AXI4-Interface if you only have one, or to an AXI-Interconnect
|
|
(from the IP-catalog) if you have multiple peripherals.
|
|
. Connect ALL the `ACLK` and `ARESETN` pins of all peripherals and interconnects to the processor's clock and reset
|
|
signals to have a _unified_ clock and reset domain (easier for a first setup).
|
|
. Open the "Address Editor" tab and let Vivado assign the base-addresses for the AXI-peripherals (you can modify them
|
|
according to your needs).
|
|
. For all FPGA-external signals (like UART signals) make all the connections you need "external"
|
|
(right-click on the signal/pin -> "Make External").
|
|
. Save everything, let VIVADO create a HDL-Wrapper for the block-design and choose this as your _Top Level Design_.
|
|
. Define your constraints and generate your bitstream.
|
|
|
|
[NOTE]
|
|
Guide provided by GitHub user https://github.com/AWenzel83[`AWenzel83`] from
|
|
https://github.com/stnolting/neorv32/discussions/52#discussioncomment-819013
|
|
|
|
|
|
|
|
|
// ####################################################################################################################
|
// ####################################################################################################################
|
| Line 915... |
Line 936... |
== Building the Documentation
|
== Building the Documentation
|
|
|
The documentation (datasheet + user guide) is written using `asciidoc`. The according source files
|
The documentation (datasheet + user guide) is written using `asciidoc`. The according source files
|
can be found in `docs/...`. The documentation of the software framework is written _in-code_ using `doxygen`.
|
can be found in `docs/...`. The documentation of the software framework is written _in-code_ using `doxygen`.
|
|
|
A makefiles in the project's root directory is provided to build all of the documentation as HTML pages
|
A makefiles in the project's `docs` directory is provided to build all of the documentation as HTML pages
|
or as PDF documents.
|
or as PDF documents.
|
|
|
[TIP]
|
[TIP]
|
Pre-rendered PDFs are available online as _nightly pre-releases_: https://github.com/stnolting/neorv32/releases.
|
Pre-rendered PDFs are available online as _nightly pre-releases_: https://github.com/stnolting/neorv32/releases.
|
The HTML-based documentation is also available online at the project's https://stnolting.github.io/neorv32/[GitHub Pages].
|
The HTML-based documentation is also available online at the project's https://stnolting.github.io/neorv32/[GitHub Pages].
|
|
|
The makefile provides a help target to show all available build options and their according outputs.
|
The makefile provides a help target to show all available build options and their according outputs.
|
|
|
[source,bash]
|
[source,bash]
|
----
|
----
|
neorv32$ make help
|
neorv32/docs$ make help
|
----
|
----
|
|
|
.Example: Generate HTML documentation (data sheet) using `asciidoctor`
|
.Example: Generate HTML documentation (data sheet) using `asciidoctor`
|
[source,bash]
|
[source,bash]
|
----
|
----
|
neorv32$ make html
|
neorv32/docs$ make html
|
----
|
----
|
|
|
[TIP]
|
[TIP]
|
If you don't have `asciidoctor` / `asciidoctor-pdf` installed, you can still generate all the documentation using
|
If you don't have `asciidoctor` / `asciidoctor-pdf` installed, you can still generate all the documentation using
|
a _docker container_ via `make container`.
|
a _docker container_ via `make container`.
|
| Line 960... |
Line 981... |
|
|
The NEORV32 Processor passes the according tests provided by the official RISC-V Architecture Test Suite
|
The NEORV32 Processor passes the according tests provided by the official RISC-V Architecture Test Suite
|
(V2.0+), which is available online at GitHub: https://github.com/riscv/riscv-arch-test
|
(V2.0+), which is available online at GitHub: https://github.com/riscv/riscv-arch-test
|
|
|
All files required for executing the test framework on a simulated instance of the processor (including port
|
All files required for executing the test framework on a simulated instance of the processor (including port
|
files) are located in the `riscv-arch-test` folder in the root directory of the NEORV32 repository. Take a
|
files) are located in the `sw/isa-test` folder of the NEORV32 repository. The test framework is executed via the
|
look at the provided `riscv-arch-test/README.md` (https://github.com/stnolting/neorv32/blob/master/riscv-arch-test/README.md[online at GitHub])
|
`sim/run_riscv_arch_test.sh` script. Take a look at the provided `sim/README.md`
|
|
(https://github.com/stnolting/neorv32/tree/master/sim[online at GitHub])
|
file for more information on how to run the tests and how testing is conducted in detail.
|
file for more information on how to run the tests and how testing is conducted in detail.
|
|
|
|
|
|
|
|
|
