| Line 2... |
Line 2... |
:sectnums:
|
:sectnums:
|
== Adding Custom Hardware Modules
|
== Adding Custom Hardware Modules
|
|
|
In resemblance to the RISC-V ISA, the NEORV32 processor was designed to ease customization and _extensibility_.
|
In resemblance to the RISC-V ISA, the NEORV32 processor was designed to ease customization and _extensibility_.
|
The processor provides several predefined options to add application-specific custom hardware modules and accelerators.
|
The processor provides several predefined options to add application-specific custom hardware modules and accelerators.
|
|
A <<_comparative_summary>> is given at the end of this section.
|
|
|
|
|
|
.Debugging/Testing Custom Hardware Modules
|
|
[TIP]
|
|
Custom hardware IP modules connected via the external bus interface or integrated as CFU can be debugged "in-system" using the
|
|
"bus explorer" example program (`sw/example_bus_explorer`). This program provides an interactive console (via UART0)
|
|
that allows to perform arbitrary read and write access from/to any memory-mapped register.
|
|
|
|
|
=== Standard (_External_) Interfaces
|
=== Standard (_External_) Interfaces
|
|
|
The processor already provides a set of standard interfaces that are intended to connect _chip-external_ devices.
|
The processor already provides a set of standard interfaces that are intended to connect _chip-external_ devices.
|
| Line 13... |
Line 21... |
https://stnolting.github.io/neorv32/#_general_purpose_input_and_output_port_gpio[GPIO],
|
https://stnolting.github.io/neorv32/#_general_purpose_input_and_output_port_gpio[GPIO],
|
https://stnolting.github.io/neorv32/#_primary_universal_asynchronous_receiver_and_transmitter_uart0[UART],
|
https://stnolting.github.io/neorv32/#_primary_universal_asynchronous_receiver_and_transmitter_uart0[UART],
|
https://stnolting.github.io/neorv32/#_serial_peripheral_interface_controller_spi[SPI] and
|
https://stnolting.github.io/neorv32/#_serial_peripheral_interface_controller_spi[SPI] and
|
https://stnolting.github.io/neorv32/#_two_wire_serial_interface_controller_twi[TWI].
|
https://stnolting.github.io/neorv32/#_two_wire_serial_interface_controller_twi[TWI].
|
|
|
The SPI and (especially) the GPIO interfaces might be the most straightforward approaches since they
|
The SPI and especially the GPIO interfaces might be the most straightforward approaches since they
|
have a minimal protocol overhead. Device-specific interrupt capabilities can be added using the
|
have a minimal protocol overhead. Device-specific interrupt capabilities could be added using the
|
https://stnolting.github.io/neorv32/#_external_interrupt_controller_xirq[External Interrupt Controller (XIRQ)].
|
https://stnolting.github.io/neorv32/#_external_interrupt_controller_xirq[External Interrupt Controller (XIRQ)].
|
|
|
Beyond simplicity, these interface only provide a very limited bandwidth and require more sophisticated
|
Beyond simplicity, these interface only provide a very limited bandwidth and require more sophisticated
|
software handling ("bit-banging" for the GPIO).
|
software handling ("bit-banging" for the GPIO). Hence, i is not recommend to use them for _chip-internal_ communication.
|
|
|
|
|
=== External Bus Interface
|
=== External Bus Interface
|
|
|
The https://stnolting.github.io/neorv32/#_processor_external_memory_interface_wishbone_axi4_lite[External Bus Interface]
|
The https://stnolting.github.io/neorv32/#_processor_external_memory_interface_wishbone_axi4_lite[External Bus Interface]
|
provides the classic approach to connect to custom IP. By default, the bus interface implements the widely adopted
|
provides the classic approach for attaching custom IP. By default, the bus interface implements the widely adopted
|
Wishbone interface standard. However, this project also includes wrappers to bridge to other protocol standards like ARM's
|
Wishbone interface standard. This project also includes wrappers to convert to other protocol standards like ARM's
|
AXI4-Lite or Intel's Avalon. By using a full-featured bus protocol, complex SoC structures can be implemented (including
|
AXI4-Lite or Intel's Avalon protocols. By using a full-featured bus protocol, complex SoC designs can be implemented
|
several modules and even multi-core architectures). Many FPGA EDA tools provide graphical editors to build and customize
|
including several modules and even multi-core architectures. Many FPGA EDA tools provide graphical editors to build
|
whole SoC architectures and even include pre-defined IP libraries.
|
and customize whole SoC architectures and even include pre-defined IP libraries.
|
|
|
.Example AXI SoC using Xilinx Vivado
|
.Example AXI SoC using Xilinx Vivado
|
image::neorv32_axi_soc.png[]
|
image::neorv32_axi_soc.png[]
|
|
|
|
Custom hardware modules attached to the processor's bus interface have no limitations regarding their functionality.
|
|
User-defined interfaces (like DDR memory access) can be implemented and the hardware module can operate completely
|
|
independent of the CPU.
|
|
|
The bus interface uses a memory-mapped approach. All data transfers are handled by simple load/store operations since the
|
The bus interface uses a memory-mapped approach. All data transfers are handled by simple load/store operations since the
|
external bus interface is mapped into the processor's https://stnolting.github.io/neorv32/#_address_space[address space].
|
external bus interface is mapped into the processor's https://stnolting.github.io/neorv32/#_address_space[address space].
|
This allows a very simple still high-bandwidth communications.
|
This allows a very simple still high-bandwidth communications. However, high bus traffic may increase access latencies.
|
|
|
|
|
=== Stream Link Interface
|
=== Stream Link Interface
|
|
|
The NEORV32 https://stnolting.github.io/neorv32/#_stream_link_interface_slink[Stream Link Interface] provides
|
The https://stnolting.github.io/neorv32/#_stream_link_interface_slink[Stream Link Interface (SLINK)] provides a
|
point-to-point, unidirectional and parallel data channels that can be used to transfer streaming data. In
|
point-to-point, unidirectional and parallel data interface that can be used to transfer _streaming_ data. In
|
contrast to the external bus interface, the streaming data does not provide any kind of "direction" control,
|
contrast to the external bus interface, the streaming interface does not provide any kind of advanced control,
|
so it can be seen as "constant address bursts". The stream link interface provides less protocol overhead
|
so it can be seen as "constant address bursts" where data is transmitted _sequentially_ (no random accesses).
|
and less latency than the bus interface. Furthermore, FIFOs can be be configured to each direction (RX/TX) to
|
While the CPU needs to "feed" the stream link interfaces with data (and read back incoming data), the actual
|
allow more CPU-independent operation.
|
processor-external processing of the data run independently of the CPU.
|
|
|
|
The stream link interface provides less protocol overhead and less latency than the bus interface. Furthermore,
|
|
FIFOs can be be configured to each direction (RX/TX) to allow more CPU-independent operation.
|
|
|
|
|
=== Custom Functions Subsystem
|
=== Custom Functions Subsystem
|
|
|
The NEORV32 https://stnolting.github.io/neorv32/#_custom_functions_subsystem_cfs[Custom Functions Subsystem] is
|
The https://stnolting.github.io/neorv32/#_custom_functions_subsystem_cfs[Custom Functions Subsystem (CFS)] is
|
an "empty" template for a processor-internal module. It provides 32 32-bit memory-mapped interface
|
an "empty" template for a memory-mapped, processor-internal module.
|
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
|
The basic idea of this subsystem is to provide a convenient, simple and flexible platform, where the user can
|
rather than taking care of the communication between the CPU/software and the design logic. The interface
|
concentrate on implementing the actual design logic rather than taking care of the communication between the
|
registers are already allocated within the processor's address space and are supported by the software framework
|
CPU/software and the design logic. Note that the CFS does not have direct access to memory. All data (and control
|
via low-level hardware access mechanisms. Additionally, the CFS provides a direct pre-defined interrupt channel to
|
instruction) have to be send by the CPU.
|
the CPU, which is also supported by the NEORV32 runtime environment.
|
|
|
The use-cases for the CFS include medium-scale hardware accelerators that need to be tightly-coupled to the CPU.
|
|
Potential use cases could be DSP modules like CORDIC, cryptographic accelerators or custom interfaces (like IIS).
|
|
|
|
|
|
=== Custom Functions Unit
|
|
|
|
The https://stnolting.github.io/neorv32/#_custom_functions_unit_cfu[Custom Functions Unit (CFU)] is a functional
|
|
unit that is integrated right into the CPU's pipeline. It allows to implement custom RISC-V instructions.
|
|
This extension option is intended for rather small logic that implements operations, which cannot be emulated
|
|
in pure software in an efficient way. Since the CFU has direct access to the core's register file it can operate
|
|
with minimal data latency.
|
|
|
|
|
|
=== Comparative Summary
|
|
|
|
The following table gives a comparative summary of the most important factors when choosing one of the
|
|
chip-internal extension options:
|
|
|
|
* https://stnolting.github.io/neorv32/#_custom_functions_unit_cfu[Custom Functions Unit] for CPU-internal custom RISC-V instructions
|
|
* https://stnolting.github.io/neorv32/#_custom_functions_subsystem_cfs[Custom Functions Subsystem] for tightly-coupled processor-internal co-processors
|
|
* https://stnolting.github.io/neorv32/#_stream_link_interface_slink[Stream Link Interface] for processor-external streaming modules
|
|
* https://stnolting.github.io/neorv32/#_processor_external_memory_interface_wishbone_axi4_lite[External Bus Interface] for processor-external memory-mapped modules
|
|
|
|
.Comparison of On-Chip Extension Options
|
|
[cols="<1,^1,^1,^1,^1"]
|
|
[options="header",grid="rows"]
|
|
|=======================
|
|
| | Custom Functions Unit | Custom Functions Subsystem | Stream Link Interface | External Bus Interface
|
|
| **SoC location** | CPU-internal | processor-internal | processor-external | processor-external
|
|
| **HW complexity/size** | small | medium | unlimited | unlimited
|
|
| **CPU-independent operation** | no | partly | partly | completely
|
|
| **CPU interface** | register-file access | memory-mapped | memory-mapped | memory-mapped
|
|
| **Low-level CPU access scheme** | custom instructions | load/store | load/store | load/store
|
|
| **Random access** | - | yes | no, only sequential | yes
|
|
| **Access latency** | minimal | low | low | medium to high
|
|
| **External IO interfaces** | no | yes, but limited | yes | yes
|
|
| **Interrupt-capable** | no | yes | yes | user-defined
|
|
|=======================
|
|
|
