Hi Board designers,

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?  Customer 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, the concern is not simply a function of the processor PLL performance. It is a function of how the two devices (MAC and EPHY) 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.

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

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.

 Regards,

Sreenivasa

Hi Board designers 

Information related to RGMII interface:

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/1474520/am6422-am6422-dp83869-rgmii-tuning/5660266

The AM64x device does not support tuning of its output signals. There is a reserved register bit associated with the AM64x MAC that allows the data to be launched at the same time as the clock transition, or allows the data to be launched 1/4 cycle ahead of the clock transition. This register bit defaults to the state that introduces the internal delay on clock because the AM64x device does not support the first option. The AM64x device was not timing closed to use the first option. Therefore, you should be seeing a fixed delay relationship when observing the TX data path.  I think the tuning you are doing is associated with the RGMII PHY. If so, I would expect the see a change in the RX data path, but not the TX data path because the TX delay you are introducing is internal to the RGMII PHY.

Does your PCB design introducing significantly more delay on the TX clock relative to TX data?  I ask because I would have expected the delay relationship to be different than what is shown in the snapshot provided. Did you deskew your scope probes to make sure one is not introducing more delay than the other?

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1469324/am6421-electrical-characteristics-requirement-to-rise-fall-time-for-rgmii_rxclk/5653999#5653999

The RGMII standard says the 20/80% rise and fall times should be less than 0.75ns. The standard also defines the output setup and hold requirements for the transmitter of RGMII signals and input setup and hold requirements for the receiver of RGMII signals. We typically do not worry about the rise and fall times as long as the setup and hold times are valid.

It would be best to follow the RGMII standard for rise/fall times, but the setup and hold times are the more important parameters.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1419001/am6442-ethernet-interface-and-ioset-restriction-on-pin-multiplexing/5436514

The RGMII peripheral timing was not closed to support this combination of pin assignments. There is a very good chance this combination of pin assignments will introduce timing violations for the RGMII peripheral. This may not appear to be an issue when testing your system with a small sample size of AM64x devices that represents only a small range of process variation. The design needs to be corrected to ensure proper operation of the RGMII peripheral across process, voltage, and temperature.

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.

For more background, we measured radiated emissions on our PCBA and we've found that one of the main noise sources is from the RGMII signals (with the pins listed above in my post). To reduce the radiated emissions, one of the strategies is to reduce the drive strength of the RGMII signals.

 So from my understanding right now, you mentioned the reason that we cannot configure the drive strengths of the RGMII pins of the Sitara MCU is because the IO timing has been closed with Nominal drive strength -- meaning the timing diagram and measurements are performed with nominal drive strength. So, in the end, can there be a timing diagram and measurements done with reduced drive strengths? At the end of the day, theoretically, can we configure drive strengths of the RGMII signals of the Sitara MCU?

At the end of the day, theoretically, can we configure drive strengths of the RGMII signals of the Sitara MCU?

The RGMII standard requires a max rise/fall time that is already a challenge for our IOs to meet even with the default output drive strength. You definitely would not want to reduce the drive strength for the RGMII outputs because it would be a challenge to meet the PHY timing requirements. You need to investigate other ways to reduce radiated emissions.

For example, are you operating the RGMII signal at 1.8V or 3.3V? I would suggest operating the RGMII signals at 1.8V if they are currently operating at 3.3V.

Yes, the RGMII is currently operating at 3.3V. Thanks for the recommendations. However, to answer the question, then in the end, can we still configure the drive strengths of RGMII signals (regardless 3.3V or 1.8V operation voltage) and how and what are the drive strength values?

 The AM64x device was designed for proper operation when using the default drive strength. Changing the drive strength may cause functional issues. Therefore, we currently do not support changing drive strengths.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1364906/am6442-rgmii-signal-slew-rate/5210550

AM62A7-Q1: AM62A CPSW3G RGMII input slew rate

I’m referring AM62A datasheet. Input slew rate for CPSW 3G RGMII is described in table CPSW3G RGMII timings  

Is the number applied to only RGMII[x]_RXC, or also applied to RGMII[x]_RD[3:0] and RGMII[x]_RX_CTL?

 It applies to all signals associated with the RGMII peripheral when operating as inputs to the AM62A.

For RGMII[x]_RD[3:0] and RGMII[x]_RX_CTL, are there any technical reason why these signals need to meet the input slew rate in addition to Setup/Hold time?

 Yes, the propagation delay through the input buffer is a function of input slew rate.  So, the setup and hold limits are only valid when the slew rate is within the ranged defined in the Timing Conditions Table.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1277896/am3352-about-rgmii-signals-level/4844299

They have designed a board that communicates via RGMII, with the AM3352 itself running at 1.8V and the PHY at 3.3V.
Normally, the level of the incoming signal is converted so that the 3.3V signal is converted to 1.8V and processed by Processor, but there seems to be a problem with this process.
They want to skip the voltage conversion process for their investigation and connect the 3.3V signal from the PHY directly to the AM3352 for testing.
The signals are as follows.

• RGMII1_RCLK
• RGMII1_RCTL
• RGMII1_RD0~3

 What stresses will be placed on the AM3352 when this is done?
We would like their opinion on whether it would be destructive, whether it would not work properly and what the long-term reliability would be.

 This is not possible.

The datasheet clearly defines the max voltage allowed on pins is it's IO supply voltage plus 0.3V. The 3.3V signal applied to the IO powered with a 1.8V power source would be clamped to the IO supply rail by internal circuits. This would cause excessive current from each signal source trying to drive 3.3V and this is likely to increase the voltage of the 1.8V IO power rail. This would create multiple Electrical Over-Stress (EOS) events and any one of them is likely to damage the device.

 https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1274352/am6442-rgmii-delay-figure-understanding/4839259

The values provided in the timing requirements and switching characteristics tables of the AM64x datasheet represent the timing relationship of the signal at the package terminals. 

This parameter is basically saying we provide at least 1.2ns of setup time to the attached RGMII PHY. The value could be larger than 1.2ns, but not smaller than 1.2ns. The RGMII specification requires the attached PHY to operate with as little as 1.0ns of setup time. Therefore, we are providing at least 200ns of margin, minus any trace length mismatch on the customers PCB.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1263384/am625-questions-for-ethernet-timings/4783039

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1164873/am625-rgmii-txc-pin-timing/4381213

The RGMII standard originally defined a timing relationship where the data transmitter changed its data at the same time clock changed, while the data receiver was defined to require a clock transition in the middle of the data valid window for proper setup and hold. This required PCB designers to insert significant delays in the clock trace path to achieve proper timing. This was a burden for PCB designers, so the RGMII specification was quickly changed to include another timing option for the data transmitter.  In the new mode, the clock was delayed such that it would transition in the middle of the data valid window. This made the PCB design much easier since it allowed the clock and data trace delays to be matched length or equal.

Most customers want to use delay mode, so there wasn't much demand for support of non-delay mode. Therefore, we decided to only support delay mode and did not perform timing closure on the RGMII ports operating in non-delay mode.  I agree there is a way to change the mode via the ENETx_CTRL_RGMII_ID_MODE bit, but you should not change this bit and use non-delay mode since the RGMII ports were not timing closed for this mode of operation.

The datasheet defines setup and hold times at the device input pins RD[3:0] and RX_CTL relative to the RXC input, and output setup and output hold times at the device output pins TD[3:0] and TX_CTL relative to TXC output. The output setup and output hold time parameters are really defining an output delay relationship of the transmitter outputs operating in delay mode, but they are being expressed as output setup and output hold to match how timing relationships were defined in the RGMII specification.

Bit-4 is always set to Zero and is reserved 

TXC delay is always enabled, with minimum delay of 1.2 ns, as specified in the below Section, CPSW3G RGMII Timing,  Table  RGMII[x]_TD[3:0] and RGMII[x]_TX_CTL Switching Characteristics - RGMII Mode of the AM62P DS

Query: TXC(Clock) is not delayed against the TXD0(DATA) and they seem to be aligned,

Verify if MAIN_CTRL_MMR_CFG0_ENET1_CTRL[4] bit is set to 0

Test result: We confirmed that the issue is gone after setting the bit4 to "0". Now, TX internal delay is observed.

(+) AM625: Difference between MAC ID and MAC ID Proxy register - Processors forum - Processors - TI E2E support forums

TXC is delayed internally before being driven to the RGMII[x]_TXD pin". Is this delay always fixed?

AM6442: RE - Clarification for range to perform SI analysis

(+) AM6442: RE - Clarification for range to perform SI analysis - Processors forum - Processors - TI E2E support forums

We are performing signal integrity (SI) analysis for an RGMII interface operating at 25 MHz using the AM6442BSFGHAALV processor and DP83869HMRGZT PHY. We have followed certain ranges for Vmax, Vmin, and rise/fall time, which I have summarized in the table below.

I have a few questions:

1. Could you please confirm whether the Vmax, Vmin, and rise/fall time ranges we've used (as shown in the table) are appropriate for this setup?
2. We are treating the TX signals (driven by the AM6442 processor) and RX signals (driven by the DP83869HM PHY) separately in our simulation.
➤ Should we consider different rise/fall time values for the processor and PHY drivers, since their output characteristics are different?
➤ If so, what are the recommended or typical rise/fall time values we should use for each?
3. For RGMII, a typical rise/fall time of 0.75 ns is often referenced. Is this value only applicable for 125 MHz operation?
Since we are operating at 25 MHz, is it acceptable to allow longer rise/fall times (e.g., 5×0.75 ns = 3.75 ns)?
Is this scaling method valid, or should we still aim for 0.75 ns regardless of the interface speed?

Are you expecting the Vmax and Vmin values to represent absolute maximum rating or recommended operating conditions? The DC limits defined in the Absolute Maximum Rating table should never be applied to a device during normal operation. Therefore, you should be using the DC levels defined in the Recommended Operating Conditions table as the DC values in your signal simulations. The "Transient overshoot and undershoot at IO pin" parameter in the Absolute Maximum Ratings table defines the absolute dynamic voltage limits.

The AM64x datasheet defines a minimum slew rate that is equivalent to a rise/fall time of 0.75ns. Note: the AM64x datasheet currently found on ti.com shows a minimum input slew rate value of 2.64V/ns. This applies to 3.3V operation. The next revision of the datasheet will also show a value of 1.44V/ns which will apply to 1.8V operation. The input slew rate limits defined in the CPSW3G RGMII Timing Conditions table were used by the design team during timing closure of the peripheral operating at its highest operating frequency. The minimum limit is based on a maximum rise/fall time requirement of 0.75ns defined in the RGMII standard. We do not support any violation of datasheet limits even at reduced frequency because the design was not validated under those operating conditions. However, we are more concerned with the clock and data delay relationship on RGMII. The data is transmitted and received via a source synchronous clock which should have similar rise/fall times. Therefore, we are more concerned with meeting the minimum setup and hold times. I encourage you to do your best to achieve a slew rate that is close to or meets the limit even when operating at a reduced frequency. The internal device delays do not scale linear to operating frequency.

AM6422: CPSW Timing

The minimum input slew rate defined for AM64x is equivalent to the input rise/fall time requirements defined for the PHY. A 20% to 80% or 80% to 20% voltage change is a voltage change that is equal to 60% of VDD. In your case, VDD is 3.3V and 60% of 3.3V is 1.98V. Changing the signal by 1.98V in 0.75ns gives a slew rate of 1.98V/0.75ns = 2.64V/ns. So, the requirements are the same for both devices and matches the signal rise/fall times defined in the RGMII standard.

Measuring the rise/fall time at the source end of an LVCMOS signal can be misleading. The voltage at the source end of the signal only steps up to a mid-supply potential until the signal has time to propagate down to the far end of the signal trace and the high impedance connection at the far end returns an in-phase reflection to the source. Therefore, measuring a 20/80 rise/fall time at the source will include 2x the PCB trace propagation delay in your measurement. The far end of the signal trace doesn't see this additional delay. I suggest you find a place to probe the RX_D1 signal near the AM64x device to get an accurate rise/fall time measurement for the RX input. Otherwise, you could subtract about 0.334ns for each inch of signal trace from the measured value at the source to get a value that is close to what is seen by the RX input. For example, you would subtract 1ns from the 1.7ns fall time measurement if you have 3 inches of PCB trace between the probe point and the RX input pin.

RGMII electrical edge speed on AM64

(+) AM6442: RGMII ICSSG TX clock delay - Processors forum - Processors - TI E2E support forums

(+) AM6442: RGMII ICSSG input slew rate - Processors forum - Processors - TI E2E support forums

here the abstract from the RGMII Spec which shows the 750ps rise/ fall time requirement:

So, without modification the AM64XX is not RGMII compliant!

We are familiar with this RGMII rise/fall time requirement. Configuring an output buffer to achieve the RGMII defined rise/fall requirement of 0.75ns can be problematic and may not be necessary for proper operation. We find many customers inserting series termination resistors near the RGMII signal source to reduce radiated emission issues. These series resistors slow the rise/fall times even further. So we have decided not to over-drive the signals beyond what is necessary to achieve the required setup/hold time margins defined in the RGMII specification.

typical we design and check against RGMII spec, because it is the common definition between MAC and PHY.

What RGMII TX signal rise/ fall time is specified for AM64XX, didn’t found it in the DS.

So what is your recommendation for this issue here?

The output setup and output hold values provided in the datasheet table titled "PRU_ICSSG RGMII Switching Characteristics - RGMII[x]_TD[3:0] and RGMII[x]_TX_CTL" were timing closed to be compliant with RGMII specification with capacitive load from 2pf to 20pf.  We assume loading will be very similar for each of RGMII data signal and its respective source synchronous clock. If so, the delays will be similar for any rise/fall. Therefore, we are not worried about being 100% compliant to the rise/fall time defined by the RGMII specification.

Regards,

Sreenivasa

Hi Board designers 

Information related to

DP83867
www.ti.com/.../snls484

Figure 8-7. Two Supply Configuration

Figure 8-8. Three Supply Configuration

Figure 8-9. Three-Supply Mode Power Supply Sequence Diagram

Table 8-5. Three-Supply Mode Power Supply Sequence

Figure 8-2. Magnetics Connection

DP83869
www.ti.com/.../snls614

Figure 8-8. Two-Supply Configuration

Figure 8-9. Two-Supply Sequence Diagram Table 8-5. Two-Supply Sequence

Figure 8-10. Three-Supply Configuration

Figure 8-11. Three-Supply Sequence Diagram

Table 8-6. Three-Supply Sequence

Figure 8-5. PHY to RJ45 and Magnetic

Regards,

Sreenivasa

Hi Board Designers,

Information related to RGMII interface

RGMII

(+) DP83869HM: TXD[3:0] & RXD[3:0] 11ps skew requirement (RGMII) in layout guidelines datasheet (pg. 113) - Interface forum - Interface - TI E2E support forums

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1319345/faq-tda4vm-how-to-configure-rgmii-clock-delay-on-j7-devices/5825452

One can fulfill the RGMII delay requirement using any of below options.

1. Configure both Tx & Rx delay at MAC side, if MAC is supported.
2. Configure both Tx & Rx delay at PHY side, If PHY is supported.
3. Enable delay from PCB traces while design of Board, in this case no need to enable delay at PHY or MAC.
4. Configure the Tx delay at MAC side, and Rx delay at PHY side.

If PHY side Tx delay is enabled then MAC side we need to disable the Tx Delay.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1497133/am67-failing-to-meet-rgmii-timing-requirements-with-dp83867irrgz-phy

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1488768/faq-sk-am62a-lp-max-recommended-trace-length-for-rgmii

Both TX data path and RX data path are completely independent of each other, where they each have their own clock and data signals that perform source synchronous data transfers.  Therefore, RGMII does not have a MAC to PHY or PHY to MAC round trip timing constraints like RMII that uses a shared clock for TX and RX paths. 

The challenge is keeping the signals short enough that the PCB doesn’t attenuate the high frequency content of the signal which is required to achieve the appropriate signal rise/fall times.  The only way I know someone can confirm their PCB is providing an acceptable path is perform a signal quality simulation of their PCB implementation using the IBIS models for each device to verify each data path.

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1480229/am620-q1-configure-rgmii-rx-tx-skew-delay-in-am6204

Is AM6204 able to support on the RGMII internal delay in MAC layer?

Currently the MAC is responsible for adding TX internal delay which is fixed (to be about a min of 1.2ns according to the information from https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1309535/am623-am62x-rgmii-always-enabled-internal-delay-time-in-tx-path/4977618#4977618), this cannot be changed.

The Ethernet PHY is responsible for adding any RX internal delays. 

To my knowledge, I don't think there is a way to enable the MAC side to add RX internal delays in addition to TX internal delays. See https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1282850/am623-rgmii-internal-delay-support/4865027#4865027 

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1452078/dp83tc813r-q1-rgmii-operation-without-xi-possible

 AM2434/AM64x PRU MDIO MDIO_phyRegRead will delay under low temperature environment (-20 degree C)

Customer changed the pull up R from 2.2k ohm to 1k ohm and found the delay phenomenon has been improved significantly which proves this should be MDIO physical waveform been affected by the low temperature to cause MDIO access malfunction although they can not get the actual waveform difference from room temperature and low temperature. 

This at least identify root cause and eliminate the suspicion on SOC and Ethernet PHY. 

The waveform captured are not meaningful and we will keep working with customer on the waveform measurement. 

FAQs

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1521263/faq-am625-am623-am620-q1-am62ax-am62px-am62d-q1-am62l-am64x-am243x-design-recommendations-custom-board-hardware-design---queries-related-to-rmii-interface-and-rmii-ti-ephy

Regards,

Sreenivasa

Hi Board Designers,

Refer below RGMII interface routing related information - Trace length and matching.

AM64x EVM

SK-AM62B

SK-AM62-LP

SK-AM62A-LP

SK-AM62P-LP

7802.AM62x_AM64x_RGMII_Trace_u.xlsx

Regards,

Sreenivasa

Hi Board Designers,

Information related to crystal and clock signals for EPHY

DP83869

Crystal load

Oscillator input

DP83867

Regards,

Sreenivasa

Hi Board designer

Information related to MDIO MDIO,MDC pulls 

DP83867

DP83869

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1630017/am2434-two-ported-ethernet-interfacing-using-ts3ddr3812-and-dp83869-s/6284170

The Ethernet management interface, signals MDC and MDIO, was defined to operate as a multi-drop bus by IEEE many years ago. It allows a single interface to manage multiple Ethernet PHYs. Therefore, the multi-drop connectivity found in the AM243x LaunchPad Development Kit is a valid connection topology. Where did you find an application note that says you should switch these signals between devices?

AM243x has two of these interfaces. One is associated with the PRU_ICSSG and the other is associated with CPSW. The AM243x LaunchPad is using the one associated with CPSW (pins W1 and V2) shown on page 12 of the schematic. The AM243x LaunchPad schematic has a mistake, where the MDC and MDIO signals and AM243x pins W1 and V2 have the wrong signal function name. They should not have the "PRG1_" prefix. The interface associated with PRU_ICSSG (pins D2 and E4) are shown on page 11 of the schematic, where they are used for GPIO signal functions.

The TS3DDR3812 mux was only used on the AM243x LaunchPad to allow the Ethernet PHY (U19) associated with RGMII1 to be connected to PRU_ICSSG or CPSW.  The mux was not needed for the Ethernet PHY (U7) associated with RGMII2 because the RGMII2 signals from PRU_ICSSG and CPSW share the same AM243x pins. That is not the case for the RGMII1 signals, so the mux was needed to select connectivity to the PRU_ICSSG RGMII1 signals or the CPSW RGMII1 signals. I would not expect your system to need the mux. You would simply connect the Ethernet PHY to the appropriate AM243x pins based on your expected use case.

One potential problem with connecting a single crystal to a CDCLC1310 and having it drive all three devices is IO voltage compatibility. The AM243x device only allows a 1.8V signal for its reference clock input and the Ethernet PHYs are operating at 3.3V. You would need to check if the Ethernet PHYs are able to use a 1.8V reference clock when operating at 3.3V.

Regards,

Sreenivasa

Hi Board designer

Refer below inputs related to Ethernet EMI/EMC 

Optimizing EMC Performance in Industrial Ethernet Application

www.ti.com/.../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 and Linux integration

Enhancing the Confidentiality and Integrity of Automotive Ethernet Data Using MACsec

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

How to Integrate Linux Driver Into Your System

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

Regards,

Sreenivasa

H Board Designers,

Please refer inputs related to External clock input levels for EPHYs

DP83867

DP83869

Regards,

Sreenivasa

H Board Designers,

Please refer inputs related to RGMII delay

(+) AM6442: RGMII delay figure understanding - Processors forum - Processors - TI E2E support forums

AM6442: RGMII delay figure understanding

The values provided in the timing requirements and switching characteristics tables of the AM64x datasheet represent the timing relationship of the signal at the package terminals. 

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,

FYI on RBIAS

https://www.ti.com/lit/ds/symlink/dp83867ir.pdf

SK schematics

A 10K, 1% resistor and a parallel 22pF cap is added.

The RBIAS updates are made to improve ethernet compliance testing.

Regards,

Sreenivasa

Hi Board Designers,

Supported impedance control for the EPHY RX signals:

DP83867

8.2.2 Detailed Design Procedure

DP83869

RGMII Layout Guidelines

Regards,

Sreenivasa

Hi Board Designers,

Can we say that the customer can use the DP83869HM PHY or similar (automotive class) PHY Transceiver that supports bridge function:

to convert from the AM620-Q1's RGMII MAC to a SGMII interface. Is this RGMII to SGMII bridge function same than the Media convertor mode ?

The DP83869HM datasheet indicates it is able to function as a RGMII to SGMII bridge, which would allow an SGMII PHY to be connected to one of the AM62x RGMII ports via the DP83869HM bridge.  This should be fairly straight forward from a hardware perspective, but it may require some custom software support.  At a minimum, software would need to configure the DP83869HM bridge and the SGMII PHY via MDIO.  I’m not sure what would be required for software to support this bridge function, but I suspect it is also fairly straight forward.  It may be as simple as configuring the DP83869HM bridge and the SGMII PHY during initialization and everything works as expected after that, without any further software intervention. 

The media conversion function supported by DP83869HM appears to be different than the bridge function.  From my understanding the media conversion function is a standalone function that is inserted between a fiber media and a wire media.  For this function, a MAC is not required on either end of the conversion.

https://www.ti.com/tool/TIDA-00306

 The bridge function supported by DP83869HM converts a RGMII MAC interface to an SGMII interface or a SGMII MAC interface to an RGMII interface, where one end is connected to a MAC and the other end is connected to a PHY.

Can you review if we can use DP83869HM in this way? thanks!

 DP83869 could be used in this application.

SFP module:

Media Converter Mode can be configured via the jumpers (OPMODE 100) and no software configuration is needed!

If the customer wants to use software to enable it, please see Section 7.4.8.5 1000M Media Convertor Mode .

DP83867 SFP Application Interface Card

https://www.ti.com/lit/ug/snlu325/snlu325.pdf

E2E2 Related to SFP

(5) DP83822IF: Optical communication through SFP module - Interface forum - Interface - TI E2E support forums

Thank you for pointing out the PU resistor on the MDI. We put that PU resistor for RJ45 connection, and the same got isolated from the circuit when we are using SFP connection. Now we PU MDI pins and now everything works fine.

Schematic for RJ45 side is

 DP83869HM: DP83869 Compatible SFP modules 

I got the following list of SFPs that we have seen being used at end applications :

1. Cisco GLC-FE-100Fx

2. Avago HFBR 57E0APZ

For 1000BFx I have received following list from field. These SFPs have been used during tests with 869 evaluation boards as link-partners.

1. IPOLEX ASF85-24-X2

2. INTELLINET 545006

3. UBIQUITI UF-MM-1G

4. INTELLINET 506724

5. OPTCORE OSP125-3110DCR

Compatibility

• INTELLINET: 506724

• OPTCORE OSP125-3110DCR

Regarding Intellinet SFP module, it is uncertain as there is no specifications of the electrical characteristics. 

Regarding Optcore SFP module, it appears that the input is asking for SGMII which DP83869 can support.

In general for SFP modules, our PHY is compliant to the SFF-8431 standard which most SFP modules should adhere to. I would recommend ensuring whichever modules you chose follow such standard.

(+) DP83869HM: DP83869HM - Link Status Detection Issue in SGMII-to-Copper Ethernet Mode with RJ45 SFP - Interface forum - Interface - TI E2E support forums

DP8386X-ASPEED-EVM Daughter card | TI.com

(+) DP83869EVM: Capable of RJ45 to SFP Data Passthrough? - Interface forum - Interface - TI E2E support forums

(+) TMS320C6678: SGMII connection for SFP module - Processors forum - Processors - TI E2E support forums

(+) DP83822HF: reference design with SFP - Interface forum - Interface - TI E2E support forums

If you are looking for reference material on how to connect SFP module to DP83822, you can use the DP83822EVM schematics. The schematics are here: www.ti.com/.../snlu179.pdf

s the DP83869 on its own [not the EVM], alongside an RJ45 port, ethernet magnetics, required power conditioning and passives, and the SFP module, sufficient for a copper to fiber media converter?

That is correct, no additional active components are required for DP83869 to achieve this media conversion.

DP83869EVM is a good reference to understand the required passive network for fiber to copper.

SGMII RGMII bridge related E2Es:

we do not have any devices that support SGMII to RMII or MII, the only support we have is for SGMII to RGMII. This is because the formats RGMII and SGMII operate in gigabit speeds while RMII and MII are for 100Mbps and 10Mbps speeds.

Bridge mode should very much do the trick for their application. Our FAQ should be able to help clarify operation:

https://e2e.ti.com/support/interface-group/interface/f/interface-forum/1357479/faq-dp83869hm-bridge-mode-clarification

This is testable to a degree with our EVM. While it does have SGMII via SMA, the RGMII is headers, so having this jumped to a MAC is a tricky task (SI issues, length matching, etc). 

 The difference between SGMII to RGMII or RGMII to SGMII is dependent on who is setting the communication speed; the RGMII interface or the SGMII.

SNLS614C section 7.4.6.1 should have all the information on the differences.

 J784S4XEVM: Need Explanation in the SGMII-RGMII mode 

 RE: DP83869HM: Can we get clock output that recovered from SGMII when DP83869 is in RGMII-to-SGMII bridge mode? 

 RE: DP83TG720S-Q1: Does two PHY MDI port can connect back to back for RGMII -to-SGMII translate application? 

We have not validated DP83TG720 to be used for this purpose. Please consider the part DP83869, which has the SGMII-RGMII Bridge functionality you are looking for. 

 RE: DP83869HM: SGMII mux with integrated SGMII to RGMII bridge 

DP83869 can act as an SGMII <-> RGMII converter in diagram 2.

 DP83869HM: SGMII-RGMII Bridge Mode Strapping 

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

I tested this in the lab on the DP83869EVM. I'm seeing RGMII to SGMII bridge mode with Pin 38 pulled up. When the pullup is removed, the op-mode is SGMII to RGMII.

I used register 0x01DF to determine the mode of operation. With the pullup present, this register was 0x0003. With the pullup removed the register is 0x0043:

The datasheet is correct here. I'll look at getting that app note SNLA318 updated in the future.

 DP83869HM: DP83869HM SGMII-to-RGMII Bridge mode application question 

You can use the DP83869 bridge mode, please see this app note on the different mode of operation. 

There is also a reference design showing the RGMII connection between AST2600 and DP83869.

For the two bridge mode, it depends on which MAC interface you want to select the operating speed of in bridge mode. In RGMII-to-SGMII bridge mode, the RGMII side automatically adjusts to the link-up speed on the SGMII side. In SGMII-to-RGMII bridge mode, SGMII adapts the link speed based on RGMII.

(5) [FAQ] DP83869HM: DP83869 in Bridge Mode to connect two MACs - Interface forum - Interface - TI E2E support forums

I finally suceeded to use the component as RGMII to SGMII BRIDGE without any auto-negociation process.

The configuration is the following:

REG(0x170) = 0x8 << 8 # Activation of CLK_OUT at 125MHz

REG(0xC6) = 0x10 # CLK-OUT control register (PLLCTL)

REG(0xC00) = 0x0140 # BIT 12 = '0' = autoneg diseable

In our case, it's important to active the bridge before the mac RGMII and SGMII.

 RE: DP83869HM: MAC to MAC SGMII to RGMII Mode 

DP83869 support RGMII to SGMII bridge mode.

 RE: DP83869HM: 1DFh register, RGMII-to-SGMII bridge mode 

 AM6422: AM6422 + DP83869 RGMII Tuning 

The AM64x device does not support tuning of its output signals. There is a reserved register bit associated with the AM64x MAC that allows the data to be launched at the same time as the clock transition, or allows the data to be launched 1/4 cycle ahead of the clock transition. This register bit defaults to the state that introduces the internal delay on clock because the AM64x device does not support the first option. The AM64x device was not timing closed to use the first option. Therefore, you should be seeing a fixed delay relationship when observing the TX data path.  I think the tuning you are doing is associated with the RGMII PHY. If so, I would expect the see a change in the RX data path, but not the TX data path because the TX delay you are introducing is internal to the RGMII PHY.

(+) DP83869HM: use for MAC to MAC interface with RGMII to SGMII - Interface forum - Interface - TI E2E support forums

 [FAQ] DP83869: Do RGMII Rise/Fall times need to meet the 750ps spec for a working system? 

The RGMII specification mandates a maximum Rise/Fall time of 750ps for all clock, data, and control signals. Through both internal and customer testing, we have determined it is often not necessary to meet the 750ps Rise/Fall timing to get functional RGMII communication.

The key care-about for RGMII is the Clock-to-data setup and hold times. Data will be latched at RGMII receivers on both the rising and falling edges of the clock (DDR). The setup time is the time before a clock transition in which the data needs to be stable. The hold time is the time after a clock transition in which the data needs to be stable. If setup and hold times are met, the RGMII communication will work regardless of the Rise/Fall time.

 RE: DP83869HM: Is RGMII-SGMII bridge mode of operation supported by DP83869HMRGZT in inux? 

Driver is available at this link: https://www.ti.com/tool/ETHERNET-SW

you should be able to replicate this with DP83868EVM but you will need to connect the EVM to RGMII MAC. For SGMII, you can either connect to another EVM which can change to a copper connection or connect SGMII to SGMII MAC.

 DP83869HM: question about RGMII-to-SGMII mode 

The PHY will not mix speeds. Both MAC interfaces must be at same speed.

 DP83869HM: RGMII to SGMII bridge auto negotiation not succeeding 

Smart Bits (data generator) <-Ethernet Cable (1000Mbps)-> DP83867SEVM <-SGMII-> DP83869HMEVM -> Oscilloscope probing the RX_CLK signal.

When Reg 0x1DF = 0x0043, the RX_CLK freq was 125 MHz (the expected value). You are correct, Reg 0x43 functions as RGMII-to-SGMII bridge.

 AM6442: Linux driver for Ethernet PHY DP83869HM cannot set OP_MODE to the RGMII-to-SGMII Bridge mode 

I understand that using the command is just setting the device in SGMII-RGMII mode.

The driver is a sample model of the driver and should be tweaked by customer as per their use case.
Can you please ask customer to tweak the driver to set the OP_MODE_DECODE register to 0x003 instead of 0x0043?

Customer can also choose to use hardware straps to set the mode correctly.

 DP83869EVM: 100BASE-TX and SGMII settings with DP83869EVM 

 DP83869HM: SGMII to RGMII bridge mode settings 

 DP83869HM: interface between our RGMII and the user's SGMII link? 

We have a need to interface with user equipment's SGMII (dual ports).

Below is the drawing of the interface.

Can we use the DP83869 for this interface?

DP83869 can help via bridge mode, but it will be extremely important that there is speed uniformity across the signal chain. RGMII can determine speeds via RX_CLK, while SGMII has auto-negotiation.

 RE: DP83869HM: [DP83869HM] RGMII to SGMII_Design Review request 

Actually, my requirement was to configure PHY in "RGMII to SGMII bridge mode" and I was supposed to use below mentioned strapping.

 DP83869HM: How to interface a CPU with RGMII pins to the Quectel EC21-A with SGMII pins? 

The first configuration will work with DP83869 between RGMII-MAC and SGMII-EC21.

[MAC (RGMII)]  <-> DP83869 (RGMII <-> SGMII bridge) <-> EC21 (SGMII) 

When the datasheet says RGMII-SGMII bridge, it means that a traditional MAC will be connected to the RGMII side of DP83869 and the traditional PHY will be connected to the SGMII side. The data will flow bi-direction. 

 TDA4VH: Is DP83869 the right part can support SGMII in TDA4VH? 

DP83869 has been verified with TDA4VM with a TI internal daughter card (SGMII daughter card). TDA4VH used similar subsystem and SERDES. You can configure SGMII to work in 100M mode. 

 RE: DP83869HM: SGMII Back-to-Back PHY Configuration Issue 

Regards,

Sreenivasa