mirror of
https://github.com/stnolting/neorv32.git
synced 2025-04-24 22:27:21 -04:00
99 lines
6.3 KiB
Text
99 lines
6.3 KiB
Text
<<<
|
|
: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.
|
|
|
|
|
|
=== 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, i is not recommend to use them for _chip-internal_ communication.
|
|
|
|
|
|
=== External Bus Interface
|
|
|
|
The https://stnolting.github.io/neorv32/#_processor_external_memory_interface_wishbone_axi4_lite[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[]
|
|
|
|
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.
|
|
|
|
|
|
=== Stream Link Interface
|
|
|
|
The https://stnolting.github.io/neorv32/#_stream_link_interface_slink[Stream Link Interface (SLINK)] provides a
|
|
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 interface does not provide any kind of advanced control,
|
|
so it can be seen as "constant address bursts" where data is transmitted _sequentially_ (no random accesses).
|
|
|
|
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
|
|
|
|
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.
|
|
|
|
|
|
=== 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
|
|
| **HW complexity/size** | low/small | medium | unlimited | unlimited
|
|
| **CPU-independent operation** | no | mostly | no | completely
|
|
| **CPU interface** | inside CPU pipeline | memory-mapped | memory-mapped | memory-mapped
|
|
| **Low-level CPU access scheme** | custom instructions | load/store | load/store | load/store
|
|
| **Random access** | yes | yes | sequential | yes
|
|
| **Access latency** | minimal | low | low | medium to high
|
|
| **External IO interfaces** | no | yes, but limited | yes | yes
|
|
| **Interrupt capable** | no | yes | yes | yes
|
|
|=======================
|
|
|