- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Hello,
I am having a problem with my implementation of the triple speed ethernet core (details below). The ethernet interface works well 99.9% of the time for both Tx and Rx packets. On the Tx interface I am seeing intermittent errors that show up as an FCS error. After some investigation I have discovered that the problem lies in the RGMII Tx interface. I have put the external PHY into loopback mode so that the Tx packets can be analysed. Looping the packets back to the TSE core Rx has shown that there is a FCS error flagged, and I can see that one or more bits in the bad packets have been corrupted (always a 1 where there should be a 0). This happens for some bit sequences more than others (seems to be worse if one RGMII line has a 1 for consecutive cycles followed by a 0). Investigating the RGMII interface on the PCB I've used a 2GHz scope with an equally good probe and I can see that the tx_clk and the rgmii data is far from ideal from a slew rate perspective (compared to the RGMII output signals of the PHY which are much more square). The IO standard I've used for the RGMII Tx signals (Tx_clk, Tx_control, RGMII_OUT[3..0]) is 3V3 LVTTL at 8mA drive strength, I am not sure that this is correct but cannot find a definitive answer. When I attempt to change this to 3V3 LVCMOS I get a warning that this standard can only be driven up to 64MHz and the resulting build does not work on the Tx side at all. I cannot find a reference that indicates the source impedance of the LVTTL outputs so I am not sure that the termination resistor (33R) that I currently have on the board is right either. I have followed AN477 to generate suitable constraints for the RGMII interface. The configuration is 3COM mode (delay implemented by the PHY) so the data and clk are edge aligned on the Tx side. Can you suggest a possible cause of the problem or fill in some of the unknowns that I've mentioned above? Details of my system are below, if you need any more info please let me know. Many Thanks, David Details: FPGA: Cyclone IV EP4CE75F23I8L PHY : Texas Instruments DP83865 On the PCB the RGMII interface traces are 50 Ohms characteristic impedance and length matched. There is a 33R termination placed near to the PHY (I have also tried 47R and this improved the slew rate slightly but still get corruption).Link Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I know nothing about ethernet, but I can say that a 3V3 LVTTL output will not drive a 33 ohm terminated line. Have you tried removing the termination altogether?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Thanks for the suggestion. When I change the termination for 0R the loopback test results in no packets recieved back at the MAC. The RGMII Tx signals on the PCB have nasty reflections which I'm guessing makes the data unreadable at the PHY.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I took a quick look at the DP83856 datasheet, you can select between a 2.5V and 3.3V MAC interface voltage. I assume you've chosen 3.3V. Try terminating at ~400 ohms which is about the lowest impedance the 8mA LVTTL driver can handle and still maintain full output swing. You could also try ~200 ohms which will give about a 1.7V signal at the receiver (assuming 8mA of drive current), which is the logic input threshold. Can you increase the drive strength of the LVTTL? If so, reduce the termination resistor accordingly.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Apologies, I should have stated that the termination on my RGMII interface is series. There are no parallel elements in the path.
I have tried a number of values between 0R and 100R. With 0R I see reflections that cause the interface to fail completely. With 100R it will work some of the time, but I still see corrupt packets, the slew that I see at the PHY pin is not good with very rounded edges. I do not know what the output impendace of the LVTTL pins is but there may be a mismatch with the 50ohms impedance of the PCB trace causing the reflections.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have also noticed that the FAST_OUTPUT_REGISTER assignment on my RGMII Tx pins is being ignored by the fitter. There is no indication of why this is being ignored, could it be something to do with the alt_ddio buffer having this already defined?
The design is not meeting timing and this may be the cause of my problems.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
OK, series termination makes a lot more sense. The resistors should be placed right next to the drivers and the value shouldn't be that critical, 30-70 ohms or something like that. Series termination is not perfect and you'll always get some reflections at the receiver which will corrupt the signal. This shouldn't be a problem if the traces are short enough, e.g. the signal transit time is much less than the risetime. How long are your traces?
In the end you may be right, the fact that the design is not meeting timing is the first thing to fix.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
The trace lengths are around 30mm on the PCB, they are all length matched.
The termination could be improved since it is placed at the PHY end but unfortunately there is no easy way to change this on my current layout. Thanks again for your help- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Sounds like the traces are short enough. Putting the termination at the receiver kind of defeats the purpose, which is to dampen the reflections from the receiver when they make their way back to the driver.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
Did you put timing constraints for your RGMII signals? Did you check with the scope that the RGMII signals timings (setup, hold) are fine wrt the TX clock?
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
I have applied timing constraints as per AN477 (http://www.altera.co.uk/literature/an/an477.pdf).
I've managed to solve the issues I was having by generating tx_clk via a DDIO buffer (connecting the tx_data_clk to the clk input and VCC and GND to the high and low data inputs). This allows the fitter to better meet timing constraints as the tx_clk is now routed through the same buffers as the rgmii_out and tx_control allowing it to delay the clock, aligning it with data edges. The design still does not meet timing however, I still have one of the four rgmii_out signals that has a negative slack (I even ran DSE and it came up with the same slack for each compile). It is only 1 output that fails to meet timing, the others are all fine, I think this is physically the furtherest pin from the PLL. The fast output registers assignment is still ignored by the fitter, any ideas on the reason for this? I think if this was solved it would meet timing. Thanks for your help- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- Quote Start --- I have applied timing constraints as per AN477 (http://www.altera.co.uk/literature/an/an477.pdf). I've managed to solve the issues I was having by generating tx_clk via a DDIO buffer (connecting the tx_data_clk to the clk input and VCC and GND to the high and low data inputs). This allows the fitter to better meet timing constraints as the tx_clk is now routed through the same buffers as the rgmii_out and tx_control allowing it to delay the clock, aligning it with data edges. The design still does not meet timing however, I still have one of the four rgmii_out signals that has a negative slack (I even ran DSE and it came up with the same slack for each compile). It is only 1 output that fails to meet timing, the others are all fine, I think this is physically the furtherest pin from the PLL. The fast output registers assignment is still ignored by the fitter, any ideas on the reason for this? I think if this was solved it would meet timing. Thanks for your help --- Quote End --- Hi, did you solved your timing problem? will you share the helpful methods? :)
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page