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.
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.
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,...); |
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); |