Guides›RGMII Clock Delay: rgmii, rgmii-id, rgmii-rxid and rgmii-txid Explained

RGMII Clock Delay: rgmii, rgmii-id, rgmii-rxid and rgmii-txid Explained

RGMII sends clock and data edge-aligned, so the clock has to reach the receiver delayed by more than 1.5 ns and less than 2.0 ns relative to its data: before RGMII 2.0 that delay had to come from extra clock trace on the board, and since 2.0 a device may add it internally, which the specification calls RGMII-ID. ^{[1, 2]} In a Linux device tree, phy-mode (or phy-connection-type) records which delays the board already provides, and the driver makes the MAC or the PHY add the rest, so that each clock is delayed exactly once. ^{[3, 4]}

This guide works through the timing, computes how long a board delay line has to be, and maps the four values rgmii, rgmii-id, rgmii-rxid and rgmii-txid to the hardware they describe.

On this page

Why the clock has to be delayed

RGMII carries gigabit Ethernet on four data lines per direction plus a control line and a clock. At 1 Gb/s the clock runs at 125 MHz and both edges are used: bits 3:0 travel on the rising edge and bits 7:4 on the falling edge. ^[1] With an 8 ns clock cycle, each nibble is on the wire for about 4 ns.

The transmitter launches clock and data at the same moment: “clock and data are generated simultaneously by the source of the signals and therefore skew between the clock and data is critical to proper operation.” ^[1] If they arrive together, the receiver samples exactly where the data is changing, with no setup or hold time. Moving the clock edge about 2 ns later puts it near the middle of the 4 ns data window. The Linux documentation describes the delay in the same terms: it is there “to let the PHY (clock sink) have a large enough setup and hold time to sample the data lines correctly.” ^[4]

Table 2 of the specification gives the numbers. The skew rows apply to the original scheme, the setup and hold rows to devices with integrated delay:

Parameter	Min	Typ	Max
T_skewT, data to clock skew at the transmitter	−500 ps	0	500 ps
T_skewR, data to clock skew at the receiver	1.0 ns	1.8 ns	2.6 ns
T_setupT / T_holdT, at the transmitter, integrated delay	1.2 ns	2.0 ns	—
T_setupR / T_holdR, at the receiver, integrated delay	1.0 ns	2.0 ns	—
T_cyc, clock cycle at 1 Gb/s	7.2 ns	8 ns	8.8 ns
Rise and fall time, 20–80 %	—	—	0.75 ns

Note 1 of the table turns the skew rows into a board rule: the PCB “will require clocks to be routed such that an additional trace delay of greater than 1.5ns and less than 2.0ns will be added to the associated clock signal.” ^{[1, 2]} The two rows are consistent: a transmitter skew of −0.5 to +0.5 ns plus a board delay of 1.5 to 2.0 ns arrives at the receiver as 1.0 to 2.5 ns, inside the 1.0–2.6 ns window. The 2.0 ns upper limit was added in version 1.3 “to ensure minimum setup time for subsequent edges”.^[1] At 10 and 100 Mb/s the clock slows to 2.5 and 25 MHz, and the maximum is unspecified. ^[1]

RGMII 1.3 and RGMII 2.0 (RGMII-ID)

Version 2.0 changed the timing specification “to allow transmitter to integrate delay previously allocated to PC layout”. ^[1] Note 4 of Table 2: the setup and hold rows allow “implementation of a delay on TXC or RXC inside the transmitter. Devices which implement internal delay shall be referred to as RGMII-ID. Devices may offer an option to operate with/without internal delay and still remain compliant with this spec.” ^[1]

Read strictly, the specification places the delay in the transmitter of each clock: the MAC delays TXC and the PHY delays RXC. ^{[1, 7]} In practice PHYs can also delay the incoming TXC on their own receive side, so a MAC without RGMII-ID can still connect without a delay line. Microchip's VSC8541 guide describes exactly that option. ^[7] Two directions and three possible places for each delay — board, MAC or PHY — are where the confusion comes from.

Option 1: a longer clock trace on the board

The original method is a “trombone”: route TXC and RXC 1.5–2.0 ns longer than their data lines. ^[7] What counts is the difference between the clock and its own data group, and since a trace's delay per millimetre depends on where it runs, the length follows from the stackup. With the delay calculator's formula, t_pd = √ε_eff / c, and an FR-4 class laminate with εr = 4.2 (the calculator's default):

Routing	ε_eff	Delay	Extra length for 1.5 ns	for 1.75 ns	for 2.0 ns
Stripline, εr 4.2	4.20	6.84 ps/mm (174 ps/in)	219 mm (8.6 in)	256 mm	293 mm (11.5 in)
50 Ω microstrip: W 0.173 mm, H 0.1 mm, 35 µm copper, no solder mask	2.98	5.76 ps/mm (146 ps/in)	260 mm (10.3 in)	304 mm	347 mm (13.7 in)

The microstrip ε_eff comes from the Hammerstad–Jensen expressions in the calculator; solder mask raises it slightly and shortens the required length. Aim for the middle of the window, 1.75 ns, so that laminate tolerance and the transmitter's ±500 ps do not push the result outside 1.5–2.0 ns.

Check a 306 mm stripline clock against a 50 mm data line (1.75 ns of skew) →

Check the same delay on 50 Ω outer-layer microstrip →

Each delay line is 220–350 mm of extra copper per clock. On its own that is longer than the 6 in (152 mm) maximum TI gives for RGMII traces, and TI recommends under 2 in. ^[5] The kernel binding notes that “very few PCBs make use of extra long clock lines”. ^[3]

Option 2: internal delay in the MAC

An RGMII-ID MAC delays TXC on its output. ^{[1, 7]} Some MACs and SoCs can also delay RXC on the input, or offer pin-pad delay settings; the Linux documentation lists a SoC “pin pad/mux/controller” capable of configuring delays as one option when neither the MAC nor the PHY can provide them. ^[4] Some MACs have delays that cannot be switched off, which restricts the phy-mode values the board can use (see below). ^[3]

Option 3: internal delay in the PHY

A PHY delays RXC on its output and can usually delay TXC on its input; the kernel binding records that “all PHYs which implement RGMII also implement the ability to add or not add the needed delays”. ^[3] Three examples show how much the details differ:

TI DP83867: each path is either aligned (no clock skew) or shifted. In shift mode the RGMIICTL register (0x0032) enables the delay and RGMIIDCTL (0x0086) sets it from 0.25 ns to 4.00 ns in 0.25 ns steps, separately for transmit and receive. ^[5]
Microchip KSZ9031RNX: by default it “adds 1.2ns typical delay” to RX_CLK and adds none on the transmit inputs, expecting the MAC to delay GTX_CLK. Pad skew registers adjust each clock, control and data pin in steps of about 0.06 ns, up to 1.38 ns on-chip delay for GTX_CLK and up to 2.58 ns for RX_CLK. ^[6]
Microchip VSC8541: supports internal delay on RX_CLK and, so that a MAC without RGMII-ID can be connected “without the use of PCB trace delays”, on TX_CLK as well. ^[7]

The KSZ9031 also shows why aggregate timing matters: Microchip asks for the whole path — PHY on-chip delay, PCB trace delay and MAC on-chip delay — to be added up when MAC and PHY are not both RGMII 2.0 devices. ^[6]

What phy-mode means in Linux

The Ethernet controller binding defines phy-connection-type, with phy-mode as an alias, and four RGMII values. Its informative section starts by saying that these values “are frequently used wrongly by developers”, and states that the property describes the board: “Device Tree describes hardware, and in this case, it describes the PCB between the MAC and the PHY, if the PCB implements delays or not.” ^[3]

`phy-mode`	Delay the PCB provides (binding) ^[3]	Delay the PHY inserts, when the MAC adds none (phy.rst) ^[4]
`rgmii`	RX and TX	None: “it assumes that either the Ethernet MAC (if capable) or the PCB traces insert the correct 1.5-2ns delay”
`rgmii-id`	Neither — “the most frequent case”; id stands for internal delay	Both transmit and receive
`rgmii-rxid`	TX only	Receive only (RXD[3:0] towards the MAC)
`rgmii-txid`	RX only	Transmit only (TXD[3:0] from the MAC)

Transmit and receive are named from the MAC: TXC runs from MAC to PHY, RXC from PHY to MAC. ^[1] The two documents describe the same values from two ends. The binding says what is on the board. The PHY documentation says what the PHY must add, and that its values “must be understood from the perspective of the PHY device itself”. ^[4] When the MAC adds no delay, which is the Linux default, the two readings coincide.

So phy-mode = "rgmii" does not mean “plain RGMII, no delay anywhere”. It means the board has both delay lines. On a board with no trombones, the correct value is almost always rgmii-id; the binding warns that any other RGMII value “is probably wrong, and is unlikely to be accepted during review” without an explanation in the commit and the .dts file. ^[3]

Add the delay exactly once

The kernel documents put the division of work in writing:

The PHY adds it by default. “By default in Linux, when using phylib/phylink, the MAC is expected to read the 'phy-mode' from Device Tree, not implement any delays, and pass the value to the PHY.” The PHY should be reconfigured to the needed delays, “replacing any setting performed by strapping or the bootloader”. ^[3] The PHY documentation says the same: “Whenever possible, use the PHY side RGMII delay”, because PHYs offer fine delay steps, a delay held constant across temperature and voltage, and reusable drivers. ^[4]
If the MAC adds a delay, the PHY must not. The MAC “must ensure that the PHY does not also implement the same delay. So it must modify the phy-mode it passes to the PHY, removing the delay it has added. Failure to remove the delay will result in a non-functioning link.” ^[3] Conversely, for any mode other than rgmii the MAC driver “should make sure that the MAC-level delays are disabled”. ^[4]
A board delay excludes both. With a MAC whose delays cannot be disabled, rgmii “is now invalid, it cannot be supported, since both the PCB and the MAC and PHY adding delays cannot result in a functional link.” ^[3]

The arithmetic explains why doubling is as bad as omitting. Two delays of about 2 ns move the clock edge by about 4 ns, one whole nibble at 1 Gb/s, so it lands on the next data transition — the same place as no delay at all.

Choosing phy-mode

Decide from the board first, then check which chip will supply what is missing:

Extra trace on TXC (MAC → PHY)?	Extra trace on RXC (PHY → MAC)?	`phy-mode`	Who adds the rest (Linux default)
No	No	`rgmii-id`	PHY adds both delays
Yes	No	`rgmii-rxid`	PHY adds the receive delay
No	Yes	`rgmii-txid`	PHY adds the transmit delay
Yes	Yes	`rgmii`	Nobody: MAC and PHY delays off

If the PHY cannot add a delay that the table asks for, the phy-mode stays the same, because it still describes the board. The MAC driver adds the delay and passes the PHY a mode without it. ^[3] If neither the MAC nor the PHY can, the Linux documentation names two fallbacks: a SoC pad-delay setting or “a specifically designed serpentine” on the PCB. ^[4] A serpentine changes the board, so the phy-mode changes with it.

For hardware engineers the practical choice is the first row: route each clock with its data group and no extra length, match TXD[3:0] and RXD[3:0] within 11 ps (about 60 mil) as TI requires ^[5], and let the PHY add the delay. Microchip defines the timing groups as the clock, control line and four data lines of each direction. ^[6] Check that the PHY really can delay both directions — the KSZ9031 above, for example, relies on the MAC or its pad skew registers for transmit. ^[6]

Fine-tuning: rx-internal-delay-ps and tx-internal-delay-ps

The binding defines rx-internal-delay-ps and tx-internal-delay-ps for controllers with configurable delays; in the MAC node, their presence means the MAC applies that delay. ^[3] They are meant for small corrections: “A value of 2000ps, i.e 2ns, and a phy-mode of 'rgmii' will not be accepted by Reviewers.” In the PHY node the same properties are used for PHY fine-tuning; with rgmii-id they “should have a value near to 2000ps”, and with rgmii a small value can trim the board delay. ^[3] Whether a value is honoured, and in which steps, depends on the driver and the part (0.25 ns on the DP83867, about 0.06 ns on the KSZ9031). ^{[5, 6]}

Symptoms of a wrong delay

The Linux PHY documentation lists the typical results of an RGMII delay mismatch ^[4]:

transmission and reception partly work, with frequent or occasional packet loss;
the MAC reports some or all received packets with FCS/CRC errors, or discards them all;
the problem disappears at 10 or 100 Mb/s, “since there is enough setup/hold time in that case”.

The last one is the signature. At 100 Mb/s the clock cycle is 40 ns rather than 8 ns ^[1], so a 2 ns error is small against the data window. When a link works at 100 Mb/s and fails at 1 Gb/s, count the delays on both clocks: board, MAC and PHY.

Checklist

Decide where each clock's delay comes from before layout. The default is the PHY, with no trombone on the board.
Without board delays, route TXC and RXC matched to their data groups and set phy-mode = "rgmii-id".
With board delays, make each clock 1.5–2.0 ns longer than its data, aiming at 1.75 ns, and compute the length from your stackup's delay per millimetre.
Use rgmii-rxid or rgmii-txid only when exactly one clock has a board delay, and say so in the .dts.
Make sure the MAC and the PHY never add the same delay, and check the PHY's defaults and strap pins against what the driver programs.
If gigabit fails while 100 Mb/s works, check the delays first.

The rest of the RGMII layout rules — 50 Ω lines, 11 ps matching within a group, trace length and series termination — are collected on the RGMII layout guidelines page.

See every RGMII layout rule with its source →

Tools used in this guide

Propagation Delay, εeff & Timing – Propagation delay, length matching from skew, rise time to bandwidth, critical length and wavelength.
Interface Design Rules – Impedance, skew, loss budget and length limits of PCIe, USB, Ethernet, HDMI, DDR and other interfaces, applied to a layer of your own stackup with the field solver.
Impedance Calculator – Single-ended and differential microstrip, coated and embedded microstrip, stripline, coplanar lines and broadside differential pairs, solved with a 2D field solver.

Sources

Browse all guides

Guides explain published methods and data with their sources; check the values for your own design. Terms · Privacy

Back to contents