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.
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 flushes the frame out manually. If this occurs, the loading and unloading phases do not overlap.
The following 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:
- Activity on the AXI interface to the Data Input channel does not necessarily correlate to the activity inside the FFT. For example, before point A, the channel loads sample data for frame B yet the FFT is internally processing Frame A.
- The Upstream Master cannot always stream frame data
without reference to
s_axis_data_tready
. - The FFT unloads a frame before loading the subsequent frame.
is similar to , 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.
is similar to , 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 and is that the master in 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 , 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.