We have detected your current browser version is not the latest one. Xilinx.com uses the latest web technologies to bring you the best online experience possible. Please upgrade to a Xilinx.com supported browser:Chrome, Firefox, Internet Explorer 11, Safari. Thank you!

Showing results for 
Search instead for 
Did you mean: 
Registered: ‎03-27-2014

A little improvement of the 'AXIS Packet FIFO' to make it really awesome?

Hey everyone,


we noticed our current implementation of the 'Packet FIFO'[Vivado 2014.4] (available for AXI-Streaming compliant FIFOs supporting TLast) are not smart enough to know if we can store one more packet, but only one more sample.


This FIFO implementation is very powerful because it only provides data ( Rd_TValid='1' ) once a Wr_TLast has been received, quite helpful when the data is only meaningful when considered as a frame(FFT?).


Now let's imagine the FIFO becomes full at some point, the FIFO does not allow any more samples to be pushed as expected (because Wr_Tready goes low). Now the thing is Wr_Tready will go high as soon as we grab one more sample: and we think it should go high once a Rd_TLast has happened.


That means the FIFO only provides the information ''I can store one more sample'', not ''I can store one more packet''. If your app` is completely frame-based, then you need extra logic to:


  • Wait for a RD_Tlast (requires clock domain crossing, heavy) => we can store one more packet
  • Wait for the end of current frame => I want to store a complete packet from index 0 to L-1

We worked it around with a threshold value, unfortunetaly constraining the logic to specific frame lengths.


I understand this is already amazing considering the core is not aware of the frame length.


I would suggest: increase the FIFO depth and use an internal threshold value, maybe ask the user for an expected 'maximum frame length', I don't know..


What do you guys think about this? is that a problem you also had to face?


NIST - Time Frequency metrology
0 Kudos