2023-12-12 01:58 AM
Hi,
I plan to use LAN8742A and STM32H7 for an ethernet application.
In the datasheet for LAN8742A there is this very interesting sentense on page 34 i the datsheet:
The REF_CLK Out Mode is not part of the RMII Specification. To ensure proper system operation, a timing
analysis of the MAC and LAN8742A/LAN8742Ai must be performed.
Does anybody have any experience or good advise on what they have done/used to get it done?
Thank you
Solved! Go to Solution.
2023-12-13 01:55 AM - edited 2023-12-13 01:56 AM
Yes, you would do the same analysis as with external 50MHz clock source, e.g. whether the cumulative oscillator asymmetry plus delays between REF_CLK input to MAC to MAC Tx output match the required delay between clock edges and Tx edges at the input of PHY.
It would probably take a rather deviant MAC not to have this fulfilled, given the timings in REFCLKO mode are generally the same or better than with external 50MHz clock; but from SMSC/Microchip's point of view, this is your responsibility to judge, that's why that note.
JW
2023-12-12 03:43 AM
Hello,
Maybe this thread could help you.
2023-12-12 03:54 AM
Hi,
OK so the hint is to have the STM32 generate the clock and then synchronisation is handled better than having the LAN8742A generate the clock from a 25MHz crystal?
2023-12-12 04:04 AM - edited 2023-12-12 04:06 AM
Hello,
This is a reference design from our Eval board schematics: you can either select to get the clock from the STM32 or to have the clock from the external clock:
I'm not expert of ETH but I think the most important thing is the ppm of the clock source you are using as said by LCE in the thread I provided to you.
2023-12-12 04:42 AM
> I'm not expert of ETH but I think the most important thing is the ppm of the clock source
Not only that, but also jitter should be reasonably low; some PLLs won't cut it.
But the message of the thread to which @SofLit gave above the link is, that unnecessarily high slew rate on GPIO may disturb crystal oscillator (this of course depends also on the exact physical arrangement of all circuitry). The basic arrangement described in that thread is IMO equivalent to the the schematics above.
JW
2023-12-12 05:05 AM
Hi,
Thank you for the answers.
Very good inputs, I will note down.
My initial questions was more related to page 34 in the LAN8742A datasheet and shown below. That some timing analysis is needed when using the REF_CLK out mode?
If using a 50 MHz reference clock equal to both STM32 and the PHY (page 33), then I guess it is only a matter of equal lengths to the two devices.
2023-12-13 01:55 AM - edited 2023-12-13 01:56 AM
Yes, you would do the same analysis as with external 50MHz clock source, e.g. whether the cumulative oscillator asymmetry plus delays between REF_CLK input to MAC to MAC Tx output match the required delay between clock edges and Tx edges at the input of PHY.
It would probably take a rather deviant MAC not to have this fulfilled, given the timings in REFCLKO mode are generally the same or better than with external 50MHz clock; but from SMSC/Microchip's point of view, this is your responsibility to judge, that's why that note.
JW
2023-12-14 02:23 AM
Hi,
I have tried to go through the ST Nucleo (MB1137) and look on how they have routed the RMII traces. Just measuring the the tracks give:
REf_CLK: 152mm
TX_EN: 155mm
TXD0: 144mm
DXD1: 154mm
RXD0: 155mm
RXD1: 163mm
So I would say, they are not that well length matched. Not even in the intra TX and RX lines.
So if this board/solution works then, then it is as you say just a disclaimer from SMSC/Microchip.
Microchip to mention in their layout guide the below suggestion, which definitely is not done on this PCB.
What are your thoughts on this?
Thank you for support.
2023-12-14 02:47 AM
What skew do you expect from 11mm difference?
We are talking nanoseconds here.
JW
2023-12-14 03:22 AM
Sorry you are right, they can be considered more or less equal in electrical length.
But what I tried to say was that, the no signal compared to the others, have not been delayed in any significant sense.
Sorry for the confusion.