101 lines
6.3 KiB
Plaintext
101 lines
6.3 KiB
Plaintext
<<<
|
|
:sectnums:
|
|
== Adding Custom Hardware Modules
|
|
|
|
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.
|
|
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
|
|
|
|
The processor already provides a set of standard interfaces that are intended to connect _chip-external_ devices.
|
|
However, these interfaces can also be used chip-internally. The most suitable interfaces are
|
|
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/#_serial_peripheral_interface_controller_spi[SPI] and
|
|
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
|
|
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)].
|
|
|
|
Beyond simplicity, these interface only provide a very limited bandwidth and require more sophisticated
|
|
software handling ("bit-banging" for the GPIO). Hence, it is not recommend to use them for _chip-internal_ communication.
|
|
|
|
|
|
=== External Bus Interface
|
|
|
|
The https://stnolting.github.io/neorv32/#_processor_external_memory_interface_wishbone[External Bus Interface]
|
|
provides the classic approach for attaching custom IP. By default, the bus interface implements the widely adopted
|
|
Wishbone interface standard. This project also includes wrappers to convert to other protocol standards like ARM's
|
|
AXI4-Lite or Intel's Avalon protocols. By using a full-featured bus protocol, complex SoC designs can be implemented
|
|
including several modules and even multi-core architectures. Many FPGA EDA tools provide graphical editors to build
|
|
and customize whole SoC architectures and even include pre-defined IP libraries.
|
|
|
|
.Example AXI SoC using Xilinx Vivado
|
|
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
|
|
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. However, high bus traffic may increase access latencies.
|
|
|
|
|
|
=== Custom Functions Subsystem
|
|
|
|
The https://stnolting.github.io/neorv32/#_custom_functions_subsystem_cfs[Custom Functions Subsystem (CFS)] is
|
|
an "empty" template for a memory-mapped, processor-internal module.
|
|
|
|
The basic idea of this subsystem is to provide a convenient, simple and flexible platform, 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. Note that the CFS does not have direct access to memory. All data (and control
|
|
instruction) have to be send by the CPU.
|
|
|
|
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 (CFU)] for CPU-internal custom RISC-V instructions
|
|
* https://stnolting.github.io/neorv32/#_custom_functions_subsystem_cfs[Custom Functions Subsystem (CFS)] for tightly-coupled processor-internal co-processors
|
|
* https://stnolting.github.io/neorv32/#_processor_external_memory_interface_wishbone[External Bus Interface (WISHBONE)] for processor-external memory-mapped modules
|
|
|
|
.Comparison of On-Chip Extension Options
|
|
[cols="<1,^1,^1,^1"]
|
|
[options="header",grid="rows"]
|
|
|=======================
|
|
| | Custom Functions Unit (CFU) | Custom Functions Subsystem (CFS) | External Bus Interface
|
|
| **RTL location** | CPU-internal | processor-internal | processor-external
|
|
| **HW complexity/size** | small | medium | large
|
|
| **CPU-independent operation** | no | yes | yes
|
|
| **CPU interface** | register file access | memory-mapped | memory-mapped
|
|
| **Low-level access mechanism** | custom instructions | load/store | load/store
|
|
| **Access latency** | minimal | low | medium to high
|
|
| **External IO interfaces** | not supported | yes, but limited | yes, user-defined
|
|
| **Exception capability** | yes | no | no
|
|
| **Interrupt capability** | no | yes | user-defined
|
|
|=======================
|