Using PLL5 for RMII-Clock

[slw]

Hi,

I have a custom board with a PVF522R and a Ethernet-PHY using RMII.

I want to use the PLL5 as clock source for the internal MAC and the PHY (PTA6 / RMII_CLOKOUT).

First tests shown that data from Phy to MAC is working well, but data-transfer from MAC to PHY is not stable.

It seams that therre is something wrong with my settings cause the MAC puts data on the RMII on the falling edge of the RMII-Clock, not on the rising edge.

When I use a external clock for RMII and set PTA to RMII_CLKIN all works fine.

Any suggestions?

Or is there a problem cause the controller is a engineering sample ?

Regards

[jochengerster]

Dear Mr Waldraff

thanks for your email

I had the same effect with the vybrid tower board with sporadic communication and the problem was that the PHY and the Vybrid drive the RMII clock at the same time.

Without knowing all details my first guess would be the same happens here as you also mentioned that if vybrid uses the RMII_CLK as an input it works but that definitely means the phy is driving the RMII clock

best regards

Jochen Gerster

[slw]

Hello Mr. Gerster,

The Phy has a dedicated clock-input-pin (which we are using) and a dedicated clock-output-pin (which we left open as suggested in the datasheet of the phy).

So this cannot be the cause for the problem.

When I disable the RMII clock in the vybrid-cpu, there is no RMII clock signal.

Any other ideas ?

regards

Sebastian Waldraff

[jochengerster]

Hello Mr. Waldraff

>>The Phy has a dedicated clock-input-pin (which we are using) and a dedicated clock-output-pin (which we left open as suggested in the datasheet of the phy).

I don't know the PHY and couldn't find the datasheet public - for me it is strange not having a direct clock between PHY and Vybrid on the RMII interface (no matter who is driving the clock)

I assume you try to save the external crystal for the phy?

This sounds like the PHY still drives the RMII clock out and so it need to be left open. I don't know how the PHY connects the clock input with the RMII clock out...

Have you compared the clock input with the not connected clock out?

best regards

Jochen Gerster

[slw]

Hello Mr. Gerster,

I have attached two diagramms which perhaps make it more clear. What we want is diagramm 1 and use the PTA6 as Clock_out to save external components as you assumed.

You can find the datasheet of the phy on http://www.microchip.com/wwwproducts/Devices.aspx?product=LAN8710A

best regards

S. Waldraff

[naoumgitnik]

Dear Sebastian,

Please, find some code, which hopefully will help you:

• Clock & pad settings – Sysinit.c (function “sysinit”),
• ENET register configurations selection - Enet_tests.c (function “functional_tests”),
• ENET register settings – enet.c (function “enet_init”).

Sincerely, Naoum Gitnik.

[slw]

Dear Naoum,

Dear Mr. Gerster,

Now I have a Freescale AutoEVB-board and have done some measurements.

And you are right, I have mixed the description of rxd and txd.

I have attached the results of my mesaurements.

In my opinion, there is a bug inside the vybrid-cpu.

Regards

Sebastian

[naoumgitnik]

Dear Sebastian,

I am still discussing the issue with my colleagues to figure out how to correct the timing, but at the same time may you also try to increase internal impedance not of the RMII clock pad  but of the RMII TXD pads' (equivalent to delaying data, not clock), please? It looks better to "delay" the data as a workaround for the following reasons:

• Slow clock signal edges are prone to multiple data sampling (due to multiple input threshold crossing), thus keeping them sharp is beneficial.
• It looks like it is easier to meet the RMII specification by delaying data, not clock - easier to meet the 2ns min. Thold requirement than the 4ns min. Tsu one (refer to the RMII specification attached).
  

Sincerely, Naoum Gitnik.

Hans-PeterRosinger

[slw]

Hi Naoum,

You are right. Its better to delaying data and not clock. I have done a test where I have set clock to the slowest impedance and fast slew rate.

When I set the data-lines to slow slew rate and an impedance of  >= 50Ohm the communication works.

Do you have any updates from your colleagues ?

Regards Sebastian

[naoumgitnik · Accepted solution]

Dear Sebastian,

I am glad my last, the better workaround works quite well for you; you have to be sure, though, the RMII spec timing requirements are met, and not just marginally.

I am still working with our Vybrid IC design team to verify if there is a way to add a delay in to the clock or data signals directly, not just playing with the pulse slope; their first, unofficial, reaction is that such option does NOT exist, and we have to apply workarounds for it (will let you know if their official reply differs, but it is quite unlikely…).

So, it looks like the summary is to use 3 possible workarounds to fix the timing:

1.       Which you already proved - using an additional Vybrid IO to output 50MHz clock to be used by both Vybrid PTA6 pins and the PHY (IMO, the most straightforward one),

2.       Inverting the RMII clock with an additional external inverter (is the RMII spec timing met then?),

3.       Playing with the TX Data pulse slope (equivalent to inserting artificial delay) - not sure if you may always count on the parasitic capacitance (PHY input + PCB stray), might need to add external capacitors to keep it spec-compliant for all voltage-temperature-process variations.

Thanks a lot in helping us find and resolve this issue!

Sincerely, Naoum Gitnik.

[slw]

Dear Naoum,

We will fix the problem using solution 1 in our custom board which is in my opinion the most stable option.

Thanks a lot for your support.

Regards Sebastian

[naoumgitnik]

Dear Sebastian,

I am working with the IC design team on this issue.

Sincerely, Naoum Gitnik.

[naoumgitnik]

Dear Sebastian,

I am still trying to get some other code examples for your case, will post here if find anything.

I reviewed the Vybrid-Phy.pdf file and am a bit confused by how the RXD and TXD pins are connected to each other - it should me the same name on both the MAC and PHY sides (e.g. see Figure 2 on page 16 of http://www.micrel.com/_PDF/Ethernet/datasheets/ksz8021rnl_8031rnl.pdf). Hopefully, the error is only in this illustrative document but not in the real design, otherwise nothing would work with any clocking scheme, right? (BTW, may you correct it in the same message, using 'Edit' option, to not confuse the others, please?)

BTW, from your PHY's datasheet, it is clear why it is working in the RX direction:

"3.4.2.2 Reference Clock (REF_CLK)

The RMII REF_CLK is a continuous clock that provides the timing reference for CRS_DV, RXD[1:0], TXEN, TXD[1:0] and RXER. The device uses REF_CLK as the network clock such that no buffering is required on the transmit data path. However, on the receive data path, the receiver recovers the clock from the incoming data stream, and the device uses elasticity buffering to accommodate for differences between the recovered clock and the local REF_CLK."

Please, keep me updated how your debugging is going.

Sincerely, Naoum Gitnik.

[Nouchi]

Hello Sebastian,

Did you try to change SPEED/DSE parameters in IOMUXC_PTA6 register, it could help, maybe the signal is too "sluggish".

[slw]

Hi,

Thanks for your answer.

I have tried different settings without success.

I can measure that the MAC puts his data on RMII at the wrong edge. The PHY reads data at the rising edge of the RMII-Clock.

But the MAC does change the data-lines at the rising edge. Which is wrong in my opinion.

The data-connection from PHY to MAC works correct.

[naoumgitnik]

Dear Sebastian,

I tried to find where in our documentation the RMII clock phase is controlled, but :smileysad:, so I decided to approach the problem from the other end...

In one of our designs, Vybrid Automotive board, an RMII Etherent PHY is used, and Vybrid provides clock for it; thus, it makes sense to compare its settings to yours to find the difference.

timesyssupport, is there a way to share either those settings or simply a relevant piece of code (responsible for Ethernet / RMII) of the Vybrid Automotive board with the customer, please?

As far as I learned, it is a part of Uboot.

If, however, the code is considered confidential, please, provide all the information required for the customer to send a request to the local Freescale FAE.

Sincerely, Naoum Gitnik.

[timesyssupport]

Hello Naoum,

In the u-boot sources supported by Timesys, version 2011.12, clocks are initialized in arch/arm/cpu/armv7/vybrid/lowlevel_init.S, in the init_clock macro.

Let me know if this helps.

Timesys Support

[naoumgitnik]

Dear Timesys Support,

Thanks for your quick reply!

How can the customer get to this "u-boot source..., version 2011.12, ... in arch/arm/cpu/armv7/vybrid/lowlevel_init.S, ... init_clock macro", please?

Sincerely, Naoum Gitnik.

[timesyssupport]

Hello Naoum,

The u-boot source can be found in any of the Starting Point builds for the Vybrid Tower published on LinuxLink:

https://linuxlink.timesys.com/download

For example, the u-boot source for the MCC Demo starting point can be found here:

https://linuxlink.timesys.com/build/viewBuildOutput.xhtml?buildId=39152&path=output/sources/u/u-boot...

You would need to download and extract the source tarball, then apply the patch.

Alternatively, you can view the u-boot source for the Vybrid Tower via the public u-boot git tree hosted by Timesys. This requires a LinuxLink account to view:

https://linuxlink.timesys.com/git?repo=u-boot.git&view=tree&h=2011.12-mvf

Thanks,

Timesys Support

[naoumgitnik]

Thanks a lot to timesyssupport for their help and clarification!

Dear Sebastian,

Please, let me know if this information helps to resolve the issue.

Sincerely, Naoum Gitnik.

[slw]

Dear Naoum and Timsys-Support

Thanks for your fast response.

I have check several register-settings without success:

- PLL5 (ANADIG_PLL5_CTRL = 0x80002001)

- CCM (CCM_CSCDR1 = 0x01000000

           CCM_CSCMR2 = 0x00000020)

- IOMUX (IOMUXC_PTA6 = 0x00102192

             IOMUXC_PTC0 = 0x00103192

             IOMUXC_PTC1 = 0x00103993

             IOMUXC_PTC2 = 0x00103191

             IOMUXC_PTC3 = 0x00103191

             IOMUXC_PTC4 = 0x00103191

             IOMUXC_PTC5 = 0x00103191

             IOMUXC_PTC6 = 0x00103192

             IOMUXC_PTC7 = 0x00103192

             IOMUXC_PTC8 = 0x00103192

Do I have to check other registers too ??

Thanks