Subversion Repositories neorv32

[source,bash]

[source,bash]

----

----

neorv32/sw/example/blink_led$ make check

neorv32/sw/example/blink_led$ make check

----

----

Everything is working fine if `Toolchain check OK` appears at the end.

Everything is working fine if `Toolchain check OK` appears at the end.

:sectnums:

:sectnums:

== General Software Framework Setup

== General Software Framework Setup

To allow executables to be _actually executed_ on the NEORV32 Processor the configuration of the software framework

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

has to be aware to the hardware configuration. This guide focuses on the memory configuration. To enabled

[TIP]

[TIP]

If you have **not** changed the _default_ memory configuration in section <<_general_hardware_setup>>

If you have **not** changed the _default_ memory configuration in section <<_general_hardware_setup>>

you are already done and you can skip the rest of this guide.

you are already done and you can skip the rest of this guide.

----

----

neorv32/sw/example/blink_led$ make clean_all exe

neorv32/sw/example/blink_led$ make clean_all exe

----

----

[start=3]

[start=3]

. This will compile and link the application sources together with all the included libraries. At the end,

. 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`)

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

takes this file and creates a final executable. The makefile will show the resulting memory utilization and

the executable size:

the executable size:

[start=1]

[start=1]

. The easiest way of creating a _new_ software application project is to copy an _existing_ one. This will keep all

. 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`.

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.

. If you want to place you application somewhere outside `sw/example` you need to adapt the application's makefile.

folder. Just modify this variable according to your new project's home location:

folder. Just modify this variable according to your new project's home location:

[source,makefile]

[source,makefile]

----

----

# Relative or absolute path to the NEORV32 home folder (use default if not set by user)

# Relative or absolute path to the NEORV32 home folder (use default if not set by user)

allow more CPU-independent operation.

allow more CPU-independent operation.

=== Custom Functions Subsystem

=== Custom Functions Subsystem

registers that can be used to communicate with any arbitrary custom design logic. The intentions of this

registers that can be used to communicate with any arbitrary custom design logic. The intentions of this

subsystem is to provide a simple base, where the user can concentrate on implementing the actual design logic

subsystem is to provide a simple base, where the user can concentrate on implementing the actual design logic

rather than taking care of the communication between the CPU/software and the design logic. The interface

rather than taking care of the communication between the CPU/software and the design logic. The interface

registers are already allocated within the processor's address space and are supported by the software framework

registers are already allocated within the processor's address space and are supported by the software framework

via low-level hardware access mechanisms. Additionally, the CFS provides a direct pre-defined interrupt channel to

via low-level hardware access mechanisms. Additionally, the CFS provides a direct pre-defined interrupt channel to

// ####################################################################################################################

// ####################################################################################################################

The http://vunit.github.io/verification_components/user_guide.html[Verification Component Library] uses those features

The http://vunit.github.io/verification_components/user_guide.html[Verification Component Library] uses those features

for abstracting away bit-toggling when verifying standard interfaces such as Wishbone, AXI, Avalon, UARTs, etc.

for abstracting away bit-toggling when verifying standard interfaces such as Wishbone, AXI, Avalon, UARTs, etc.

Testbench sources in `sim` (such as `sim/neorv32_tb.vhd` and `sim/uart_rx*.vhd`) use VUnit's VHDL libraries for testing

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.

NEORV32 and peripherals.

[source, bash]

[source, bash]

----

----

# ./sim/run.py -l

# ./sim/run.py -l

neorv32.neorv32_tb.all

neorv32.neorv32_tb.all