AM2432: Clarification on IPG handling in SORTE-G (Physical vs Protocol IPG)

Kazuya Yorimoto said:

If both the physical IPG and the protocol IPG are configured to the same value (e.g., 300ns), and both the controller and device PHYs support this value, is it acceptable to omit explicit IPG delay handling in PRU firmware (i.e., no additional delay loops or IEP-based timing between frames)?

I believe this is ok as it reduces overhead in the PRU firmware. I am assigning this thread to SORTE expert

Hi Yorimoto-san,

Thank you for your question. Let me address them individually.

1. Regarding IPG: There is the physical IPG (TX_IPG0/1 register), which the ICSS_G IP uses to maintain packet gaps. This means that the HW will not send out the next packet until this time has passed. We set it to some value during device/protocol initialization. Then there is the capability to overwrite the configured value in TX_IPG0/1, via the protocol IPG provided in the Parameterizations packet. We added this as an configuration option, but there might not be actual SW/FW code overwriting TX_IPG register in after parameterization state.

2. The protocol IPG is meant to replace/overwrite the default/startup physical IPG, if needed. It is not to add sum both up, but use either one or the other IPG value.

3. I assume you are asking for the devices, not for the controller: There should not be additional delay loops in PRU firmware when devices sending. It is all controlled by IEP timer using time triggered send.

Let me know if this addresses your question or if you need additional clarification.

Thank you,

 Thomas

Hi Thomas,

Thank you for your detailed explanation. I have two follow-up questions regarding the IPG handling:

1. Regarding protocol IPG configuration timing:
Is it correct to assume that the device updates the TX_IPG register based on the protocol IPG value upon receiving the Parameterization packet, and that the controller starts using the protocol IPG from the Synchronization phase onward?

2.I am assuming IPG is controlled based on the ICSSG core clock (MII_RT_TXCFG0[12] = 0h). According to the description of the MII_RT_TX_IPG register in the reference manual, it is recommended to configure the IPG in increments of 8 interface clock cycles.
Would it be correct to apply this same recommendation to the protocol IPG as well?

Thanks in advance!

Hi Yorimoto-san,

Let me address your questions.

1. The device does not use write nor update the IPG register, based on the protocol IPG. It could be added in the task_manager , when the state is transitioning from Parametrization to Line Delay Measurement. But as mentioned, we did not implement this yet.

2. Correct, please apply the same recommendation for protocol IPG. This is the simples way, so PRU can just take the value and write it to the register.

Regards,

 Thomas