RMII1_REFCLK parameters

The AM335x data sheet defines the RMII[x]_REFCLK to have period of 20ns or frequency of 50MHz.

The Ethernet Subsystem chapter of the AM335x TRM also describes a 50MHz requirement for the RMIIx_REFCLK.

When this pin is configured to operate as RMII[x]_REFCLK, it always operates as the Ethernet Subsystem input clock.  However, the AM335x device may also be configured to source this clock.  In this case the pin is an output and input at the same time.  See the TRM figure titled "Ethernet Switch RMII Clock Detail" to visualize how this I/O can be configured as input only or both input and output.

Regards,
Paul

paul,

my concern is related to following characteristics:-

1) Clock Frequency drift

2) Clock Jitter

3) Clock duty cycle

4) Clock voltage level

The first three parameters have not been characterized at this time.  However, they should meet the requirements defined in the RMII specification.

The voltage level of these I/Os will be determined by the VDDSHV5 supply voltage since this power domain sources power to the I/O buffer of both RMII[x]_REFCLK pins.  For more details, refer to the "All other LVCMOS pins" section of the "DC Electrical Characteristics Over Recommended Ranges of Supply Voltage and Operating Temperature" table in the AM335x data sheet.

Regards,
Paul

Hi Paul,

How is going the characterization of this RMII[x]_REFCLK ?

We have some troubles with a NS PHY used with RMII[x]_REFCLK sourced by AM3359. We suspect an error of synchronization on the Ethernet signal due to the characteristics of reference clock. For example, the measure of this clock at PHY is just over the limit in term of duty-cycle.

We will check the layout, but it will be great to know if the source respects our needs.

Do you know other trouble cases by using this clock as source?

Thanks

Hello Cyril,

We are looking at this right now. I should have an update for you soon.

Can you point me to the datasheet for the PHY you are using?

-DK

Hello,

we use this PHY : http://www.ti.com/product/dp83848k

Cyril

Paul,

is there an update on TI measuring these clock parameters? 

We are using the AM3359 with a LAN8710A Ethernet PHY.  We are also seeing issues with the clock. On our boards, the REFCLK duty-cycle is 40%-60%, which is right at this PHY's limit. The REFCLK frequency drift measures about 2000 ppm instead of the specified 50 ppm.  It looks like this frequency follows the frequency drift of the AM3359's crystal, which also has about 2000 ppm drift on our boards. 

I'd like to find out if these clock issues in our design are specific to our implementation, or if they are related to the AM335x processor.  How do these clock parameters look on TI's boards?

thanks

Hi Paul and all,

I have seen the errata and the workaround suggested. I have one concern:

Does anyone have tested two ethernet ports 10/100 using RMII and an external clock source as suggested in the workaround?

The scenario above will be the only option for our case, and we would like to have some reference of results. The phy we goingo to use is the LAN8720.

Thanks

Rodrigo

I'm not aware of any boards that have implemented two RMII PHYs.

Regards,
Paul 

Hi All,

We also bounced to the problem of the RMII clock out of the AM335x, which has to much jitter. (We are using a Micrel KSZ8021.)

Very annoying that this silicon bug is showing up so late! Our production run has started :-(

Temporary solution is to force the phy to work in 10mbps mode, which seems to work stable.

We don't have a jitter measurement tool, my questions are:

1. If we select a clock crystal (24MHz) with - lets say - 10ppm, does this positively affect or even meet the jitter of the 50Mhz clock output?
2. Is it possible with a redefinition of the internal clocking scheme in clock33xx_data.c to use the ADPLLLJ? (TRM is very complex about clocking)
3. Are the multiply/divider values of the ADPLLS set to have minimum extra jitter introduction? Are there improvements possible?

Best Regards,

Wim

Unfortunately the TI AM335x EVM, the internal hardware platform used to verify AM335x,  was designed with an RGMII Ethernet PHY so we were not aware of this problem until it was reported by a customer.

The DPLL sourcing the RMII reference clock output is inserting the jitter.  This is not a function of the crystal accuracy.

The AM335x does not provide any option to source the RMII reference clock output from ADPLLLJ.

The ADPLLS jitter performance can not be improved enough to comply with the requirements of RMII Ethernet PHYs.

Regards,
Paul

Hi,

We have implemented two PHY (NS SP83848) in RMII mode. We used the clock sourced by AM335x and we have to redesign our board with externals clocks. If you ask again in 5 ou 6 weeks, we will have more results to give.

Cyril

Thanks for sharing this info, Cyril.

Just one question: why do you decided to use two single phy DP83848 instead dual phy DP83849 ? Any special reason ?

Thanks

Marcelo

We have two designs with AM335x. One with  two Ethernet ports and one with only one port. Because of space cost on board, we can remove unused PHY. And we also have used this PHY in the past... ;-)

Cyril

Thanks Cyril. As area (7x7  x  14x14 mm) and power (267mW x 594mW) didn't help so much, I was wondering if they were related to your decision. See you !

Does this mean that booting from Ethernet, using RMII, no longer is supported?

 Never mind. I just found the answer in Advisory 1.0.18.

Cyril BEGUET said:

Hi,

 

We have implemented two PHY (NS SP83848) in RMII mode. We used the clock sourced by AM335x and we have to redesign our board with externals clocks. If you ask again in 5 ou 6 weeks, we will have more results to give.

 

Cyril

Hi Andre,

Bit 6 and 7 of GMII_SEL register need to be set.

my first MAC is working fine. but the 2nd MAC can't receive data. Paul told me maybe my external crystal oscillator maybe not a low jitter one.

I need to check the data output by the phy to find out if the phy is work correctly.

FTR: In my board file in function am335x_evm_init(), changing am33xx_cpsw_init_generic(RMII_MODE_ENABLE,gigabit_enable); to am33xx_cpsw_init_generic((RMII_MODE_ENABLE|(1 << 6)|(1 << 7)),gigabit_enable); does the trick.