Controlling the FFT Core - 9.1 English - PG109

Symbol data to be processed is loaded into the core using the Data Input channel. Processed symbol data is unloaded using the Data Output channel. Both of these use the AXI4-Stream protocol. The following figure shows the basics of this protocol.

TVALID is driven by the Master component to show that it has data to transfer, and TREADY is driven by the Slave component to show that it is ready to accept data. When both TVALID and TREADY are High, a transfer takes place. Points A in the diagram show clock cycles where no data is transferred because neither the Master or the Slave is ready. Point B shows two clock cycles where data is not transferred because the Master does not have any data to transfer. This is known as a Master Waitstate. Point C shows a clock cycle where no data is transferred because the Slave is not ready to accept data. This is known as a Slave Waitstate. Master and Slave waitstates can extend for any number of clock cycles.

Figure 1. AXI Transfers and Terminology

After the master asserts TVALID High, it must remain asserted (and the associated data remain stable) until the slave asserts TREADY High.

To load a frame into the core, the upstream master supplying the XN_RE and XN_IM data has to send it when it is ready. If the core can accept it (which is when s_axis_data_tready = 1) then it is buffered by the core until it can be processed. If the core cannot accept it (which is when s_axis_data_tready = 0), a slave waitstate exists in the AXI channel and the master is stalled. The preceding figure shows the loading of the sample data for an 8 point FFT. The upstream master drives TVALID and the core drives TREADY. In this case, both the master and the core insert waitstates.

Unloading a frame works in a similar manner, except that the core is the master in this case. When it has XK_RE and XK_IM data to unload, it asserts its TVALID signal (m_axis_data_tvalid = 1). The downstream slave that consumes the processed sample data can then accept the data (m_axis_data_tready = 1) or not (m_axis_data_tready = 0). The preceding figure also shows the unloading of the sample data for an 8 point FFT (with no cyclic prefix). The core drives TVALID and the downstream slave drives TREADY. In this case, both the core and the slave insert waitstates.

The previous description only applies when the core is configured to use Non-Realtime mode. The situation is different in Realtime mode, which is used to create a smaller and faster design at the expense of flexibility in loading and unloading data. When the core is configured to use Realtime mode, the following occurs:

1. The TREADY signal on the Data Output channel (m_axis_data_tready ) is removed
2. The TREADY signal on the Status channel (m_axis_status_tready ) is removed
3. The TVALID signal on the Data Input channel is ignored when the loading of a frame has begun

The first two points mean that neither the downstream slave that consumes processed data, or the downstream slave that consumes status information, can insert waitstates using TREADY (m_axis_data_tready and m_axis_status_tready, respectively) as the pins are not present on the core. Both slaves must be able to respond immediately on every clock cycle where the core is producing data (m_axis_data_tvalid asserted High or m_axis_status_tvalid asserted High). If the slave cannot respond immediately, then data is lost.

The third point is slightly more complex as TVALID (s_axis_data_tvalid ) cannot be removed. The upstream master still controls the start of a frame with TVALID. The core does not try to load a frame until the upstream master has asserted TVALID to provide the first symbol and there is no requirement for the master to supply the first sample of a frame at any particular time. However, when this has occurred, TVALID is then ignored by the core and it assumes that the master provides symbol data immediately on every clock cycle where TREADY is High. If the master does not provide data when requested, the data from the last provided symbol is reused and the event_data_in_channel_halt is asserted to show that the timing requirements are violated. The core can still insert waitstates when in Realtime mode. It is only the response to externally induced waitstates that changes.

The following figure shows the upstream master inserting waitstates while loading an 8 point frame in Realtime mode. At point A, the master has sent one sample to the Data Input channel. The core then inserts a waitstate while it waits for the FFT processing core to start the transform. This is shown as one cycle here, but it could be longer in certain cases. At point B, the master inserts two waitstates using TVALID. However, the core ignores them and uses the previous data (D3) for the missing data. It is likely that the processed frame is corrupted.

At point C, the master starts supplying the last samples of the frame (D7 and later D8) but the core has already started processing the frame and inserts a waitstate. The Master and the core are now out of synchronisation. When the core finishes processing the frame and is ready for a new frame, it sees D7 as the first symbol of the new frame and starts to consume another 8 samples.

Figure 2. Incorrect Transfer in Realtime mode