DP83867IS: DP83867IS

Hi,

Voltage swings are as per the VDDIO chosen for your application. At what point you are measuring the signals ? You shall always measure them on the sink side to see the right levels.

Regards,
Geet

Hello Geet,

That's what I thought - the RGMii voltage level should be the VDDIO voltage rail. My VDDIO is 3.3V and I am measuring the signal at the series termination resistors. The RX_CLK signal has a swing of about 3.3V, but the data lines at very small - 200mv p-p.

Any ideas??

Thank you,

Mike

Hello Geet - I think what I am seeing on the RGMii bus is the "in-band status". Here is what I am reading:
Bit 0 = 0 ; link down
Bit 1 = 0 ; 125 Mhz
Bit 2 = 1
Bit 3 = 1 ; full duplex

But - even the logic 1's are only at 1.8V. My VDDIO pins (pins 19, 30 and 41 - RGZ package) are at 3.3V

Any ideas??
Mike

Hello Geet - the "in-band status" for RGMii is showing link down. Is this link associated with the RGMii bus? Both of my PHYs have link on the analog side. I do not have the Tx side of the MAC connected to the PHY.
Thank you for your help,
Mike

Hi Mike,

Suggest following:
1. Power Down one of the Phy and run experiments with only one PHY.
2. Remove CAT5e cable, Reset the PHY, and measure RX_CLK clock frequency ? Till Link is up, it shall remain at 2.5 MHz.
3. Measure the voltage levels on data lines as well.
4. Power up the second PHY. now measure the voltage levels.


Regards,
Geet

Hello Geet,

We finally got the PHYs working - apparently there is a "secret test" mode we were putting the PHYs in that disabled the RGMII interface. Fixed now.

Next question - Here is my configuration: I have 2 PHYs that are connected via the RGMii bus. From my test equipment, I can run packets into PHY A and receive them on PHY B (and from B to A). I have sent packet sizes from 64 Byte to 9000 Byte packets through the PHYs. All work fine. The I am seeing is when I run "random size" packets - from 64 to 9000 Byte packets, I start to see FCS errors on my test set and dropped packets. Any ideas what might be causing this in the PHY??

Thanks Geet,

Mike

p.s. let me know if you are interested in the "secret test mode"

  

Hi,

Good to know you resolve the issue. Please share the details of the observations you had causing the issue ?


For second problem, how is the clocking tree of these systems ? We have RGMII FIFO Buffers configurations, can you try increasing ? I think it's in RGMII control register.

Regards,
Geet

Hello Geet,

Hi Mike,

What's the Inter Packet Gap you are using ?

Regards,
Geet

Hello Geet,
The IPG is controlled by the Xena tester - here is what we have:
90% utilization, random packet size(64Byte-9000Byte) = 4206nS (runs errors/drops frames)
95% utilization, random packet size (64Byte-9000Byte) = 2077nS (no dropped frames)
90% utilization, 64Byte frames = 235nS (no dropped frames)
90% utilization, 9000Byte frames = 8178nS (no dropped frames)
95% utilization, 64Byte frames = 195nS (no dropped frames)
95% utilization, 9000Byte frames = 3958nS (no dropped frames)

The IPG was confirmed by measuring with a oscilloscope.
Mike

Hi Mike,

I am not clear on IPG from above data for the error and non error case.

Regards,
Geet

Hi Geet,

The test data is strange - with 90% utilization (IPG = 4206nS) we runs errors, but with 95% utilization (IPG = 2077nS) the board does not run errors. This test has been verified over 3 different boards.

I have also programmed the PHY into far-end loopback, and saw the same results?

Any ideas??

Thanks for your help!!
Mike

Hi Geet,
What would cause certain data rates to run with no dropped frames, while other data rates will drop frames?
Mike

Hi Mike,

With relaxed IPG, the performance shall always be better. This is really puzzling to me as well. Can you check the input clock quality ?

Regards,
Geet