DP83TC813R-Q1: RGMII shift TX&RX question

Masatoshi Oguri, Can you maybe address those questions ?

Hi Yanan,

Please find my comments below:

1. the RX timing parameters are specified at the ouput pin of RGMII RX interface, right? The parameters need to match the receiver's(SOC) input specification, right?

   This is correct.

2. This is correct.
3. 
   
   1. Tsetup and Thold times are relevant in both shift and align modes. In TX shift mode, the skew is introduced internally so TX_D and TX_CLK signals should be aligned at the pins of the PHY. 
   2. If skew is introduced on the transmit of the SoC, the PHY should not introduce additional skew. Please use TX align mode for the PHY in this case. 
   3. Figure 7-3 will be corrected in the next revision of datasheet. In TX shift mode, TX_CLK should be aligned with TX_Data signals at the pins of the PHY. 

Thanks,

David

Thank you, David.

as I understand below, are they all right?

1. about RGMII RX or TX, despite of received clock and data synced or not, shift mode will introduce delay of clock inside PHY, while align mode will keep the original signal timing unchanged without other delay introduced.

2. just for the receiver, no matter PHY or MAC, the received data must be sampled at the clock edge, inside receiver.

3. if all the tracks of RGMII bus on PCB have the same length in parallel, the transition time of clock and data is the same, then the PCB track causes no transition delay. but for the receiver, the data must be stable before the clock edge comes, so the delay is introduced inside receiver.

(transimitter in align mode) + (PCB tracks have the same length) = (data and clock are synced on receiver side) ==> receiver must enter shift mode;

(transimitter in shift mode) + (PCB tracks have the same length) = (clock is delayed after data on receiver side) ==> receiver must enter align mode.

if PCB tracks have different length, which makes transition delay between data and clock signals, then the shift mode or align mode can be chosen according to the transition delay, to match the receiving timing of the receiver.

no matter what, the goal is to make receiving timing OK: data must be stable before clock edge, with t_setup and t_hold of receiving data compatible with receiver's datasheet.

Hi Yanan,

1. Correct

2. Received data is sampled on the clock edge, yes. The TX_Data signals must have a minimum of 1ns setup and 1ns hold time, with respect to the TX_CLK. Figure 7-4 shows this.

3. Yes this is exactly correct and well said. 

Thanks,

David

Hi, David. Thanks for your reply and praise.

It is clear now about the align/shift mode and the timing.

according to our test result, the data rising/falling time is not compatible with the range in datasheet.

the tr and tf in the test are 1.59ns and 1.71ns, respectively, but the datasheet specifies 1.2ns maximum with 5pF Cload.

I am considering: the overrange of RX_D[3:0] tr&tf can be accepted or not, if the receiving timing on receiver SOC is good(t_setup and t_hold is >1ns is specified in SOC's datasheet)?

Hi Yanan,

Slightly higher rise/fall time is okay as long as the setup and hold times are met at the receiver. Rise/fall time spec given in datasheet is with 5pF load, your board or SoC may have slightly different load. 

Are you able to transfer data without issue?

Thanks,

David

OK. I got it. it is the reveiving timing that actually matters, as long as the tr&tf deviate not too much.

in the DV test, ethernet is lost @Ta=-40ºC and Ta=95ºC, we are troubleshooting this issue now. I do not know whether the issue is caused by the tr&tf.

Hi Yanan,

Let me know as you find out more details on this. Is link dropping or is link stable at -40C and 95C?

Thanks,

David 

Thank you,David, for your following.

my colleague is dealing with this issue now. I have given him the thread link for support, if he gets more details, perhaps he will reply to you here.
I will also follow this issue till the final solution.

Sure, will await his reply.

Thanks,

David