<<< :sectnums: ==== Processor-External Memory Interface (WISHBONE) (AXI4-Lite) [cols="<3,<3,<4"] [frame="topbot",grid="none"] |======================= | Hardware source file(s): | neorv32_wishbone.vhd | | Software driver file(s): | none | _implicitly used_ | Top entity port: | `wb_tag_o` | request tag output (3-bit) | | `wb_adr_o` | address output (32-bit) | | `wb_dat_i` | data input (32-bit) | | `wb_dat_o` | data output (32-bit) | | `wb_we_o` | write enable (1-bit) | | `wb_sel_o` | byte enable (4-bit) | | `wb_stb_o` | strobe (1-bit) | | `wb_cyc_o` | valid cycle (1-bit) | | `wb_ack_i` | acknowledge (1-bit) | | `wb_err_i` | bus error (1-bit) | | `fence_o` | an executed `fence` instruction | | `fencei_o` | an executed `fence.i` instruction | Configuration generics: | _MEM_EXT_EN_ | enable external memory interface when _true_ | | _MEM_EXT_TIMEOUT_ | number of clock cycles after which an unacknowledged external bus access will auto-terminate (0 = disabled) | | _MEM_EXT_PIPE_MODE_ | when _false_ (default): classic/standard Wishbone protocol; when _true_: pipelined Wishbone protocol | | _MEM_EXT_BIG_ENDIAN_ | byte-order (Endianness) of external memory interface; true=BIG, false=little (default) | | _MEM_EXT_ASYNC_RX_ | use registered RX path when _false_ (default); use async/direct RX path when _true_ | | _MEM_EXT_ASYNC_TX_ | use registered TX path when _false_ (default); use async/direct TX path when _true_ | CPU interrupts: | none | |======================= The external memory interface provides a Wishbone b4-compatible on-chip bus interface. The bus interface is implemented if the _MEM_EXT_EN_ generic is _true_. This interface can be used to attach external memories, custom hardware accelerators, additional IO devices or all other kinds of IP blocks to the processor. The external interface is _not_ mapped to a _specific_ address space region. Instead, all CPU memory accesses that do not target a processor-internal module are delegated to the external memory interface. In summary, a CPU load/store access is delegated via the external bus interface if... * it does not target the internal instruction memory IMEM (if implemented at all). * **and** it does not target the internal data memory DMEM (if implemented at all). * **and** it does not target the internal bootloader ROM or any of the IO devices - regardless if one or more of these components are actually implemented or not. .Address Space Layout [TIP] See section <<_address_space>> for more information. .Execute-in-Place Module [NOTE] If the Execute In Place module (XIP) is implemented accesses targeting the XIP memory-mapped-region will not be forwarded to the external memory interface. See section <<_execute_in_place_module_xip>> for more information. **Wishbone Bus Protocol** The external memory interface either uses the **standard** (also called "classic") Wishbone protocol (default) or **pipelined** Wishbone protocol. The protocol to be used is configured via the <<_mem_ext_pipe_mode>> generic: * If _MEM_EXT_PIPE_MODE_ is _false_, all bus control signals including `wb_stb_o` are active and remain stable until the transfer is acknowledged/terminated. * If _MEM_EXT_PIPE_MODE_ is _true_, all bus control except `wb_stb_o` are active and remain until the transfer is acknowledged/terminated. In this case, `wb_stb_o` is asserted only during the very first bus clock cycle. .Exemplary Wishbone bus accesses using "classic" and "pipelined" protocol [cols="^2,^2"] [grid="none"] |======================= a| image::wishbone_classic_read.png[700,300] a| image::wishbone_pipelined_write.png[700,300] | **Classic** Wishbone read access | **Pipelined** Wishbone write access |======================= .Wishbone Specs. [TIP] 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. **Bus Access** The NEORV32 Wishbone gateway does not support burst transfer yet, so there is always just a single transfer in "in fly". Hence, the Wishbone `STALL` signal is not implemented. An accessed Wishbone device does not have to respond immediately to a bus request by sending an ACK. Instead, there is a _time window_ where the device has to acknowledge the transfer. This time window id configured by the _MEM_EXT_TIMEOUT_ top generic that defines the maximum time (in clock cycles) a bus access can be pending before it is automatically terminated with an error condition. If _MEM_EXT_TIMEOUT_ is set to zero, the timeout disabled an a bus access can take an arbitrary number of cycles to complete (this is **not recommended**!). When _MEM_EXT_TIMEOUT_ is greater than zero, the Wishbone gateway starts an internal countdown whenever the CPU accesses an address via the external memory interface. If the accessed device does not acknowledge (via `wb_ack_i`) or terminate (via `wb_err_i`) the transfer within _MEM_EXT_TIMEOUT_ clock cycles, the bus access is automatically canceled setting `wb_cyc_o` low again and a CPU load/store/instruction fetch bus access fault exception is raised. .External "Address Space Holes" [IMPORTANT] Setting _MEM_EXT_TIMEOUT_ to zero will permanently stall the CPU if the targeted Wishbone device never responds. Hence, _MEM_EXT_TIMEOUT_ should be always set to a value greater than zero. + + This feature can be used as **safety guard** if the external memory system does not check for "address space holes". That means that accessing addresses, which do not belong to a certain memory or device, do not permanently stall the processor due to an unacknowledged/unterminated bus access. If the external memory system can guarantee to acknowledge **any** bus accesses (even if targeting an unimplemented address) the timeout feature can be safely disabled (_MEM_EXT_TIMEOUT_ = 0). **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. * `wb_tag_o(0)` 1: privileged access (CPU is in machine mode); 0: unprivileged access (CPU is not in machine mode) * `wb_tag_o(1)` always zero (indicating "secure access") * `wb_tag_o(2)` 1: instruction fetch access, 0: data access **Endianness** The NEORV32 CPU and the Processor setup are *little-endian* architectures. To allow direct connection to a big-endian memory system the external bus interface provides an _Endianness configuration_. The Endianness of the external memory interface can be configured via the _MEM_EXT_BIG_ENDIAN_ generic. By default, the external memory interface uses little-endian byte-order. Application software can check the Endianness configuration of the external bus interface via the SYSINFO module (see section <<_system_configuration_information_memory_sysinfo>> for more information). **Access Latency** By default, the Wishbone gateway introduces two additional latency cycles: processor-outgoing (`*_o`) and processor-incoming (`*_i`) signals are fully registered. Thus, any access from the CPU to a processor-external devices via Wishbone requires 2 additional clock cycles. This can ease timing closure when using large (combinatorial) Wishbone interconnection networks. Optionally, the latency of the Wishbone gateway can be reduced by removing the input and output register stages. Enabling the _MEM_EXT_ASYNC_RX_ option will remove the input register stage; enabling _MEM_EXT_ASYNC_TX_ option will remove the output register stages. Each enabled option reduces access latency by 1 cycle. .Output Gating [NOTE] All outgoing Wishbone signals use a "gating mechanism" so they only change if there is a actual Wishbone transaction being in progress. This can reduce dynamic switching activity in the external bus system and also simplifies simulation-based inspection of the Wishbone transactions. Note that this output gating is only available if the output register buffer is not disabled (_MEM_EXT_ASYNC_TX_ = _false_). **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. See The USer Guide for more information: https://stnolting.github.io/neorv32/ug/#_packaging_the_processor_as_ip_block_for_xilinx_vivado_block_designer [WARNING] Using the auto-termination timeout feature (_MEM_EXT_TIMEOUT_ greater than zero) is **not AXI4 compliant** as the AXI protocol does not support "aborting" bus transactions. Therefore, the NEORV32 top wrapper with AXI4-Lite interface (`rtl/system_integration/neorv32_SystemTop_axi4lite`) configures _MEM_EXT_TIMEOUT_ = 0 by default.