Hi Board designers, 

1.Peripherals Supporting Ethernet interface

The CPSW3G and PRU_ICSSG peripherals support ethernet interfaces

2.Number of Ethernet interfaces supported by CPSW3G.

CPSW3G supports 2 external interfaces that could be used a switch or individual MAC.

3.Number of Instances and Ethernet interfaces supported by PRU_ICSSG

x2 instances of PRU_ICSSG are supported by AM64x devices. Each of the PRU_ICSSG instance supports 2 Ethernet interfaces PRU0 and PRU1 

4.Are all 6 Ethernet interfaces supported by any of the AM64x family of devices.

The processor supports up to five concurrent external Ethernet (EPHY) interfaces. Pinmuxing overlaps one of the CPSW3G and PRU_ICSSG1 (PRG1_PRU1).

5.Do all the devices in the Family support the same number of Ethernet interfaces?

The Ethernet interfaces support depends on the device selection. Refer below section of the device specific data sheet

Table 5-1. Device Comparison

6.What PRU_ICSSG functionality is on each AM64x device

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1098260/faq-am6442-what-pru_icssg-functionality-is-on-each-am64x-device/4068272#4068272

7.Any recommendation for using MDIO interfaces.

It is recommended to use the MDIO module available on the CPSW3G and the PRU_ICSSG for the Ethernet interfaces implemented with CPSW3G and PRU_ICSSG peripherals.

8.Is AM64x affected by the MDIO Errata

Before configuring the MDIO interface, see the advisory i2329 MDIO: MDIO interface corruption (CPSW and
PRU-ICSS) of the device-specific silicon errata.
Refer to advisory MDIO: MDIO interface corruption (CPSW and PRU_ICSS) and device-specific silicon errata to
verify if the processor selected is affected by the advisory.
If the selected processor and the silicon revision being used is affected by the silicon errata, there is a work around
implemented by the driver. The driver reads the device JTAG ID and configures the MDIO to use manual (bit
bang) mode.

9.Do you have recommendations on adding series resistors for RGMII interface?

It is recommended to provide provision for series resistors close to the SOC for the TX signals.

Series resistors for the Receive signals are EPHY dependent. It is recommended to provision for series resistors with 0R for enhancements for future use.

10.Are the above series resistor recommendations valid for MII or RMII interface

The Above recommendations for series resistors are valid for these MAC interfaces.

11.Is there any clock recommendations When using Ethernet interface

Refer below section of the device specific data sheet.

Table 7-17. MCU_OSC0 Crystal Circuit Requirements

https://www.ti.com/lit/gpn/am6442

12.Recommendations for using External clock oscillator

7.10.4.1.2 MCU_OSC0 LVCMOS Digital Clock Source

Refer 

https://www.ti.com/tool/TMDS64EVM 

and 

https://www.ti.com/tool/SK-AM64B

for implementation.

13.IO levels supported for Ethernet interface.

The IOs support dual voltage (Either 1.8 V or 3.3 V)

14.Is the RGMII internal delay supported by the processor and is the RGMII internal delay configurable

RGMII_ID is not timed, tested, or characterized. RGMII_ID is enabled by default for TX (Transmit) and the register bit is reserved.

Delay is not implemented for the RX (Receive) path.

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.

15.Can AM64x CPSW handle both 100BASE RMII for one port and 1000BASE RGMII for another port?

CPSW3G allows using mixed RGMII/RMII interface.

16. Can i interface 2 X RMII PHYs with the PHY configured as Master 

RMII_REF_CLK is common to both RMII1 and RMII2. It is recommended to use one of the interface as RMII and the other interface as RGMII for 100M

17. Do you have interfacing recommendations for RMII interface.

Refer below document for guidelines.

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

An FAQ for the RMII interface guideline is planned and the FAE link will be provided in this FAQ when available.

Regards,

Sreenivasa 

Hi Board designers, 

Refer below FAQs related to clocking of EPHY and SOC + usage of buffers

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1415577/am625-am625x-etherphy-rgmii-synchronous-clock

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

Regards,

Sreenivasa

Hi Board designers, 

The FAQ is valid for AM62X processor families.

AM625 / AM623 / AM620-Q1 / AM62L / AM62A / AM62D-Q1 / AM62P-Q1 / AM62P

Regards,

Sreenivasa

Hi Board designers, 

Refer below FAQs

Issue related to EPHY reset ,configuration 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1474171/am625-about-am62-ethernat?tisearch=e2e-sitesearch&keymatch=AM625%252525252520USB0#

AM625-Q1: crystal accuracy

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1467149/am625-q1-crystal-accuracy/5629628?tisearch=e2e-sitesearch&keymatch=AM625%252525252525252520RGMII#5629628

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1415577/faq-am625-am625x-etherphy-rgmii-synchronous-clock/5423029#5423029

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.

RMII mode configuration and issues

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1440535/am625-how-to-configure-rmii-mode?tisearch=e2e-sitesearch&keymatch=AM625%25252520RGMII#

Customer found there is also a 33 ohms resistor on the carrier board, and if they reduce the resistor value, the RMII could work normally now

AM67: Failing to meet RGMII timing requirements with DP83867IRRGZ PHY

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1497133/am67-failing-to-meet-rgmii-timing-requirements-with-dp83867irrgz-phy?tisearch=e2e-sitesearch&keymatch=RGMII#

Regards,

Sreenivasa

Hi Board designers, 

Refer below FAQs

Reading MAC ID

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers/f/arm-based-microcontrollers-forum/1496643/am2434-mac-address-on-am2434-alx-chip-for-ethernet-ip

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1188333/faq-am6412-mac-address-in-ctrlmmr_mac_id-registers

MDIO

https://e2e.ti.com/support/microcontrollers/arm-based-microcontrollers-group/arm-based-microcontrollers---internal/f/arm-based-microcontrollers---internal-forum/1480022/am2434-am2434-am64x-pru-mdio-mdio_phyregread-will-delay-under-low-temperature-environment--20-degree-c/5724995#5724995

Pullup - can they move near to each EPHY for testing 

Pullup value - can you suggest customer to reduce pullup value to 1K.

Series resistor - can you suggest customer to reduce series resistors to 0R.

Can you pls request customer to capture the waveform during normal and low temperature.

A quick update on the experiments had been done on customer side. 

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. 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1494010/am625-wkup-i2c0-issue

Regards,

Sreenivasa

Hi Board designers, 

Refer below FAQs

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

The RMII standard requires the reference clock to be within 50PPM of 50MHz, so SSC is not possible for Ethernet.

regards,

Sreenivasa

Hi Board designers, 

Information related to series resistor on the MAC interface signals

It looks like in your EVM, you don't use any sort of series termination on the RGMII TX pins. Is there internal series termination which makes these unnecessary?

In the specific case of our Control Card EVM, the end-points are fairly electrically close to each other so this was an attempt to reduce the number of passives on the less edge sensitive nets. As a default assumption though, I would still suggest placing at least 0-ohm resistors on the transmit side of each of these lines in case there is a need for additional termination. The AM263x does not have any built-in termination on these LVCMOS IO.

The impedance of the output buffer should be in the range of 30-50 ohms. So the impedance match with respect to the PCB transmission line impedance will not be perfect, but any additional reflections due to this mismatch will be minimum and not very likely to cause an issue on a data signal.

You could make provisions in your system to include source termination resistors for these signals just in case you have signal integrity problems. However, it may not be necessary if your signal traces are short.

Regards,

Sreenivasa

Hi Board designers, 

AM6421: [Electrical Characteristics] Requirement to Rise/Fall time for RGMII_RXCLK

Regards,

Sreenivasa

Hi Board designers, 

Refer below E2Es related to SOC + Ethernet clock architecture

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1512884/am6442-ethernet-phy-osc-in-evm

[FAQ] SK-AM64B: Why the Ethernet phy use the same clock buffer?

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

[FAQ] AM625 / AM623 / AM620-Q1 / AM625-Q1 / AM625SIP: Ethernet PHY RGMII synchronous clock

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

Regards,

Sreenivasa

Hi Board designers, 

Inputs related to RGMII rise time and timing.

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

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/706283/am3352-rgmii-timing-issues/2605196

Regards,

Sreenivasa

Hi Board designers, 

Refer queries related to SyncE

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1518708/am625-processor-which-support-synchronized-ethernet-sync-e

Regards,

Sreenivasa

Hi Board designers, 

Information related to use of oscillator + buffer vs crystal + internal oscillator 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1521570/am6442-clarification-on-clkout0-a19-usage-for-custom-10-mhz-clock-output/5850462#5850462

1. The answer to this question depends on your product requirements. I have been told some of our customers using the PRU_ICSSG subsystem in AM64x may need a common clock source to all Ethernet PHYs when implementing a Time-Sensitivity Network. The common clock source eliminates PPM error differences associated with multiple reference clock sources. You will need to research your product requirements and understand how to implement the appropriate clocking topology to achieve the requirement.

2. No. The CLKOUT0 signal function can only be configured to source a 25MHz or 50MHz clock. The intended function of this clock output was to be used with an Ethernet PHY, where it can be configured to source a 50MHz clock for the RMII peripheral, or a 25MHz clock in lieu of a crystal circuit. I suggest you use the clock tree tool that is part of the SYSCONFIG tool to understand the internal clocking topology of AM64x devices.

3. The CLKOUT0 signal function is not selected by default. Software must configure the appropriate multiplexers in the signal path to select either 25MHz or 50MHz, configure the respective PADCONFIG register to select the CLKOUT0 signal function, and enable the output buffer associated with the pin being used for this signal function. Note: The internal multiplexers and pin multiplexing logic which selects and enables the signal function may create a short clock pulse (glitch) since the registers which control these operations are not synchronous to the clock signal. This means the device you are source with this clock should be held in reset until software has initialized the entire signal path and the clock is stable. We also do not define performance of the clock output because it can be system dependent. You should validate the clock output performance meets the clock input requirements for the attached device across all operating conditions before deciding to use it.

Use of WKUP_CLKOUT0 for EPHY (AM62x)

When you need a clock to be available after reset, you should consider using the WKUP_CLKOUT0 pin since AM62x configures the pin by default to source the HSOSC0 output (25MHz) as soon as MCU_PORz is released.

Note: You must validate the performance of this clock output meets your system requirements in your actual system implementation. We do not define the performance of clock outputs because there are many system specific dependencies that can impact clock performance.

Note: When using AM64x, if the requirement is to generate a clock output after reset, an external oscillator + buffer is recommended 

A accurate representation of the clock tree can be seen using the SYSCONFIG tool. This tool can be found in the AM62x product folder under Software Development Tools. You can Launch the tool from your browser then select Clock Tree when asked to select the Software Product.

Sreenivasa

Hi Board designers, 

Refer below inputs related to MDIO interface supporting Clause 22 and Clause 45:

Below is the DP83826 EPHY extract

8.3.11 Serial Management Interface The Serial Management Interface provides access to the DP83826 internal register space for status information and configuration. The SMI is compatible with IEEE 802.3 clause 22. The implemented register set consists of the registers required by the IEEE 802.3 plus several others to provide additional visibility and controllability of the DP83826.

from data sheet of AM62P, Clause 45 is supported,

customer has question: clause 22 is supported or not?

Yes, we have always supported clause 22 because that was the original definition.

The MDIO module was updated several to support clause 45.  I searched the AM62Px TRM and found the following register definition.  Based on this, it appears AM62Px supports clause 45.  However, you should check the Silicon Errata to confirm there are no advisories saying that is not the case.

The below registers indicate the MDIO interface could be configured for Clause 22 or Clause 45 access.

14.8.3.1.2.53.1 CPSW3_MDIO_CLAUS45_REG Register (Offset = 3Ch) [reset = 0h]

14.8.3.1.2.54.1 CPSW3_MDIO_USER_ADDR0_REG Register (Offset = 40h) [reset = 0h]

14.8.3.1.2.55.1 CPSW3_MDIO_USER_ADDR1_REG Register (Offset = 44h) [reset = 0h]

CPSW3_MDIO_USER_GROUP_USER_ACCESS_REG_J Register (Offset = 0h) [reset = 0h]

Regards,

Sreenivasa 

Hi Board designers, 

Refer below inputs related to ETHERCAT interface:

AM243x INDUSTRIAL COMMUNICATIONS SDK: EtherCAT SubDevice FWHAL

Hardware Requirements

• Sitara Processor with PRU-ICSS IP and EtherCAT support
• Current implementation uses only Spinlock 0. Spinlocks 1 to 7 are free for use.
• HW signals required to implement EtherCAT subdevice functionality is shown below, this info needs to be used in conjunction with SYSCONFIG:

  Signal Name	Requirement	Description
  PRU-ICSS MDIO
  PRGx_MDIO0_MDC	Mandatory	MDIO clock
  PRGx_MDIO0_MDIO	Mandatory	MDIO Data
  PRU-ICSS Distributed Clocks (Network Clock synchronization)
  PRGx_IEP0_EDC_SYNC_OUT0	Recommmended (for DC capable SubDevices)	SYNC0 out - Time synchronized OUT0
  PRGx_IEP0_EDC_SYNC_OUT1	Optional (depends on customer application))	SYNC1 out - Time synchronized OUT1 (depends on SYNC0)
  PRGx_IEP0_EDC_LATCH_IN0	Optional	LATCH0 in (Time stamp latch input0)
  PRGx_IEP0_EDC_LATCH_IN1	Optional	LATCH1 in (Time stamp latch input1)
  PRU-ICSS MII PDI Interrupt
  PRGx_IEP0_EDIO_DATA_IN_OUT28	Optional	PDI ISR output to external SOC pin (via one of the 4 PRU-ICSS digio outputs). PDI ISR pin can be selected via vendor specific register at offset 0xE0A.
  PRGx_IEP0_EDIO_DATA_IN_OUT29
  PRGx_IEP0_EDIO_DATA_IN_OUT30
  PRGx_IEP0_EDIO_DATA_IN_OUT31
  PRU-ICSS MII Port0 (IN Port) & PRU-ICSS MII Port1 (OUT Port)
  PRx_MII0_RXD0	Mandatory	MII0 and MII1 Receive Data0
  PRx_MII1_RXD0
  PRx_MII0_RXD1	Mandatory	MII0 and MII1 Receive Data1
  PRx_MII1_RXD1
  PRx_MII0_RXD2	Mandatory	MII0 and MII1 Receive Data2
  PRx_MII1_RXD2
  PRx_MII0_RXD3	Mandatory	MII0 and MII1 Receive Data3
  PRx_MII1_RXD3
  PRx_MII0_RXDV	Mandatory	MII0 and MII1 RX Data Valid
  PRx_MII1_RXDV
  PRx_MII0_RXER	Optional if PHY supports Enhanced Link detection	MII0 and MII1 RXERR
  PRx_MII1_RXER
  PRx_MII0_TXD0	Mandatory	MII0 and MII1 Transmit Data0
  PRx_MII1_TXD0
  PRx_MII0_TXD1	Mandatory	MII0 and MII1 Transmit Data1
  PRx_MII1_TXD1
  PRx_MII0_TXD2	Mandatory	MII0 and MII1 Transmit Data2
  PRx_MII1_TXD2
  PRx_MII0_TXD3	Mandatory	MII0 and MII1 Transmit Data3
  PRx_MII1_TXD3
  PRx_MII0_TXEN	Mandatory	MII0 and MII1 TX enable
  PRx_MII1_TXEN
  PRx_MII_MR0_CLK	Mandatory	MII0 and MII1 Receive clock
  PRx_MII_MR1_CLK
  PRx_MII_MT0_CLK	Mandatory	MII0 and MII1 Transmit clock
  PRx_MII_MT1_CLK
  PRx_MII0_RXLINK	Mandatory for cable redundancy support	Enhanced link detection. Redundancy support: connect LED_LINK/LED_SPEED from PHY here
  PRx_MII1_RXLINK

AM2434: Using RGMII for EtherCAT

(+) AM2434: Using RGMII for EtherCAT - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

AM2432: AM243 MII/RGMII HW design as Ethercat slave

(+) AM2432: AM243 MII/RGMII HW design as Ethercat slave - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

I see RGMII support to happen only when we support EtherCAT G in future (as of now there is no clear roadmap). EtherCAT 100M will remain MII only.

(+) AM6421: EtherCAT G support with RGMII interface? - Processors forum - Processors - TI E2E support forums

(+) AM6421: EtherCAT G support with RGMII interface? - Processors forum - Processors - TI E2E support forums

(+) PROCESSOR-SDK-AM64X: RGMII support for EtherCat - Processors forum - Processors - TI E2E support forums

EtherCAT considers on the fly latency as KPI. RGMII introduces large MAC level latencies in 100M mode due to additional FIFOs required by the interface. Such a solution won't be competitive, EtherCAT also discourages use RMII due to latency concerns.

Application Note (beckhoff.com)

This requires a different PRU firmware than MII variant, as you can see since overhead in maintaining such a firmware is high and we anticipate limited potential use due to performance overheads - this is not planned to be pursued. 

(25) AM2432: Which RGMII or MII is supported for EtherCAT on LP-AM243? - Arm-based microcontrollers - INTERNAL forum - Arm-based microcontrollers - INTERNAL - TI E2E support forums

Only MII mode is supported by EThercat firmware. The pin nomenclature  has RGMII in it, because ICSSG can support MII/RGMII mode but RGMII mode is not used by ethercat firmware.

(25) AM2432: Is RGMII supported for EtherCAT, EtherNet/IP and Profinet ? - Arm-based microcontrollers - INTERNAL forum - Arm-based microcontrollers - INTERNAL - TI E2E support forums

(25) AM6442: sysconfig: RGMII and EtherCAT pins confliction - Processors forum - Processors - TI E2E support forums

(25) AM2432: EtherCAT using DP83867 - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

I have finally found the issue. It is a pin routing error on our board. We mistakenly routed TX_D1 to TX_D0 of the PHY and TX_D0 to TX_D1.

Is it possible to correct this using Sysconfig or any custom Pinmux without a hardware patch?

(25) AM6442: Help to choose right interface between CPSW-RGMII & ICSSG-RGMIIs - Processors forum - Processors - TI E2E support forums

CPSW3G and ICSSG are Ethernet L2 level solutions compliant with IEEE802.1Q-2018. Out of the items you list HSR forwarding offload is the one item where only ICSSG has the ability to support. For the rest the features roughly align, maybe main difference is ICSSG uses 4 queues and a hash based forwarding lookup (4k entries), which CPSW3G has a true 512 entry lookup table and 8 queues, and similarly some differences like TSN feature EST where ICSSG has 16 entries while CPSW3G has 128.

ICSSG in general is perhaps a little behind in SW driver features, for example multicast filtering is coming in the next release (9.1).

(25) AM2432: Which Ethernet PHY mode is supported on AM2434 EtherCAT and ProfiNET demo? - Arm-based microcontrollers - INTERNAL forum - Arm-based microcontrollers - INTERNAL - TI E2E support forums

elow is the summary table available 3rd party master stacks for Industrial Protocols.

(25) AM6442: EtherCAT versions - Processors forum - Processors - TI E2E support forums

1. Do TI ESC port0 and port1 support MII and RMII?
2. Is the order of the TI ESC ports as follows?
   Outbound : port0(in)→EPU(ESC)→port1(out)
    inbound  : port1(out)→port0(in)

1. We do not support RMII but MII only for EtherCAT. RGMII is supported for other protocols (EtherNet/IP and PROFINET)

2. Yes - this is correct. Port0 (IN) and Port1 (OUT)

Regards,

Sreenivasa

Hi Board designers, 

Please refer below FAQs and the SOC data sheet section for information related to the CPSW CPTS

CPTS
e2e.ti.com/.../am6442-cpts
e2e.ti.com/.../am6442-is-cpts-mandatory-to-achieve-good-performance-ptp-sync
e2e.ti.com/.../am6442-gpevm-how-to-check-1-pps
e2e.ti.com/.../am6442-am6442-cpsw-cpts-output-pps
e2e.ti.com/.../am6442-does-cpts-rely-on-any-peripheral
e2e.ti.com/.../1588_5F00_KS2_5F00_HW_5F00_SW_5F00_Overview.pptx
e2e.ti.com/.../tda4vp-q1-cpts-event-types
e2e.ti.com/.../var-3p-som-am62-what-is-the-maximum-frequency-for-events-to-be-correctly-timestamped-via-hw-ts-push-in-cpts
e2e.ti.com/.../am2431-regarding-trm-10-1-1-cpts-overview-it-is-unclear-how-to-use-the-cpts-module

SOC data sheet reference.

12.2.1.4.7 Common Platform Time Sync (CPTS)

Regards,

Sreenivasa

Hi Board designers, 

Inputs regarding configuring internal delay ID for the MAC interface clock output 

https://e2e.ti.com/support/processors-group/processors/f/processors-forum/1474520/am6422-am6422-dp83869-rgmii-tuning/5660450

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?

Our PCB traces are less than 10 cm long, and we have implemented length matching to ensure proper signal integrity. This should minimize the impact of PCB propagation delays. However, after checking scope probes, it looks like our initial measurements may have been skewed by a 1.34 ns probe delay, which could have misled our interpretation of the TXC vs. TX_Dx timing. Given this, we’re planning to redo our measurements properly to confirm the actual timing relationship. We appreciate your guidance, it really helped us clarify the situation. We'll update once we have more

Regards,

Sreenivasa

Hi Board designers, 

 Inputs regarding 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?

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

so the ER pin is optional.

We disabled this pin in SW configuration and now no more SMD error.

Additional information

(+) AM2431: RMII Ethernet connection without RX_ER - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

(+) AM2431: Industrial Communications subsystem support - is the RMII interface supported with this option? - Arm-based microcontrollers forum - Arm-based microcontrollers - TI E2E support forums

(+) DP83825I: DP83825 RX_ER pin / RMII interface - Interface forum - Interface - TI E2E support forums

(+) TDA4VM-Q1: How to deal with RX_ER pin in the case of RMII MAC to MAC? - Processors forum - Processors - TI E2E support forums

Ethernet PHY DP83TC814R-Q1 has the RX_ER pin.  Does this have to be connected to AM62P when using RMII?

Hi Board designers, 

 Inputs regarding MAC to MAC interface on the same device

(+) AM6442: Is it possible to do an ethernet loopback test when both eth0 and eth1 are on the CPSW? - Processors forum - Processors - TI E2E support forums

AM6442: Is it possible to do an ethernet loopback test when both eth0 and eth1 are on the CPSW?

Our product is using am6442, and config both eth0 and eth1 on the CPSW, rmii mode.

We want to connect eth0 and eth1 with a network cable, then do a loopback test to confirm whether eth0 and eth1's hardware is OK.

The network config is like this:

  eth0: 192.168.10.1/24

  eth1: 192.168.10.2/24

Then "ping -I eth0 192.168.10.2" or "ping -I eth1 192.168.10.1", both ping are failed(can not receive anything).

And I found some information said that, CPSW's hardware DO NOT support loopback test like this.

If eth0 on CPSW, and eth1 on ICSSG, the loopback test can run, but both eth0 and eth1 on CPSW, it can not work.

While not mentioned this sounds like a Linux setup. If so, there are a couple of issues both related to Linux, not the network drivers. First is Linux cannot handle two different ports on the same subnet (192.168.10.x), this is related to how the kernel does the ARP with those two ports. It would not matter switching ports. Using two different subnets "might" work but I doubt the packets ever get transmitted. The kernel will figure out that the ports on the same device and the packets will be loop-backed internally and never be transmitted.

Regards,

Sreenivasa

Hi Board designers, 

 Inputs regarding SOC input slew rate - CPSW3G Timing

We were taking some measurements on our board where we use the AM6422 and DP83822 PHYs and I noticed some values that I was wondering if you could help me clarify.

 In the AM6422 Datasheet I see the information below:

Looking at our PHY:

I attached a sample measured of RX_D1 and TX_D1 as references, but similar timings are observed on all relevant signals:

As you can see above, when it comes to the TX signals the requirements are fulfilled both for the processor and the PHY.

This is, not the case for the Receive signals, so my questions are :

1. Why is this requirement from the processor so restrictive?
2. Would this timing from the RX line cause an issue with the processor?(lost frames etc.)
3. Could this be somehow be adjusted by the processor or the PHY?(Driver strengths or timing parameters)

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.

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

AM6442: RE - Clarification for range to perform SI analysis

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?

re 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.

Regards,

Sreenivasa

Hi Board designers, 

Refer below E2E for queries related to ethernet interface:

(+) AM62P-Q1: RGMII output clock change to 125MHz failed - Processors forum - Processors - TI E2E support forums

Thanks for clarifying that you are using a different EPHY, for checking the PHY side, please check with EPHY silicon vendor to ensure your PHY is also correctly configured.
Changxing Du said:
the uboot then try to change the mac control register to 0xA1.
What I meant by "manual" is exactly this action of changing the registers. This typically is not a necessary step as I explained in my previous message. The below suggestions are assuming you do not make changes to the registers.
What is your network hardware setup? (i.e. what link partner is connected to your custom board? Is it a direct connection or is there a switch involved?)
Can you share what is the result of "ethtool <eth interface name you are testing>"? We want to see what the linked speed is.
Can you share what is your device tree? We want to see if you selected the correct interface mode and speed.
Changxing Du said:
Additionally could help clarity how the GMII_RFT_CLK is selected, it is by any register or automatically once the mac control register is set?
My understanding is that the Linux drivers should already handle clock configuration as well as all necessary MAC register configurations to bring up your Ethernet interface and that the only changes that are necessary on your end is ensuring your device tree is correctly configured and you didn't unknowingly connect to a lower link speed link partner (assuming there are no issues on your EPHY configuration and custom hardware).

Thanks for your clarification. The issue has been fixed. Our Link speed is 1000 for the u-boot . The MAC automatically detect the speed from phy. But the latency is not enabled at PHY side which can lead to fail to detect the speed.

the MAC enables the internal delay on the TX clock. The Rx clock delay is expected to be enabled by the EPHY and good to hear you have been able to configure the dealy and resolve the issue.

Regards,

Sreenivasa

Hi Board designers, 

Please follow the below guidance to improve waveform quality:

Refer below inputs i received and the summary of the discussions:

1. If they are concerned about signal quality, here are some recommendations regarding possible methods of improving it. They can implement whichever technique works best for their design.

Customer attached a Eye diagram – not sure how they generated and if the eye diagram is applicable for the RGMII TX clock.

The clock waveform seems to have multiple distortions causing the rise time to change.

Did you have any comments on the waveform for the clock customer shared.

SDM>> The recommendations in the table below should all help in improving the waveform for the Clock.

Regarding the below table, did you have a cap that can be added on both ends.

SDM>> The cap in the table is only meant to be added at the load end to “compensate” for a lower Ccomp in the load.

There is no specific value – it will depend on the difference in the total (Ccomp + Cpkg) value in the AM4x SoC and the customer PHY

Typically in the order of a few pFs

 (+) AM6442: AM6442BSFGHAALV - Processors forum - Processors - TI E2E support forums

Regards,

Sreenivasa