cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
spajas
Observer
Observer
337 Views
Registered: ‎08-20-2018

UltraScale+ 100G MAC AXIS strange behaviour under load

Jump to solution

Dear all,

I'm currently busy debugging a product we develop. It has a 100G MAC Xilinx IP with the AXIS interface connected to our logic. We both use RX and TX, but the issue is with RX.

The product works perfectly except when we provide a high-load data-stream (video streams + small PTP and ARP packets). When we go above ~75Gbit/sec, I can see, for me, strange AXIS behaviour. It seems that not every packet is 'terminated' with a AXIS_TLAST. A quick scan of the TDATA seems to show all the packets with valid TKEEP+TVALID but some of them are missing the TLAST. My debug TDATA-word counter - it counts TVALID words from first TVALID of a packet until TLAST - goes beyond (1536B/64B=) 24 TDATA-words which should not be correct. Our downstream logic cannot cope with this and generate errors.

For this I have a few questions:

1) Should we expect a TLAST for every Ethernet packet received by the 100G MAC?

2) If so, what can explain this behaviour? The MAC generates its own clock (322,625625MHz) and databus width (512bits)

3) If not, how should we handle this case when packets are (almost) back-to-back?

4) Is LBUS required when we require 100Gbit performance?

5) Any other recommendations?

As our customers expect around 100Gbit performance we need to solve this issue (i.e. lowering the bandwidth is not an option). Please advice. I can provide screenshots or any other test if required.

Thanks in advance.

0 Kudos
1 Solution

Accepted Solutions
richardhead
Scholar
Scholar
207 Views
Registered: ‎08-01-2012

Are you sure you dont have any "jumbo" frames flowing around your network? Jumbo ethernet allows up to 9k bytes/packet (which is nice if you like jitter in your media flows ). Hence why limiting the MTU in the MAC is now giving you tuser packet fails (because it found jumbos on the network).

Is there any possibility the video sources have accidently missed the last word off, or held tvalid high at the source MAC (like I managed to do recently). Is the source your own kit (I assume 2022-6 )

View solution in original post

4 Replies
guozhenp
Xilinx Employee
Xilinx Employee
249 Views
Registered: ‎05-01-2013

Yes, please upload the screenshots.

Every packet should have tlast.

Could you also check LBUS interface? Does it also have any problem with the failing packet?

0 Kudos
spajas
Observer
Observer
225 Views
Registered: ‎08-20-2018

Hi,

 

Thank you for responding. I've created a PDF-document with screenshots and text. Please see the attached file. I'm not (yet) able to have an LBUS version. I'll try when I have some more time.

0 Kudos
richardhead
Scholar
Scholar
208 Views
Registered: ‎08-01-2012

Are you sure you dont have any "jumbo" frames flowing around your network? Jumbo ethernet allows up to 9k bytes/packet (which is nice if you like jitter in your media flows ). Hence why limiting the MTU in the MAC is now giving you tuser packet fails (because it found jumbos on the network).

Is there any possibility the video sources have accidently missed the last word off, or held tvalid high at the source MAC (like I managed to do recently). Is the source your own kit (I assume 2022-6 )

View solution in original post

spajas
Observer
Observer
156 Views
Registered: ‎08-20-2018

Hi @richardhead 

Thank you for your answer. I already thought of that, but after asking some colleagues to verify various things (like switch status), I 'ruled-out' this potential cause. However, due to your question, I rechecked and double-checked and you are right, it was exactly that!

The sender used an older bit-file version that does not correctly cope with 20+ video streams.The switch was also set in "cut-through" mode, so some statistics/safeguards were unavailable. In the end, the sender FIFO overflowed causing some Ethernet  packets to be corrupted and/or too long. After updating the sender bit-file to the latest version, the problem disappeared :-).

As an additional safeguard, I implemented a packet-length clipper on the RX-side to clip the Ethernet packet to the maximum supported length. It will also report an error to our application software if the device receives unsupported long Ethernet packets. It works perfectly and we have a stable device again.

Thanks again for the reminder/trigger!

0 Kudos