cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
Highlighted
Contributor
Contributor
859 Views
Registered: ‎04-25-2019

FIFO Reset Conditions

Jump to solution

Hi, 

I am trying to setup a FIFO before the FFT stage of my system as I need to accurately frame the data in time and in variable sizes (2^n) up to 4096, so that an FFT is performed on exactly the right amount of data at the right time, with no loss of data. I have been having a lot of difficulty understanding how the provided IP's for the FIFO work specifically with regards to the reset or flushing conditions. The operating frequency of the system is 122.88 MHz and the data is downsampled with a DDC by 64, resulting in a data rate of 1.92 MHz on the axi stream bus. I am working at the block level with the IPs in Vivado and I am trying to avoid writing a custom verilog FIFO module or modifying any FIFO IPs as I am certain this functionality should be possible without such intervention, its just a matter of making sure the control signals are correct or the GUI parameters are set properly. 

I have searched the forum on this and have noticed two relevant posts (and are similar to the problems which I am experiencing): 

https://forums.xilinx.com/t5/Design-Entry/FIFO-empty-always-high/td-p/796433
https://forums.xilinx.com/t5/Xilinx-IP-Catalog/Proper-Reset-for-AXI4-Stream-Data-FIFO/td-p/794117

I have tried three approaches to implementing a FIFO and observed the effects in the ILA:

- AXIS Data Fifo 2.0 - this is the closest I have got to what I need, but it doesnt have an input programmable full and empty flag therfore I am unsure how I could make the FIFO size variable during runtime, additionally it seems to need systematic resets as soon as it has finished offloading the data after the packet burst containing the data (this works as desired and offloads all the data before new data arrives since the FIFO is 64 words deep). The annoying part is having to send a reset signal to the core after the data has been offloaded, which is a unideal I would prefer if it could automatically be flushed once it is full or it has hit a counter value. Otherwise I have to perfectly time the reset signal which is rather annoying. The counter values are also offset by +-5 data samples which makes it difficult to work with. 

- FIFO Generator 13.2 (Axi Stream mode) - setup input programmable flags, which can be controlled from the PS and are definitely correct as the ILA confirms this, the input data seems to be loaded in and then clocked back out instantly, as expected but doesnt count up and nothing happens when it reaches the 64 word depth or any of the counter values that I have programmed. I have experimented with these values and most of the parameters but it has made no difference. I have a feeling it might be something to do with my reset signal and the post above says simply disable it, but it does not give me that option as it is greyed out. 

- FIFO Generator 13.2 (Native mode) + AXI4 Stream FIFO (IP blocks) - common BRAM, FWFT, no reset input - seems to just count up to 4 and then restart even though I am changing the thresholds in the PS. There is output data but it is rubbish and there is a huge number of glitches on the output data. 

I have attached the ILA data to the post and a screenshot of one of the FIFO gen + Axi stream combo test, I can post all the other waveforms and corresponding screenshots upon request. 

Any help would really be greatly appreciated, as this rather 'simple' IP seems to be incredibly mysterious.

Best Regards, Ren 

Screenshot from 2020-02-08 20-19-05.png
0 Kudos
1 Solution

Accepted Solutions
Highlighted
Contributor
Contributor
561 Views
Registered: ‎04-25-2019

Hi, 

Thanks for your reply, after spending some months working on other parts of the system and writing some of my own custom IP blocks and various other shenanigans. I discovered that I actually needed to come back and address this problem, I couldn't get the FFT to work in pipeline streaming mode for my application properly (above 64 point FFT) below worked fine. I suspect that its because that the system has to consume data fast enough, which mine doesn't. Anyway Radix-4 burst I/O seemed like the next appropriate solution, I did some testing with the parameters and the HW ILA and with 64 point + FFT's the core began de-asserting S Axis T Ready whilst the FFT was offloading data.

So I stuck with the FIFO idea and placed one in the AXI stream (in Axi-stream mode) to handle the back pressure, when T Ready is de-asserted the FIFO begins to fill and when it is re-asserted the data stored in the FIFO is offloaded into the FFT when it is ready. This worked perfectly and no data packets are lost or messed up. The timing side of things was solved by synchronising a system wide pulse generator with the processing system and then that becomes the single reset signal for the FFT core and the FIFO, this ensures that the first sample to enter the FFT is roughly known. 

Best Regards, Ren

View solution in original post

6 Replies
Highlighted
Teacher
Teacher
843 Views
Registered: ‎07-09-2009

Taking step back,

  why ?

The FFT is in streaming mode ? it takes in the 4096 samples and spits out the answers, then it takes in the next 4096 samples , etc etc,

 

Does it matter which actual sample it starts on ?  The FFT is just as valid no matter where it starts .

 

Provided the FFT is fast enough to take the data as fast as it is coming in, you will not lose data, 

   If its not fast enough, then the FIFO will fill, and yes you will lose data, 

If FFT is  too fast, then the fifo will flag empty , and the fifo will not take any more data nor start till data is available, 

 

 

<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Contributor
Contributor
778 Views
Registered: ‎04-25-2019
Cheers for the reply,

That's a good question, the FFT is in Radix 4 burst IO mode but it indeed is able to compute FFT faster than the FIFO can be filled so it is idle about 92% of the time for all buffer sizes. I understand that the AXI stream protocol allows for controlled data transactions, only when requested and only when the data is ready. In my application it is extremely important that I start the FFT on a specific known sample over a length which could change during runtime. I also eventually want to implement a window function such as a hamming over the input data before it is processed by the FFT, this could be a little challenge too.

As I am quite new to FPGA design (2 months), I find myself committing to an architecture which ends up only having to be changed drastically as soon as I want a little more functionality - I do agree where you are coming from though simplicity is always the easiest and most sane route.

Best Regards, Ren
0 Kudos
Highlighted
Teacher
Teacher
745 Views
Registered: ‎07-09-2009
How are you going to know which sample to start on ?
How about only writing into the fifo the samples you want ?

Reset fifo, and release reset,
wait till you want to start writing data
write data into fifo at the right point,
Kick off fft when you have enough samples .

Out of interest, what do you have that you want to get the frequency reprocess off , that can only take samples at a certain time,


<== If this was helpful, please feel free to give Kudos, and close if it answers your question ==>
0 Kudos
Highlighted
Contributor
Contributor
562 Views
Registered: ‎04-25-2019

Hi, 

Thanks for your reply, after spending some months working on other parts of the system and writing some of my own custom IP blocks and various other shenanigans. I discovered that I actually needed to come back and address this problem, I couldn't get the FFT to work in pipeline streaming mode for my application properly (above 64 point FFT) below worked fine. I suspect that its because that the system has to consume data fast enough, which mine doesn't. Anyway Radix-4 burst I/O seemed like the next appropriate solution, I did some testing with the parameters and the HW ILA and with 64 point + FFT's the core began de-asserting S Axis T Ready whilst the FFT was offloading data.

So I stuck with the FIFO idea and placed one in the AXI stream (in Axi-stream mode) to handle the back pressure, when T Ready is de-asserted the FIFO begins to fill and when it is re-asserted the data stored in the FIFO is offloaded into the FFT when it is ready. This worked perfectly and no data packets are lost or messed up. The timing side of things was solved by synchronising a system wide pulse generator with the processing system and then that becomes the single reset signal for the FFT core and the FIFO, this ensures that the first sample to enter the FFT is roughly known. 

Best Regards, Ren

View solution in original post

Highlighted
Scholar
Scholar
545 Views
Registered: ‎05-21-2015

@jarez95,

I like to think of pipeline mode as the most natural mode for FFT processing in an FFT.  In pipeline mode, the FFT accepts one sample every time you have a sample ready.  After some delay, the pipeline mode will produce one sample for every time you place a sample in.  The two rates match on both ends.  This approach should work for all applications except those requiring a minimum of delay though the FFT.  In that case, you can flush the FFT at high speed with zero data until you can get a value out.  Synchronizing will be important along the way.

You might also find this example of an FFT window function valuable.  It doesn't really use AXI stream signaling, but it would be easy to adjust for that purpose.  Lord willing, I'm hoping to blog about it's design soon enough, I just haven't finished the article yet.  (I have blogged about my own FFT generator , should you be interested--it offers an open source example of how a pipelined FFT might work.)

Dan

Highlighted
Contributor
Contributor
501 Views
Registered: ‎04-25-2019

Hi Dan,

Yes in my application I needed burst output rather than a continuous stream and I am happy with my Radix-4 implementation as it also occupies less resources. The resources and documentation you are working on regarding FFT implementations look extremely valuable, I encourage anyone reading this post to check them out!
My next step is to begin implementing a short time Fourier transform. FPGA's are fun when they work *smile*

Edit: 
Just been through your code to implement a windowing function on the input data. I will have a go myself at some point implementing something with the BRAM reader and probably some custom Verilog core to oversee and control things. I will probably have the window values loaded from the PS as floating point, and this would change when the NFFT's is changed, it may cost a couple of FFT frames in switching over, but that is acceptable. 

Cheers, Ren

0 Kudos