FPGA Intellectual Property
PCI Express*, Networking and Connectivity, Memory Interfaces, DSP IP, and Video IP
Announcements
Intel Support hours are Monday-Fridays, 8am-5pm PST, except Holidays. Thanks to our community members who provide support during our down time or before we get to your questions. We appreciate you!

Need Forum Guidance? Click here
Search our FPGA Knowledge Articles here.
5881 Discussions

Triple-Speed Ethernet with Max10 Issue

RHark
Novice
248 Views

I'm implementing the triple speed ethernet IP (MAC, with a DP83867 as the PHY) and it's mostly working, but I've run into an issue on the TX side.  When I transmit out a packet (any packet, type doesn't matter), I get about 66% packet loss.  When I delved a bit deeper, I saw that the last byte of the FCS is getting replaced on the bad packets with 0xFE.  The first three bytes all match the proper FCS, so I know the IP is calculating the CRC properly, but for some reason it's not sending out the last byte of it. 

tx_cmd_stat register bit 17 is 0

ff_tx_crc_fwd signal is 0

My line lengths are all about 2 +- .02"

The transmitted data is perfectly fine, the only error is the last byte of the FCS

All RX data comes through just fine, no issues with FCS there

125mhz clock is free running, so I'm not halting it early

 

Am I missing something obvious?  8 bits would be one full clock cycle on the line, but if my TX_CTL signal was a full cycle behind my data lines I'd expect the FCS to be shifted one byte and not simply replaced.  

 

Edit:

I played around a bit with disabling the CRC generation and found that the last byte of my packet gets corrupted regardless of whether the CRC is generated by me or by the IP.  

 

0 Kudos
1 Solution
RHark
Novice
203 Views

I calculated and inserted the CRC myself, but I also tried letting the MAC do it automatically.  Both times the final byte was corrupted.  

 

I was able to get it working though, it appears as though the MAC IP was causing a much larger delay in the TXD to GTX_CLK path than I had thought.  I inverted the GTX_CLK signal into the MAC and then was able to adjust the line delays on my PHY in order to get the signals to line up properly.  

View solution in original post

4 Replies
SengKok_L_Intel
Moderator
214 Views

Hi,


Did you provide the CRC from the application? I would suggest you check if the ethernet basic frame format is correct (e.g length/type and Payload data). Perhaps you can perform a MAC loopback test, and ensure your design timing is clean.


Regards -SK


RHark
Novice
204 Views

I calculated and inserted the CRC myself, but I also tried letting the MAC do it automatically.  Both times the final byte was corrupted.  

 

I was able to get it working though, it appears as though the MAC IP was causing a much larger delay in the TXD to GTX_CLK path than I had thought.  I inverted the GTX_CLK signal into the MAC and then was able to adjust the line delays on my PHY in order to get the signals to line up properly.  

SengKok_L_Intel
Moderator
197 Views

This is glad to see the problem was resolved. Thank.


SengKok_L_Intel
Moderator
174 Views

If further support is needed in this thread, please post a response within 15 days. After 15 days, this thread will be transitioned to community support. The community users will be able to help you with your follow-up questions.


Reply