Phys Chip Received Data to Clock Timing ------------------------------------------- Initial Rev. 15-Jan-18 Current Rev. 17-Jan-18 This note is about the relative timing of the Clock and Data that come out of the Receiver section of the Phys chips. This starts with a description of some Scope Pictures that are in the following web directory and then gives references to some of the RGMII component documentation: http://www.pa.msu.edu/hep/atlas/l1calo/hub/hardware/drawings/U22_Receiver_Clk_and_Data/ 5 Scope Pictures from 29-Aug-2017: - u22_both_probes_clock.png both scope probes on the Rx_Clk signal and confirms that there is no channel to channel skew in the scope - u22_rx0_multiple.png The Phy Rx0 signals is Ch 1 and the Phy Rx_Clk is Ch 4. - u22_rx1_multiple.png The Phy Rx1 signals is Ch 1 and the Phy Rx_Clk is Ch 4. - u22_rx1_negative.png The Phy Rx1 signals is Ch 1 and the Phy Rx_Clk is Ch 4. - u22_rx1_positive.png The Phy Rx1 signals is Ch 1 and the Phy Rx_Clk is Ch 4. Summary of the above 5 scope pictures from 29-Aug-2017: I believe that the above scope pictures are all with the default setup of the Phys Chip. The Clock edge is about 0.5 nsec to 0.8 nsec after center of the Data signal transition. 5 Scope Pictures from 30-Aug-2017 using the scope in a better way, i.e. persistence and averaging: - u22_rx0_neg_persist.png Rx0 Negative edge vs Rx_Clk - u22_rx0_pos_persist.png Rx0 Positive edge vs Rx_Clk - u22_rx1_neg_persist.png Rx1 Negative edge vs Rx_Clk - u22_rx1_pos_persist.png Rx1 Positive edge vs Rx_Clk - u22_rx1_pos_avg_16.png Rx1 Positive edge vs Rx_Clk Summary of the 5 better scope pictures from 30-Aug-2017: I do not know if the above scope pictures are all with the default setup of the Phys Chip or if these pictures were taken when Yuri had some values loaded into the pad delay registers. These pictures all look like the Clock and Data both switching at exactly the same time. What do we expect the default output of the Phy Chip to be ? Answer: Simultaneous Clock and Data transition edges. - See the introduction of ti_snla243_rgmii_timing_from_yuri.pdf "RGMII specifies that the clock and data will be generated simultaneously by the transmitting source which requires a skew be introduced between clock and data." - See section 3.3 rgmii_specification_hp_v1.3_dec_2000.pdf "Timing for this interface will be such that the 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." - The above references files are in our web directory: http://www.pa.msu.edu/hep/atlas/l1calo/hub/hardware/components/micrel/ - What does the datasheet for the KSZ9031RNX say: Section 3.9.3 RGMII PAD SKEW REGISTERS Pad skew registers are available for all RGMII pins (clocks, control signals, and data bits) to provide programming options to adjust or correct the timing relationship for each RGMII pin. RX_DV output pad skew control (0.06 ns/step) default 0_0111 RXD(3:0) output pad skew control (0.06 ns/step) default 0_0111 RX_CLK output pad skew control (0.06 ns/step) default 0_1111 The RGMII control signals and data bits have 4-bit skew settings, while the RGMII clocks have 5-bit skew settings. Each register bit is approximately a 0.06 ns step change. A single-bit decrement decreases the delay by approximately 0.06 ns, while a single-bit increment increases the delay by approximately 0.06 ns. TABLE 3-6: ABSOLUTE DELAY FOR 4-BIT PAD SKEW SETTING Pad Skew Value Delay (ns) -------------- ---------- 0_0000 -0.42 ... ... 0_0110 -0.06 0_0111 No delay adjustment (default value) 0_1000 +0.06 ... ... 0_1111 +0.48 TABLE 3-5: ABSOLUTE DELAY FOR 5-BIT PAD SKEW SETTING Pad Skew Value Delay (ns) -------------- ---------- 0_0000 -0.90 ... ... 0_1110 -0.06 0_1111 No delay adjustment (default value) 1_0000 +0.06 ... ... 1_1111 +0.96 From the KSZ9031RNX Datasheet on page 22: As the default, after power-up or reset, the KSZ9031RNX RGMII timing conforms to the timing requirements in the RGMII Version 2.0 Specification for internal PHY chip delay. -------- For the receive path (KSZ9031RNX to MAC), the KSZ9031RNX adds 1.2 ns typical delay to the RX_CLK output pin with ---------- respect to RX_DV and RXD[3:0] output pins. If necessary, the KSZ9031RNX has pad skew registers that can adjust the RX_CLK on-chip delay up to 2.58 ns from the 1.2 ns default delay. The above default RGMII timings imply: . RX_CLK clock skew is set by the KSZ9031RNX default register settings. . GTX_CLK clock skew is provided by the MAC. . No PCB delay is required for GTX_CLK and RX_CLK clocks. My note about the 2.58 nsec maximum RX_CLK delay shown above. This must come from having a built in default RX_CLK delay of 1.20 nsec, then cranking up the adjustable RX_CLK delay from its default of 0.00 nsec to its maximum of 0.96 nsec, and cranking down the adjustable RX_Data and RX_DV delay from its default of 0.00 nsec to -0.42 nsec. What does the input signal to the Xilinx MAC need to be ? From Yuri's note of 25-Aug-2017: "According to XILINX expert: "The core is designed as per RGMII v2.0 and expects 2 ns delay on the RX path provided by the PHY."" I do not understand that sentence. The RGMII spec says nothing about 2.0 nsec delay in Rx Data or Clk.