The NEORV32 RISC-V Processor: Datasheet

The processor setup features the standard machine-level RISC-V interrupt lines for "machine timer interrupt", "machine software interrupt" and "machine external interrupt". Their usage is defined by the RISC-V privileged architecture specifications. However, bare-metal system can also repurpose these interrupts. See CPU section Traps, Exceptions and Interrupts for more information.

As part of the NEORV32-specific CPU extensions, the processor core features 16 fast interrupt request signals (FIRQ0 - FIRQ15) providing dedicated bits in the mip and mie CSRs and custom mcause trap codes. The FIRQ signals are reserved for processor-internal modules only (for example for the communication interfaces to signal "available incoming data" or "ready to send new data").

The mapping of the 16 FIRQ channels to the according processor-internal modules is shown in the following table (the channel number also corresponds to the according FIRQ priority: 0 = highest, 15 = lowest):

Each default region of the NEORV32 address space provides specific physical memory attributes that define the allowed access types. The according access permission are enforced by the hardware and cannot be changed. If an access violates the PMA’s permissions an exception is raised. The access permissions can be further constrained using the CPU’s PMP ISA Extension.

The CPU can access all of the 32-bit address space from the instruction fetch interface (I) and also from the data access interface (D). These two CPU interfaces are multiplexed by a simple bus switch (rtl/core/neorv32_busswitch.vhd) into a single processor-internal bus. All processor-internal memories, peripherals and also the external memory interface are connected to this bus. Hence, both CPU interfaces (instruction fetch & data access) have access to the same (identical!) address space making the processor a modified von-Neumann architecture.

The general address space layout consists of two main configuration constants: ispace_base_c defining the base address of the instruction memory address space and dspace_base_c defining the base address of the data memory address space. Both constants are defined in the NEORV32 VHDL package file rtl/core/neorv32_package.vhd:

The default configuration assumes the instruction memory address space starting at address 0x00000000 and the data memory address space starting at 0x80000000. Both values can be modified for a specific setup and the address space may also overlap or can even be identical.

The NEORV32 Processor was designed to provide maximum flexibility for the actual memory configuration. The processor can populate the instruction address space and/or the data address space with internal memories for instructions (IMEM) and data (DMEM). Processor external memories can be used as an alternative or even in combination with the internal ones. The figure below show some exemplary memory configurations.

Due to the flexible memory configuration, the NEORV32 Processor provides several different boot scenarios. The following section illustrates the two most common boot scenarios.

There are two general boot scenarios: Indirect Boot (1a and 1b) and Direct Boot (2a and 2b) configured via the INT_BOOTLOADER_EN generic. If this generic is true the indirect boot scenario is used. This is also the default boot configuration of the processor. If INT_BOOTLOADER_EN is *false the direct boot scenario is used.

Implementation of the processor-internal instruction memory is enabled via the processor’s MEM_INT_IMEM_EN generic. The size in bytes is defined via the MEM_INT_IMEM_SIZE generic. If the IMEM is implemented, the memory is mapped into the instruction memory space and located right at the beginning of the instruction memory space (default ispace_base_c = 0x00000000), see Address Space.

By default the IMEM is implemented as true RAM so the content can be modified during run time. This is required when using a bootloader that can update the content of the IMEM at any time. If you do not need the bootloader anymore - since your application development has completed and you want the program to permanently reside in the internal instruction memory - the IMEM is automatically implemented as pre-intialized ROM when the processor-internal bootloader is disabled (INT_BOOTLOADER_EN = false).

When the IMEM is implemented as ROM, it will be initialized during synthesis with the actual application program image. The compiler toolchain provides an option to generate and override the default VHDL initialization file rtl/core/neorv32_application_image.vhd, which is automatically inserted into the IMEM. If the IMEM is implemented as RAM (default), the memory will not be initialized at all.

Implementation of the processor-internal data memory is enabled via the processor’s MEM_INT_DMEM_EN generic. The size in bytes is defined via the MEM_INT_DMEM_SIZE generic. If the DMEM is implemented, the memory is mapped into the data memory space and located right at the beginning of the data memory space (default dspace_base_c = 0x80000000), see Address Space. The DMEM is always implemented as true RAM.

This boot ROM module provides a read-only memory that contain the executable image of the default NEORV32 Bootloader. If the internal bootloader is enabled via the INT_BOOTLOADER_EN generic the CPU’s boot address is automatically set to the beginning of the bootloader ROM. See sections Address Space and Boot Configuration for more information regarding the processor’s different boot scenarios.

The processor features an optional instruction cache to improve performance when using memories with high access latencies. The cache is directly connected to the CPU’s instruction fetch interface and provides full-transparent buffering of instruction fetch accesses to the entire address space.

The cache is implemented if the ICACHE_EN generic is true. The size of the cache memory is defined via ICACHE_BLOCK_SIZE (the size of a single cache block/page/line in bytes; has to be a power of two and greater than or equal to 4 bytes), ICACHE_NUM_BLOCKS (the total amount of cache blocks; has to be a power of two and greater than or equal to 1) and the actual cache associativity ICACHE_ASSOCIATIVITY (number of sets; 1 = direct-mapped, 2 = 2-way set-associative) generics. If the cache associativity is greater than one the LRU replacement policy (least recently used) is used.

The processor features an optional data cache to improve performance when using memories with high access latencies. The cache is directly connected to the CPU’s data access interface and provides full-transparent buffering.

The cache is implemented if the DCACHE_EN generic is true. The size of the cache memory is defined via the DCACHE_BLOCK_SIZE (the size of a single cache block/page/line in bytes; has to be a power of two and greater than or equal to 4 bytes) and DCACHE_NUM_BLOCKS (the total amount of cache blocks; has to be a power of two and greater than or equal to 1) generics. The data cache provides only a single set, hence it is direct-mapped.

The data cache provides direct accesses (= uncached) to memory in order to access memory-mapped IO (like the processor-internal IO/peripheral modules). All accesses that target the address range from 0xF0000000 to 0xFFFFFFFF will not be cached at all. This also allows to attach custom IO modules via the processor’s external memory interface when they are mapped to upper-most 256 MB address page (see section Address Space).

Overview

The NEORV32 DMA provides a small-scale scatter/gather direct memory access controller that allows to transfer and modify data independently of the CPU. A single read/write transfer channel is implemented that is configured via memory-mapped registers. a configured transfer can either be triggered manually or by a programmable CPU FIRQ interrupt (see NEORV32-Specific Fast Interrupt Requests).

The DMA is connected to the central processor-internal bus system (see section Address Space) and can access the same address space as the CPU core. It uses interleaving mode accessing the central processor bus only if the CPU does not currently request and bus access.

The controller can handle different data quantities (e.g. read bytes and write them back as sign-extend words) and can also change the Endianness of data while transferring.

Theory of Operation

The DMA provides four memory-mapped interface registers: A status and control register CTRL and three registers for configuring the actual DMA transfer. The base address of the source data is programmed via the SRC_BASE register. Vice versa, the base address of the destination data is programmed via the DST_BASE. The third configuration register TTYPE is use to configure the actual transfer type and the number of elements to transfer.

The DMA is enabled by setting the DMA_CTRL_EN bit of the control register. Manual trigger mode (i.e. the DMA transfer is triggered by writing to the TTYPE register) is selected if DMA_CTRL_AUTO is cleared. Alternatively, the DMA transfer can be triggered by a processor internal FIRQ signal if DMA_CTRL_AUTO is set (see section below).

The DMA uses a load-modify-write data transfer process. Data is read from the bus system, internally modified and then written back to the bus system. This combination is implemented as an atomic progress, so canceling the current transfer by clearing the DMA_CTRL_EN bit will stop the DMA right after the current load-modify-write operation.

If the DMA controller detects a bus error during operation, it will set either the DMA_CTRL_ERROR_RD (error during last read access) or DMA_CTRL_ERROR_WR (error during last write access) and will terminate the current transfer. Software can read the SRC_BASE or DST_BASE register to retrieve the address that caused the according error. Alternatively, software can read back the NUM bits of the control register to determine the index of the element that caused the error. The error bits are automatically cleared when starting a new transfer.

Transfer Configuration

If the DMA is set to manual trigger mode (DMA_CTRL_AUTO = 0) writing the TTRIG register will start the programmed DMA transfer. Once started, the DMA will read one data quantity from the source address, processes it internally and then will write it back to the destination address. The DMA_TTYPE_NUM bits of the TTYPE register define how many times this process is repeated by specifying the number of elements to transfer.

Optionally, the source and/or destination addresses can be increments according to the data quantities automatically by setting the according DMA_TTYPE_SRC_INC and/or DMA_TTYPE_DST_INC bit.

Four different transfer quantities are available, which are configured via the DMA_TTYPE_QSEL bits:

Optionally, the DMA controller can automatically convert Endianness of the transferred data if the DMA_TTYPE_ENDIAN bit is set.

Automatic Trigger

As an alternative to the manual trigger mode, the DMA can be configured to automatic trigger mode starting a pre-configured transfer if a specific processor-internal peripheral issues an interrupt request. The automatic trigger mode is enabled by setting the CTRL register’s DMA_CTRL_AUTO bit. In this configuration no transfer is started when writing to the DMA’s TTYPE register.

The actual trigger is configured via the control register DMA_CTRL_FIRQ_MASK. These bits reflect the state of the CPU’s mip CSR showing any pending fast interrupt requests (for a full list see NEORV32-Specific Fast Interrupt Requests). The same bit definitions/locations as for the mip and mie CPU CSRs are used. If any of the enabled sources issues an interrupt the DMA will start the pre-configured transfer (note that all enabled sources are logically OR-ed).

DMA Interrupt

The DMA features a single CPU interrupt that is triggered when the programmed transfer has completed. This interrupt is also triggered if the DMA encounters a bus error during operation. An active DMA interrupt has to be explicitly cleared again by writing zero to the according mip CSR bit.

Register Map

The external memory interface provides a Wishbone b4-compatible on-chip bus interface. The bus interface is implemented if the MEM_EXT_EN generic is true. This interface can be used to attach external memories, custom hardware accelerators, additional IO devices or all other kinds of IP blocks to the processor.

The external interface is not mapped to a specific address space. Instead, all CPU memory accesses that do not target a processor-internal module are delegated to the external memory interface. In summary, a CPU load/store access is delegated via the external bus interface if…​

Wishbone Bus Protocol

The external memory interface either uses the standard (also called "classic") Wishbone protocol (default) or pipelined Wishbone protocol. The protocol to be used is configured via the MEM_EXT_PIPE_MODE generic:

Bus Access

The NEORV32 Wishbone gateway does not support burst transfer yet, so there is always just a single transfer "in fly". Hence, the Wishbone STALL signal is not implemented. An accessed Wishbone device does not have to respond immediately to a bus request by sending an ACK. Instead, there is a time window where the device has to acknowledge the transfer. This time window s configured by the MEM_EXT_TIMEOUT generic that defines the maximum time (in clock cycles) a bus access can be pending before it is automatically terminated with an error condition. If MEM_EXT_TIMEOUT is set to zero, the timeout is disabled and a bus access can take an arbitrary number of cycles to complete (this is not recommended!).

When MEM_EXT_TIMEOUT is greater than zero, the Wishbone gateway starts an internal countdown whenever the CPU accesses an address via the external memory interface. If the accessed device does not acknowledge (via wb_ack_i) or terminate (via wb_err_i) the transfer within MEM_EXT_TIMEOUT clock cycles, the bus access is automatically canceled setting wb_cyc_o low again and a CPU load/store/instruction fetch bus access fault exception is raised.

Wishbone Tag

The 3-bit wishbone wb_tag_o signal provides additional information regarding the access type:

Endianness

The NEORV32 CPU and the Processor setup are little-endian architectures. To allow direct connection to a big-endian memory system the external bus interface provides an Endianness configuration. The Endianness of the external memory interface can be configured via the MEM_EXT_BIG_ENDIAN generic. By default, the external memory interface uses little-endian byte-order.

Application software can check the Endianness configuration of the external bus interface via the SYSINFO module (see section System Configuration Information Memory (SYSINFO) for more information).

Access Latency

By default, the Wishbone gateway introduces two additional latency cycles: processor-outgoing (*_o) and processor-incoming (*_i) signals are fully registered. Thus, any access from the CPU to a processor-external devices via Wishbone requires 2 additional clock cycles. This can ease timing closure when using large (combinatorial) Wishbone interconnection networks.

Optionally, the latency of the Wishbone gateway can be reduced by removing the input and output register stages. Enabling the MEM_EXT_ASYNC_RX option will remove the input register stage; enabling MEM_EXT_ASYNC_TX option will remove the output register stages. Each enabled option reduces access latency by 1 cycle.

Overview

The stream link interface provides independent RX and TX channels for sending for sending and receiving stream data. Each channel features an internal FIFO with configurable depth to buffer stream data (IO_SLINK_RX_FIFO for the RX FIFO, IO_SLINK_TX_FIFO for the TX FIFO). The interface provides higher bandwidth and less latency than the external bus interface making it ideally suited for coupling custom stream processing units or streaming peripherals.

Interface & Protocol

The SLINK interface consists of three signals dat, val and rdy per channel.

Theory of Operation

The SLINK provides two interface registers: CTRL and DATA. The control register (CTRL) is used to configure the module and to check its status. The data register (DATA) is sued to send data (by writing to it) or to read received data (by reading from it). Note that accessing the data register will actually access the internal FIFOs.

The configured FIFO sizes can be retrieved by software via the SLINK_CTRL_RX_FIFO_* and SLINK_CTRL_TX_FIFO_* bits.

The SLINK is globally activated by setting the control register’s enable bit SLINK_CTRL_EN. Clearing this bit will reset all internal logic and will also clear both FIFOs. The FIFOs can also be cleared manually at all time by setting the SLINK_CTRL_RX_CLR and SLINK_CTRL_TX_CLR bits (these bits will auto-clear).

The current status of the RX and TX FIFOs can be determined via the SLINK_CTRL_RX_* and SLINK_CTRL_TX_* flags. A global interrupt can be programmed based on these FIFO status flags via the control register’s SLINK_CTRL_IRQ_* bits. Note that all enabled interrupt conditions are logically OR-ed. Once the SLINK’s interrupt has become pending, it has to be explicitly cleared again by writing zero to the according mip CSR bit(s).

Register Map

Theory of Operation

The Bus Keeper is a fundamental component of the processor’s internal bus system that ensures correct bus operations while maintaining execution safety. It monitors every single bus transactions that is initiated by the CPU. If an accessed device responds with an error condition or do not respond at all within a specific access time window, an according bus access fault exception is raised. The following exceptions can be raised by the Bus Keeper (see section Traps, Exceptions and Interrupts for a list of all available bus access-related exceptions):

The access time window, in which an accessed device has to respond, is defined by the max_proc_int_response_time_c constant from the processor’s VHDL package file (rtl/neorv32_package.vhd). The default value is 15 clock cycles.

In case of a bus access fault exception application software can evaluate the Bus Keeper’s control register CTRL to retrieve further details regarding the bus exception. The BUSKEEPER_ERR_FLAG bit indicates that an actual bus access fault has occurred. The bit is sticky once set and is automatically cleared when reading or writing the NEORV32_BUSKEEPER.CTRL register. The BUSKEEPER_ERR_TYPE bit defines the type of the bus fault:

Register Map

The general purpose parallel IO unit provides a simple parallel input and output port. These ports can be used chip-externally (for example to drive status LEDs, connect buttons, etc.) or chip-internally to provide control signals for other IP modules.

The actual number of input/output pairs is defined by the IO_GPIO_NUM generic. When set to zero, the GPIO module is excluded from synthesis and the output port gpio_o is tied to all-zero. If IO_GPIO_NUM is less than the maximum value of 64, only the LSB-aligned bits in gpio_o and gpio_i are actually connected while the remaining bits are tied to zero or are left unconnected, respectively.

Register Map

Theory of Operation

The watchdog (WDT) provides a last resort for safety-critical applications. The WDT provides a "bark and bite" concept. The timeout counter first triggers an optional CPU interrupt ("bark") when reaching half of the programmed interval to inform the application of the imminent timeout. When the full timeout value is reached a system-wide hardware reset is generated ("bite"). The internal counter has to be reset explicitly by the application program every now and then to prevent a timeout.

Configuration

The watchdog is enabled by setting the control register’s WDT_CTRL_EN bit. When this bit is cleared, the internal timeout counter is reset to zero and no interrupt and no system reset can be triggered.

The internal 32-bit timeout counter is clocked at 1/4096th of the processor’s main clock (f_WDT[Hz] = f_main[Hz] / 4096). Whenever this counter reaches the programmed timeout value (WDT_CTRL_TIMEOUT bits in the control register) a hardware reset is triggered. In order to inform the application of an imminent timeout, an optional CPU interrupt is triggered when the timeout counter reaches half of the programmed timeout value.

The watchdog is "fed" by writing 1 to the WDT_CTRL_RESET control register bit, which will reset the internal timeout counter back to zero.

Configuration Lock

The watchdog control register can be locked to protect the current configuration from being modified. The lock is activated by setting the WDT_CTRL_LOCK bit. In the locked state any write access to the control register is entirely ignored (see table below, "writable if locked"). Read accesses to the control register as well as watchdog resets (by setting the WDT_CTRL_RESET flag) are not affected.

The lock bit can only be set if the WDT is already enabled (WDT_CTRL_EN is set). Furthermore, the lock bit can only be cleared again by a system-wide hardware reset.

Cause of last Hardware Reset

The cause of the last system hardware reset can be determined via the WDT_CTRL_RCAUSE flag. If this flag is cleared, the processor has been reset via the external reset signal (or the on-chip debugger). If this flag is set, the last system reset was caused by the watchdog itself.

Register Map

The MTIME module implements a memory-mapped MTIME machine system timer that is compatible to the RISC-V privileged specifications. The 64-bit system time is accessed via the memory-mapped TIME_LO and TIME_HI`registers. A 64-bit time compare register, which is accessible via the memory-mapped `TIMECMP_LO and TIMECMP_HI registers, can be used to configure the CPU’s MTI (machine timer interrupt). The interrupt is triggered whenever TIME (high & low part) is greater than or equal to TIMECMP (high & low part). The interrupt remains active (=pending) until TIME becomes less TIMECMP again (either by modifying TIME or TIMECMP).

Register Map

Overview

The NEORV32 UART provides a standard serial interface with independent transmitter and receiver channels, each equipped with a configurable FIFO. The transmission frame is fixed to 8N1: 8 data bits, no parity bit, 1 stop bit. The actual transmission rate (Baud rate) is programmable via software. The module features two memory-mapped registers: CTRL and DATA. These are used for configuration, status check and data transfer.

Theory of Operation

The module is enabled by setting the UART_CTRL_EN bit in the UART0 control register CTRL. The Baud rate is configured via a 10-bit UART_CTRL_BAUDx baud divisor (baud_div) and a 3-bit UART_CTRL_PRSCx clock prescaler (clock_prescaler).

Baud rate = (f_main[Hz] / clock_prescaler) / (baud_div + 1)

The control register’s UART_CTRL_RX_* and UART_CTRL_TX_* flags provide information about the RX and TX FIFO fill level. Disabling the module via the UART_CTRL_EN bit will also clear these FIFOs.

A new TX transmission is started by writing data to the lowest byte of the DATA register. The transfer is completed when the UART_CTRL_TX_BUSY control register flag returns to zero. RX data is available when the UART_CTRL_RX_NEMPTY flag becomes set. The UART_CTRL_RX_OVER will be set if the RX FIFO overflows. This flag is cleared by reading the DATA register or by disabling the module.

UART Interrupts

The UART module provides independent interrupt channels for RX and TX. These interrupts are triggered by certain RX and TX FIFO levels. The actual configuration is programmed independently for the RX and TX interrupt channel via the control register’s UART_CTRL_IRQ_RX_* and UART_CTRL_IRQ_TX_* bits:

Once an UART interrupt has fired it remains pending until the actual cause of the interrupt is resolved; for example if just the UART_CTRL_IRQ_RX_NEMPTY bit is set, the RX interrupt will keep firing until the RX FIFO is empty again. Furthermore, a pending UART interrupt has to be explicitly cleared again by writing zero to the according mip CSR bit.

RTS/CTS Hardware Flow Control

The NEORV32 UART supports optional hardware flow control using the standard CTS uart0_cts_i ("clear to send") and RTS uart0_rts_o ("ready to send" / "ready to receive (RTR)") signals. Both signals are low-active. Hardware flow control is enabled by setting the UART_CTRL_HWFC_EN bit in the modules control register CTRL.

When hardware flow control is enabled:

Simulation Mode

The UART provides a simulation-only mode to dump console data as well as raw data directly to a file. When the simulation mode is enabled (by setting the UART_CTRL_SIM_MODE bit) there will be no physical transaction on the uart0_txd_o signal. Instead, all data written to the DATA register is immediately dumped to a file.

Both file are created in the simulation’s home folder.

Register Map

Overview

The secondary UART (UART1) is functionally identical to the primary UART (Primary Universal Asynchronous Receiver and Transmitter (UART0)). Obviously, UART1 uses different addresses for the control register (CTRL) and the data register (DATA). The register’s bits/flags use the same bit positions and naming as for the primary UART. The RX and TX interrupts of UART1 are mapped to different CPU fast interrupt (FIRQ) channels.

Simulation Mode

The secondary UART (UART1) provides the same simulation options as the primary UART (UART0). However, output data is written to UART1-specific files: neorv32.uart1.sim_mode.text.out is used to dump plain ASCII text. This data is also printed to the simulator console. neorv32.uart1.sim_mode.data.out is used to dump full 32-bit hexadecimal ASCII-chars data words.

Register Map

Overview

The NEORV32 SPI transceiver module operates on 8-bit base, supports all 4 standard clock modes and provides up to 8 dedicated chip select signals via the top entity’s spi_csn_o signal. An receive/transmit FIFO can be configured via the IO_SPI_FIFO generic to support block-based transmissions without CPU interaction.

The SPI module provides a single control register CTRL to configure the module and to check it’s status and a single data register DATA for receiving/transmitting data.

Theory of Operation

The SPI module is enabled by setting the SPI_CTRL_EN bit in the CTRL control register. No transfer can be initiated and no interrupt request will be triggered if this bit is cleared. Clearing this bit will reset the module, clear the FIFO and terminate any transfer being in process.

The data quantity to be transferred within a single data transmission is fixed to 8 bits. However, the total transmission length is left to the user: after asserting chip-select an arbitrary amount of 8-bit transmission can be made before de-asserting chip-select again.

A transmission is started when writing data to the transmitter FIFO via the DATA register. Note that data always transferred MSB-first. The SPI operation is completed as soon as the SPI_CTRL_BUSY flag clears. Received data can be retrieved by reading the RX FIFO also via the DATA register. The control register’s SPI_CTRL_RX_AVAIL, SPI_CTRL_TX_EMPTY, SPI_CTRL_TX_NHALF and SPI_CTRL_TX_FULL flags provide information regarding the RX/TX FIFO levels.

The SPI controller features 8 dedicated chip-select lines. These lines are controlled via the control register’s SPI_CTRL_CS_SELx and SPI_CTRL_CS_EN bits. The 3-bit SPI_CTRL_CS_SELx bits are used to select one out of the eight dedicated chip select lines. As soon as SPI_CTRL_CS_EN is set the selected chip select line is activated (driven low). Note that disabling the SPI module via the SPI_CTRL_EN bit will also deactivate any currently activated chip select line.

SPI Clock Configuration

The SPI module supports all standard SPI clock modes (0, 1, 2, 3), which are configured via the two control register bits SPI_CTRL_CPHA and SPI_CTRL_CPOL. The SPI_CTRL_CPHA bit defines the clock phase and the SPI_CTRL_CPOL bit defines the clock polarity.

The SPI clock frequency (spi_clk_o) is programmed by the 3-bit SPI_CTRL_PRSCx clock prescaler for a coarse clock selection and a 4-bit clock divider SPI_CTRL_CDIVx for a fine clock configuration.

The following clock prescalers (SPI_CTRL_PRSCx) are available:

Based on the programmen clock configuration, the actual SPI clock frequency f_SPI is derived from the processor’s main clock f_main according to the following equation:

f_SPI = f_main[Hz] / (2 * clock_prescaler * (1 + SPI_CTRL_CDIVx))

Hence, the maximum SPI clock is f_main / 4 and the lowest SPI clock is f_main / 131072. The SPI clock is always symmetric having a duty cycle of 50%.

SPI Interrupt

The SPI module provides a set of programmable interrupt conditions based on the level of the RX/TX FIFO. The different interrupt sources are enabled by setting the according control register’s SPI_CTRL_IRQ_* bits. All enabled interrupt conditions are logically OR-ed so any enabled interrupt source will trigger the module’s interrupt signal.

Once the SPI interrupt has fired it remains pending until the actual cause of the interrupt is resolved; for example if just the SPI_CTRL_IRQ_RX_AVAIL bit is set, the interrupt will keep firing until the RX FIFO is empty again. Furthermore, an active SPI interrupt has to be explicitly cleared again by writing zero to the according mip CSR bit.

Register Map

Overview

The serial data interface module provides a device-class SPI interface and allows to connect the processor to an external SPI host, which is responsible for triggering (clocking) the actual transmission - the SDI is entirely passive. An optional receive/transmit FIFO can be configured via the IO_SDI_FIFO generic to support block-based transmissions without CPU interaction.

The SDI module provides a single control register CTRL to configure the module and to check it’s status and a single data register DATA for receiving/transmitting data.

Theory of Operation

The SDI module is enabled by setting the SDI_CTRL_EN bit in the CTRL control register. Clearing this bit resets the entire module including the RX and TX FIFOs.

The SDI operates on byte-level only. Data written to the DATA register will be pushed to the TX FIFO. Received data can be retrieved by reading the RX FIFO via the DATA register. The current state of these FIFOs is available via the control register’s SDI_CTRL_RX_* and SDI_CTRL_TX_* flags. The RX FIFO can be manually cleared at any time by setting the SDI_CTRL_CLR_RX bit.

SDI Clocking

The SDI module supports both SPI clock polarity modes ("CPOL") but regarding the clock phase only "CPHA=0" is supported yet. All SDI operations are clocked by the external sdi_clk_i signal. This signal is synchronized to the processor’s clock domain to simplify timing behavior. However, the clock synchronization requires that the external SDI clock (sdi_clk_i) does not exceed 1/4 of the processor’s main clock.

SDI Interrupt

The SDI module provides a set of programmable interrupt conditions based on the level of the RX & TX FIFOs. The different interrupt sources are enabled by setting the according control register’s SDI_CTRL_IRQ bits. All enabled interrupt conditions are logically OR-ed so any enabled interrupt source will trigger the module’s interrupt signal.

Once the SDI interrupt has fired it will remain active until the actual cause of the interrupt is resolved; for example if just the SDI_CTRL_IRQ_RX_AVAIL bit is set, the interrupt will keep firing until the RX FIFO is empty again. Furthermore, an active SDI interrupt has to be explicitly cleared again by writing zero to the according mip CSR bit.

Register Map

Overview

The NEORV32 TWI implements a TWI controller. Currently, no multi-controller support is available. Furthermore, the NEORV32 TWI unit cannot operate in peripheral mode.

Tri-State Drivers

The TWI module requires two tri-state drivers (actually: open-drain) for the SDA and SCL lines, which have to be implemented in the top module of the setup. A generic VHDL example is given below (sda and scl are the actual TWI bus signal, which are of type std_logic).

TWI Clock Speed

The TWI clock frequency is programmed by the 3-bit TWI_CTRL_PRSCx clock prescaler for a coarse selection and a 4-bit clock divider TWI_CTRL_CDIVx for a fine selection.

Based on the the clock configuration, the actual TWI clock frequency f_SCL is derived from the processor’s main clock f_main according to the following equation:

f_SCL = f_main[Hz] / (4 * clock_prescaler * (1 + TWI_CTRL_CDIV))

Hence, the maximum TWI clock is f_main / 8 and the lowest TWI clock is f_main / 262144. The generated TWI clock is always symmetric having a duty cycle of exactly 50%. However, an accessed peripheral can "slow down" the bus clock by using clock stretching (= actively driving the SCL line low). The controller will pause operation in this case if clock stretching is enabled via the TWI_CTRL_CSEN bit of the unit’s control register CTRL

TWI Transfers

The TWI is enabled via the TWI_CTRL_EN bit in the CTRL control register. The user program can start / stop a transmission by issuing a START or STOP condition. These conditions are generated by setting the according bits (TWI_CTRL_START or TWI_CTRL_STOP) in the control register.