AM67A: Internal RGMII delay

Hi Joerg,

Interesting, I agree that I don't see the TXC delayed w.r.t to the TDx.

Have you configured the PHY with the RGMII-ID mode enabled? 

From the TRM register sheet, I see the RGMII internal delay control registers as below. On reset, the default value is 0, but please confirm if it is 0 or 1.

Hi,

after Reset/PowerOn RGMII-ID mode bit is '1' = no_delay (this is exactly that what I measured!).

When I set RGMII-ID mode bit to '0' (= int_delay) then delay is enabled but interface is no more operational...see picture below....

Hi Joerg,

Ok got it. Good to see that it matches your earlier measurement where the internal delay was non-existent. 

when enabling the rgmii_id mode, we can now see the delay as expected. 

about the link break when enabling the internal delay, have you also configured the PHY to provide the TX delay making them violate the setup/hold timings?

Were any timing simulations during the board layout done to see how much the board traces would contribute?

Hi,

good to see that there is a bit to enable or disable the tx delay. But the datasheet reads it is fixed enabled. Can you confirm, that the datasheet is wrong in this regard?

Thanks,
-michael

Hi,

Michael Walle said:

good to see that there is a bit to enable or disable the tx delay. But the datasheet reads it is fixed enabled. Can you confirm, that the datasheet is wrong in this regard?

Do you mean PHY Spec or AM67 Spec.
As Shreays shared screenshot of CTRL_MMR_ENET_CTRL,  ID_MODE bit is R/W.

Also, refer to FAQ below about how to configure the RGMII Delay.
[FAQ] TDA4VM: How to configure RGMII clock delay on J7 devices?


Best Regards,
Sudheer

Hi,

Doredla Sudheer Kumar said:

Do you mean PHY Spec or AM67 Spec.

The AM67 spec. https://www.ti.com/de/lit/gpn/am67a, see Figure 6-32, annotation A. Quote: "TXC is delayed internally before being driven to the RGMII[x]_TXC pin. This internal delay is always enabled."

Doredla Sudheer Kumar said:

As Shreays shared screenshot of CTRL_MMR_ENET_CTRL,  ID_MODE bit is R/W.

What is the source document of that screenshot. I've just downloaded the latest AM67A TRM (https://www.ti.com/de/lit/zip/sprujb3) and there is not documented Bit 4.

Doredla Sudheer Kumar said:

Also, refer to FAQ below about how to configure the RGMII Delay.

Thanks, but we know how the delays are configured, if they are documented correctly. The issue is with the latest linux next kernel, which contains a patch to disable any TX delays in a PHY because it assumes that the TX delay on the MAC side is always enabled (and cannot be disabled). This doesn't seem to be the case here.

I'll still need to find out wether the bootloader will overwrite that bit or if it's reset default is 1. But again, there is seems to be no documention.

BR,
-michael

Hi,

Michael Walle said:

I'll still need to find out wether the bootloader will overwrite that bit or if it's reset default is 1. But again, there is seems to be no documention.

I have verified the excel document, it was  mentioned as reserved filed.
Let me check internally and get back to you on Monday. It would be a documentation issue.

Joerg Gauchel said:

after Reset/PowerOn RGMII-ID mode bit is '1' = no_delay (this is exactly that what I measured!).

When I set RGMII-ID mode bit to '0' (= int_delay) then delay is enabled but interface is no more operational...see picture below....

As per above, you were able to change the bit field.  As it is common register across TDA4 devices for ENET CTRL we know bit fields very well.
If you refer to other device's TRM, you can find the description.

If MAC side delay is enabled, you can disable at PHY side.
is communication working for you post managing the RGMII delay?

Best Regards,
Sudheer

Hi,

Doredla Sudheer Kumar said:

It would be a documentation issue.

Any news on this? Because that was my main question. What is the reason TI is "hiding" this bit and even telling the user that the delay is always enabled. Is it a documentation error? Does it work with every SoC? Are there SoCs which really have this fixed enabled, etc.

I'm being that pedantic, because there is a more or less larger discussion on the linux kernel mailinglist about this and how to really solve it. Some pointers:
lore.kernel.org/.../
lore.kernel.org/.../

Doredla Sudheer Kumar said:

If MAC side delay is enabled, you can disable at PHY side.
is communication working for you post managing the RGMII delay?

Yeah that is working fine. That is, if the delay is configured only on one side, everything works.

-michael