cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 
mistercoffee
Scholar
Scholar
9,488 Views
Registered: ‎04-04-2014

10GE losing packet

Jump to solution

Hi,

 

I have what is otherwise a fully working 10GE core in my design. It is only one directional, sending data to a PC.

 

Under certain circumstances we have noticed we are losing a packet at the PC. I have chipscoped and simulated the signals at the core from my modules upstream and all seems correct at the time of packet loss. One thing you could say I suppose is that the time between the lost packet and the one after (which we do receive) is very short (only a few clock cycles). We suspect this is causing as issue but would expect the core to not signal being ready if it wasn't.

 

Is there anything else we could have configured in the core that we need to look at? IFG is not enabled at the minute so will be set to minimum.

 

Thanks

0 Kudos
1 Solution

Accepted Solutions
mistercoffee
Scholar
Scholar
15,597 Views
Registered: ‎04-04-2014

Hi, I have managed to work out what was going on here.

 

The tx_axis_tuser signal going to the MAC core was being driven (in a module outside of the example code) by tlast for some reason. The tuser input to the core was therefore being asserted at the end of every frame entering the fifo before the core. This was telling the core that there was an explicit underrun condition and hence it droped the current frame. 

 

Thought I would close this off.

Thanks

 

View solution in original post

0 Kudos
7 Replies
mistercoffee
Scholar
Scholar
9,487 Views
Registered: ‎04-04-2014
We're using a Kintex 7 by the way.
0 Kudos
mistercoffee
Scholar
Scholar
9,475 Views
Registered: ‎04-04-2014

Ok, some more information here. Attached is a comparison of two screenshots taken of mu simulation. The simulation suggests the lost packet is not being sent by the 10GE core.

 

I decided to monitor the tx_statistics_vector and tx_statistics_valid signal that is output from the core. Bit 0 of the tx_statistics_vector suggests a frame was successfully transmitted, and the tx_statistics_valid signal is asserted when the information in the vector is valid.

 

The screenshot shows the tvalid, tlast and tready signals at the core interface at the time we lose a packet. When I insert an arbitrary long time delay between the first and second packet you can see that the tx_statistics_valid signal goes high twice, once at the end of each packet. 

 

When I don't, and the two packets are close together, you can see that the tx_statistics_valid signals only goes high once, at the end of the second packet, which suggests the first was not sent.

 

The gap in tvalid between the two packets is only 2 clock cycles but I can't see anything in the core datasheet that suggests that this is too short.

 

Does anyone know why this is causing problems? The actual code is from the 10GE core example design. It is purely connecting the tx fifo with the core. I am tempted to add some code to make sure that the tvalid signal next goes high after tx_statistics_valid has gone high also. 

 

Thanks

lost packet.png
0 Kudos
mistercoffee
Scholar
Scholar
9,466 Views
Registered: ‎04-04-2014

So, I have made some progess in my investigations and would be interested if anyone knows why the following is happening.

 

I have looked at what happens when my two closely spaced packets pass through the pre-MAC fifo. In the case where a packet is lost the first packet is being read out of the fifo, into the MAC, as the second packet is being written into the fifo, from the upstream module.

 

If I delay the writing of the second packet into the fifo until after the first packet has completed being read out into the MAC on the other side, then both packets are transmitted successfully.

 

For the time being this is a workaround but I am concerned why it is happening. This is limited my maximum throughput and makes the fifo kind of pointless.

 

I have looked at the axi signals on both sides of the fifo and all seem to be correct. The ready, valid and last signals on both sides do as I expect. I cannot therefore work out why the MAC refuses to send the first of the two packets. Bizarre.

 

Thanks

 

0 Kudos
yenigal
Xilinx Employee
Xilinx Employee
9,430 Views
Registered: ‎02-06-2013

Hi

 

Which version of the core are you using?

 

Can you attach the xco/xci file.

 

Can you zoom the snapshot and also confirm that the tlast of the first packet is actually detected by the core and tready and tvalid are both high when tlast is asserted.

 

 

Regards,

Satish

--------------------------------------------------​--------------------------------------------
Kindly note- Please mark the Answer as "Accept as solution" if information provided is helpful.

Give Kudos to a post which you think is helpful.
--------------------------------------------------​-------------------------------------------
0 Kudos
mistercoffee
Scholar
Scholar
9,428 Views
Registered: ‎04-04-2014

Hi,

 

Ok, we are using v11.6, I have attached the xco/xci files.

 

I haven't got the test bench set up right now but I can confirm from memory that when tlast was asserted both tready and tvalid were high. I will try and grab a screenshot when I next have it running.

 

Thanks

0 Kudos
mistercoffee
Scholar
Scholar
9,414 Views
Registered: ‎04-04-2014

missing frame.png

no missing frame.png

Ok, I have taken some more zoomed in screenshots. The top image is when a frame is dropped, the bottom image is when it is transmitted. This time I have included all the signals that are passed to the xgmac_block, apart from the rx signals which are not being used a 'X' anyway.

 

I haven't included the signals going into the fifo block )(en_gig_ethernet_mac_fifo) before the xgmax_block. Remember, in order to ensure that the first of the two frames is not dropped I have to delay writing the second frame into the fifo until the first frame has left. This is the case in the second screenshot. In the first, I have left the upstream module to write the second frame into the fifo at the same time as the first frame is leaving it and being written to the xgmac_block.

 

It doesn't appear as if there is any difference in the signals being sent to the mac block other than the delay. If I allow the 

fifo to be written to as normal, but insert a manual delay between the frames leaving the fifo, the frame is still dropped.

0 Kudos
mistercoffee
Scholar
Scholar
15,598 Views
Registered: ‎04-04-2014

Hi, I have managed to work out what was going on here.

 

The tx_axis_tuser signal going to the MAC core was being driven (in a module outside of the example code) by tlast for some reason. The tuser input to the core was therefore being asserted at the end of every frame entering the fifo before the core. This was telling the core that there was an explicit underrun condition and hence it droped the current frame. 

 

Thought I would close this off.

Thanks

 

View solution in original post

0 Kudos