AM335x RGMII version

Where did you find a reference to RGMII version 2.0?

Regards,
Paul

Hello Paul,

I found few documents regarding Version 2.0, like the one below.

http://www.hp.com/rnd/pdfs/RGMIIv2_0_final_hp.pdf

Regards.

Hello Paul.

Thank you so much for the detailed information.

I understood that, generally AM335x RGMII interface support's both PHY's with RGMII version 1.3

and version 2.0(with internal delay).

Actually our customer had problems using two Gigabit Ethernet ports on AM335x 

and the PHY maker told us to confirm if RGMII version 1.3 is supported.

And a  separate question:Just wanted to know if  DP83865 is recommended to use with AM335x?

Regards.

Hi Paul,

According to the AM335x ARM Cortex-A8 Technical Reference Manual, the SYSBOOT configuration pins [7:6] seems to suggest that the AM335x does support internal delay. This, however, can only be configured when boot from ethernet is configured. How does this add up?

Regards, Peter

In the TRM, look in the Control Module chapter. The register gmii_sel has the bits to enable/disable the internal delay.

Steve K.

The AM335x contains the internal delay feature and the ROM code was designed to support this feature, but timing closure for internal delay mode was not done. 

Therefore, AM335x does not support internal delay mode because RGMII timing may not be compliant to the requirements defined in the RGMII specification when this feature is enabled.

It is important to disable this feature because the AM335x default state is enabled.  This will be described in the next version of the AM335x Silicon Errata.

Regards,
Paul

Thanks, but my worry is whether internal delay is actually supported on AM335x.

Paul wrote

"The AM335x device does not support this option, so you need to use an RGMII PHY that provides internal delay on the clock input if you want to design your PCB with equal length signal traces"

And the document:

AM335x ARM Cortex-A8 Microprocessors (SPRS717C –OCTOBER 2011–REVISED APRIL 2012)

has a note to Figure 5-11 that says:

"The Ethernet MAC/Switch implemented in the AM335x device supports internal delay mode, but timing closure was
not performed for this mode of operation. Therefore, the AM335x device does not support internal delay mode"

Regards

Peter

AM335x does not support internal delay mode.

You must use an RMII PHY that provides internal delay to both transmit and receive data paths and/or insert PCB delays if necessary.  TI recommends timing analysis using timing parameters published in the AM335x and respective RMII PHY data sheets to determine PCB delay requirements.  

Regards,
Paul

Thanks, Paul

My last comment crossed yours.

It seems this issue has been known for some months, and I only came across it by accident. Realising it has a fair impact on my component selection and/or PCB layout, where could I find notifications about such deviations, when the the errata sheets are not out yet?

Best regards

Peter

The original product preview data sheet released in October 2011 had a note attached to RGMII transmit timing diagrams stating internal delay mode is not supported. 

Internal delay mode support was never planned for AM335x.  The decision not to close timing for this mode was made many months before the device was fabricated.

The errata advisory being published is only a reminder for customers to change the default value which enables the internal delay mode by default.

We publish errata advisories describing any silicon related issues as soon as we have confirmed them.  In this case the silicon is operating as designed but we recently had a couple of  customers that did not realize they needed to disable internal delay mode so we are adding an advisory describing this requirement.

Regards,
Paul

Hello Paul,

Please help us with this issue.
As I mentioned in another thread about our customer using AM3352.

Our customer has mistakenly designed their custom boards assuming AM335x's RGMII
does supports internal clock delay feature.

With the recent eratta(Advisory 1.0.10) they came to know to that
the RGMII interface on the custom board doesnot work if the
RGMII1_IDMODE and RGMII2_IDMODE are set to 1b.
It works in the opposite case i.e when internal delay is enabled.

We understood that "The AM335x device does not support internal delay mode"
but unfortunately the custom board is designed already and redesigning the board
may cost too much at this juncture.

As you say "the timing closure was not performed for this mode of operation"
will it be ok to use the internal clock delay feature?
and is it strongly recommended to use a different PHY supporting internal delay or
change the design?

Best Regards.
Paddu

Advisory 1.0.10 is not new, this advisory was published in May 2012. 

The purpose of this advisory was to describe how the default state of the RGMII1_IDMODE and RGMII2_IDMODE bits were selecting the unsupported internal delay mode.  This advisory was not added to the errata for the purpose of communicating internal delay mode not being supported.  This information was already discussed in the AM335x Data Sheet.  Note "A" in Figure 5-15. RGMII[x]_TD[3:0], RGMII[x]_TCTL Timing - RGMII Mode of data sheet section 5.4.1.4 Ethernet MAC and Switch RGMII Electrical Data and Timing has described this limitation since January of 2012.

To answer your question, Texas Instruments can not guarantee RGMII operation when operating with internal delay mode enabled.

Most RGMII PHYs provide a way to enable an internal delay on the transmit clock, but it may not be enabled by default which means it can not be used when booting from Ethernet since the each PHY has a unique implementation that is not understood by the AM335x ROM code.  Therefore, this may not be an issue if the customer is not planning to boot from Ethernet.  We need to ask the following questions.

What RGMII PHY is being used?  Does it support a internal delay option for its transmit clock input?

Are they planning to boot from Ethernet?  If not and the PHY supports internal delay on transmit clock, the application code should be able to enable this feature and get the PHY to work with AM335x.  If they are planning to boot from Ethernet, they may be able to design the additional 1.8ns delay into their PCB design and still use the same PHY.

Regards,
Paul

Thank you Paul,

Actually it seems they are using RGMII PHY which supports internal delay option.
So there is no problem with the AM335x to PHY communication.

But, they are connecting two AM3352s through RGMII interface with 
internal delay mode enabled.

I was confused with the latest TRM which mentions "0: Reserved" for
"RGMII2 Internal Delay Mode" in the gmii_sel Register.

But according to your comment "this may not be an issue if the customer
is not planning to boot from Ethernet"
we assume that we can still use the "RGMII2 Internal Delay Mode" option
in the current and future AM335x silicon versions.
(provided:boot from Ethernet is not used and the RGMII operation is not guaranteed in this case)

Best Regards.
Paddu

No, you misunderstood my comment about Ethernet boot.

RGMII operation can not be guaranteed for any use case when AM335x internal delay mode is enabled.

This does not cause an issue when the product does not require Ethernet boot and the RGMII PHY supports internal delay on the transmit clock, because the application software can enable the delay in the RGMII PHY while initializing the Ethernet subsystem.  So the delay is inserted by the PHY not AM335x.

This is not an option for Ethernet boot applications because the ROM code does not know how to enable the delay in the RGMII PHY.

The TRM was updated to remove this option since it is not supported.  At this time, there are no plans to support this on future silicon revisions.

Does this help answer your question?

Regards,
Paul

Hi Paul,

Thank you so much the helpful information.

If possible we need one final confirmation/suggestion.

As mentioned above they are connnecting two AM3352s through RGMII interface,
but including a delay into their PCB design would be very difficult at this time.

So they will continue using the unsupported AM335x's internal delay feature,
and they will check if they are no errors with all sort of tests like
Temperature test, connectivity test,running test etc with number of boards.
(Note: they will use Silicon Revision 2.0 for the mass production)

If possible please let us know if there is anything else to be tested to make sure the
connection works well.

Best Regards.
Paddu

Process, Voltage, and Temperature (PVT) variations are the the most likely contributors to performance variations.  Your customer can limit variations of voltage and temperature, but they do not have any control over semiconductor manufacturing process variations.

Your customer may have seen good results while using this unsupported feature on a limited number of AM335x devices.  However, all AM335x devices passing their test may be from the same manufacturing lot which have favorable timing parameters for their system.  There is no guarantee the next lot of AM335x devices will provide RGMII signal timing that is compatible with their system. 

TI does not recommend using a unsupported feature in AM335x.

Regards,
Paul