The NEORV32 RISC-V Processor: Datasheet

Check out the setups folder (@GitHub: https://github.com/stnolting/neorv32/tree/master/setups), which provides several demo setups for various FPGA boards and toolchains.

See section System Configuration Information Memory (SYSINFO) for more information.

See section Instruction Sets and Extensions for more information.

See section PMP Physical Memory Protection for more information.

See section HPM Hardware Performance Monitors for more information.

See sections Address Space and Instruction Memory (IMEM) for more information.

See sections Address Space and Data Memory (DMEM) for more information.

See section Processor-Internal Instruction Cache (iCACHE) for more information.

See sections Address Space and Processor-External Memory Interface (WISHBONE) (AXI4-Lite) for more information.

See section Stream Link Interface (SLINK) for more information.

See section External Interrupt Controller (XIRQ) for more information.

See section Processor-Internal Modules for more information.

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.

The processor provides an optional interrupt controller for up to 32 user-defined external interrupts (see section External Interrupt Controller (XIRQ)). These external IRQs are mapped to a single CPU fast interrupt request so a software handler is required to differentiate / prioritize these interrupts.

As part of the custom/NEORV32-specific CPU extensions, the CPU features 16 fast interrupt request signals (FIRQ0 – FIRQ15). These are used 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 is shown in the following table (the channel number also corresponds to the according FIRQ priority; 0 = highest, 15 = lowest):

The CPU can access all of the 4GB 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 setup 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 overlap or can be completely identical. Make sure that both base addresses are aligned to a 4-byte boundary.

The processor setup defines fixed attributes for the four processor-internal address space regions. Accessing a memory region in a way that violates any of these attributes will raise an according access exception..

The NEORV32 Processor was designed to provide maximum flexibility for the 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 concept, the NEORV32 Processor provides several different boot concepts. The figure below shows the exemplary concepts for 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 set true the indirect boot scenario is used. This is also the default boot configuration of the processor. If INT_BOOTLOADER_EN is set 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).

By default, the IMEM is implemented as 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 will generate a 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). The DMEM is always implemented as RAM.

This HDL modules provides a read-only memory that contain the executable code image of the bootloader. If the INT_BOOTLOADER_EN generic is true this module will be implemented and the CPU boot address is modified to directly execute the code from the bootloader ROM after reset.

The bootloader ROM is located at address 0xFFFF0000 and can occupy a address space of up to 32kB. The base address as well as the maximum address space size are fixed and cannot (should not!) be modified as this might address collision with other processor modules.

The bootloader memory is read-only and is automatically initialized with the bootloader executable image rtl/core/neorv32_bootloader_image.vhd during synthesis. The actual physical size of the ROM is also determined via synthesis and expanded to the next power of two. For example, if the bootloader code requires 10kB of storage, a ROM with 16kB will be generated. The maximum size must not exceed 32kB.

The processor features an optional cache for instructions to compensate memories with high latency. The cache is directly connected to the CPU’s instruction fetch interface and provides a full-transparent buffering of instruction fetch accesses to the entire 4GB 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 >= 4 bytes), ICACHE_NUM_BLOCKS (the total amount of cache blocks; has to be a power of two and >= 1) and the actual cache associativity ICACHE_ASSOCIATIVITY (number of sets; 1 = direct-mapped, 2 = 2-way set-associative, has to be a power of two and >= 1).

If the cache associativity (ICACHE_ASSOCIATIVITY) is > 1 the LRU replacement policy (least recently used) is used.

By executing the ifence.i instruction (Zifencei CPU extension) the cache is cleared and a reload from main memory is forced. Among other things, this allows to implement self-modifying code.

Bus Access Fault Handling

The cache always loads a complete cache block (ICACHE_BLOCK_SIZE bytes) aligned to the size of a cache block if a miss is detected. If any of the accessed addresses within a single block do not successfully acknowledge (i.e. issuing an error signal or timing out) the whole cache block is invalidate and any access to an address within this cache block will also raise an instruction fetch bus error fault exception.

The external memory interface uses the Wishbone interface protocol. The external interface port is available when 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. All memory accesses from the CPU, that do not target the internal bootloader ROM, the internal IO region or the internal data/instruction memories (if implemented at all) are forwarded to the Wishbone gateway and thus to the external memory interface.

Wishbone Bus Protocol

The external memory interface either uses standard ("classic") Wishbone transactions (default) or pipelined Wishbone transactions. The transaction protocol is configured via the MEM_EXT_PIPE_MODE generic:

When MEM_EXT_PIPE_MODE is false, all bus control signals including STB are active (and stable) until the transfer is acknowledged/terminated. If MEM_EXT_PIPE_MODE is true, all bus control except STB are active (and stable) until the transfer is acknowledged/terminated. In this case, STB is active only during the very first bus clock cycle.

A detailed description of the implemented Wishbone bus protocol and the according interface signals can be found in the data sheet "Wishbone B4 – WISHBONE System-on-Chip (SoC) Interconnection Architecture for Portable IP Cores". A copy of this document can be found in the docs folder of this project.

Interface Latency

By default, the Wishbone gateway introduces two additional latency cycles: processor-outgoing ("TX") and processor-incoming ("RX") signals are fully registered. Thus, any access from the CPU to a processor-external devices via Wishbone requires 2 additional clock cycles (at least; depending on device’s latency).

If the attached Wishbone network / peripheral already provides output registers or if the Wishbone network is not relevant for timing closure, the default buffering of incoming ("RX") data within the gateway can be disabled by implementing an "asynchronous" RX path. The configuration is done via the MEM_EXT_ASYNC_RX generic.

Bus Access Timeout

The Wishbone bus interface provides an option to configure a bus access timeout counter. The MEM_EXT_TIMEOUT top generic is used to specify the maximum time (in clock cycles) a bus access can be pending before it is automatically terminated. If MEM_EXT_TIMEOUT is set to zero, the timeout disabled an a bus access can take an arbitrary number of cycles to complete.

When MEM_EXT_TIMEOUT is greater than zero, the WIshbone adapter starts an internal countdown whenever the CPU accesses a memory address via the external memory interface. If the accessed memory / 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 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. This signal is compatible to the AXI4 AxPROT signal.

Exclusive / Atomic Bus Access

If the atomic memory access CPU extension (via CPU_EXTENSION_RISCV_A) is enabled, the CPU can request an atomic/exclusive bus access via the external memory interface.

The load-reservate instruction (lr.w) will set the wb_lock_o signal telling the bus interconnect to establish a reservation for the current accessed address (start of an exclusive access). This signal will stay asserted until another memory access instruction is executed (for example a sc.w).

The memory system has to make sure that no other entity can access the reservated address until wb_lock_o is released again. If this attempt fails, the memory system has to assert wb_err_i in order to indicate that the reservation was broken.

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 (like the rest of the processor / CPU).

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

AXI4-Lite Connectivity

The AXI4-Lite wrapper (rtl/system_integration/neorv32_SystemTop_axi4lite.vhd) provides a Wishbone-to- AXI4-Lite bridge, compatible with Xilinx Vivado (IP packager and block design editor). All entity signals of this wrapper are of type std_logic or std_logic_vector, respectively.

The AXI Interface has been verified using Xilinx Vivado IP Packager and Block Designer. The AXI interface port signals are automatically detected when packaging the core.

The SLINK component provides up to 8 independent RX (receiving) and TX (sending) links for transmitting stream data. The interface provides higher bandwidth (and less latency) than the external memory bus interface, which makes it ideally suited to couple custom stream processing units (like CORDIC, FFTs or cryptographic accelerators).

Each individual link provides an internal FIFO for data buffering. The FIFO depth is globally defined for all TX links via the SLINK_TX_FIFO generic and for all RX links via the SLINK_RX_FIFO generic. The FIFO depth has to be at least 1, which will implement a simple input/output register. The maximum value is limited to 32768 entries. Note that the FIFO depth has to be a power of two (for optimal logic mapping).

The actual number of implemented RX/TX links is configured by the SLINK_NUM_RX and SLINK_NUM_TX generics. The SLINK module will be synthesized only if at least one of these generics is greater than zero. All unimplemented links are internally terminated and their according output signals are pulled to low level.

Theory of Operation

The SLINK provides eight data registers (DATA[i]) to access the links (read accesses will access the RX links, write accesses will access the TX links), one control register (CTRL) and one status register (STATUS).

The SLINK is globally activated by setting the control register’s enable bit SLINK_CTRL_EN. The actual data links are accessed by reading or writing the according link data registers DATA[0] to DATA[7]. For example, writing the DATA[0] will put the according data into the FIFO of TX link 0. Accordingly, reading from DATA[0] will return one data word from the FIFO of RX link 0.

The configuration (done via the SLINK generics) can be checked by software by evaluating bit fields in the control register. The SLINK_CTRL_TX_FIFO_Sx and SLINK_CTRL_RX_FIFO_Sx indicate the TX & RX FIFO sizes. The SLINK_CTRL_TX_NUMx and SLINK_CTRL_RX_NUMx bits represent the absolute number of implemented TX and RX links.

The status register shows the FIFO status flags of each RX and TX link. The SLINK_CTRL_RXx_AVAIL flags indicate that there is at least one data word in the according RX link’s FIFO. The SLINK_CTRL_TXx_FREE flags indicate there is at least one free entry in the according TX link’s FIFO. The SLINK_STATUS_RXx_HALF and SLINK_STATUS_RXx_HALF flags show if a certain FIFO’s fill level has exceeded half of its capacity.

Blocking Link Access

When directly accessing the link data registers (without checking the according FIFO status flags) the access is as blocking. That means the CPU access will stall until the accessed link responds. For example, when reading RX link 0 (via DATA[0] register) the CPU will stall, if there is not data available in the according FIFO yet. The CPU access will complete as soon as RX link 0 receives new data.

Vice versa, writing data to TX link 0 (via DATA[0] register) will stall the CPU access until there is at least one free entry in the link’s FIFO.

Non-Blocking Link Access

For a non-blocking link access concept, the FIFO status flags in STATUS need to be checked before reading/writing the actual link data register. For example, a non-blocking write access to a TX link 0 has to check SLINK_STATUS_TX0_FREE first. If the bit is set, the FIFO of TX link 0 can take another data word and the actual data can be written to DATA[0]. If the bit is cleared, the link’s FIFO is full and the status flag can be polled until it there is free space in the available.

This concept will not raise any exception as there is no "direct" access to the link data registers. However, non-blocking accesses require additional instructions to check the according status flags prior to the actual link access, which will reduce performance for high-bandwidth data streams.

Interrupts

The stream interface provides two interrupts that are globally driven by the RX and TX link’s FIFO fill level status. The behavior of these interrupts differs if the FIFO depth is exactly 1 (minimal) or if it is greater than 1.

When SLINK*X_FIFO_ is 1 a TX interrupt will fire if any TX link was full and becomes empty again. Accordingly, if the FIFO of any RX link was empty and a new data word appears in it, the RX interrupt fires.

When SLINK*X_FIFO_ is greater than 1 the TX interrupt will fire if any TX link’s FIFO falls below half-full fill level. Accordingly, the RX interrupt will fire if any RX link’s FIFO exceeds half-full fill level.

The interrupt service handler has to evaluate the SLINK status register is order to detect which link(s) has caused the interrupt. No further interrupt can fire until the CPU acknowledges the last interrupt by reading the SLINK status register. However, further IRQ conditions are buffered and will trigger another interrupt after the current one has been acknowledged.

Note that these interrupts can only fire if the SLINK module is actually enabled by setting the SLINK_CTRL_EN bit in the unit’s control register.

Stream Link Interface & Protocol

The SLINK interface consists of three signals dat, val and rdy for each RX and TX link. Each signal is an "array" with eight entires (one for each link). Note that an entry in slink_*x_dat is 32-bit wide while entries in slink_*x_val and slink_*x_rdy are are just 1-bit wide.

The stream link protocol is based on a simple FIFO-like interface between a source (sender) and a sink (receiver). Each link provides two signals for implementing a simple FIFO-style handshake. The slink_*x_val signal is set by the source if the according slink_*x_dat (also set by the source) contains valid data. The stream source has to ensure that both signals remain stable until the according slink_*x_rdy signal is set by the stream sink to indicate it can accept another data word.

In summary, a data word is transferred if both slink_*x_val(i) and slink_*x_rdy(i) are high.

Theory of Operation

The general purpose parallel IO port unit provides a simple 64-bit parallel input port and a 64-bit parallel output port. These ports can be used chip-externally (for example to drive status LEDs, connect buttons, etc.) or system-internally to provide control signals for other IP modules. The component is disabled for implementation when the IO_GPIO_EN generic is set false. In this case GPIO output port is tied to all-zero.

Theory of Operation

The watchdog (WDT) provides a last resort for safety-critical applications. The WDT has an internal 20-bit wide counter that needs to be reset every now and then by the user program. If the counter overflows, either a system reset or an interrupt is generated (depending on the configured operation mode).

Configuration of the watchdog is done by a single control register CTRL. The watchdog is enabled by setting the WDT_CTRL_EN bit. The clock used to increment the internal counter is selected via the 3-bit WDT_CTRL_CLK_SELx prescaler:

Whenever the internal timer overflows the watchdog executes one of two possible actions: Either a hard processor reset is triggered or an interrupt is requested at CPU’s fast interrupt channel #0. The WDT_CTRL_MODE bit defines the action to be taken on an overflow: When cleared, the Watchdog will trigger an IRQ, when set the WDT will cause a system reset. The configured actions can also be triggered manually at any time by setting the WDT_CTRL_FORCE bit. The watchdog is reset by setting the WDT_CTRL_RESET bit.

The cause of the last action of the watchdog can be determined via the WDT_CTRL_RCAUSE flag. If this flag is zero, the processor has been reset via the external reset signal. If this flag is set the last system reset was initiated by the watchdog.

The Watchdog control register can be locked in order to protect the current configuration. The lock is activated by setting bit WDT_CTRL_LOCK. In the locked state any write access to the configuration flags is ignored (see table below, "accessible if locked"). Read accesses to the control register are not effected. The lock can only be removed by a system reset (via external reset signal or via a watchdog reset action).

Theory of Operation

The MTIME machine system timer implements the memory-mapped MTIME timer from the official RISC-V specifications. This unit features a 64-bit system timer incremented with the primary processor clock. The current system time can also be obtained using the time[h] CSRs and is made available for processor-external use via the top’s mtime_o signal.

The 64-bit system time can be accessed via the TIME_LO and TIME_HI memory-mapped registers (read/write) and also via the CPU’s time[h] CSRs (read-only). A 64-bit time compare register – accessible via memory-mapped TIMECMP_LO and TIMECMP_HI registers – is used to configure an interrupt to the CPU. The interrupt is triggered whenever TIME (high & low part) >= TIMECMP (high & low part) and is directly forwarded to the CPU’s MTI interrupt.

Theory of Operation

In most cases, the UART is a standard interface used to establish a communication channel between the computer/user and an application running on the processor platform. The NEORV32 UARTs features a standard configuration frame configuration: 8 data bits, an optional parity bit (even or odd) and 1 stop bit. The parity and the actual Baudrate are configurable by software.

The UART0 is enabled by setting the UART_CTRL_EN bit in the UART control register CTRL. The actual transmission Baudrate (like 19200) is configured via the 12-bit UART_CTRL_BAUDxx baud prescaler (baud_rate) and the 3-bit UART_CTRL_PRSCx clock prescaler.

Baudrate = (f_main[Hz] / clock_prescaler) / (baud_rate + 1)

A new transmission is started by writing the data byte to be send to the lowest byte of the DATA register. The transfer is completed when the UART_CTRL_TX_BUSY control register flag returns to zero. A new received byte is available when the UART_DATA_AVAIL flag of the UART0_DATA register is set. A "frame error" in a received byte (broken stop bit) is indicated via the UART_DATA_FERR flag in the UART0_DATA register.

RX Double-Buffering

The UART receive engine provides a simple data buffer with two entries. These two entries are transparent for the user. The transmitting device can send up to 2 chars to the UART without risking data loss. If another char is sent before at least one char has been read from the buffer data loss occurs. This situation can be detected via the receiver overrun flag UART_DATA_OVERR in the DATA register. The flag is automatically cleared after reading DATA.

Parity Modes

The parity flag is added if the UART_CTRL_PMODE1 flag is set. When UART_CTRL_PMODE0 is zero the UART operates in "even parity" mode. If this flag is set, the UART operates in "odd parity" mode. Parity errors in received data are indicated via the UART_DATA_PERR flag in the UART_DATA registers. This flag is updated with each new received character. A frame error in the received data (i.e. stop bit is not set) is indicated via the UART_DATA_FERR flag in the DATA. This flag is also updated with each new received character

Hardware Flow Control – RTS/CTS

The UART supports hardware flow control using the standard CTS (clear to send) and/or RTS (ready to send / ready to receive "RTR") signals. Both hardware control flow mechanisms can be individually enabled.

If RTS hardware flow control is enabled by setting the UART_CTRL_RTS_EN control register flag, the UART will pull the uart0_rts_o signal low if the UART’s receiver is idle and no received data is waiting to get read by application software. As long as this signal is low the connected device can send new data. uart0_rts_o is always LOW if the UART is disabled.

The RTS line is de-asserted (going high) as soon as the start bit of a new incoming char has been detected. The transmitting device continues sending the current char and can also send another char (due to the RX double-buffering), which is done by most terminal programs. Any additional data send when RTS is still asserted will override the RX input buffer causing data loss. This will set the UART_DATA_OVERR flag in the DATA register. Any read access to this register clears the flag again.

If CTS hardware flow control is enabled by setting the UART_CTRL_CTS_EN control register flag, the UART’s transmitter will not start sending a new char until the uart0_cts_i signal goes low. If a new data to be send is written to the UART data register while uart0_cts_i is not asserted (=low), the UART will wait for uart0_cts_i to become asserted (=high) before sending starts. During this time, the UART busy flag UART_CTRL_TX_BUSY remains set.

If uart0_cts_i is asserted, no new data transmission will be started by the UART. The state of the uart0_cts_i signals has no effect on a transmission being already in progress.

Signal changes on uart0_cts_i during an active transmission are ignored. Application software can check the current state of the uart0_cts_o input signal via the UART_CTRL_CTS control register flag.

Interrupts

The UART features two interrupts: the "TX done interrupt" is triggered when a transmit operation (sending) has finished. The "RX done interrupt" is triggered when a data byte has been received. If the UART0 is not implemented, the UART0 interrupts are permanently tied to zero.

Simulation Mode

The default UART0 operation will transmit any data written to the DATA register via the serial TX line at the defined baud rate. Even though the default testbench provides a simulated UART0 receiver, which outputs any received char to the simulator console, such a transmission takes a lot of time. To accelerate UART0 output during simulation (and also to dump large amounts of data for further processing like verification) the UART0 features a simulation mode.

The simulation mode is enabled by setting the UART_CTRL_SIM_MODE bit in the UART0’s control register CTRL. Any other UART0 configuration bits are irrelevant, but the UART0 has to be enabled via the UART_CTRL_EN bit. When the simulation mode is enabled, any written char to DATA (bits 7:0) is directly output as ASCII char to the simulator console. Additionally, all text is also stored to a text file neorv32.uart0.sim_mode.text.out in the simulation home folder. Furthermore, the whole 32-bit word written to DATA is stored as plain 8-char hexadecimal value to a second text file neorv32.uart0.sim_mode.data.out also located in the simulation home folder.

If the UART is configured for simulation mode there will be NO physical UART0 transmissions via uart0_txd_o at all. Furthermore, no interrupts (RX done or TX done) will be triggered in any situation.

Theory of Operation

The secondary UART (UART1) is functional identical to the primary UART (Primary Universal Asynchronous Receiver and Transmitter (UART0)). Obviously, UART1 has different addresses for the control register (CTRL) and the data register (DATA) – see the register map below. However, the register bits/flags use the same bit positions and naming. Furthermore, the "RX done" and "TX done" interrupts are mapped to different CPU fast interrupt channels.

Simulation Mode

The secondary UART (UART1) provides the same simulation options as the primary UART. However, output data is written to UART1-specific files: neorv32.uart1.sim_mode.text.out is used to store plain ASCII text and neorv32.uart1.sim_mode.data.out is used to store full 32-bit hexadecimal encoded data words.

Theory of Operation

SPI is a synchronous serial transmission interface. The NEORV32 SPI transceiver allows 8-, 16-, 24- and 32- bit long transmissions. The unit provides 8 dedicated chip select signals via the top entity’s spi_csn_o signal.

The SPI unit is enabled via the SPI_CTRL_EN bit in the CTRL control register. The idle clock polarity is configured via the SPI_CTRL_CPHA bit and can be low (0) or high (1) during idle. The data quantity to be transferred within a single transmission is defined via the SPI_CTRL_SIZEx bits. The unit supports 8-bit (00), 16-bit (01), 24- bit (10) and 32-bit (11) transfers. Whenever a transfer is completed, the "transmission done interrupt" is triggered. A transmission is still in progress as long as the SPI_CTRL_BUSY flag is set.

The SPI controller features 8 dedicated chip-select lines. These lines are controlled via the control register’s SPI_CTRL_CSx bits. When a specifc SPI_CTRL_CSx bit is set, the according chip select line spi_csn_o(x) goes low (low-active chip select lines).

The SPI clock frequency is defined via the 3-bit SPI_CTRL_PRSCx clock prescaler. The following prescalers are available:

Based on the SPI_CTRL_PRSCx configuration, the actual SPI clock frequency f_SPI is derived from the processor’s main clock f_main and is determined by:

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

A transmission is started when writing data to the DATA register. The data must be LSB-aligned. So if the SPI transceiver is configured for less than 32-bit transfers data quantity, the transmit data must be placed into the lowest 8/16/24 bit of DATA. Vice versa, the received data is also always LSB-aligned.

Theory of Operation

The two wire interface – also called "I²C" – is a quite famous interface for connecting several on-board components. Since this interface only needs two signals (the serial data line twi_sda_io and the serial clock line twi_scl_io) – despite of the number of connected devices – it allows easy interconnections of several peripheral nodes.

The NEORV32 TWI implements a TWI controller. It features "clock stretching" (if enabled via the control register), so a slow peripheral can halt the transmission by pulling the SCL line low. Currently, no multi-controller support is available. Also, the NEORV32 TWI unit cannot operate in peripheral mode.

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.

Data is send by writing a byte to the DATA register. Received data can also be read from this register. The TWI controller is busy (transmitting data or performing a START or STOP condition) as long as the TWI_CTRL_BUSY bit in the control register is set.

An accessed peripheral has to acknowledge each transferred byte. When the TWI_CTRL_ACK bit is set after a completed transmission, the accessed peripheral has send an acknowledge. If it is cleared after a transmission, the peripheral has send a not-acknowledge (NACK). The NEORV32 TWI controller can also send an ACK by itself ("controller acknowledge MACK") after a transmission by pulling SDA low during the ACK time slot. Set the TWI_CTRL_MACK bit to activate this feature. If this bit is cleared, the ACK/NACK of the peripheral is sampled in this time slot instead (normal mode).

In summary, the following independent TWI operations can be triggered by the application program:

The TWI clock frequency is defined via the 3-bit TWI_CTRL_PRSCx clock prescaler. The following prescalers are available:

Based on the TWI_CTRL_PRSCx configuration, the actual TWI clock frequency f_SCL is derived from the processor main clock f_main and is determined by:

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

The PWM controller implements a pulse-width modulation controller with up to 60 independent channels and 8- bit resolution per channel. The actual number of implemented channels is defined by the IO_PWM_NUM_CH generic. Setting this generic to zero will completely remove the PWM controller from the design.

The PWM controller is based on an 8-bit base counter with a programmable threshold comparators for each channel that defines the actual duty cycle. The controller can be used to drive fancy RGB-LEDs with 24- bit true color, to dim LCD back-lights or even for "analog" control. An external integrator (RC low-pass filter) can be used to smooth the generated "analog" signals.

Theory of Operation

The PWM controller is activated by setting the PWM_CTRL_EN bit in the module’s control register CTRL. When this bit is cleared, the unit is reset and all PWM output channels are set to zero. The 8-bit duty cycle for each channel, which represents the channel’s "intensity", is defined via an 8-bit value. The module provides up to 15 duty cycle registers DUTY[0] to DUTY[14] (depending on the number of implemented channels). Each register contains the duty cycle configuration for 4 consecutive channels. For example, the duty cycle of channel 0 is defined via bits 7:0 in DUTY[0]. The duty cycle of channel 2 is defined via bits 15:0 in DUTY[0]. Channel 4’s duty cycle is defined via bits 7:0 in DUTY[1] and so on.

Based on the configured duty cycle the according intensity of the channel can be computed by the following formula:

Intensity_x = DUTY[y](i*8+7 downto i*8) / (2⁸)

The base frequency of the generated PWM signals is defined by the PWM core clock. This clock is derived from the main processor clock and divided by a prescaler via the 3-bit PWM_CTRL_PRSCx in the unit’s control register. The following prescalers are available:

The resulting PWM base frequency is defined by:

f_PWM = f_main[Hz] / (2⁸ * clock_prescaler)