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.

These generics allow to customize the Zihpm ISA extension. Note that the following generics are ignored if the CPU_EXTENSION_RISCV_Zihpm generic is false. See section Zihpm 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 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 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.

Theory of Operation

The Bus Keeper is a fundamental component of the processor’s internal bus system that ensures correct bus operations to maintain execution safety. The Bus Keeper monitors every single bus transactions that is intimated by the CPU. If an accessed device responds with an error condition or do not respond within a specific access time window, the according bus access fault exception is raised. The following exceptions can be raised by the Bus Keeper (see section NEORV32 Trap Listing for all CPU 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 NEORV32_BUSKEEPER.CTRL to retrieve further details of the bus exception. The BUSKEEPER_ERR_FLAG bit indicates that an actual bus access fault has occurred. The bit is sticky once set is automatically cleared when reading the NEORV32_BUSKEEPER.CTRL register. The BUSKEEPER_ERR_TYPE indicated the tape or bus fault:

Furthermore, application software can determine the source of the bus access fault via the BUSKEEPER_ERR_SRC bit:

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.

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.

Interrupts

The stream interface provides two independent interrupts that are globally driven by the RX and TX link’s FIFO fill level status. Each RX and TX link provides an individual interrupt enable flag and an individual interrupt type flag that allows to configure interrupts only for certain (or all) links and for application- specific interrupt conditions. The interrupt configuration is done using the NEORV32_SLINK.IRQ register. Any interrupt can only become pending if the SLINK module is enabled at all.

The current FIFO fill-level of a specific RX link can only raise an interrupt request if it’s interrupt enable flag SLINK_IRQ_RX_EN is set. Vice versa, the current FIFO fill-level of a specific TX link can only raise an interrupt request if it’s interrupt enable flag SLINK_IRQ_TX_EN is set.

The RX link’s SLINK_IRQ_RX_MODE flags define the FIFO fill-level condition for raising an RX interrupt request: * If a link’s interrupt mode flag is 1 an IRQ is generated when the link’s FIFO is not empty ("RX data available"). * If a link’s interrupt mode flag is 0 an IRQ is generated when the link’s FIFO is at least half-full ("time to get data from RX FIFO to prevent overflow").

The TX link’s SLINK_IRQ_TX_MODE flags define the FIFO fill-level condition for raising an TX interrupt request: * If a link’s interrupt mode flag is 1 an IRQ is generated when the link’s FIFO is not full ("space left in FIFO for new TX data"). * If a link’s interrupt mode flag is 0 an IRQ is generated when the link’s FIFO is less than half-full ("SW can send SLINK_TX_FIFO/2 data words without checking any flags").

If any configured interrupt condition is fulfilled, the according global SLINK RX / SLINK TX CPU interrupt becomes pending. If the interrupt enable flags of several links are set, the interrupt service handler has to evaluate the SLINK status register is order to detect which link(s) caused the interrupt.

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 assert an IRQ, when set the WDT will cause a system reset. The configured action 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.

A watchdog interrupt can only occur if the watchdog is enabled and interrupt mode is enabled. A pending interrupt is cleared by either disabling the watchdog or by resetting the watchdog.

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. The interrupt remain active (=pending) until TIME < TIMECMP (either by modifying TIME or TIMECMP).

The UART is a standard serial interface mainly used to establish a communication channel between a host computer computer/user and an application running on the embedded processor.

The NEORV32 UARTs feature independent transmitter and receiver with a fixed frame configuration of 8 data bits, an optional parity bit (even or odd) and a fixed stop bit. The actual transmission rate - the Baudrate - is programmable via software. Optional FIFOs with custom sizes can be configured for the transmitter and receiver independently.

The UART features two memory-mapped registers CTRL and DATA, which are used for configuration, status check and data transfer.

Theory of Operation

UART0 is enabled by setting the UART_CTRL_EN bit in the UART0 control register CTRL. The Baud rate is configured via a 12-bit UART_CTRL_BAUDxx baud prescaler (baud_prsc) and a 3-bit UART_CTRL_PRSCx clock prescaler (clock_prescaler) that scales the processor’s primary clock (f_main).

Baud rate = (f_main[Hz] / clock_prescaler) / (baud_prsc + 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 DATA register is set. A "frame error" in a received byte (invalid stop bit) is indicated via the UART_DATA_FERR flag in the DATA register. The flag is cleared by reading the DATA register.

RX and TX FIFOs

UART0 provides optional FIFO buffers for the transmitter and the receiver. The UART0_RX_FIFO generic defines the depth of the RX FIFO (for receiving data) while the UART0_TX_FIFO defines the depth of the TX FIFO (for sending data). Both generics have to be a power of two with a minimal allowed value of 1. This minimal value will implement simple "double-buffering" instead of full-featured FIFOs. Both FIFOs are cleared whenever UART0 is disabled (clearing UART_CTRL_EN in CTRL).

The state of both FIFO (empty, at lest half-full, full) is available via the UART_CTRL?X_EMPTY_, UART_CTRL?X_HALF_ and UART_CTRL*X_FULL_ flags in the CTRL register.

If the RX FIFO is already full and new data is received by the receiver unit, the UART_DATA_OVERR flag in the DATA register is set indicating an "overrun". This flag is cleared by reading the DATA register.

Hardware Flow Control - RTS/CTS

UART0 supports optional 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 enabled individually.

Parity Modes

An optional parity bit can be added to the data stream 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 DATA register. This flag is updated with each new received character and is cleared by reading the DATA register.

Interrupts

UART0 features two independent interrupt for signaling certain RX and TX conditions. The behavior of these interrupts differ based on the configured FIFO size. If the according FIFO size is greater than 1, the UART_CTRL_RX_IRQ and UART_CTRL_TX_IRQ CTRL flags allow a more fine-grained IRQ configuration.

An interrupt can only become pending if the according interrupt condition is fulfilled and the UART is enabled at all. A pending interrupt is removed by resolving the interrupt-triggering conditions (for example by reading data from the more-than-half-full RX FIFO).

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 via the physical link. To accelerate UART0 output during simulation (and also to dump large amounts of data) the UART0 features a simulation mode.

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 for this mode but UART0 has to be enabled via the UART_CTRL_EN bit. There will be no physical UART0 transmissions via uart0_txd_o at all when simulation mode is enabled. Furthermore, no interrupts (RX & TX) will be triggered.

When the simulation mode is enabled any data written to DATA[7:0] is directly output as ASCII char to the simulator console. Additionally, all chars are 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[31:0] 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.

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. 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. 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 data words.