0
\$\begingroup\$

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.

\$\endgroup\$
  • \$\begingroup\$ It would be nice to have a few screenshots of the signals in question as we aren't sitting at your bench and have no idea what's going on \$\endgroup\$ – Voltage Spike Jul 7 '17 at 21:19
  • \$\begingroup\$ Why do you consider TREADY remaining high to be a problem in the first place? I would normally expect TREADY to be high nearly all the time, unless I was trying to overrun the FFT with data, in which case, TREADY would be negated in order to apply "back pressure" (flow control). \$\endgroup\$ – Dave Tweed Jul 7 '17 at 23:07
  • \$\begingroup\$ @laptop2d Yes will add screenshots as soon as possible (monday morning). \$\endgroup\$ – Chandran Goodchild Jul 8 '17 at 8:43
  • \$\begingroup\$ @DaveTweed If I allow TREADY to remain high, the FFT takes the 15 data points from my next sample. Then TREADY goes low while the FFT transmits it's output and the next sample isn't read correctly... \$\endgroup\$ – Chandran Goodchild Jul 8 '17 at 8:52
  • \$\begingroup\$ I agree with @DaveTweed that you need not bother about the TREADY being High. s_axis_data_tready - (Used by the core to signal that it is ready to accept data.) you can generate s_axis_data_tvalid signal - (Used by the external master to signal that it is able to provide data.) accordingly to have control over the transfer of the total number of data points. \$\endgroup\$ – Sourabh Tapas Jul 8 '17 at 10:19
1
\$\begingroup\$

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?

\$\endgroup\$
  • \$\begingroup\$ Thanks, this sounds like an explanation. I thought my data was being corrupted, because the FFT was filling it's buffer with 15 (maybe 16) points from the next sample. Then TREADY went low and the FFT started returning an output while it was supposed to be recieving data from the next sample... \$\endgroup\$ – Chandran Goodchild Jul 8 '17 at 15:11
0
\$\begingroup\$

Dave Tweed and Sourabh Tapas were right, s_axis_data_tready does not normally go low when the FFT has received the sample.

Page 54 of the product guide illustrates what Dave Tweed pointed out graphically: enter image description here

s_axis_data_tready only goes low when the FFT has recieved too much data.

This is how it should look: This is how it should look

\$\endgroup\$

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.