Hi Board designers,

Please refer below RMII connection illustration to follow:

Refer below inputs regarding crystal 

Information related to Crystal

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1467149/am625-q1-crystal-accuracy/5629628

Operating the PHY with a clock that has 100 PPM accuracy would violate the industry standard. Therefore, this is not supported. We only support a reference clock that has 50 PPM accuracy. The 50 PPM limit must include the initial accuracy of the clock source as well as the temperature variation and aging.

Query relate to allowed SOC clock frequency

The only crystal frequency supported is 25 MHz and the maximum deviation from that frequency being +/- 50 Parts Per Million (PPM) when using RMII or RGMII Ethernet peripherals. This limit is defined in the datasheet and means the frequency can only vary +/- 1250 Hz from the nominal frequency of 25 MHz for this use case. The limit doubles when not using RMII or RGMII.

The device datasheet is correct. I do not know the purpose of the TISCI User Guide. I will need to discuss this with the software team. 

It is very unlikely that something inside the device is causing the issue. Radiated emissions are most likely being generated by one or more of the peripherals signals. The customer needs to determine which peripheral is radiating emissions and look at their PCB layout and connectivity to the attached peripheral device to better understand why they have this issue. These type issues are typically caused when signals are not impedance controlled along its entire path. Radiation occurs when the electric fields generated by the fast signal transitions are allowed to radiate away from the signal where there are impedance discontinuities in the signal path.

Power supply resonances can also radiate emissions, so they should check for noise on their power supplies.  

FYI: The TRM content you referenced above has a note saying "Reference clock selections may be limited by the device. Please consult the device specific datasheet to determine which system clock frequencies are valid."

 The SoC has been qualified using a 25MHz Xtal only and TI will not qualify any other frequencies

AM62P guidelines for using a crystal

The spec shows that a crystal with 50ppm or less can be used for Ethernet.  TI’s EVM uses an oscillator instead.  Is there a special guideline for using a crystal?  Panasonic is concerned about the characteristics such as jitter when generating clocks from PLL using a crystal.

 The 50 PPM reference clock frequency accuracy requirement represents a limit defined in the RMII specification. Frequency error expressed in PPM is typically based on a long-term average and is completely unrelated to PLL jitter

Jitter is a parameter that defines short-term frequency error of a PLL output as it attempts to stay locked to the reference clock. Jitter can be defined in many ways.

Period jitter defines how much variation is seen in a single clock cycle. This definition is commonly used when trying to understand the maximum operating frequency of synchronous circuits, where you must make sure the shortest clock period doesn't over clock any synchronous path. 

N-cycle jitter defines how much variation is seen over N clock cycles. This definition is typically used to understand how many consecutive fast or slow clock cycles the PLL produces over N clock cycles. This frequency error typically needs to be understood when transmitting data from one clock domain to another to ensure the elastic buffer in the receiver is able to accommodate data entering fast than it is consumed. 

A crystal circuit typically has very low jitter due to it having a very high-Q resonance. Converting the sinusoid signal from the crystal circuit to a digital reference clock will introduce some jitter. The jitter introduced by the AM62P oscillator has been modeled and taken into account with respect to PLL input requirements. Therefore, you do not need to be concerned with jitter when using a crystal circuit as the reference clock source for AM62P.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1184856/omap-l138-jitter-characteristics/4463861

We do not publish PLL jitter characteristics in the datasheet because there are many system and implementation specific variables that contribute to PLL jitter.

We have seen at least one instance of a problem when another TI processors with similar PLLs was used to source the RMII PHY reference clock. In this case, the RMII PHY was not compatible with the PLL output clock. We found the PLL filter in the PHY was inserting a delay, which caused the PHY PLL to be running fast when the processor PLL was running slow, or the PHY PLL to be running slow when the processor PLL was running fast. This delay caused a worst-case operating frequency difference between the MAC clock and the PHY clock, and this delay allowed an elastic buffer in the PHY to be over-run when the MAC was operating at a high clock rate then than the PLL was shifting data out on the wire. The result was CRC errors cause by missing data that occurred when the buffer was over-run.  

Therefore, your concern is not simply a function of the OMAP-L138 PLL performance. It is a function of how the two devices operate together.

I recommend using a non-PLL based clock source as your RMII reference clock. If this is not possible, you need to select a clock source with low N-cycle jitter and validate your system performance across all operating conditions to be sure it doesn't cause a problem.

 In our specific case, we wonder if we can use a 24MHz ±50ppm oscillator at OMAP input, then PLL0_PREDIV register set to x1, PLL0_PLLM set to x25 (so 600MHz) and PLL0_PLLDIV7 set to /6 (so 50 MHz).

In this case, what would be the 50MHz EMAC_RMII  clock jitter?

As mentioned above, there are many contributors to PLL jitter that is unique to their specific system design. Things like power supply transient response, inductance of PCB power rails, ESR and loop inductance of power supply decoupling capacitors. Therefore, we do not know what the PLL jitter characteristics will be in their system.

Even if they knew the PLL jitter characteristics, how do they know what level of jitter is acceptable for the RMII PHY? The RMII standard only defines a frequency accuracy parameter of 50 PPM. It does not define a limit for clock jitter. The PLL will lock to the crystal reference clock, so the long-term average frequency error associated with the PLL output will be the same as the crystal reference.  

They need to validate this use case across all operating conditions using their actual system design to be sure the RMII PHY is compatible with the PLL clock source. There is risk with this approach. We have seen examples where it didn't work with other combinations of TI processors and RMII PHYs.

AM62A3-Q1: XTAL ±50ppm SPEC OUT

We use RGMII, but Our XTAL measured value is ±100ppm. So we can't meet ±50ppm. What kind of problems can be expected if this specification is not followed? 

This parameter and its limits are defined by the Ethernet standards. The device on each end of an Ethernet cable must constrain it's frequency error to ensure there is not too much frequency error between the transmit data rate and the operating frequency of the receiver. It is possible to over-run elastic buffers in the receiver if this difference is greater than the limits defined in the Ethernet specifications. For example, when the transmit rate is greater than the limit and/or the receiver is operating with a frequency that is lower than limit. This could result in data corruption and dropped packets. We recommend selecting a compliant clock source to ensure there is no problem with Ethernet communication.

  Am I correct in assuming that no other functions other than Ether are affected?

 Ethernet is the only function in the AM62Ax device that requires a 50PPM reference clock. All other functions require a 100PPM reference clock.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1398105/faq-am2432-loop-back-clock-for-rgmii-and-mii/5350828#5350828

AM62P 25MHz XTAL Specifications

 Let me confirm the specifications of the AM62P 25MHz XTAL.

Many PHY suppliers and SOC manufacturers require an accuracy of +/- 100 ppm for XTAL for GMII.

Is the AM62P set to +/- 50 ppm for both RGMII and RMII?

If you use the RGMII interface, I can understand. But why is the RMII specification +/- 50ppm?

Also, can't this specification be relaxed?

 Both RGMII and RMII standards require a clock accuracy of 50PPM.

No, the requirement cannot be relaxed. The requirement is 50PPM when using RGMII or RMII.

If possible, can you tell me which part of the specification is listed?

For RGMII, you can find the limit defined in the TXC and RXC signal descriptions. 

TXC - The transmit reference clock will be 125Mhz, 25Mhz, or 2.5Mhz +- 50ppm depending on speed.

RXC - The continuous receive reference clock will be 125Mhz, 25Mhz, or 2.5Mhz +- 50ppm.

For RMII, you can find the limit defined in the REF_CLK signal description.

The REF_CLK frequency shall be 50 MHz +/- 50 ppm with a duty cycle between 35% and 65% inclusive.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1209671/am6442-25mhz-crystal-tolerance-stability/4563920

I assume Tolerance is the difference in the actual resonance frequency of the crystal vs the expected resonance frequency. The crystal itself will have some error based on manufacturing tolerances, but your crystal circuit implementation could also introduce some error based on how close you match the load capacitance defined in the crystal specification. Applying the proper load capacitance is important to prevent your circuit from pulling the resonant frequency from the desired frequency. We describe what needs to be done to properly calculate load capacitance in the MCU_OSC0 Internal Oscillator Clock Source section of the datasheet.

I assume Stability includes error introduced by temperature changes and crystal aging.

You are correct the 50 PPM requirement originates from the RGMII specification, where it says the clocks used to transfer data between the PHY and MAC must have an accuracy of +/-50 PPM. This means the total frequency error, which includes the combination introduced by tolerance and stability. We tell you that in the MCU_OSC0 Internal Oscillator Clock Source section of the datasheet, where we say: When selecting a crystal, the system design must consider temperature and aging characteristics of the crystal based on worst case environment and expected life expectancy of the system.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1179376/faq-am623-clock-outputs/4441725#4441725

The AM62x device is able to source a 25MHz clock via the CLKOUT0 signal function that is multiplex to the EXT_REFCLK1 pin.  However, software will need to configure the appropriate PLL, internal multiplexing, and the respective PADCONFIG register before this clock will be sourced from the pin. Most RGMII PHYS require a valid clock before reset is released, so you will need design your system to hold the RGMII PHY in reset until the clock is valid.

The AM62x device will automatically begin sourcing the device reference clock (MCU_OSC0) to the WKUP_CLKOUT0 pin as soon as the device is released from reset (MCU_PORz 0->1).

I'm not sure if it is possible to generate a 24.576MHz or 22.5792MHz from the AM62x device. I sent an email to our clocking and McASP experts asking if this is possible. I will need to let you know the answer once they reply.

It is good that you plan to use a 25 MHz crystal on MCU_OSC0 since this is the only reference clock frequency supported by this device.

I'm not able to address any questions related to your specific software implementation. You need will need to confirm your software configures the device such that it achieves your system function and performance goals.

Note: TI does not define performance of the AM62x clock outputs because clock performance is influenced by many variables unique to each system implementation. You should plan to validate any clock output is able to meet the appropriate level of performance required by the attached device using your actual system design while operating across all operating conditions.

 Regards,

Sreenivasa

Hi Board designers,

Refer below inputs related to RMII interface and implementation using AM6x processor families

Signal Naming conventions:

For the RGMII signals we are using TDn and RDn as signal names and for RMII we are using TXn and RXn as signal names.

Wanted to get your thoughts on the naming convention followed and if the signal names have dependencies on the interface specifications.

We follow the standard on signal names. 

RMII

RGMII

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1484209/am6421-am64-clocking/5699455#5699455

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.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1434352/am1808-emac-rmii-communication-failure/5569916

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.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1431234/faq-am6442-mcu_osc0-crystal-circuit-requirements/5489637

 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.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1415577/faq-am625-am623-am620-q1-am625-q1-am625sip-ethernet-phy-rgmii-synchronous-clock/5422984#5422984

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.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1415096/faq-sk-am64b-why-the-ethernet-phy-use-the-same-clock-buffer/5421503#5421503

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. 

Configuring x2 RMII interface using CPSW3G for AM64x

For AM64x RMII_REF_CLK is common to both RMII1 and RMII2.. Both AM64x RMII ports are synchronous to a common input clock.

When RMII interface is configured as master and the output of EPHY is the processor clock input, x1 RMII interface can be used.

In case x2 EPHYs are required to be interfaced, the recommendation is to configure the RMII EPHYs in slave configuration and clock the EPHYs and the SOC using external 50M clock (Oscillator + single input, x3 output buffer)

Configuring x2 RMII interface using CPSW3G for AM62x, AM62Ax, AM62Px and AM62Lx

Each RMII port operates independent of the other RMII port

x2 RMII interface can be configured for the above mentioned processor families with the EPHY configured as Master (EPHYs can be configured as slave as required using a common generated externally using Oscillator + single input, x3 output buffer

Note: AM62Lx MAC interface supports only 1.8V IO level.

AM64x CPSW3G pin configuration

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.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1228260/am6442-cpsw-3g-rmii_ref_clk-connection-for-2-rmii/4639150

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.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1355104/faq-am6442-clkout0-feedback-to-rmii_ref_clk-always-necessary/5167774#5167774

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/984897/am3352-am335x-rmii-ref-clock/3640974

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. 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1277513/faq-am6442-use-of-2x-rmii-ephy-for-cpsw/4848973#4848973

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

 [FAQ] DP83822HF: How does power up sequence affect PHY operation? 

For DP83822, there is a guidance where AVD and VDDIO must not exceed 0.3V prior to complete supply ramp, with an additional footnote suggesting AVD to ramp up after VDDIO to avoid false detection of VDDIO. False detection may lead to non-operational performance from the device, such as no link up. If such a case is happening, it may be helpful to read register 0x421 to indicate what supply level the PHY is operating at and compare to intended levels. If a level is mis-detected, a way to bypass and rectify would be adjusting Reg 0x41F accordingly. Please note these registers are extended registers and thus will require 4-step process to read and write per datasheet.

Regards,

Sreenivasa

Hi Board designers, 

Inputs related to RMII interface connections

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/882787/dp83tc811s-q1-difference-between-rmii-slave-and-master-mode

DP83TC812x-Q1 TC-10 Compliant 100BASE-T1 Automotive Ethernet PHY

Hi Board designers, 

E2Es for reference:

(+) AM623: Usage of RMII interface - Processors forum - Processors - TI E2E support forums

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1528318/am623-usage-of-rmii-interface

In our design, there is a network switch IC using RMII without RMII_RX_ER pin connected to AM623,  when we trying with ping action, AM6232 keeps reporting iet_rx_smd_err and can not establish communication with switch, does this related to the pin missing ? is there any way to dismiss this error or disable RX_ER pin?

So the ER pin is optional. We disabled this pin in SW configuration and now no more SMD error.

Regards,

Sreenivasa

Hi Board designer

Refer below inputs related to Ethernet EMI/EMC 

Optimizing EMC Performance in Industrial Ethernet Application

https://www.ti.com/lit/an/snla466/snla466.pdf

https://www.we-online.com/files/pdf1/emc-emi-optimizations-in-single-pair-ethernet-spe-for-industrial-communication.pdf

Regards,

Sreenivasa

Hi Board designer

Refer below inputs related to Ethernet MACsec

Enhancing the Confidentiality and Integrity of Automotive Ethernet Data Using MACsec

https://www.ti.com/lit/wp/snla462/snla462.pdf

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,

FYI

(+) DP83TC817S-Q1: MII Termination Resistors - Interface forum - Interface - TI E2E support forums

Internal termination resistors apply to all MAC interface selections

These termination resistors are always in place and are not able to be disabled. Is this correct?

Correct.

Regards,

Sreenivasa

Hi Board designers,

Inputs related to MDIO MDC

DP83822

DP83826

Regards,

Sreenivasa

Hi Board Designers 

FYI 0n AM6442: MAC to MAC RMII Connections with AM263P4

I have a confirmation from our experts that an AM64x CPSW3G RMII to RMII connection is unsupported by TI.
Would you please tell us more about your use-case:
Q1. Why is RMII considered over RGMII for MAC2MAC ? Q2. Don't you wish to explore a RGMII - MAC-to-MAC connection solution ?

We would prefer to use RMII because our application does not require the bandwidth of RGMII, and using RMII would ideally reduce the pin count required to support this interface. By "unsupported", do you mean that a RMII to RMII connection is not possible? Or just has not been tested?

The RGMII TX and RX signals are symmetrical with respect to electrical and timing requirements, where each data path has four data signals, a control signal, and a source synchronous clock. This allows two MACs to be connected together, where the TX pins of each MAC is connected to RX pins of the other MAC.

That is not the case for RMII. The RMII control signals are not symmetrical. The MAC has two control signal inputs, RX_ER and CRS_DV, which connects to two PHY outputs. The PHY has one control signal input, TX_EN, which connects to one MAC output.

Regards,

Sreenivasa

Hi Board Designers,

Supported impedance control for the EPHY RX signals:

DP83822

9.2.2.2 Detailed Design Procedure

Communication Does not work including loopback

1. link connection was initiated to the external ethernet interface.

2. External loopback test as illustrated in the figure was executed and observed signals in RX_CLK and RX_Data.

a. Upon examining RX_CLK and RX_DATA , necessary adjustments are made in the register mapping to compensate the shift.

b. RGMII[x]_RXC was externally delayed relative to the data and control pins.

c. Following  clock tuning, we successfully accomplished both external loopback and MII loopback

(+) TMDS64EVM: PRU-ICSSG Ethernet Port Testing through R5F Core - Processors forum - Processors - TI E2E support forums

You can skip reading from EEPROM by enabling Manual entry method for filling MAC addresses. You can find this option in:
Enet(ICSSG) -> System Integration Info - > Mac Address Assignment Method -> Manual Entry.

Alternatively, you can implement your own function to read the MAC addresses by altering the template function EnetApp_initializeMacAddrPool(), which is located in the file: "$MCU_PLUS_SDK/source/networking/enet/core/sysconfig/networking/.meta/enet_cpsw/templates/enet_app_syscfg_info.c.xdt"

In this API, you can either stop calling the fillMacAddrList API to completely stop filling MAC addresses, or change the definition to suit your application.

Please try setting an ID of 2nS on the EPHY side.

The issue got resolved when a delay of 2ns was introduced between the RX data and RX clock.

DP83822H: Why in Clock Shift mode will have 3.5ns delay?

Why in Clock Shift mode will have 3.5ns delay?  Where is the delay come from?

This delay is used to help meet RGMII timing requirements noted here:

As the RGMII timing will be affected by trace length delays in layout, the configurable delay is intended as an option to help meet timing requirements if needed.

Ethernet PHY DP83822I. They have question regarding determining the delay value of the TX and RX clock.

They want to configure the value of PHY TX delay and PHY RX delay of DP83822I as shown above. Is there any method to determine it? Once determined, how to configure DP83822I so that it uses that delay value.

The delay of RX_CLK and TX_CLK could be tune through register 0x0017bit[15:14]. As long as the total delay time between the clock signal and data signal satisfy the setup and hold time, the RGMII signal could read properly.

e2e.ti.com/.../5722480

DP83826

Regards,

Sreenivasa

Hi Board Designers,

AM62P and DP83TC814R-Q1 interface through RMII:

The DP83TC814R RMII (RX_D[1:0], RX_ER, TX_D[1:0], and TX_EN) signals will connect directly to AM62Px.

The DP83TC814R PHY supports two clocking modes. 

The PHY sources a 50 MHz clock to the MAC when configured to operate in master mode. This clock is used for the synchronous transfer of data in both directions. This clocking topology creates non-symmetrical timing, where the MAC receives the clock delayed relative to when the PHY receives the clock. This delay depends on PCB trace lengths between the MAC and PHY. The effect of PCB delays must be carefully analyzed, and trace lengths adjusted to compensate for the non-symmetrical timing introduced by this clocking topology. Note: This clocking topology will limit the maximum trace length allowed between the PHY and MAC, but it allows a direct clock connection between the MAC and PHY.

The PHY receives a 50 MHz clock from an external clock source when configured to operate in slave mode. This clock could be sourced from any 50 MHz +/-50 PPM clock source. AM62Px provides a CLKOUT0 signal function that can be configured to source this clock, where the clock can be routed with equal delays to both the PHY and MAC. This clocking topology allows the PCB designer to implement a symmetrical clock solution. Note: This clocking topology will not limit the maximum trace length allowed between the PHY and MAC, but it requires an equal delay clock buffer to be inserted between the AM62Px CLKOUT0 output and each clock signal path going to the MAC and PHY.

The DP83TC814R datasheet indicates each PHY pin associated with RMII (RX_D[1:0], RX_ER, TX_D[1:0], and TX_EN) has an internal pull-down that will hold the respective signal low until software initializes peripheral.

The AM62Px pins default to an off state, where the input buffer is turned off, the output buffer is disabled, and the internal pull resistors are turned off. There is no concern with AM62Px pins floating as long as their input buffers are turned off. However, they must never allow a AM62Px pin to float to a mid-supply voltage once the receiver is turned on.

1. Is there damage risk when RX and TX pin configure as floating?
2. Wiil Rx pin be always driven as High or Low state after enabling MAC IF even though there isn't any data on RMII bus?
   Ether PHY's internal PU/PD resister will be disabled after completed initialization.
   However, PHY team said that PHY's RX and "TX" bus is always driven as high or low so unstable condition won't occur after initialization.

The output buffer (TX) implemented in the AM62Px IO cell will not be damaged by a floating signal.

The input buffer (RX) implemented in the AM62Px IO cell will not be damaged by a floating signal as long as it is turned off (RXACTIVE = 0). However, the input buffer can be damaged if a mid-supply potential is applied while it is turned on (RXACTIVE = 1). The input buffer is turned off by default for most AM62Px pins. The state of each AM62Px pin during and immediately after reset can be found in the Pin Attributes table of the device datasheet.

All of the RMII signals will be driven to valid logic levels by the MAC or the PHY during normal operation. Therefore, you only need to be concerned with the state of each device as they are being initialized. For example, you should never turn on the AM62Px input buffers connected to the PHY until you know the PHY is driving or pulling its outputs to a valid logic level. The system designer must understand the software initialization sequence of both devices to determine if there is any chance the signal will be floating after the input buffer is turned on. If so, it may be necessary to connect an external pull resistor on the signal to hold it in a valid logic state.

 I will try to highlight a few concerns which you need to be considered in your design. 

The PHY has a reset input that may need to be controlled by a combination of your system power-on reset, the AM62Px warm reset output, and a GPIO controlled by software. Your PHY reset topology depends on your specific use case. For example, does your Ethernet driver ever need to reset the entire Ethernet subsystem including the PHY?  If so, you need to combine a GPIO with the system power-on reset for software to use for this purpose. Does the PHY need to be reset if a watchdog timer in AM62Px is configured to generate a warm reset? If so, you need to combine MCU_RESETSTATz or RESETSTATz with the system power-on reset. Does your system plan to support Ethernet boot? If so, you need to make sure the PHY is boot strapped to a proper configuration supported by the AM62Px boot code.

You need to understand all of the various corner cases related to software sequencies like in the example use case mentioned above, where the Ethernet driver resets the PHY with a GPIO. In this case, the input buffers in the AM62Px IOs were turned on before the Ethernet driver decided to reset the PHY. This could be a problem if this PHY reset creates a condition where the AM62Px input buffers remain turned on and the PHY stops driving or pulling the signals to a valid logic state.

TI not able to answer all of your questions related to this topic since they depend on your specific implementation of hardware and software.

1. Would you tell me specific voltage range of mid supply condition on Rx pin?
   PHY team said Rx pin's apply voltage should be higher than VIO*0.7.
   So, if your mid supply condition is out of this range, concern for SoC's RX pin will disappear.
2. Does this device accept turning on input and output buffer separately

The steady state voltage applied to a AM62Px CMOS input needs to be above the VIHSS (Steady State High Input Voltage) or below the VILSS (Steady State Low Input Voltage) values defined in the respective Electrical Characteristics sections of the datasheet.

Yes. The input buffer is turned on/off via the RXACTIVE bit in the respective Pad Configuration register. The output buffer is enabled/disabled via an internal enable signal that is sourced from the peripheral selected by with the MUXMODE bits in the respective Pad Configuration register. The output buffer can be forced off with the TX_DIS bit in respective Pad Configuration register.

I think they may difficult to satisfy VIHSS(0.85*VDD) but they probably can satisfy VIH(0.6 * VDD).
Would you tell me the difference between both number and can this accept VIH?

VIH and VIL parameters define the standard minimum logic high and maximum logic low voltage levels which determine the input threshold limits.

The VIHSS and VILSS parameters define minimum high and maximum low steady-state levels that shall be maintained on the input when the signal is not toggling to prevent any long-term reliability issues. The input buffer performance may degrade over time if the applied voltage spends too much time between the VIHSS and VILSS levels.

The VIHSS value for 1.8V operation is higher than the VIH level. That is not the case when the IO is operating at 3.3V since the VIHSS value for 3.3V operation is the same as the VIH level.

The datasheet defines a minimum slew rate parameter in the Electrical Characteristics of each IO type. The input slew rate min limit defines a maximum transition time of 1000ns. This parameter only applies once the input buffer is turned on. Therefore, your system should never apply a steady-state voltage that lies in the region of VILSS to VIHSS for longer than 1000ns when the input buffer associated with the signal is turned on.

Regards,

Sreenivasa

Hi Board Designers,

Inputs related to recent debugs

(+) TMDS64EVM: PRU-ICSSG Ethernet Port Testing through R5F Core - Processors forum - Processors - TI E2E support forums

The issue got resolved when a delay of 2ns was introduced between the RX data and RX clock.

(+) AM623: How to change the ethernet phy reset sequence with CPSW/DAVINCI MDIO driver - Processors forum - Processors - TI E2E support forums

The customer found a workaround, resolving the issue on all boards – asserting a lengthy PHY reset using GPIO in Linux userspace.

Regards,

Sreenivasa

Hi Board Designers,

Inputs related to RMII interface clock source

(1) I = Input; O = Output

(2) n 1 to 2

Spread Spectrum Clocking support:

do we support dithering or spread spectrum clocking for RMII

Can you help me understand if the specs in the below section are the one to be considered for the RMII reference clock inputs.

Table 6-32. RMII[x]_REF_CLK Timing Requirements – RMII Mode

The RMII standard requires a clock with a frequency accuracy of 50 PPM.  It is not possible to enable spread spectrum clocking and maintain a frequency accurate of 50 PPM.

It is not clear how they can do the dithering without violating the RMII standard.  We did not design our MAC to accommodate a spread spectrum clock.  The data buffers used to cross clock domains were not designed to accommodate frequency error beyond what was defined in the RMII specification.

Regards,

Sreenivasa