- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
This is glad to see the problem was resolved. Thank.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.

- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page