Electrical – AXI interface of an FFT core expecting more data than it should

dspfftsignal processingvhdlxilinx

I am working with the FFT v9.0 core from Xilinx.

The FFT is configured to use the Radix-4 Burst I/O architecture.

When I reach the last element of my signal, I set s_axis_data_tlast to 1 (while transmitting the last data point) and set it back to zero. I neither get an event_tlast_unexpected nor event_tlast_missing.

My problem is that the s_axis_data_tready signal from the FFT remains high!

In order to satisfy the FFT I had to give it 15 additional data points after it has already accepted the last datapoint:
The FFT is receiving 15 additional data points at the end of the sample.

In disbelief, I reduced the length of my data stream from 4096 points to 64 points so that I could manually count the data points that were transmitted. This caused the same behaviour – again the FFT requires 15 additional data points in order to proceed.

How can I resolve this issue?

EDIT 1

Maybe I should provide some more information:

The FFT core is clocked at 200 Mhz while my data points arrive at a rate of 50 Mhz, so I am actively slowing down the FFT with s_axis_data_tvalid. Each sample has a length of 81.92 microseconds and I start transmitting a new sample every 300 microseconds.

My plan was to feed in my first sample for 81.92 microseconds, recieve the output within 218.08 microseconds and then feed in the next sample.

If I don't fill the buffer (see Dave Tweed's answer), the FFT simply waits 218.08 micro seconds and fills up it's buffer with 15 points from the next sample. Then s_axis_data_tready goes low and the FFT returns it's output while it should be recieving data from the new sample.

Best Answer

The document you linked to confirms how I would expect TREADY to be handled. Page 51, paragraph 2 says:

In particular, the behavior of TREADY on the input data channel [timing diagram] is not fully accurate because the Data Input channel buffers the data (16 symbols in Non-Realtime mode and 1 symbol in Realtime mode). However, this data waits in the buffer until the FFT processing core is ready for it. The Data Input channel TREADY in these diagrams is used as an indication of when the FFT processing core wants data rather than when the AXI channel (with its buffer) wants data.

And page 52, paragraph 3 repeats:

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.

That whole section starting on page 52 provides a lot of additional information about buffering and flow control at the module interfaces. Why are you concluding that the data is not being processed correctly?

Related Topic