UPGRADE YOUR BROWSER

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!

cancel
Showing results for 
Search instead for 
Did you mean: 
Highlighted
Observer jcappello
Observer
4,637 Views
Registered: ‎08-10-2009

10GE MAC Rx AXIS outputs corrupt frame though Rx STATS indicate good frame

Jump to solution

[I had posted this issue in simulation forum but got no response. This is the more appropriate forum anyway...]

 

I am seeing faulty behavior from 10GE MAC IP core (v15.0) in simulation (ModelSim PE 10.5c). Strangely, the core model seems to corrupt frames output from its RX AXIS (streaming) port for packets whose payload sizes are in multiple of 256 bytes (256, 512, 768, 1024, etc.).

 

I am using Vivado 2015.4. In my architecture, the MAC is hooked up to an RXAUI IP (v4.3). In my testbench, the RXAUI backend is configured for loopback. I see the same anomaly whether I'm looping back on the RXAUI or on the backend XGMII of the MAC.

 

I am bursting Ethernet frames into MAC's TX AXIS port. The loopback causes the MAC to output the same traffic through its RX AXIS port. The MAC is able to pass all packets except those whose payload is multiple of 256 bytes. The corruption appears on the RX AXIS port. The attached pic shows the TX AXIS and RX AXIS signaling for a single frame. The top shows a normal looking frame of 256 bytes transmitted into the MAC's TX AXIS port. The bottom shows that packet looped back, except for whatever reason the MAC de-asserts its TVALID after the first cycle, clocks through the entire frame of data, then only asserts the TVALID again during the TLAST cycle. 

 

As shown at the bottom of the pic, the RX STATS vector indicates a "good" frame (bit [0]) with the frame size field indicating the expected 274 bytes (256 bytes payload + 18 bytes of Ethernet frame overhead -- DA, SA, LT, FCS).

 

The fault occurs whether I'm sending that 256-byte multiple frame alone or mixed with other frames. It's as if the MAC sim model has this strange corner case where it shuts down its RX AXIS port for those frames except for the first and last cycles.

 

Has anyone seen this type of behavior before?

 

You may have noticed that the tx_axis_tlast signal at the top of the pic goes high during the last cycle of the transmission, and stays high. This is due to a FIFO in FWFT mode sending this to the MAC. This shouldn't cause the anomaly, but just in case, I put a gate so that the tlast going into the MAC was gated with the tvalid. This reduced that tlast signal to one cycle, but the fault remained.

 

It's hard to isolate this problem any further because it appears to be buried into the MAC IP core.

 

Thank you for any assistance.

tenge_mac_rx_axis_frame_corruption_pyldlen256mult.png
0 Kudos
1 Solution

Accepted Solutions
Observer jcappello
Observer
8,357 Views
Registered: ‎08-10-2009

Re: 10GE MAC Rx AXIS outputs corrupt frame though Rx STATS indicate good frame

Jump to solution

Thanks for the tips, Satish. After further debug using your suggestions, I was able to find the fault in my custom frame generator logic feeding the 10GE MAC core. I had the LEN/TYPE bytes reversed of what they should have been. (Although it was strange that the MAC wasn't able to give me more clues or failure indications for even the good frames. I suspect maybe I could have configured the MAC to check for payload size errors?)

 

I first tried Vivado 2016.2 (from 2015.4) but the bug was still there. Next, I went into 10GE MAC IP example design and changed the simulation demo (ten_gig_eth_mac_0_demo_TB.v) to BIST mode. Since the fault I was seeing was occurring for payload sizes in multiples of 256 bytes, I changed the maxsize for the demo (at its port) from 200 dec to 300 dec.

 

After making these changes and re-running the demo, I analyzed the MAC RX port and saw that the 256-byte payload frame was being output correctly. But I then noticed that the LEN/TYP bytes appeared opposite of what I was using. After some research, I convinced myself that my frame generator was inserting the two LEN/TYP bytes in opposite order of what they were supposed to be, so I switched them. I re-ran my simulation and it no longer failed for the 256-byte payload frame.

View solution in original post

0 Kudos
5 Replies
Xilinx Employee
Xilinx Employee
4,549 Views
Registered: ‎02-06-2013

Re: 10GE MAC Rx AXIS outputs corrupt frame though Rx STATS indicate good frame

Jump to solution

Hi

 

Does this issue specific to Modelsim simulator?

 

Have you tried simulating the core in vivado simulator and the same issue is seen in that too and do you see the issue with latest core in 2016.2 also.

 

Can you attach the test design to look at this issue at our end.

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
Observer jcappello
Observer
4,528 Views
Registered: ‎08-10-2009

Re: 10GE MAC Rx AXIS outputs corrupt frame though Rx STATS indicate good frame

Jump to solution
Thanks for your suggestions. I will try those then upload the design if necessary.
0 Kudos
Xilinx Employee
Xilinx Employee
4,517 Views
Registered: ‎02-06-2013

Re: 10GE MAC Rx AXIS outputs corrupt frame though Rx STATS indicate good frame

Jump to solution

Hi

 

Also check with the example design simulation in BIST mode, where the pattern generator can be used to send 256 byte packets or in DEMO mode by changing the frame length.

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.
--------------------------------------------------​-------------------------------------------
Observer jcappello
Observer
8,358 Views
Registered: ‎08-10-2009

Re: 10GE MAC Rx AXIS outputs corrupt frame though Rx STATS indicate good frame

Jump to solution

Thanks for the tips, Satish. After further debug using your suggestions, I was able to find the fault in my custom frame generator logic feeding the 10GE MAC core. I had the LEN/TYPE bytes reversed of what they should have been. (Although it was strange that the MAC wasn't able to give me more clues or failure indications for even the good frames. I suspect maybe I could have configured the MAC to check for payload size errors?)

 

I first tried Vivado 2016.2 (from 2015.4) but the bug was still there. Next, I went into 10GE MAC IP example design and changed the simulation demo (ten_gig_eth_mac_0_demo_TB.v) to BIST mode. Since the fault I was seeing was occurring for payload sizes in multiples of 256 bytes, I changed the maxsize for the demo (at its port) from 200 dec to 300 dec.

 

After making these changes and re-running the demo, I analyzed the MAC RX port and saw that the 256-byte payload frame was being output correctly. But I then noticed that the LEN/TYP bytes appeared opposite of what I was using. After some research, I convinced myself that my frame generator was inserting the two LEN/TYP bytes in opposite order of what they were supposed to be, so I switched them. I re-ran my simulation and it no longer failed for the 256-byte payload frame.

View solution in original post

0 Kudos
Xilinx Employee
Xilinx Employee
4,393 Views
Registered: ‎02-06-2013

Re: 10GE MAC Rx AXIS outputs corrupt frame though Rx STATS indicate good frame

Jump to solution

Hi John

 

Thanks for the update.

 

Glad to know that the issue is resolved.

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