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.

DP83869HM: Issue Setting up PHY Level (MII) Loopback

Part Number: DP83869HM
Other Parts Discussed in Thread: DP83869, DP83867IS

Hi all, 

I am attempting to setup MII level loopback within our PHY to confirm communications between MAC<-->PHY. I have been able to successfully perform loopback testing with passing results at the MAC & PCS level (both internal to the MAC), but not at the MII level (external to the MAC). I'm looking for some advice or clues as to what might be missing / going wrong.

Our Hardware:

  • Intel Cyclone 10 GX FPGA
  • NIOS II process (soft-core, instantiated in FPGA fabric)
  • TI DP83869HM PHY

Our Software / Tools:

  • Quartus Prime Pro 19.4
  • NIOS II Software Build Tools for Eclipse 19.4
  • Intel Ethernet Packet Generator / Ethernet Packet Monitor 19.4 IP
  • Intel Triple Speed Ethernet 19.4 IP

Our Settings / Setup:

  • SGMII-->Copper mode (OP_MODE_DECODE = 0x0046)
  • Gigabit speed
  • Auto-Negotiation disabled (docs suggest this should be disabled for loopback)
  • Full Duplex

Our Documentation:

  • Triple-Speed Ethernet Intel FPGA IP User Guide (UG-01008 - 2021.10.04)
  • DP83869HM Datasheet - Revised December 2018p
  • Intel Cyclone 10 LP FPGA Triple-Speed Ethernet and Intel On-Board PHY Chip Reference Design
    • pg. 4, figure 1 provides a basic diagram of our system. We however have an additional muxer to allow flow of 'normal' traffic when connected to a link partner
  • How to Configure DP838xx for Ethernet Compliance Testing

Things we've tried to get it it working

  • We've confirmed ability to R/W all registers in MAC / PCS / PHY (including extended registers) via reading data back from registers / observing data on a scope
  • We've confirmed all MAC / PCS / PHY settings match each other in terms of speed, duplex and auto-negotiation
  • We've confirmed MAC and PCS level loopback are working. Can see statistics in both the ethernet packet monitor registers and MAC registers
  • We've confirmed we are accurately following PHY loopback setup steps found in "Intel Cyclone 10 LP FPGA Triple-Speed Ethernet and Intel On-Board PHY Chip Reference Design" package
    • Detailed steps themselves are found in .tcl scripts included in the .zip
  • Attempted setting the proprietary 0xC6 register to 0x10.
    • This register has no description about what it does. But is called out as a necessary step in the "How to Configure DP838xx for Ethernet Compliance Testing document", pg. 13. Unclear if this needs to be set for loopback
  • Attempted setting the LOOPCR (0xFE) to 0xE720.
    • This register has no description about what it does, and is only briefly mentioned in "DP83869HM Datasheet", pg 27. It is unclear if this needs to be set for MII loopback.
  • Attempting forcing our LINK_STS1 in the BMSR (0x01) register to up by setting 'FORCE_LINK_GOOD' in the PHY_CONTROL (0x10) register.
    • NOTE: When we attempted digital loopback (which did not work), LINK_STS1 was high. Should this bit be high for MII loopback?

In this post the user states that "we just set the bit 14 of register 0x00  to 1 ,and  write 0x0004 to register 0x16. The test results were successful". In the next response, TI employee states "The configuration for MII and Analog/Digital loopback is correct." We have attempted these settings and confirmed they do not work in our case. Is there more to these steps that was left out?

Here is our current implementation:

#include <stdio.h>
#include <system.h>
#include <io.h>
#include <altera_eth_tse_regs.h>

typedef volatile struct tse_pcs_struct
{
    unsigned int control;
    unsigned int status;
    unsigned int phy_id1;
    unsigned int phy_id2;
    unsigned int dev_ability;
    unsigned int partner_ability;
    unsigned int an_expansion;
    unsigned int device_next_page;
    unsigned int partner_next_page;
    unsigned int master_slave_cntl;
    unsigned int master_slave_stat;
    unsigned int reserved1;
    unsigned int reserved2;
    unsigned int reserved3;
    unsigned int reserved4;
    unsigned int extended_status;
    unsigned int scratch;
    unsigned int rev;
    unsigned int link_timer1;
    unsigned int link_timer2;
    unsigned int if_mode;
} tse_pcs;

// Offsets from MAC Base
#define MAC_REV 0x00
#define MAC_SCRATCH 0x01
#define MAC_CMD_CFG 0x02
#define MAC_MAC_0 0x03
#define MAC_MAC_1 0x04
#define MAC_FRM_LEN 0x05
#define MAC_PAUSE_QUANT 0x06
#define MAC_RX_SEC_EMPTY 0x07
#define MAC_RX_SEC_FULL 0x08
#define MAC_TX_SEC_EMPTY 0x09
#define MAC_TX_SEC_FULL 0x0A
#define MAC_RX_ALMOST_EMPTY 0x0B
#define MAC_RX_ALMOST_FULL 0x0C
#define MAC_TX_ALMOST_EMPTY 0x0D
#define MAC_TX_ALMOST_FULL 0x0E
#define MAC_MDIO_ADDR0 0x0F
#define MAC_MDIO_ADDR1 0x10
#define MAC_HOLDOFF_QUANT 0x11
#define MAC_TX_IPG_LENGTH 0x17
#define MAC_TX_CMD_STAT 0x3A
#define MAC_RX_CMD_STAT 0x3B

// Offsets from Packet Gen Base
#define PKT_GEN_NUM_PKT 0x00
#define PKT_GEN_CONFIG_REG 0x01
#define PKT_GEN_RAND_SEED0 0x02
#define PKT_GEN_RAND_SEED1 0x03
#define PKT_GEN_SRC_ADDR0 0x04
#define PKT_GEN_SRC_ADDR1 0x05
#define PKT_GEN_DEST_ADDR0 0x06
#define PKT_GEN_DEST_ADDR1 0x07
#define PKT_GEN_OPERATION 0x08
#define PKT_GEN_PKT_TX_CNT 0x09

// Offsets from Packet Monitor Base
#define PKT_MON_NUM_PKT 0x00
#define PKT_MON_RX_OK 0x01
#define PKT_MON_RX_ERROR 0x02
#define PKT_MON_BYTE_RX_CNT0 0x03
#define PKT_MON_BYTE_RX_CNT1 0x04
#define PKT_MON_CYCLE_RX_CNT0 0x05
#define PKT_MON_CYCLE_RX_CNT1 0x06
#define RX_CTRL_STATUS 0x07

// Offsets for PCS Registers
#define ETH_PCS_BASE 0x10002200
#define PCS_CTRL_REG 0x00
#define PCS_IF_MODE_REG 0x14

// Offsets for PHY Registers
#define ETH_PHY_BASE 0x10002280
#define PHY_BMCR 0x00
#define PHY_BMSR 0x01
#define PHY_REGCR 0x0D
#define PHY_ADDAR 0x0E
#define PHY_CONTROL 0x10
#define PHY_STATUS 0x11
#define PHY_BIST 0x16
#define PHY_GEN_CTRL 0x1F
#define PHY_LOOPCR 0xFE
#define OP_MODE_DECODE 0x1DF

#define NUM_PKTS_TX_RX 1000

np_tse_mac *mac_registers = ((void*) ETH_TSE_0_BASE);
tse_pcs *pcs_registers = ((void*) ETH_PCS_BASE);

int main()
{
    alt_u32 selector = 0;

    // Step 1a - Configure MAC
    IOWR(ETH_TSE_0_BASE, MAC_CMD_CFG, 0x003B); // tx/rx enable, gigE, promiscuous mode
    IOWR(ETH_TSE_0_BASE, MAC_MAC_0, 0x17231C00); // Set upper portion of MAC address
    IOWR(ETH_TSE_0_BASE, MAC_MAC_1, 0x0000CB4A); // Set lower portion of MAC address
    IOWR(ETH_TSE_0_BASE, MAC_FRM_LEN, 1518); // Set dframe length
    IOWR(ETH_TSE_0_BASE, MAC_PAUSE_QUANT, 0xFFFF); // Set pause quant to max
    IOWR(ETH_TSE_0_BASE, MAC_RX_SEC_EMPTY, 4080);
    IOWR(ETH_TSE_0_BASE, MAC_RX_SEC_FULL, 16);
    IOWR(ETH_TSE_0_BASE, MAC_TX_SEC_EMPTY, 4080);
    IOWR(ETH_TSE_0_BASE, MAC_TX_SEC_FULL, 16);
    IOWR(ETH_TSE_0_BASE, MAC_RX_ALMOST_EMPTY, 8);
    IOWR(ETH_TSE_0_BASE, MAC_RX_ALMOST_FULL, 8);
    IOWR(ETH_TSE_0_BASE, MAC_TX_ALMOST_EMPTY, 8);
    IOWR(ETH_TSE_0_BASE, MAC_TX_ALMOST_FULL, 3);
    IOWR(ETH_TSE_0_BASE, MAC_MDIO_ADDR0, 0);
    IOWR(ETH_TSE_0_BASE, MAC_MDIO_ADDR1, 0);
    IOWR(ETH_TSE_0_BASE, MAC_TX_IPG_LENGTH, 12);
    IOWR(ETH_TSE_0_BASE, MAC_TX_CMD_STAT, 0); // OMIT_CRC = 0, TX_SHIFT16 = 0
    IOWR(ETH_TSE_0_BASE, MAC_RX_CMD_STAT, 0); // RX_SHIFT16 = 0

    IOWR(ETH_TSE_0_BASE, MAC_CMD_CFG, 0x203B); // Reset MAC using same values as above
    while ( (IORD(ETH_TSE_0_BASE, MAC_CMD_CFG) & 0x2000) == 0x2000)
    {
        // do nothing. Wait for MAC reset to complete
    }
    IOWR(ETH_TSE_0_BASE, MAC_CMD_CFG, 0x003B); // re-enable Tx/Rx lines (reset disables these)

    // Step 1b - Configure PCS ------------------------------------------------
    IOWR(ETH_PCS_BASE, PCS_CTRL_REG, 0x0140); // disable AN, gigE
    IOWR(ETH_PCS_BASE, PCS_IF_MODE_REG, 0x0009); // disable SGMII AN, gigE, full duplex

    // Step 1c - Configure PHY ------------------------------------------------
    IOWR(ETH_TSE_0_BASE, MAC_MDIO_ADDR1, 0); // set mdio address 1 to PHY 0

    IOWR(ETH_PHY_BASE, PHY_REGCR, 0x001F); // Set OP_MODE_DECODE
    IOWR(ETH_PHY_BASE, PHY_ADDAR, OP_MODE_DECODE);
    IOWR(ETH_PHY_BASE, PHY_REGCR, 0x401F);
    IOWR(ETH_PHY_BASE, PHY_ADDAR, 0x0046);

    IOWR(ETH_PHY_BASE, PHY_REGCR, 0x001F); // set LOOPCR - Data sheet says this needs to be done. No description on what it does
    IOWR(ETH_PHY_BASE, PHY_ADDAR, PHY_LOOPCR);
    IOWR(ETH_PHY_BASE, PHY_REGCR, 0x401F);
    IOWR(ETH_PHY_BASE, PHY_ADDAR, 0xE720);

    IOWR(ETH_PHY_BASE, PHY_BMCR, 0x0140); // Set BMCR - AN disabled, gigE (need to turn off AN before enabling MII Loopback mode)
    IOWR(ETH_PHY_BASE, PHY_CONTROL, 0x5008); // Set MDI Mode - 0x5028 = MDI-X, 0x5008 = MDI (need to turn off Auto MDI-x before enabling MII Loopback mode)
    IOWR(ETH_PHY_BASE, PHY_BMCR, 0x4140); // Enable MII Loopback
    IOWR(ETH_PHY_BASE, PHY_GEN_CTRL, 0x4000); // SW Reset - preserves register values

    // Step 2 - Configure packet generator ------------------------------------
    IOWR(ETH_GEN_DW_0_BASE, PKT_GEN_NUM_PKT, NUM_PKTS_TX_RX); // set number of pkts to be sent
    IOWR(ETH_GEN_DW_0_BASE, PKT_GEN_CONFIG_REG, 0x0BB8); // Set # pkts, fixed pkt length of 1500, incremental pattern
    IOWR(ETH_GEN_DW_0_BASE, PKT_GEN_RAND_SEED0, 0x12345678); // Set random seed lower (can be anything, chose value from .tcl script)
    IOWR(ETH_GEN_DW_0_BASE, PKT_GEN_RAND_SEED1, 0x00009ABC); // Set random seed upper (can be anything, chose value from .tcl script)
    IOWR(ETH_GEN_DW_0_BASE, PKT_GEN_SRC_ADDR0, 0x17231C00); // Set src mac address lower (pulled MAC address from TI docs)
    IOWR(ETH_GEN_DW_0_BASE, PKT_GEN_SRC_ADDR1, 0x0000CB4A); // Set src mac address upper (pulled MAC address from TI docs)
    IOWR(ETH_GEN_DW_0_BASE, PKT_GEN_DEST_ADDR0, 0x17231C00); // Set dest mac address lower (pulled MAC address from TI docs)
    IOWR(ETH_GEN_DW_0_BASE, PKT_GEN_DEST_ADDR1, 0x0000CB4A); // Set dest mac address upper (pulled MAC address from TI docs)

    // Step 3 - Configure packet monitor --------------------------------------
    IOWR(ETH_MON_DW_0_BASE, PKT_MON_NUM_PKT, NUM_PKTS_TX_RX); // set number of pkts to be received

    // Step 4 - Configure muxers ----------------------------------------------
    IOWR(ST_MUX_2_TO_1_DW_0_BASE, 0, 0x01); // Set mux 0 to a 1 (data coming in from mux 1)
    IOWR(ST_MUX_2_TO_1_DW_1_BASE, 0, 0x00); // Set mux 1 to a 0 (data coming in from pkt generator)

    // Step 5 - Turn on packet monitor ----------------------------------------
    IOWR(ETH_MON_DW_0_BASE, RX_CTRL_STATUS, 0x01);

    // Step 6 - Turn on packet generator --------------------------------------
    IOWR(ETH_GEN_DW_0_BASE, PKT_GEN_OPERATION, 0x01);


    while(!selector)
    {
        // do nothing until we pause and change selector to 1
    }

    alt_u32 rx_OK = IORD(ETH_MON_DW_0_BASE, PKT_MON_RX_OK);
    alt_u32 tx_ERROR = IORD(ETH_MON_DW_0_BASE, PKT_MON_RX_ERROR);
    alt_u32 last_bmcr = IORD(ETH_PHY_BASE, PHY_BMCR);
    alt_u32 last_bmsr = IORD(ETH_PHY_BASE, PHY_BMSR);
    last_bmsr = IORD(ETH_PHY_BASE, PHY_BMSR); // need to be read 2x for valid link up read
    alt_u32 last_phy_ctrl = IORD(ETH_PHY_BASE, PHY_CONTROL);
    alt_u32 last_phy_sts = IORD(ETH_PHY_BASE, PHY_STATUS);

    while(1)
    {
        // do nothing
    }

    return 0;
}

See above code for exact steps we're taking to enable MII level loopback. By examining the MAC statistics registers, we are able to see that all of the packets get sent out OK, but the MAC is not receiving any of those frames which should have been looped back. This suggests to us that the data is not being looped back in the PHY as we expect.

Overall it feels like there is some step(s) / knowledge we're missing to get this working properly. Is there something missing from our setup? Any help or advice would be welcomed and appreciated!

  • Hi Neil,

    Firstly, I wanted to understand a few more things related to the setup.

    1. Is the link partner of DP83869HM connected on the copper side?
    2. I see that SGMII Auto-Negotiation is disabled. During normal functional mode, is SGMII Auto-negotiation disabled? On the MAC, is SGMII Auto-Negotiation enabled/disabled during the loopback testing?

    I suggest we first debug PHY PCS loopback/digital loopback. Please share your thoughts.

    --
    Regards,
    Gokul.

  • Hi Gokul,

    1) In our setup there is nothing connected to the copper side.

    2) We have disabled SGMII Auto-Negotiation specifically for this loopback setup as instructed by the documentation. 

        2a) During normal functioning mode (no loopback, copper side connected to link partner via ethernet cable), SGMII Auto-Negotation is enabled.

        2b) On the MAC side, SGMII Auto-Negotiation is disabled for the loopback setup.

    At the end of the day we'd like to have all levels of loopback working for us. To start we wanted to work with MII as it's the shallowest loop into the PHY

  • Hi Neil,

    Can you please just enable SGMII Auto-negotiation on both MAC and PHY and check if the loopback is working, Please check MII loopback and PCS loopback in this case.

    --
    Regards,
    Gokul.

  • Hi Gokul, 

    We turned on SGMII Auto-Negotiation and attempted running each of MII, PCS and Digital loopback. Here are our results:

    MII Loopback

    We did not receive any packets in the packet monitor. So loopback is not happening as expected.

    Values taken from PHY_STATUS register:

    • AN = not complete
    • Speed = 10Mbps
    • LINK_STATUS_2 = down

    PCS Loopback

    PCS Loopback has 3 different modes. In each of them we did not receive any packets in the packet monitor. So loopback is not happening as expected.

    1. Loop Before Scrambler mode
      1. AN = not complete
      2. Speed = 10Mbps
      3. LINK_STATUS_2 = up
    2. Loop after scrambler, before MLT3 encoder
      1. AN = not complete
      2. Speed = 10Mbps
      3. LINK_STATUS_2 = down
    3. Loop after MLT3 encoder
      1. AN = not complete
      2. Speed = 10Mbps
      3. LINK_STATUS_2 = up

    Digital Loopback

    We did not receive any packets in the packet monitor. So loopback is not happening as expected.

    Values taken from PHY_STATUS register:

    • AN = not complete
    • Speed = 10Mbps
    • LINK_STATUS_2 = down

    Note that in digital loopback, if we disabled Auto-Negotiation and specify 1000Mbps, we see the link come up as good (but still no data to packet monitor).

  • Hi Neil,

    Let me work that out in our lab and get back to you by mid of next week.

    --
    Regards,
    Gokul.

  • Hi Gokul, 

    What were the results of your testing in the lab?

  • Hi Neil,

    Sorry for the delay in response. I was able to have successful data transfer using MII loopback. Here are the settings I used.

    • 0x0000 = 0x4140
    • 0x0010 = 0x5008
    • 0x00FE = 0xE720
    • 0x0016 = 0x0004

    I haven't disabled SGMII autonegotiation and was still able to get it working.

    Can you please try the same?

    However, I was not able to get other loopbacks working. I am working with the design team to get them resolved and hence the delay.

    --
    Regards,
    Gokul.

  • Hi Gokul, 

    We attempted to the steps as written above and still no luck getting loopback working. We observe the same behavior as before where packets are being sent out by the generator (we see them go out over the MAC) but no packets received by the checker (we don't see them come into the MAC).

    I have a few questions regarding the steps you shared

    1. 0x0000 = 0x4140 enables MII loopback, while 0x0016 = 0x0004 enabled digital loopback. Why are we setting two different loopback modes?
    2. Related to the above question - was your successful loopback testing truly in MII mode? Or was it digital loopback?
    3. Does the order of the steps listed above match the order in which we should write to registers?
    4. Could you share the code you've used to successfully run MII loopback?
    5. Lastly, I wanted to double check that your successful loopback testing was done on the DP83869HM
  • Hi Neil,

    SGMII link-up depends on the link-up of the Copper side. Digital loopback is a way to trick the PHY to assume that the copper side is linked-up. If you intend to not use the digital loopback, please connect the link-partner and make sure that the copper side link is up in 1G mode.

    After the above script, can you please check the link status of DP83869HM in the 0x0001 register?

    I have used the registers in the same order and on DP83869HM EVM.

    I don't the exact script I used to validate this currently. Please give me time until Monday to send the same script to you.

    --
    Regards,
    Gokul.

  • Hi Gokul, 

    Thanks for explaining how digital loopback affects the link status'. Out of curiosity, why does the copper side need to have a link up for loopback? My understanding is that since we're not talking to the outside world, we wouldn't need this link to be up.

    Running the above set of registers you shared (with digital loopback enabled) we see both the LINK_STS of register 0x0001 and the LINK_STATUS_2 of register 0x0011 set to 'Link Up'. However we are still not seeing any packets coming back into the MAC / Packet Checker.

    There isn't much description of LINK_STS and LINK_STATUS_2 in the data sheet. Could you explain the differences?

  • Hi Neil,

    Copper side link-up is needed for the SGMII side to link-up. This is because PHY waits for the speed resolution on the copper side to start the link-up on SGMII side.

    I think the  difference between 0x0001 and 0x0011 is that 0x0001 is latch low status whereas 0x0011 is a live status, but I am not completely sure. Let me check and get back to you.

    Can you please let me know if these are your observations until now

    1. In loopback, copper side link is up, but SGMII shows link-down. Is this the case?
    2. Without loopback, SGMII link is up. Data transfer is not done in this case.

    If these are the observations, it is strange that SGMII is link-up in one case and not in other.

    --
    Regards,
    Gokul.

  • Hi Gokul, 

    All results were using the registers you shared above.

    My first question is which bit exactly determines if SGMII link is up? Is this LINK_STS, LINK_STATUS_2, or some other bit?

    1) In loopback mode, both LINK_STS and LINK_STATUS_2 come up as 'Link Up'.

    2) Without loopback, both LINK_STS and LINK_STATUS_2 come up as 'Link Up'. In this case we do see some data transfer (TCP connection made via telnet). However this connection quickly dies after receiving a handful of messages with a 'corrupt packet' error. This corrupt packet error indicates to us that the buffer we've just pulled from the queue is missing its end tag and thus has an invalid length.

  • Hi Neil,

    Link status and link status 2 indicate link-up on the copper side. Information regarding the SGMII side link-up can be found in register 0x0C01.

    --
    Regards,
    Gokul.

  • Hi Gokul, 

    Thanks for explaining LINK_STS and LINK_STATUS_2 for me, very helpful!

    I just ran the tests again and here are my results:

    1) In loopback mode, both LINK_STS and LINK_STATUS_2 come up as 'Link Up'. SGMII Link is 'Link Down'

    2) Without loopback, both LINK_STS and LINK_STATUS_2 come up as 'Link Up'.  SGMII Link is 'Link Down'. In this case, we do see some data transfer back and forth before the connection dies.

    I have a follow up question regarding this SGMII Link Up bit in the FX_STS register. On the data sheet it indicates that this bit is valid in RGMII-SGMII mode and in SGMII-RGMII mode. We are operating in SGMII-Copper mode. Does this bit still indicate a valid SGMII link up in our case?

  • Hi Neil,

    0x0C01 should show you the link status on the SGMII side for SGMII-Cu mode. 0x037 also has some information on SGMII status.

    Looks like there is some problem on the SGMII side. With Autoneg enabled on DP83869 and the MAC, can you please share register logs of 0x0C00 to 0x0C08?
    Please share the schematic of your board also for review.

    --
    Regards,
    Gokul.

  • Hi Gokul, 

    I ran the code again and here are the results. Note that I've included some additional registers to help provide context.

    last_bmcr             0x4140
    last_bmsr             0x794d
    last_phy_ctrl         0x5008
    last_phy_sts          0xac02
    last_pcs_ctrl         0x1140
    last_pcs_if_mode      0x3
    last_bist_cntrl       0x4
    last_phy_gencfg2      0x29c7
    last_fx_ctrl          0x1140
    last_fx_status        0x6149
    last_fx_phyid1        0x2000
    last_fx_phyid2        0xa0f1
    last_fx_anadv         0x20
    last_fx_lpabl         0x0
    last_fx_anexp         0x0
    last_fx_locnp         0x2001
    last_fx_lpnp          0x0
    last_phy_sgmii_an_sts 0x2

    BMSR says link is up and auto-negotiation is not complete. However PHY_STS says link is up and auto-negotiation IS complete. Are these two bits referring to different auto-negotiations?

    FX_STS says auto-negotiation is not complete

    PHY_SGMII_AN_STS says auto-negotiation is not complete

    Here is a copy of our schematic. Note that resistors R37-44 under the "Protection" section of the schematic have been removed. They were an artifact of the previous revision of this board.

    6472.Ethernet Page.pdf

    And just so you know Gokul, I will be away from the office next week. However my co-workers will continue to work with you in my absence.

  • Hi Gokul, 

    I had a couple more questions for you.

    In the instructions you gave us above, there is no Software Restart (which preserves register values) after setting the LOOPCR register. However, on page 83 of the DP83867is datasheet it states " A software reset through bit 14 of the Control Register (CTRL), address 0x001F, is required after changes to this [LOOPCR] register value. Other values for this register are not recommended." 

    • Is this statement no longer true in the 83869 part?
    • Is this something we should be doing?

    My second question is regarding enabling MII loopback. In the instructions you gave above, we set reg 0x0000 = 0x4140. This instruction enables MII loopback and disables auto-negotiation in the same step. However, on page 27 of the DP83869 it states "To maintain the desired operating mode, Auto-Negotiation should be disabled before selecting the Near-End Loopback mode. This constraint does not apply for external-loopback mode."

    • Is this statement no longer true?
  • Hi Gokul, 

    We just ran another set of tests in our lab and I wanted to share the results with you.

    We ran a build where we are able to establish a connection to a telnet server. After connecting we read the value of the 0x0C01 register, and it indicated to us that this link is down. In this situation we know a solid connection has been made (we can see traffic on wireshark) and thus the SGMII auto-negotiation must be complete and this link should be up. This suggests to us that this register does not in fact reflect the state of the SGMII link.

    .

    Could you help explain this?

    .

    Of note, during this same experiment we observed the value of reg 0x37 (SGMII_AUTO_NEG_STATUS) and it indicated to us that the SGMII auto-negotiation has been completed as expected in this situation.

  • Hi Neil,

    I will check this with our design team and get back to you in a day.

    --
    Regards,
    Gokul.

  • Hi Neil,

    I am very sorry for the delay in response.

    I checked the design and looks like SGMII Auto-neg done is available in both 0x37 and 0xC01. However, in SGMII-Cu mode, link status in 0xC01 is always connected to 0. We will have to rely on SGMII Auto-neg done in one of the registers above.

    --
    Regards,
    Gokul.