• State TI Thinks Resolved
  • Locked Locked
  • Replies 5 replies
  • Answers 1 answer
  • Subscribers 99 subscribers
  • Views 1097 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

AM5726: RGMII timing isues

David Yat Sin
Prodigy 220 points
Part Number: AM5726
Other Parts Discussed in Thread: DRA752

 On our board, the RGMII0 interface is running with no errors on the receive side but there are errors on the transmit (this interface is on the 1.8V rail because the partner, FPGA, has only 1.8V capability).

AM572x RGMII timing is dependent on the CPU initialization. The datasheets states that a minimum setup and hold time is guaranteed as in the table below so I expect to see at least 1ns setup and 1 ns hold from clock edges. And this is what the FPGA needs to properly operate.


The PCB has matched the length of the TxD[0-3] with the TxC so there is no delay inserted by the PCB. The matching of lengths is as recommended by TI to be less than 50ps.The RGMII lines are 80mm long, 50 Ohms traces. The series resistors are 22 ohms on all lines and the edges are not great (1.6ns rising and 1.7ns falling edge).

 With the scope I measured the relationship between TxD[0-3] and TxC and they transition at the same time (there is no setup and no hold time and this is not fine with the FPGA)

 The function to initialize the timing is below and is probably a copy of the SDK. David can give you details on this. He also built uBoot built with 2 variants. One that uses the DRA752_ES1_1 and one that uses DRA752_ES2_0. Surprisingly there was no change in delay measurement between those builds selecting two different delays.

 

Using mem I also checked the transmit registers:

 

BIST:~# mem -d -s 0x4844a740 -u

0x4844a740:0x00000402

BIST:~# mem -d -s 0x4844a74c -u

0x4844a74c:0x00000402

BIST:~# mem -d -s 0x4844a758 -u

0x4844a758:0x00000404

BIST:~# mem -d -s 0x4844a764 -u

0x4844a764:0x00000401

BIST:~# mem -d -s 0x4844a770 -u

0x4844a770:0x00000400

BIST:~# mem -d -s 0x4844a77c -u

0x4844a77c:0x00000404

 

The RGMII0 pads configuration is

 

BIST:~# mem -d -s 0x4a003650 -u

0x4a003650:0x00010000

BIST:~# mem -d -s 0x4a003654 -u

0x4a003654:0x00010000

BIST:~# mem -d -s 0x4a003658 -u

0x4a003658:0x00010000

BIST:~# mem -d -s 0x4a00365C -u

0x4a00365c:0x00010000

BIST:~# mem -d -s 0x4a003660 -u

0x4a003660:0x00010000

BIST:~# mem -d -s 0x4a003664 -u

0x4a003664:0x00010000

It’s a bit strange, but bit RGMII_..._MODESELECT is “0” when I would expect it to be “1” in all pad registers.

  • 0
    TI__Genius 16906 points

    In SR2.x, Internal TXC delay on transmit can be enabled or disabled using bits [26] RGMII2_ID_MODE_N and [25] RGMII1_ID_MODE_N of the CTRL_CORE_SMA_SW_1  register.  See TRM section "RGMII Features" for this information.

    To get the correct RGMII transmit timing, the internal delay on transmit must be enabled per above, and the Manual IO Timing Mode GMAC_RGMII0_MANUAL1 described in data sheet section "GMAC RGMII Timings" must be used.  The procedure for using the Manual IO Timing Mode is described in TRM section "IO Delay Recalibration".  Based on the pad registers dump you provided, I agree that it does not appear that the Manual IO Timing mode is being programmed correctly, since the MODESELECT bit is not set.

  • 0 in reply to B.C.
    Intellectual 260 points

    By setting the RGMII1_ID_MODE_N to 0 the timing has changed as described in the datasheet.

    Additional questions:

    1) Does bit 8 of all CTRL_CORE_PAD_RGMII0_xxx registers need to be set ?

    2) If bit 19 of CTRL_CORE_PAD_RGMII0_TXC is toggled I do  not see any difference on the scope. Is it supposed to do anything in RGMII mode ? Is there another method to improve on the rise/fall time of the rgmii TxC (this interface is operating at 1.8V)

    3) The FPGA connected to this port delays the TxC additionally by 300ps. How shall be the A_Delay and G_Delay (table 7-88 of datasheet) modified to compensate for this ? 

  • 0 in reply to Ioan Marusca
    TI__Genius 16906 points

    1) Yes, bit 8 of the corresponding pad config register must be set for each pin listed as part of the Manual IO Timing Mode GMAC_RGMII0_MANUAL1 described in data sheet section "GMAC RGMII Timings".

    2) The slew rate control provided by bit 19 is very minor, and likely not noticable under most conditions.  There is no other programmable way to change the slew rate.  

    3) There is no defined method for using custom A/G delay values.  Only the values published in the datasheet are supported.  The FPGA should be designed to comply with the timing requirements of the RGMII spec.

  • 0 in reply to B.C.
    Intellectual 260 points

    Where can I get a good description of what the A/G delay mean ?

  • 0 in reply to Ioan Marusca
    TI__Genius 16906 points

    The A/G delay values are required inputs to the Manual IO Timing Mode calculations.  They were calculated and verified by TI to enable the timings presented in the datasheet.  Only the A/G delay values listed in the datasheet should be used.  All other values result in undefined IO timings.