axi_lite_xbar.md

AXI4-Lite Fully-Connected Crossbar

axi_lite_xbar is a fully-connected crossbar that implements the AXI4-Lite specification.

Design Overview

axi_lite_xbar is a fully-connected crossbar, which means that each master module that is connected to a slave port for of the crossbar has direct wires to all slave modules that are connected to the master ports of the crossbar. A block-diagram of the crossbar is shown below:

The crossbar has a configurable number of slave and master ports.

Address Map

axi_lite_xbar uses the same address decoding scheme as axi_xbar.

Decode Errors and Default Slave Port

Each slave port has its own internal decode error slave module. If the address of a transaction does not match any rule, the transaction is routed to that decode error slave module. That module absorbs each transaction and responds with a decode error (with the proper number of beats). The data of each read response beat is 32'hBADCAB1E (zero-extended or truncated to match the data width).

Each slave port can have a default master port. If the default master port is enabled for a slave port, any address on that slave port that does not match any rule is routed to the default master port instead of the decode error slave. The default master port can be enabled and changed at run time (it is an input signal to the crossbar), and the same restrictions as for the address map apply.

Configuration

The crossbar is configured through the Cfg parameter with a axi_pkg::xbar_cfg_t struct. That struct has the following fields:

Name	Type	Definition
NoSlvPorts	int unsigned	The number of AXI4-Lite slave ports of the crossbar (in other words, how many AXI4-Lite master modules can be attached).
NoMstPorts	int unsigned	The number of AXI4-Lite master ports of the crossbar (in other words, how many AXI4-Lite slave modules can be attached).
MaxMstTrans	int unsigned	Each slave port can have at most this many transactions in flight.
MaxSlvTrans	int unsigned	Each master port can have at most this many transactions in flight.
FallThrough	bit	Routing decisions on the AW channel fall through to the W channel. Enabling this allows the crossbar to accept a W beat in the same cycle as the corresponding AW beat, but it increases the combinatorial path of the W channel with logic from the AW channel.
LatencyMode	enum logic [9:0]	Latency on the individual channels, defined in detail in section Pipelining and Latency below.
AxiIdWidthSlvPorts	int unsigned	Not used by the AXI4-Lite crossbar. Set default: '0.
AxiIdUsedSlvPorts	int unsigned	Not used by the AXI4-Lite crossbar. Set default: '0.
AxiAddrWidth	int unsigned	The AXI4-Lite address width.
AxiDataWidth	int unsigned	The AXI4-Lite data width.
NoAddrRules	int unsigned	The number of address map rules.

The other parameters are types to define the ports of the crossbar. The *_chan_t and *_req_t/*_resp_t types must be bound in accordance to the configuration with the AXI_TYPEDEF macros defined in axi/typedef.svh. The rule_t type must be bound to an address decoding rule with the same address width as in the configuration, and axi_pkg contains definitions for 64- and 32-bit addresses.

Pipelining and Latency

The LatencyMode parameter allows to insert spill registers after each channel (AW, W, B, AR, and R) of each master port (i.e., each multiplexer) and before each channel of each slave port (i.e., each demultiplexer). Spill registers cut combinatorial paths, so this parameter reduces the length of combinatorial paths through the crossbar.

Some common configurations are given in the xbar_latency_e enum. The recommended configuration (CUT_ALL_AX) is to have a latency of 2 on the AW and AR channels because these channels have the most combinatorial logic on them. Additionally, FallThrough should be set to 0 to prevent logic on the AW channel from extending combinatorial paths on the W channel. However, it is possible to run the crossbar in a fully combinatorial configuration by setting LatencyMode to NO_LATENCY and FallThrough to 1. If two crossbars are connected in both directions, meaning both have one of their master_ports connected to a slave_port of the other, it is required to have either CUT_SLV_PORTS, CUT_MST_PORTS or CUT_ALL_PORTS as the configuration of the two crossbars. This is to prevent timing loops. The other configurations will lead to timing loops in simulation and synthesis on the not cut channels between the two crossbars.

Ports

Name	Description
clk_i	Clock to which all other signals (except rst_ni) are synchronous.
rst_ni	Reset, asynchronous, active-low.
test_i	Test mode enable (active-high).
slv_ports_*	Array of slave ports of the crossbar. The array index of each port is the index of the slave port. This index will be prepended to all requests at one of the master ports.
mst_ports_*	Array of master ports of the crossbar. The array index of each port is the index of the master port.
addr_map_i	Address map of the crossbar (see section Address Map above).
en_default_mst_port_i	One bit per slave port that defines whether the default master port is active for that slave port (see section Decode Errors and Default Slave Port above).
default_mst_port_i	One master port index per slave port that defines the default master port for that slave port (if active).

Ordering and Stalls

The ordering inside the crossbar is organized by a network of FIFO's ensuring the in order transaction transmission. It is possible to have multiple transactions to different master ports in flight, however when one of the slave modules connected to these master ports stalls, other consecutive in fight transaction will also be stalled.

Verification Methodology

This module has been verified with a directed random verification testbench, described and implemented in test/tb_axi_lite_xbar.sv.

Design Rationale for No Pipelining Inside Crossbar

This is identical to the issue described in axi_xbar.