FPGAs are used extensively in signal processing chains. Data enters through an FPGA high speed interface and into one processing block, processed by that block, then the output data subsequently used as input data into another processing block.

The AXI4-Stream protocol is a standard interface standardized by ARM and used extensively by FPGA vendor IP cores. It is used to stream data from a single producing master to a single data consuming slave. SpeakHDL on the other hand, uses framework fifos to preform point to point communication between application modules. Although a native fifo is not AXI stream compliant, the AXI stream interface and native fifo signaling are very similar, so SpeakHDL makes very easy to interface with IP cores that have the AXI-Stream Interface. This is done by connecting the 'read-side' of the framework fifo, from the READ_FIFO_DATA procedure call to the axi slave interface of the component, and the axi master side of the component to input parameters of the WRITE_FIFO_DATA procedure call.

Problems Interfacing a Native Fifo to An AXI Stream

Strictly speaking, a native fifo is not AXI stream compliant. The AXI stream standard mandates that the slave (reader) need not assert the ready signal before the master (writer) asserts the valid signal. The master is allowed to assert the valid signal and place valid data on the bus whether the slave is ready or not. Native fifos do not work this way, as the writer typically waits for the reader to assert is ready signal before placing valid data on the bus. Thus, connecting a native fifo writer to an axi slave interface could create a deadlock situation, where the native fifo is waiting for the axi slave to assert the ready signal, and the axi slave is waiting for the native fifo to assert the valid signal.

Another possibly problematic situation arises when connecting a SpeakHDL framework fifo directly to an AXI-Stream interface is that framework fifos have a 3 clock cycle latency from the clock cycle that the ready signal is asserted until the reception of valid data. The implication is that both the reader and writer must have apriori knowledge of the maximum amount of data that writer will attempt to transmit after the ready signal is asserted. Otherwise, data could be lost.

Whether connecting a native fifo directly to an axi component will work becomes an implementation detail of the axi component and as rule should not be directly connected. However, in some AXI-Streaming applications, the situation will work seamlessly. If strict compliance to AXI4-Stream protocol is necessary, one should first connect the native fifo to a native fifo to axi stream converter before connecting to the AXI Stream component.

Slave Interface Mapping

AXI Slave Interface Framework Fifo Signal/ API Call
s_axis_tvalid srr.fifo_data_valid
s_axis_tdata srr.fifo_data
s_axis_tlast srr.fifo_data_done
s_axis_tready (output) READ_FIFO_DATA(..., enable,...);

Master Interface Mapping

AXI Master Interface Framework Fifo Signal/ API Call
m_axis_tready srr.fifo_write_ready
m_axis_tdata (output) WRITE_FIFO_DATA(..., data,...);
m_axis_tvalid (output) WRITE_FIFO_DATA(..., ..., data_valid);

Notes and Warnings

Connecting a native fifo directly to an AXI Stream interface could lead to a deadlock situation.
See also