- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic to the Top
- Bookmark
- Subscribe
- Printer Friendly Page
FCS errors
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-08-2012 10:13 AM
Hi,
I have a new board (my design, not a dev bboard) using a Virtex6 CX130T, and I'm using the hard TEMAC with the Marvell 88E1111 PHY and the RGMII interface. I've implemented the address-swap example design, and my received packets are all being rejected because of FCS errors (I'm looking at the statistics vector, and seeing bit 2 set after every packet, = FCS error). This happens in 10, 100 or 1000 Mb/s mode. May well be a hardware problem, but I thought I'd ask if anybody else has had such a problem. I've tried adding delay to the RGMII_RXC input, no help. Also checked that the crystal freq is 25.0000 MHz. Any ideas?
Thanks,
Rick
Solved! Go to Solution.
Re: FCS errors
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-09-2012 04:52 AM
Re: FCS errors
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-09-2012 08:46 AM
Hi Luis,
I was referring to the crystal connected to the 88E1111 PHY chip, which is 25MHz. My internal GTX _CLK to the "hard_emac_wrap_example_design" block is 125MHz, multiplied up in an MMCM from a separate 25MHz crystal oscillator. I also generate a 200MHz clock for the REF_CLK signal to the IODELAYCTRL block. I mentioned the 25.000 MHz because I know this has to be within a 50ppm tolerance.
I'm guessing I have a signal integrity problem with the PHY or the magnetics. Or maybe a clocking problem between the RXDATA and the local RGMII_RXC.
Thanks
Rick
Re: FCS errors
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-09-2012 06:17 PM
Will the quality of your internally multiplied GTX_CLK be acceptable for the MGT? I've always used an external synthesizer/jitter attentuator, but perhaps that is not necessary.
EM Photonics, Inc.
Re: FCS errors
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-10-2012 10:10 AM
Hmm, I hadn't thought of that. I'd think it would be adequate for 100Mb/s at least, and the RXDATA comes with its own source-synchronous clock, but maybe that's worth looking into. Thanks for the idea.
Rick
Re: FCS errors
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
02-17-2012 01:40 PM
After much more screwing around, I find that there is a very basic problem: there is twice as much data coming out of the TEMAC as there should be! I must be missing something very basic.
I've implemented the TEMAC wrapper example design (as generated in coregen) both with the EMAC_USECLKEN attribute TRUE and with it FALSE. I have the board connected to a link partner which is limited to 100Mb/s.
In the FALSE case the EMACCLIENTRXCLIENTCLKOUT signal is at 25MHz (and so the data rate is 200Mb/s). If I look at every other byte, the data look correct.
In the TRUE case, the EMACCLIENTRXCLIENTCLKOUT is at logic 1 always, so again the data rate is 200Mb/s.
Shouldn't this signal be at 12.5MHz in either case?
Device is xc6vcx130t-1
Any help appreciated!
Rick
Re: FCS errors
- Mark as New
- Bookmark
- Subscribe
- Subscribe to RSS Feed
- Highlight
- Email to a Friend
- Report Inappropriate Content
03-02-2012 09:59 AM
This was my own misunderstanding: I expected the TEMAC to figure out what speed it was connected at and switch its speed accordingly, but in fact it needs a host to do this. When I compile it for 10/100 it works, and when I compile it for 1000 it works, it just doesn't switch between the two without a host processor.
Thanks to all who responded.
Rick











