The Burst I/O architectures do not allow frame overlapping to the same degree as the Pipelined Streaming I/O architecture. When natural ordered outputs are used, a frame has to be processed and unloaded before the core can start to load the following frame.
Note: This refers to the FFT processing core. As the Data In channel has a 16 element deep buffer on its input, it can start to pre-buffer a frame while a frame is still being processed. In the case of 8 and 16 point FFTs, it can pre-buffer entire frames. However, this buffered data waits in the buffer until the FFT engine has finished dealing with the current frame.
When bit-reversed outputs are used, the core only unloads data when a new frame is loaded. This means that the loading of frame N+1 overlaps with (and actually causes) the unloading of frame N. However, if the upstream master does not supply data to the core when it is ready to start unloading a frame, the core will flush the frame out manually. If this occurs, the loading and unloading phases do not overlap.
This Figure shows the general transform timing for a Burst I/O architecture with natural ordered outputs. This requires distinct load, process and unload phases. The upstream master is constantly attempting to stream data as is the downstream slave. These examples do not show the effect of a cyclic prefix, which is to extend the unloading phase.
The Upstream Master loads all of the data for Frame A into the Data Input channel of the FFT. As the FFT is loading this data to process it, the buffer in the channel never fills. However, the master immediately starts sending data for Frame B. At point A in the waveform, the buffer in the Data Input channel fills, because the FFT is processing frame A and no longer draining the buffer. This can be seen externally as s_axis_data_tready going Low. The Data Input channel remains in a slave waitstate situation, where the FFT cannot accept data from the upstream Master, until point B. Now the FFT has unloaded frame A and started loading Frame B into the processing core. This drains the buffer in the Data Input channel, which unblocks the Upstream Master and allows it to send the remaining data for Frame B. The situation then repeats itself with Frame C.
The important points here are:
1. Activity on the AXI interface to the Data Input channel does not necessarily correlate to the activity inside the FFT. For example, just before point A, the channel loads sample data for frame B yet the FFT is internally processing Frame A.
2. The Upstream Master cannot always stream frame data without reference to s_axis_data_tready .
3. The FFT unloads a frame before loading the subsequent frame.
This Figure is similar to This Figure , except that the FFT is configured to have bit reversed outputs. As the upstream master is always supplying data, the loading and unloading of frames can overlap.
This Figure is similar to This Figure , except that the upstream master does not supply data for Frame B until the core has started flushing out Frame A. As the core has already started flushing Frame A, it completes this before loading Frame B. The loading and unloading of frames do not overlap.
In this example, s_axis_data_tready remains High at Point A. Loading Frame A into the core drained the buffer in the Data Input channel, and because the Upstream Master did not send any new data, the buffer is empty. The core is ready to accept new frame data at point A although it is not able to do anything with it at this point. At point B the Upstream Master starts to send data from Frame B. This fills the buffer in the Data Input channel, but because the core is committed to flushing Frame A, the buffer fills and the core stalls the Upstream Master with waitstates. At point C, the core has started loading Frame B to process it, so the buffer drains and more data can be accepted to finish off Frame B.
The key difference between the situation in This Figure and This Figure is that the master in This Figure has provided new frame data during the processing phase of the previous frame. As a result, the core knows there is a new frame coming so when processing finishes, it starts to load the new frame as this flushes the old frame out. In This Figure , the master did not provide data (and therefore did not tell the core that there would be a new frame) during the processing phase, so when the core finishes processing the frame, it moves to a flushing phase where it is no longer possible to load a new frame. Even if the master provides a sample for the new frame a cycle after unloading has begun, that sample is not loaded until the core is finished unloading the old frame.
|
|
