Tool/software:
Hi TI experts,
Please provide guidelines for using RMII interface
Recommendations while using TI EPHY for RMII interface
Information related to RMII
could you confirm if SSC from LMK3C0105V33RERR is supported by 50-MHz CLK inputs for both 1V8/3V3 RMII (implemented at AM64x by CPSW3G, RMII-REF_CLK )
If yes, at which % ranges ?
The RMII standard requires the reference clock to be within 50PPM of 50MHz, so SSC is not possible for Ethernet.
The signal integrity associated with the original 10 ohm series resistor may have created a condition where the step was occurring very close to the device input switching threshold, such that it was not causing a problem. There may have been a small shift in the device input switching threshold that caused the original implementation to become problematic. The input switching threshold can have a lot of variability and still be compliant to the JEDEC standard logic levels, so it is not something that is tightly controlled. You can try to shift the step such that it occurs above VIH on the low to high transition and below VIL on the high to low transition to be sure it doesn't cause any problems.
You still need to limit maximum frequency error to 50 PPM.
Both clocks have the same requirement, where they need to operate within the +/-50PPM limit to ensure there is not too much difference in the rate which data is transmitted vs the rate the receiver is operating. If there is too much error the transmit rate from one end may over-run elastic buffers which were only designed to accommodate a maximum difference of 100PPM, which could occur if one end is operating 50PPM fast and the other end is operating 50PPM slow. The Ethernet standard had to draw the line somewhere and they decided to select the limit of +/-50PPM for RMII and RGMII. Note: The limit was +/-100PPM for the MII standard but was reduced to +/-50PPM when they defined the RMII and RGMII standards.
The Ethernet data must be moved to/from the RGMII/RMII side of the Ethernet MAC to/from the other side of the Ethernet MAC that is communicating with other internal logic functions operating from a different clock domain. The elastic buffers that span across the clock domains were only design to accommodate the maximum frequency difference allowed by the Ethernet standard. Increasing the elastic buffer size to allow for a larger frequency difference than defined by the Ethernet standard would unnecessarily increase the elastic buffer size and increase silicon cost.
This clocking topology was introduced on the AM64x EVM to satisfy an industrial application that uses Time Sensitive Networking (TSN). The clocking topology has been carried over to newer EVMs. The person that included the comments in the schematic check list may not have fully understood the reason this was done. I will try to get this clarified in the next revision.
Most applications do not require the SoC and Ethernet PHY to operate from the same clock source. This is only a requirement for a few industrial applications using Time Sensitive Networking (TSN). The TSN application doesn’t require phase aligned clocks, but it does require all of the devices to be operating at the same frequency. This clocking topology was used to ensuring each device on the AM64x EVM is operating at the same frequency, without the small PPM error that would be introduced from multiple clock sources.
In some cases, a customer may want to use a single 25MHz clock source for multiple devices and their application doesn't require a specific clock relationship across the devices. They may be buying a single LVCMOS clock source and using it for multiple devices because it offers a lower cost solution then buying multiple LVCMOS oscillators or crystals. In this case they should use a 1-input to n-output buffer to ensure appropriate signal quality on each clock signal. Branching a clock signal without buffers on each signal path is problematic because the clock signal will be distorted, and the distortion could create glitches on the internal clock tree of the attached devices.
You will need to determine the best clocking solution for your specific system. Assuming your system is using separate clock sources for each device, you just need to make sure the clock source selected for each device is operating within the limits defined for that device. For example, the AM62x device requires a 25MHz reference clock with a maximum frequency error of 50PPM when using RMII or RGMII. The 50PPM error must be the combination of the initial frequency error and the frequency error introduced by temperature variation and aging of the clock source across the system's entire operating range.
The 25MHz reference clocks required for the AM62x device and Ethernet PHY does not need to be synchronous because Ethernet data is transferred between the MAC and PHY using the source synchronous clocks that are part of RGMII. Each device has a maximum frequency error that is allowed for their reference clock to ensure data flowing from one device to the other never over-runs an elastic buffer that spans the two clock domains.
Connecting multiple loads to a single clock output is a bad design practice because this creates signal distortion that can be problematic on clock signals.
A single clock source topology was implemented on the EVM to support industrial applications that needed the Ethernet PHYs to operate at the exact same frequency as the AM64x device, without the small PPM error that would be introduced when using multiple clock sources. This may not be a concern for your application. If not, you can provide a separate clock source to the Ethernet PHY(s). However, you need to make sure each clock source is operating within the valid operating range of the respective devices. For example, the AM64x device requires a reference clock that has a maximum frequency error of 50PPM when using RMII or RGMII. The 50PPM error must include the initial accuracy of the clock source combined with any deviation due to temperature changes and aging.
I'm not clear how to configure IOSET1 and 2 for each. Is it possible to mix IOSET1 and 2?
For example, is it possible to use IOSET1 for RMII and IOSET2 for MDIO?
You must select one of the valid combination of pins (IOSET) defined for a peripheral. For example, you must select the pins defined in RMII IOSET1 or RMII IOSET2 when using one or both of the RMII peripheral ports. Normally each peripheral port has its own IOSETs, but that is not the case for the RMII ports on AM243x because both RMII ports use a common RMII_REF_CLK. The IOSETs associated with any other peripheral is not related. For example, the IOSETs associated with RMII are completely independent of the IOSETs associated with MDIO.
The two RMII ports on AM64x share a common clock to transfer RMII data between the MAC and PHYs.
The RMII specification does not define a clocking mode where the PHY sources the clock. The specification assumes the clock is sourced by an external 50MHz clock source. Some PHYs were designed to source this clock, but this is an optional feature that is only provided on a few PHYs.
It is not possible to use the optional PHY master mode when connecting two RMII PHYs to AM64x because you must source the same clock to three inputs (the common clock input on AM64x and each of the two RMII PHYs clock inputs). The clock source needs to be buffered with equal delay that is half of the data path delay connecting the MAC and PHYs. This also means the data path delays to each PHY must be the same.
You should perform a timing analysis of the interface using the Switching Characteristics and Timing Requirement values from each device (AM335x and attached RMII PHY) datasheet along with actual PCB delays. You may find it is necessary to adjust signal trace lengths to optimize trace delays to provide margin for all timing requirements. For example, you may find the 50 MHz reference clock needs to be injected closer to one end of the reference clock signal connecting the two devices.
You will need to configure the PADCONF register for each AM335x IO that connects to the RMII PHY to make sure you have selected the correct mux mode and turned on the receivers of any IOs that are operating as inputs.
Some Ethernet PHYs share configuration functions on their RMII IOs. If that is the case for your PHY, you may need to evaluate the effect of AM335x internal pull resistors on the PHYs configuration pins.
What is the purpose of having a clock input at RMII_REF_CLK pin? Normally this pin is supposed to be an output and if we are using an external clock to the phy, why should we be connecting the same clock to the AM335x? Is it to sync clocks with the phy somehow but isn't the MDCLK for that purpose? What happens if we leave RMII_REF_CLK floating?
The Ethernet PHY has two interfaces, MDIO and RMII.
MDIO is a two signal interface, where one is a clock that originates from the MAC and the other is bi-directional data signal. This interface is used by the MAC to read/write configuration information in the PHY and read status from the PHY.
RMII is used to transfer TX and RX Ethernet data between the MAC and PHY. The 50 MHz reference clock is a signal that synchronizes the RMII data transfers. So you need the reference clock for RMII to transfer data. RMII was originally defined to use a separate clock source that would source both MAC and PHY sides of RMII. Some MACs and PHYs may provide enhanced capabilities of sourcing the reference clock to the attached device. However, this may be problematic since the device sourcing the clock will see the clock transition before the attached device sees the clock transition due to propagation delay introduced by the PCB trace. This could reduce or eliminate timing margin necessary to achieve valid data transfers.
customer wants to use 2x RMII EPHY (DP83826) in slave mode for CPSW. What design/layout challenges does he need to take care? What clock buffer do we recommend to source the common clock for the RMII EPHY and AM64xx?
is it possible to use the following clock buffer for the RMII-50MHz clock provided by the Sitara?
https://www.ti.com/product/LMK1C1103
One output will be routed back to the Sitara RMII-REF pin used for both RMII-Interfaces of CPSW3G
The remaining two outputs will be routed to the respective XI-pins of DP83826 and all three outputs need to be length-matched, right?
I believe this can be done with the low skew clock buffer mentioned above. However, it will require careful PCB layout to ensure all timing requirements have margin. The tricky one you need to watch is the MAC min output delay of 2ns and the PHY hold time of 2ns. The PCB delay of the MAC to PHY data path will provide some margin, but it needs to be at least 50ps to account for the max clock buffer skew. You could also place the clock buffer closer to the two PHYs, such that the PHYs see the clock before the MAC. This would add additional margin for this parameter. However, this clock delay difference will impact the margin of other timing parameters. You need to do a careful timing analysis that includes all trace and clock path delays and adjust your PCB delays such that all timing requirements have margin.
Since both AM64x RMII ports use a common clock, you need to make sure the PCB paths between AM64x and both PHYs have matched delays.
We are working on a very similar setup with the RMII clock provided by the CLKOUT of the AM6442, but with only one PHY.
Do we actually need a clock buffer in this case or can the CLKOUT of the AM6442 drive both clock pins like in the picture above? The length between CLKOUT->PYH and CLKOUT->MAC should be matched of course.
Could you also please elaborate on your explanation above regarding the clock skew? Because, to be honest, I can't quite follow your explanation? Why is the low skew of the clock buffer "bad", making the PCB layout more tricky? How is the data path delay connected to the clock buffer skew? The data is set on the falling edge and sampled on the rising edge of the clock:
So as long as T2 and T3 are "long enough" there should be no problem. The clock period is 20ns, 50ps clock skew should not significantly influence the timing.
I would not recommend sourcing two loads with a single clock source. There will be an impedance discontinuity when the signal splits into two paths and this will create reflections that distorts the clock signal. The distortion could cause glitches on the internal clocks of the MAC and PHY. There may be tricks you can do on your PCB to minimize the reflections, but you would need to simulate signal integrity of your specific PCB design to be sure the implementation will not cause problems. Adding the low skew clock buffer is the best approach.
I never said the low skew buffer was a problem. You actually need a low skew buffer to make this work.
Let's assume you match the length of each clock path. The clock buffer could insert as much as 50ps of skew, so the PHY could receive the clock 50ps after the MAC. This could be a problem because the PHY has a 2ns hold time requirement and the MAC may only hold the previous data value for 2ns. It takes some time for the MAC output data to reach the PHY because the of the data path delay. However, this data path delay must be greater than 50ps to ensure the data arriving at the PHY does not violate its hold time requirement. If the data path is not at least 50ps long, you would need to make it longer, or shorten the clock delay to the to the PHY relative to the clock delay to the MAC. This would add additional margin to the PHY hold time requirement. However, it removes setup time margin.
Setup time is a function of clock period since data is changed on the rising edge of clock and latched on the next rising edge of clock. Hold time is not a function of clock period since data must be held for a specific period of time after the clock edge that latches data.
Regards,
Sreenivasa
Hi Board designers,
Refer below input regarding MDI termination and EPHY supply filtering
Ethernet PHY PCB Design Layout Checklist
DP83822
www.ti.com/.../snls505
Figure 9-2. TPI Network Circuit
Figure 10-1. Power Connections
MDI connections
https://www.ti.com/tool/TIDA-00928
https://www.ti.com/lit/ug/tiducd5c/tiducd5c.pdf
https://www.ti.com/tool/TIDA-00299
https://www.ti.com/lit/ug/snlu179/snlu179.pdf
CRCW040249R9FKED R37, R38, R39, R40 RES, 49.9, 1%, 0.063 W, 0402
DP83826
https://www.ti.com/lit/pdf/snls64
Figure 9-2. TPI Network Circui
Figure 9-6. Power Supply Decoupling Recommendation
The T1 is the XI/RX_CLK/Master clock frequency and that TI frequency depends on the specific RMII operation. In RMII Master operation, the DP83826 operates from either a 25-MHz CMOS-level oscillator connected to XI pin, a 25-MHz crystal connected across XI and XO pins. A 50-MHz output clock referenced from DP83826 can be connected to the MAC. In RMII Slave operation, the DP83826 operates from a 50-MHz CMOS-level oscillator connected to the XI pin and shares the same clock as the MAC. Alternatively, in RMII slave mode, the PHY can operate from a 50-MHz clock provided by the Host MAC.
So in the DP83826 datasheet, please see the clock specification below for the TI.
DP83825
www.ti.com/.../snls638
Figure 7-3. TPI Network Circuit
Figure 7-4. DP83825I Power Supply Decoupling Recommendation
Regards,
Sreenivasa
Hi Board designers,
Inputs related to RMII interface connections
DP83TC812x-Q1 TC-10 Compliant 100BASE-T1 Automotive Ethernet PHY
What are the difference between RMII Master and RMII slave besides reference clock?
Do they have difference in power dissipation or other things?
How to select whether use slave or master by application?
The difference between RMII Master and Slave is the type of reference clock being fed into the device and whether or not the clock is being shared between the PHY and MAC (Slave). To select one or the other, you can set it by register or strap options. There is no difference except how to supply the clock and the connections
https://e2e.ti.com/support/interface-group/interface/f/interface-forum/648893/dp83822h-master-slave
I saw DP83822 have RMII Master and Slave mode. May I know which application have to use Master mode? the difference is clock routing only?
I don't understand which application or condition I need to use Slave mode
For RMII Master, the PHY will operate off of a 25MHz reference clock.
This clock can either be a CMOS-level oscillator connected to XI pin or a 25MHz crystal across XI and XO.
When bootstrapped for RMII Master, the PHY will automatically output a 50MHz reference clock that needs to be fed to the connected MAC.
When in RMII Slave mode, the PHY will operate off a 50MHz CMOS-level oscillator connected to XI.
This clock must be shared between the PHY and MAC. That is the only difference between RMII Master and RMII Slave. It is purely how you supply and route the reference clock.
FAQ for RGMII
Regards,
Sreenivasa
Hi Board designers,
FYI
DP83TG721S-Q1: Voltage level XI-pin Ethernet PHYs (DP83TC812S-Q1, DP83TC817S-Q1, DP83TG721S-Q1, DP83TG727S-Q1)
What are the requirements for the XI pin for the TI Ethernet PHYs DP83TC812S-Q1, DP83TC817S-Q1, DP83TG721S-Q1 and DP83TG727S-Q1 regarding the voltage level or the VIH and VIL levels when using a clock oscillator?
The specific question is whether a 1.8V level clock signal can be used for all of these devices also when VDDIO is 3.3V?
Schematic Checklist/Data Sheet Extract:
For 812S I find in the data sheet that XI VIH needs to be between 1.3V and VDDIO, where 1.8V would work (6.8, page 20) Can you confirm it's the same for the above mentioned devices as well?
Yes, this is also the same for the other devices you mentioned. You can use 1.8V CMOS clock.
Regards,
Sreenivasa
Hi Board designers,
Inputs related to MDC
DP83822
DP83826
Regards,
Sreenivasa
