i.MX6Q ENET.REF_CLK input

[clemensgruber]

Hi,

we use the i.MX6Q with a KSZ9031RNX PHY from Micrel.

Besides the RGMII signals, there is the ENET.REF_CLK input to the i.MX6 Ethernet MAC: Originally we tried to connect the CLK125_NDO output from the PHY to the ENET.REF_CLK, but there is an erratum for the KSZ9031 that this CLK125_NDO signal has duty cycle variations. One workaround would be, to use a separate 125 MHz oscillator and not use the PHY's CLK125_NDO pin at all?

We read in the reference manual of the i.MX6Q that there is an internal 125 MHz clock, so is it even necessary to connect an external oscillator to ENET.REF_CLK or would the i.MX6Q Ethernet MAC just use the internal 125 MHz clock instead automatically? Or can this be configured via pinmuxing / input select?

PS: The errata sheet lists a second workaround: Enforcing 1000Base-T Master mode, but that is not a viable option for us as devices must be interconnectable directly.

Any ideas?

Thank you.

Best regards,

Clemens Gruber

[clemensgruber]

Now I know that we have to use an external 125 MHz oscillator (which does not have to be synchronous to the RGMII signals). Frequency stability has to be 50ppm or less though.

Another alternative would be to choose another PHY which does not have this erratum (that CLK125_NDO's duty cycle varies), but in our case we will stick with the KSZ9031 and add a separate oscillator.

Maybe this helps someone else having the same problem.

[gusarambula · Accepted solution]

Correct, thanks for updating your post! Indeed the latest revision of the i.MX6 Hardware Development Guide (link below) in recommendation 1 of table 2-9 clarify that a 125Mhz reference clock must feed the ENET_REF_CLK input from either an external 125Mhz oscillator or an external PHY. Unfortunately there is no way to internally generate the clock signal for the RGMII even tough documentation may be confusing in this regard.

http://cache.freescale.com/files/32bit/doc/user_guide/IMX6DQ6SDLHDG.pdf

While the recommended configuration is the one supported some community users have generated the 125Mhz reference clock internally and exited it trough GPIO16 pin (R2, used by RMII to feed the PHY) to the ENET_REF_CLK pin (V22) externally on the PCB.

While providing this reference clock can be theoretically be possible, this option is NOT formally supported so I would strongly recommend having an external oscillator providing for both the PHY and the i.MX6 ENET module. One of the reasons behind this is that as the GPIO_16 pin is a standard GPIO pin it might result in a poor clock quality at 125Mhz.

I hope the external 125Mhz signal is a suitable solution for your design!

[clemensgruber]

Hi gusarambula,

thanks for your answer! :smileyhappy:

Then we will provide the 125MHz clock externally. However it won't be "in-sync" with the 25 MHz PHY clock because we use two separate oscillators, one 125MHz for ENET.REF_CLK and one 25 MHz oscillator for the PHY (XI on KSZ9031). But that's OK, right?

I have another question regarding logic levels for the ENET.REF_CLK:

Quote from the hardware development guide:

"If NVCC_ENET is powered at 3.3 V, the minimum VIH level is 70% of 3.3 V or 2.3 V. Designers should ensure that there is margin to this minimum value. A starting value could be 500 mV margin, resulting in a requirement of 2.8 V for the logic high."

As our NVCC_ENET is at 2.5V, would it be safe to use an oscillator with a Vhigh of 0.8 x 2.5V ?

The hardware development guide specifies 70% but then recommends a 500mV margin for 3.3V which would be a VIH level of 84%.

We found many oscillators with guaranteed Vhigh of 0.8 but only a few with 0.9. Is 0.8 x 2.5V safe?

Best regards,

Clemens

[gusarambula]

The PHY clock and the ENET_REF_CLK do not need to be “in-sync” so you shouldn’t have any issues with that.

As mentioned on the HW Development Guide, the minimum VIH level is 70% of the NVCC_ENET voltage with a 500mV margin as reference. In the case of 2.5V that would be 2.5*0.7+0.5 so around 2.25V. I would recommend trying to use this value which would be the 0.9*2.5V that you mention is harder to find.

That being said, Freescale’s SABRE board uses an AR8035 PHY which feeds the ENET_REF_CLK. The oscillator output from this oscillator does have a 2.8V maximum High Voltage but the typical value is actually 2.62V which is about 0.8*NVCC_ENET so it’s very likely that the 0.8*2.5V would also work but I would recommend some testing as the HW Guide recommendations ensure the most robust operation.

[clemensgruber]

Hi,

is it correct that ENET_REF_CLK is used internally to source the RGMII TXC ? If so, this would explain why it is OK to use an external oscillator for ENET_REF_CLK and it does not have to be "in-sync" with the PHYs XTAL_IN clock. So, if I connect a higher quality oscillator to ENET_REF_CLK, it is used for the RGMII TXC and on the other side, the PHY generates its own 125 MHz with PLL from the XTAL_IN. So PHY and MAC already see both RXC and TXC and there is no need for them to be "in-sync".

Am I correct? Can you confirm that this is the reason why it is OK to use a separate oscillator?

I was a little bit confused in the beginning, because I wrongly assumed that ENET_REF_CLK is a separate clock and had nothing to do with TXC.

[sinanakman]

Hi Gusarambula

Thanks for chiming in here. Rereading now the Reference

Manual, I see that enet_ref_clk would not be needed

for RGMII. So in Clemens' case, since they seemed to

be using only RGMII on their design, why they can't

just use an external 25M xtal for their PHY and leave

enet_ref_clk not connected ?

BTW, I can confirm that feeding PHY's XI from an IMX6 internally

generated clock is not very stable although if I am not mistaken

at least on FSL's eval board (solosx?) uses this mechanism.

Thanks

Sinan Akman

[gusarambula]

RGMII does require a 125 MHz reference clock feeding the ENET_REF_CLK input. This reference clock may either be sourced by an external oscillator or an external PHY. Freescale’s SABRE board uses a PHY to generate the clock and then feed it to the ENET_REF_CLK input. There's information on this on the i.MX6 Hardware Development Guide (link below) on table 2-9.

http://cache.freescale.com/files/32bit/doc/user_guide/IMX6DQ6SDLHDG.pdf

You are correct in that the internal clock should not be used for RGMII, the workaround I mentioned is not the intended use and does not provide an optimal clock.

[sinanakman]

Hi Gusarambula, Clemens

I know the HD guide explains as you mention and

in the design I worked we probably did it that way

but here is what Reference Manual says :

-------------------------------------------------------------------------

From Table 23-1. ENET External Signals on page 1062"

Signal  :   ENET_REF_CLK

Description :

In RMII mode, this signal is the

reference clock for receive, transmit,

and the control interface.

Mode : RMII

-------------------------------------------------------------------------

As it doesn't explicitly specify  RGMII mode it

wasn't clear if it is needed for RGMII.

Perhaps more of an issue on the document.

Regards

Sinan Akman

[sinanakman]

Now looking at this a bit further. On Figure 23-72. RGMII transmit operation

and Figure 23-73. RGMII receive operation that ENET_REF_CLK is not even

included. The more I think about this, it looks like for the RGMII case

the related clock signals (RGMII_TXC and RGMII_RXC) are output

from ENET PLL. This PLL's source can be REF_CLK_24M, CLK1,

CLK2 or XOR of CLK1 and CLK2. The output clock signals' frequency

is either 5MHz, 50MHz, 100MHz or 125MHz depending on the value

of CCM_ANALOG_PLL_ENET[0:1]. In all that ENET_REF_CLK

seems to be irrelevant.

Perhaps I am reading all these wrong but it would be interesting

to know what you guys are thinking.

Regards

Sinan Akman

[clemensgruber]

As far as I understood, ENET_REF_CLK is something like a core / operational clock for the MAC and has nothing to do with the RGMII signals. But maybe gusarambula can say more about this?

[sinanakman]

Hi Clemens, thanks for sharing this.

I am just trying to understand one thing.

In KSZ9031 datasheet XO is marked as no

connect when an external xtal is used.

Also I didn't think you had to have 125M

for RGMII/GigE. If I remember correctly

I worked on a design where we had an

25M external XTAL and this was fine for

iMX6/RGMII/GigE. We did use a different

PHY though. Are you sure you can not

have 25M external xtal for iMX6/RGMII/GigE.

This would solve your problem as XO would

be irrelevant ?

Thanks

Sinan Akman

[clemensgruber]

Hi Sinan,

we are already using an external 25 MHz oscillator for the PHY, connected to XI and we did not connect XO.

The hardware development guide specifies that you need to have an external oscillator with 125 MHz for the ethernet MAC. (Table 2-9 "Gigabit Ethernet Recommendations") in IMX6DQ6SDLHDG:

"This chip requires a 125 MHz reference clock feeding the ENET_REF_CLK input. This reference clock should be sourced from an external 125 MHz oscillator or an external PHY."

In the KSZ9031 datasheet, Micrel writes "The KSZ9031RNX has the option to output a 125MHz reference clock on the CLK125_NDO pin. This clock provides a lower-cost reference clock alternative for RGMII MACs that require a 125MHz crystal or oscillator."

So first, we decided to use that as input for the i.MX6Q ENET.REF_CLK but then we read the KSZ9031RNX errata sheet: This "lower cost alternative" 125MHz clock on CLK125_NDO should not be used because there are duty cycle variations.

Are you sure you left the ENET.REF_CLK on the i.MX6Q unconnected or did your PHY also provide a 125 MHz clock for the Ethernet MAC?

Best regards,

Clemens