The NEORV32 RISC-V Processor: Datasheet

The following table shows exemplary NEORV32 processor implementation results for different FPGA platforms. Most setups use the default peripheral configuration (like no CFS, no caches and no TRNG), no external memory interface and only internal instruction and data memories (IMEM uses 16kB and DMEM uses 8kB memory space).

Notes

The performance of the NEORV32 was tested and evaluated using the Core Mark CPU benchmark. This benchmark focuses on testing the capabilities of the CPU core itself rather than the performance of the whole system. The according source code and the SW project can be found in the sw/example/coremark folder.

The resulting CoreMark score is defined as CoreMark iterations per second. The execution time is determined via the RISC-V [m]cycle[h] CSRs. The relative CoreMark score is defined as CoreMark score divided by the CPU’s clock frequency in MHz.

The NEORV32 CPU is based on a multi-cycle architecture. Each instruction is executed in a sequence of several consecutive micro operations. Hence, each instruction requires several clock cycles to execute.

The average CPI (cycles per instruction) depends on the instruction mix of a specific applications and also on the available CPU extensions. The following table shows the performance results for successfully (!) running 2000 CoreMark iterations.

The average CPI is computed by dividing the total number of required clock cycles (only the timed core to avoid distortion due to IO wait cycles) by the number of executed instructions ([m]instret[h] CSRs). The executables were generated using optimization -O3.

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

See section Instruction Sets and Extensions 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 Processor-Internal Modules for more information.

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 mechanisms. The figure below shows details and further options of the two most common boot scenarios.

The general boot scenario (1 or 2) is configured via the INT_BOOTLOADER_EN generic. If this generic is set true, boot scenario 1 is used. If it is set false, boot scenario 2 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 wb_pipe_mode_c constant in the in the main VHDL package file (rtl/neorv32_package.vhd):

When wb_pipe_mode_c is disabled, all bus control signals including STB are active (and stable) until the transfer is acknowledged/terminated. If wb_pipe_mode_c is enabled, 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. The configuration is done via the wb_rx_buffer_c constant in the in the main VHDL package file (rtl/neorv32_package.vhd):

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 global wb_big_endian_c constant in the main VHDL package file (rtl/neorv32_package.vhd). 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_FEATURES_MEM_EXT_ENDIAN flag in the processor’s SYSINFO module (see section System Configuration Information Memory (SYSINFO) for more information).

AXI4-Lite Connectivity

The AXI4-Lite wrapper (rtl/templates/system/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.

Theory of Operation

The general purpose parallel IO port unit provides a simple 32-bit parallel input port and a 32-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. When the modules is disabled for implementation the GPIO output port is tied to zero.

Pin-Change Interrupt

The parallel input port gpio_i features a single pin-change interrupt. Whenever an input pin has a low-to-high or high-to-low transition, the interrupt is triggered. By default, the pin-change interrupt is disabled and can be enabled using a bit mask that has to be written to the GPIO_INPUT register. Each set bit in this mask enables the pin-change interrupt for the corresponding input pin. If more than one input pin is enabled for triggering the pin-change interrupt, any transition on one of the enabled input pins will trigger the CPU’s pinchange interrupt. If the modules is disabled for implementation, the pin-change interrupt is also permanently disabled.

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 WDT_CT. The watchdog is enabled by setting the WDT_CT_EN bit. The clock used to increment the internal counter is selected via the 3-bit WDT_CT_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_CT_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_CT_FORCE bit. The watchdog is reset by setting the WDT_CT_RESET bit.

The cause of the last action of the watchdog can be determined via the WDT_CT_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_CT_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 MTIME_LO and MTIME_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 MTIMECMP_LO and MTIMECMP_HI registers – are used to configure an interrupt to the CPU. The interrupt is triggered whenever MTIME (high & low part) >= MTIMECMP (high & low part) and is directly forwarded to the CPU’s MTI interrupt.

The 64-bit counter and the 64-bit comparator are implemented as 2×32-bit counters and comparators with a registered carry to prevent a 64-bit carry chain and thus, to simplify timing closure.

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_CT_EN bit in the UART control register UART0_CT. The actual transmission Baudrate (like 19200) is configured via the 12-bit UART_CT_BAUDxx baud prescaler (baud_rate) and the 3-bit UART_CT_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 UART0_DATA register. The transfer is completed when the UART_CT_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 UART0_DATA register. The flag is automatically cleared after reading UART0_DATA.

Parity Modes

The parity flag is added if the UART_CT_PMODE1 flag is set. When UART_CT_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 UART0_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_CT_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 UART0_DATA register. Any read access to this register clears the flag again.

If CTS hardware flow control is enabled by setting the UART_CT_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_CT_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_CT_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 UART0_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_CT_SIM_MODE bit in the UART0’s control register UART0_CT. Any other UART0 configuration bits are irrelevant, but the UART0 has to be enabled via the UART_CT_EN bit. When the simulation mode is enabled, any written char to UART0_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 UART0_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 thw control register (UART1_CT) and the data register (UART1_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_CT_EN bit in the SPI_CT control register. The idle clock polarity is configured via the SPI_CT_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_CT_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_CT_BUSY flag is set.

The SPI controller features 8 dedicated chip-select lines. These lines are controlled via the control register’s SPI_CT_CSx bits. When a specifc SPI_CT_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_CT_PRSCx clock prescaler. The following prescalers are available:

Based on the SPI_CT_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 SPI_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 SPI_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_CT_EN bit in the TWI_CT 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_CT_START or TWI_CT_STOP) in the control register.

Data is send by writing a byte to the TWI_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_CT_BUSY bit in the control register is set.

An accessed peripheral has to acknowledge each transferred byte. When the TWI_CT_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_CT_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_CT_PRSCx clock prescaler. The following prescalers are available:

Based on the TWI_CT_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_CT_EN bit in the module’s control register PWM_CT. 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 PWM_DUTY0 to PWM_DUTY14 (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 PWM_DUTY0. The duty cycle of channel 2 is defined via bits 15:0 in PWM_DUTY0. Channel 4’s duty cycle is defined via bits 7:0 in PWM_DUTY1 and so on.

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

Intensity_x = PWM_DUTY_CHx / (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_CT_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)

Theory of Operation

The NEORV32 true random number generator provides physical true random numbers for your application. Instead of using a pseudo RNG like a LFSR, the TRNG of the processor uses a simple, straight-forward ring oscillator as physical entropy source. Hence, voltage and thermal fluctuations are used to provide true physical random data.

Architecture

The NEORV32 TRNG is based on simple ring oscillators, which are implemented as an inverter chain with an odd number of inverters. A latch is used to decouple each individual inverter. Basically, this architecture is some king of asynchronous LFSR.

The output of several ring oscillators are synchronized using two registers and are XORed together. The resulting output is de-biased using a von-Neumann randomness extractor. This de-biased output is further processed by a simple 8-bit Fibonacci LFSR to improve whitening. After at least 8 clock cycles the state of the LFSR is sampled and provided as final data output.

To prevent the synthesis tool from doing logic optimization and thus, removing all but one inverter, the TRNG uses simple latches to decouple an inverter and its actual output. The latches are reset when the TRNG is disabled and are enabled one by one by a "real" shift register when the TRNG is activated. This construct can be synthesized for any FPGA platform. Thus, the NEORV32 TRNG provides a platform independent architecture.

TRNG Configuration

The TRNG uses several ring-oscillators, where the next oscillator provides a slightly longer chain (more inverters) than the one before. This increment is constant for all implemented oscillators. This setup can be customized by modifying the "Advanced Configuration" constants in the TRNG’s VHDL file:

Using the TRNG

The TRNG features a single register for status and data access. When the TRNG_CT_EN control register bit is set, the TRNG is enabled and starts operation. As soon as the TRNG_CT_VALID bit is set, the currently sampled 8-bit random data byte can be obtained from the lowest 8 bits of the TRNG_CT register (TRNG_CT_DATA_MSB : TRNG_CT_DATA_LSB). The TRNG_CT_VALID bit is automatically cleared when reading the control register.

Randomness "Quality" I have not verified the quality of the generated random numbers (for example using NIST test suites). The quality is highly effected by the actual configuration of the TRNG and the resulting FPGA mapping/routing. However, generating larger histograms of the generated random number shows an equal distribution (binary average of the random numbers = 127). A simple evaluation test/demo program can be found in sw/example/demo_trng.

Theory of Operation

The custom functions subsystem can be used to implement application-specific user-defined co-processors (like encryption or arithmetic accelerators) or peripheral/communication interfaces. In contrast to connecting custom hardware accelerators via the external memory interface, the CFS provide a convenient and low-latency extension and customization option.

The CFS provides up to 32x 32-bit memory-mapped registers (see register map table below). The actual functionality of these register has to be defined by the hardware designer.

Take a look at the template CFS VHDL source file (rtl/core/neorv32_cfs.vhd). The file is highly commented to illustrate all aspects that are relevant for implementing custom CFS-based co-processor designs.

CFS Software Access

The CFS memory-mapped registers can be accessed by software using the provided C-language aliases (see register map table below). Note that all interface registers provide 32-bit access data of type uint32_t.

CFS Interrupt

The CFS provides a single one-shot interrupt request signal mapped to the CPU’s fast interrupt channel 1. See section Processor Interrupts for more information.

CFS Configuration Generic

By default, the CFS provides a single 32-bit std_(u)logic_vector configuration generic IO_CFS_CONFIG that is available in the processor’s top entity. This generic can be used to pass custom configuration options from the top entity down to the CFS entity.

CFS Custom IOs

By default, the CFS also provides two unidirectional input and output conduits cfs_in_i and cfs_out_o. These signals are propagated to the processor’s top entity. The actual use of these signals has to be defined by the hardware designer. The size of the input signal conduit cfs_in_i is defined via the (top’s) IO_CFS_IN_SIZE configuration generic (default = 32-bit). The size of the output signal conduit cfs_out_o is defined via the (top’s) IO_CFS_OUT_SIZE configuration generic (default = 32-bit). If the custom function subsystem is not implemented (IO_CFS_EN = false) the cfs_out_o signal is tied to all-zero.

Theory of Operation

The numerically-controller oscillator (NCO) provides a precise arbitrary linear frequency generator with three independent channels. Based on a direct digital synthesis core, the NCO features a 20-bit wide accumulator that is incremented with a programmable "tuning word". Whenever the accumulator overflows, a flip flop is toggled that provides the actual frequency output. The accumulator increment is driven by one of eight configurable clock sources, which are derived from the processor’s main clock.

The NCO features four accessible registers: the control register NCO_CT and three NCO_TUNE_CHi registers for the tuning word of each channel i. The NCO is globally enabled by setting the NCO_CT_EN bit in the control register. If this bit is cleared, the accumulators of all channels are reset. The clock source for each channel i is selected via the three bits NCO_CT_CHi_PRSCx prescaler. The resulting clock is generated from the main processor clock (f_main) divided y the selected prescaler.

The resulting output frequency of each channel i is defined by the following equation:

f_NCO(i) = ( f_main[Hz] / clock_prescaler(i) ) * (tuning_word(i) / 2*2²⁰⁺¹)

The maximum NCO frequency f_NCOmax is configured when using the minimal clock prescaler and a maximum all-one tuning word:

f_NCOmax = ( f_main[Hz] / 2 ) * (1 / 2*2²⁰⁺¹)

The minimum "frequency" is always 0 Hz when the tuning word is zero. The frequency resolution f_NCOres is defined using the maximum clock prescaler and a minimal non-zero tuning word (= 1):

f_NCOres = ( f_main[Hz] / 4096 ) * (1 / 2*2²⁰⁺¹)

Assuming a processor frequency of f_main = 100 MHz the maximum NCO output frequency is f_NCOmax = 12.499 MHz with an NCO frequency resolution of f_NCOres = 0.00582 Hz.

Advanced Configuration

The idle polarity of each channel is configured via the NCO_CT_CHi_IDLE_POL flag and can be either 0 (idle low) or 1 (idle high), which basically allows to invert the NCO output. If the NCO is globally disabled by clearing the NCO_CT_EN flag, nco_o(i) output bit i is set to the according NCO_CT_CHi_IDLE_POL.

The current state of each NCO channel output can be read by software via the NCO_CT_CHi_OUTPUT bit. The NCO frequency output is normally available via the top nco_o output signal. The according channel output can be permanently set to zero by clearing the according NCO_CT_CHi_OE bit.

Each NCO channel can operate either in standard mode or in pulse mode. The mode is configured via the according channel’s NCO_CT_CHi_MODE control register bit.

Standard Operation Mode

If this NCO_CT_CHi_MODE bit of channel i is cleared, the channel operates in standard mode providing a frequency with exactly 50% duty cycle (T_high = T_low).

Pulse Operation Mode

If the NCO_CT_CHi_MODE bit of channel i is set, the channel operates in pulse mode. In this mode, the duty cycle can be modified to generate active pulses with variable length. Note that the "active" pulse polarity is defined by the inverted NCO_CT_CHi_IDLE_POL bit.

Eight different pulse lengths are available. The active pulse length is defined as number of NCO clock cycles, where the NCO clock is defined via the clock prescaler bits NCO_CT_Chi_PRSCx. The pulse length of channel i is programmed by the 3-bit NCO_CT_CHi_PULSEx configuration:

If NCO_CT_CHi_IDLE_POL is cleared, T_high is defined by the NCO_CT_CHi_PULSEx configuration and T_low = T – T_high. If NCO_CT_CHi_IDLE_POL is set, T_low is defined by the NCO_CT_CHi_PULSEx configuration and T_high = T – T_low.

The actual output frequency of the channel (defined via the clock prescaler and the tuning word) is not affected by the pulse configuration.

For simple PWM applications, that do not require a precise frequency but a more flexible duty cycle configuration, see section Pulse-Width Modulation Controller (PWM).