ENET_REF_CLK (ball V22) duty-cycle requirements on i.MX6

cancel
Showing results for 
Show  only  | Search instead for 
Did you mean: 

ENET_REF_CLK (ball V22) duty-cycle requirements on i.MX6

Jump to solution
1,320 Views
grantfordham
Contributor I

Hi,

I would like to know the duty-cycle requirements for the ENET_REF_CLK input in RGMII mode. We are using the KSZ9031RNX PHY which has the following errata:

The 125MHz reference clock (CLK125_NDO pin) output

has duty cycle variation when the KSZ9031 links up in

1000Base-T Slave mode, resulting in wide variation on

the falling clock edge.

Has anyone successfully used this PHY with the i.MX6 while driving ENET_REF_CLK from CLK125_NDO output of the PHY?

One of the workarounds is to only use the rising edge of the clock provided on CLK125_NDO, but I'm unsure how exactly ENET_REF_CLK is used internally. Does it drive RGMII_TXC directly or is there a PLL in between?

There is a similar question from clemensgruber at the link below, but the question as to how ENET_REF_CLK is used internally and exactly what the duty cycle requirements are has not been answered. BTW, thanks clemensgruber for alerting me to the KSZ9031RNX errata :smileyhappy:

i.MX6Q ENET.REF_CLK input

Regards,

Grant

Labels (1)
Tags (1)
0 Kudos
1 Solution
738 Views
clemensgruber
Contributor III

Hi,

the TQMa6x starter kit used this approach, but I think they corrected it in the following revision and are now using another PHY.

I saw some workaround patches for said starter kit, which forced auto-negotiation master mode, but this was not a satisfying solution for us.

I think ENET_REF_CLK drives RGMII_TXC directly.

I strongly recommend using a separate 125 MHz oscillator with good (25ppm) frequency stability, I don't think you are saving much by using CLK125_NDO as ENET_REF_CLK.

Also, the ENET_REF_CLK does not have to be "in sync" with the PHYs 25 MHz clock, therefore a separate oscillator is the best solution.

In the end we decided to use a Marvell 88E1510 PHY (which is working great btw.) and although that PHY also has a 125 MHz clock output, it is not supported to use as reference clock for the MAC as it is only used for PTP etc. They explicitly tell you in the datasheet that it's not supported to use as MAC reference clock.

Maybe Micrel planned to give customers a cheap alternative to an external oscillator, but according to mentioned errata, it did not work out.

We use an oscillator from Abracon, the ASEMPC-125.000MHZ-LR-T as ENET_REF_CLK input. For more information see http://www.abracon.com/Oscillators/ASEMP.pdf

View solution in original post

0 Kudos
1 Reply
739 Views
clemensgruber
Contributor III

Hi,

the TQMa6x starter kit used this approach, but I think they corrected it in the following revision and are now using another PHY.

I saw some workaround patches for said starter kit, which forced auto-negotiation master mode, but this was not a satisfying solution for us.

I think ENET_REF_CLK drives RGMII_TXC directly.

I strongly recommend using a separate 125 MHz oscillator with good (25ppm) frequency stability, I don't think you are saving much by using CLK125_NDO as ENET_REF_CLK.

Also, the ENET_REF_CLK does not have to be "in sync" with the PHYs 25 MHz clock, therefore a separate oscillator is the best solution.

In the end we decided to use a Marvell 88E1510 PHY (which is working great btw.) and although that PHY also has a 125 MHz clock output, it is not supported to use as reference clock for the MAC as it is only used for PTP etc. They explicitly tell you in the datasheet that it's not supported to use as MAC reference clock.

Maybe Micrel planned to give customers a cheap alternative to an external oscillator, but according to mentioned errata, it did not work out.

We use an oscillator from Abracon, the ASEMPC-125.000MHZ-LR-T as ENET_REF_CLK input. For more information see http://www.abracon.com/Oscillators/ASEMP.pdf

0 Kudos