I have an AXI4-Lite master BFM. I need to connect it to a slave that I have found to use AXI4. In this scenario the master is using a simplified version of the AXI4 than the slave. Is it possible to connect the two sides without involving a third component in between them?
Have a look at table B1-2 "Full AXI and AXI4-Lite interoperability" in the current AXI protocol document as this covers all possible combinations of AXI and AXI4-lite transaction sources ("managers") and targets ("subordinates").
The answer to your question is "yes", as shown in line 3 of the above table, described as "Fully operational".
AXI4-lite is a subset of AXI4, so your BFM can only generate a subset of transactions that your AXI4 target should be designed to support, and any unused AXI4 target inputs would be tied off to static values as described in section B1.1.1. The only AXI4 target response that is not supported by an AXI4-lite source is an EXOKAY (exclusive okay) response, which the AXI4 target would not be returning as the AXI4-lite BFM source cannot generate exclusive transactions, so no problem.
The main problem is that the AXI-Lite master lacks these signals which are present on the AXI Slave.
Some of these are inputs while others are outputs. It is not at all clear what to do with these. This is what is preventing me from connecting the AXI-Lite master BFM with the AXI slave.
i_s_axi_awid : in std_logic_vector(AXI_ID_WIDTH-1 downto 0); -- AXI write address channel write address ID tag i_s_axi_awlen : in std_logic_vector(7 downto 0); -- AXI write address channel write burst length i_s_axi_awsize : in std_logic_vector(2 downto 0); -- AXI write address channel size of transfer in burst i_s_axi_awburst : in std_logic_vector(1 downto 0); -- AXI write address channel burst type i_s_axi_awlock : in std_logic; -- AXI write address channel lock type i_s_axi_awcache : in std_logic_vector(3 downto 0); -- AXI write address channel memory type i_s_axi_awprot : in std_logic_vector(2 downto 0); -- AXI write address channel protection type i_s_axi_awqos : in std_logic_vector(3 downto 0); -- AXI write address channel QoS identifier i_s_axi_wlast : in std_logic; -- AXI write data channel write last o_s_axi_bid : out std_logic_vector(AXI_ID_WIDTH-1 downto 0); -- AXI write response channel write response ID tag i_s_axi_arid : in std_logic_vector(AXI_ID_WIDTH-1 downto 0); -- AXI read address channel read address ID tag i_s_axi_arlen : in std_logic_vector(7 downto 0); -- AXI read address channel read burst length i_s_axi_arsize : in std_logic_vector(2 downto 0); -- AXI read address channel size of transfer in burst i_s_axi_arburst : in std_logic_vector(1 downto 0); -- AXI read address channel burst type i_s_axi_arlock : in std_logic; -- AXI read address channel lock type i_s_axi_arcache : in std_logic_vector(3 downto 0); -- AXI read address channel memory type i_s_axi_arprot : in std_logic_vector(2 downto 0); -- AXI read address channel protection type i_s_axi_arqos : in std_logic_vector(3 downto 0); -- AXI read address channel QoS identifier o_s_axi_rid : out std_logic_vector(AXI_ID_WIDTH-1 downto 0); -- AXI read data channel read ID tag o_s_axi_rlast : out std_logic; -- AXI read data channel read last
Did you have a read at section B1.1.1, as this describes what AXI4-lite does implement, and so mostly tells you what to set all the unsupported signals to ?
Going down your list...
AWID (and ARID) - IDs are used to support multiple outstanding transactions, so as AXI4-lite does not support these, the ID signals are not used. Therefore AWID and ARID can be set to any static value you want (and the RID and BID responses ignored).
AWLEN (and ARLEN) - B1.1.1 tells you that all AXI4 transactions are length 1, so AWLEN=8'b00000000
AWSIZE (and ARSIZE) - B1.1.1 tells you that all accesses are to the full width of the data bus, so 3'b010 (32-bit) or 3'b011 (64-bit) depending on your implemented data bus width
AWBURST (and ARBURST) - with a burst length of 1, the burst type should be the simplest INCR (2'b01)
AWLOCK (and ARLOCK) - B1.1.1 says drive to 1'b0 as no exclusive transfers supported
AWCACHE (and ARCACHE) - B1.1.1 says drive to non-modifiable, non-bufferable, 4'b0000
AWPROT (and ARPROT) - driven by the AXI-lite source outputs
AWQOS (and ARQOS) - too complex for AXI4-lite, so any static value, either a default 4'b0000, or if driving any arbitration logic choose a value to suit this source's priority so it can compete correctly with other transfer sources.
WLAST - we know the transaction will always be 1 transfer long, so drive to 1'b1
RLAST - ignore as we know the incoming read transaction must have RLAST high
Please do have a read at section B1.1.1 as this would have answered most of the above questions, and section A9.3 for sensible default values where none are mandated in B1.1.1.