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.

DP83822IF: Talking with another mfg PHY

Part Number: DP83822IF
Other Parts Discussed in Thread: DP83822EVM, USB-2-MDIO

I've got the TI PHY and Broadcom PHY both configured for fiber, disable A/N, 100Mbps, full-duplex.

They are connected to each other transmitting dummy data and I expected this would be successful right out of the box.

For reference, connecting two TI PHYs together in the same fashion was successful.

As I understand, these are both transmitting 4B5B codes and the data is NRZI.

What could be the incompatibility?

  • Hi Craig,

    Could you clarify the problem you are seeing? Is link completely down, or are you seeing intermittent packet loss?

    If you have register access, please share a DP83822 register dump from registers 0x0 to 0x1F so I may confirm the configuration.

    Thank you,

    Evan

  • I've got two test boards that are identical.  Each board has our legacy PHY (Broadcom 5241) and TI PHY DP83822IF, among others.  I have an FPGA on the development board.  I have a Verilog module that transmits dummy data.  I connected the TI PHY on each board together via POF (using Broadcom AFBR-5972EZ transceivers).  I've established a link between both TI PHYs and I'm successfully transmitting and receiving.  We proved this out by connecting together the Broadcom PHY on both boards.  But when I connect the TI PHY to the Broadcom PHY, I'm transmitting from both PHYs but neither are receiving.

    I have another Verilog module that initializes the PHYs.  I can confirm settings using a SALEAE analyzer.  It's a little clunky.  But I've got a launchpad on its way so I can use the USB MDIO tool instead.  Would make it easier to interrogate the PHY.

    Here are the TI PHY register values I grabbed from the analyzer with the TI PHYs connected together:

    Register Address [0x00] Data [0x2100]
    Register Address [0x01] Data [0x7849]
    Register Address [0x02] Data [0x2800]
    Register Address [0x03] Data [0xAAD0]
    Register Address [0x04] Data [0xA5E9]
    Register Address [0x05] Data [0x0000]
    Register Address [0x06] Data [0x0005]
    Register Address [0x07] Data [0x2001]
    Register Address [0x08] Data [0x0000]
    Register Address [0x09] Data [0x0000]
    Register Address [0x0A] Data [0x4000]
    Register Address [0x0B] Data [0x1000]
    Register Address [0x0C] Data [0x0000]
    Register Address [0x0D] Data [0x0000]
    Register Address [0x0E] Data [0x0000]
    Register Address [0x0F] Data [0x0000]
    Register Address [0x10] Data [0x0004]
    Register Address [0x11] Data [0x0108]
    Register Address [0x12] Data [0x0000]
    Register Address [0x13] Data [0x0000]
    Register Address [0x14] Data [0x0000]
    Register Address [0x15] Data [0x0000]
    Register Address [0x16] Data [0x0100]
    Register Address [0x17] Data [0x0041]
    Register Address [0x18] Data [0x0400]
    Register Address [0x19] Data [0x0021]
    Register Address [0x1A] Data [0xA000]
    Register Address [0x1B] Data [0x807D]
    Register Address [0x1C] Data [0x05EE]
    Register Address [0x1D] Data [0x0000]
    Register Address [0x1E] Data [0x0002]
    Register Address [0x1F] Data [0x0000]
  • Hi Craig,

    Thanks for sharing the register dump. The PHY configuration looks good to me.

    Assuming the Broadcom PHY supports the same forced speed configuration, it's strange there are link issues.

    Have you tested with back to back Broadcom PHYs forced in 100M? If this fails, the issue looks to be isolated to Broadcom side.

    Could you share a schematic/block diagram with me so I may double-check the connections and straps? (email to e-mayhew@ti.com for private share)

    Thank you,

    Evan

  • Thanks for taking the time to review.  Yes, the Broadcom part supports 100Mbps, A/N is disabled, and forced full-duplex.  We started with back-to-back Broadcom PHYs and it works perfectly.  Same with the TI PHY back-to-back.  I'll send you the schematic.

  • Hi Craig,

    Please allow me some time to review. I will get back to you with suggestions by Tuesday 2/6.

    Thank you,

    Evan

  • Hi Craig,

    Please try this configuration:

    - 0x19[15] = '1' (enable auto-mdix)

    - 0x40[13] = '1' (alternative 100M fiber force config)

    I suspect incompatible SFP modules are the cause of fiber link issues between TI and Broadcom PHY. I'm unable to find the datasheet for the SFP module U9, have you seen any case with link up between U9 and U10?

    Also, can you help me understand the LVPECL <-> LVDS logic translation? For the Broadcom PHY, I see only one of the MDI pairs connected to the translator, but ​both MDI pairs of DP83822 have translation.

    Thank you,

    Evan

  • Hi Evan,

    I could not set Auto-mdix enable.  Is it because I’ve disabled auto-negotiation?  I can try again with auto-negotiation enabled.

    But I successfully set alternative 100M fiber force config.  Unfortunately, I’m still not talking.

    Both U9 and U10 are the same device – AFBR-5972EZ.  I’ll email you the datasheet.

    This transceiver uses LVDS level inputs/outputs.

    What I’m trying to do is link up U9 on board 1 to U10 on board 2.

    Our proven production circuit is the Broadcom PHY.  This device uses LVPECL.  PECL has a wider voltage swing than LVDS.  The transceiver expects a smaller voltage swing.  But in the other direction we use the voltage translator (U8) to step up to the PECL levels expected by the PHY.   We worked with Broadcom on this circuit back when we started using the AFBR-5972EZ maybe 6-7 years ago.

    We were not sure about the TI PHY so we used resistors to achieve the voltage level translation.  I can send you the source for that decision in email.

  • Hi Craig,

    Auto-negotiation should not affect register access.

    I need to discuss with the team about possible incompatibilities between TI and Broadcom PHY, please expect a follow-up before Friday 2/9.

    Thank you,

    Evan

  • Hi Craig,

    Do you have access to a fiber network switch to test as the link partner instead of Broadcom PHY? 

    It's unclear if the issue is due to termination incompatibility, this is the reference termination we have for LVPECL on DP83822EVM:

    Thank you,

    Evan

  • I'll get one.  Not sure what I have access to until I look.  I can always buy one and receive it in short order.  Does this switch need any fancy features?  I'll take a close look at the EVM terminations.

  • Any standard managed switch should be fine, given that you can access the speed/auto-neg features and set to the same mode as DP83822.

    Thank you,

    Evan

  • Questions:

    We are running our own protocol - not Ethernet.  Would a switch still be valuable?

    I've not seen any switches with the style of POF connector.  I suppose I would need a media converter?

    Thanks,

    Craig

  • Hi Craig,

    What protocol are you using? If you do not expect it to be straightforward to have link-up with a switch without media / protocol conversion, then it may be a more efficient use of our time to debug at the PHY level with the boards you currently have.

    Are you confident that the MDI termination schemes between Broadcom and TI PHY are compatible? As there are no packets seen on the receive end of either PHY between DP83822 <-> 5241, I suspect the issue is on the MDI connection.

    Thank you,

    Evan

  • Hi Evan,

    We developed this simple ethernet-like protocol to essentially transmit I/O commands from and feedbacks to a main controller.  We call it SDL for Sampled or Simple Data Link.  We do not use MDIX or auto-negotiation.  I basically set the PHY for 100Mbps, full-duplex, and fiber.  I have a media converter RJ45 to POF.  I just wonder how difficult this would be to get working (if we could get it working).  I agree that it would be more efficient to debug with what I've got.

    I'm not confident at all that I've got these termination schemes right.  In fact, I'm missing some resistors in that area - the schematic says they need to be hand-soldered.  Maybe the first step is to get the boards to agree with the schematic.  Although I wonder why it worked with TI PHY <-> TI PHY.  I'm with you.  I suspect the MDI connection.  Maybe it was balanced enough with the two TI PHYs connected?

  • Hi Craig,

    I agree - it's possible that the LVPECL termination was balanced with back-to-back DP83822s, but there is marginality when attempting to interface with the 5421 termination scheme.

    Are you able to probe the transmit path methodically to see if the voltage levels are following the expected values for LVPECL <-> LVDS translation at each step? We have not validated this type of translation before for DP83822, so I do not have many resources to replicate your setup and help debug.

    Thank you,

    Evan

  • I'm setting up with some high-end active differential probes.  I believe we have two probes (still need to confirm).  And I've got access to the right scope.  Plus I have some other work to do.  It will take me about a day and a half to setup and do some other work that has intervened.

  • Sounds good, please let me know when you are able to share MDI scope shots.

    Thank you,

    Evan

  • Hi Evan,

    I've got the right scope and probes.  Unfortunately, I cannot get back to where I was with the TI PHYs on each board talking with each other.  These agilent diff probes work best when soldered on.  They require an axial lead resistor and I must have a solder bridge somewhere.  Soldering in a very tightly congested area.

    I've got this back in focus and have time to work on it again.  May take me a few days to sort this out.

  • Hi Craig,

    Thanks for the update. Let me know if I can help with the initial back-to-back TI PHY setup.

    Best regards,

    Evan

  • Hi Evan,

    I'm back to this debugging effort.  Although I think it's reverted into debugging connecting two TI PHYs together.  I attempted to adjust the termination resistors to better match the schematic but it's not working.    

    I can repeatably take the following actions and the two boards will communicate:

    • Program the FPGA on either board
    • Cycle power on one board
    • Manually perform soft-reset on one board (write 0x4000 to register 0x001F via USB-2-MDIO)

    If I cycle power on both boards, they will not communicate.  When the boards are communicating I've been able to check bit 2 in register 0x1 is high indicating valid link established.

    I've been able to get the USB-2-MDIO tool working.  I can tap into the MDIO/MDC lines of any PHY on the boards.

    In addition, I've got the DP83822EVM now.  It comes stock with an RJ45 Ethernet interface.  I also have a media converter to get from RJ45 to versatile link POF connections we use.

    I'd like to start debugging here because I figure if I solve this problem, might make the other problem of connecting TI PHY to Broadcom PHY easier to solve.

    This something you can help me with?

  • Hi Craig,

    Yes, I'm happy to help on this.

    Can you clarify the minimum steps required to have link up between the 822's? After powering both boards, is writing 0x1F = 4000 to one/both PHYs sufficient?

    Please also share results when connecting one 822 board to the DP83822EVM, as this may clarify the problem signature with mismatched termination schemes.

    Thank you,

    Evan

  • Evan,

    That is correct.  After I power up both boards, I can perform soft reset (0x001F = 0x4000) on one of the 822 boards and they will link up and communicate.  Same can be accomplished by cycling power on one board after both have powered up.

    I should be able to report back later today on my exploits with the EVM and media converter.

    Thanks,

    Craig

  • Using the USB-2-MDIO tool on the EVM, I get 0x786d for register 0x1 because auto-negotiation is enabled on the EVM.  Unplugged the Ethernet cable and checked register 0x1 and it’s now 0x7849 and bit 2 has gone low again because there is no link (and auto-negotiate is also low).  Also LED D4 is lit when connected and unlit when not connected.  D4 is LINK/ACT indication.  I’m able to get a link with either a straight-thru and crossover cable.  I suspect this is the auto MDIX function working for me.  I get no receive LED indication on the 838 board.  But the EVM isn’t transmitting.  So far this seems to check out.

  • Hi Craig,

    The behavior with back-to-back 822s is as expected, for fiber connection 0x1F = 0x4000 reset is required to update link status (FAQ).

    For your tests with EVM, you are seeing link up but communication issues? Please let me know which cases are failing.

    Thank you,

    Evan

  • Hi Evan,

    Thanks for confirming behavior.  Makes sense.

    I'm seeing the link LED and 0x1 bit 2 high on the EVM so I've established a link.  The PHY on the 838 board is transmitting but not receiving.   I can see this with LEDs on the 838 board and I can see in Chipscope from the FPGA.  I'm not sure the easiest way to see activity on the EVM.  Change mode of LED using USB-2-MDIO?  So no communication regardless of which case - but I suspect it's because I'm not transmitting from the EVM?  Is there a mode I can put it into like would loopback make sense?  I do not have the scope probes on the rx/tx lines yet - primarily because I'm unable to access the termination resistors with the probes soldered on.

  • Here is my current understanding of your setup, please correct me if there are errors:

    Can you send/check packets on the host end? If so, we can iterate through some loopback tests to isolate where the signal chain is failing.

    Starting with the custom board DP83822:

    - Write 0x0[14] = '1' to enable MII loopback.

    - Any data sent from host should be immediately looped back without error through the DP83822 MII.

    - Similar test can be done with analog loopback (0x16[3] = '1'), to verify the internal PHY signal chain.

    Moving onto the connection with DP83822EVM:

    - Write 0x16[4] = '1' on DP83822EVM to enable reverse loopback.

    - Any data sent from host should pass through custom board DP83822 and the full internal signal chain of DP83822EVM before being looped back.

    I suspect the latter test will fail due to incompatibility with the terminations. If so, the next step would be to systematically probe the chain to debug and decide what termination modifications may be required.

     Thank you,

    Evan

  • Thanks Evan.

    Your drawing is accurate except the converter is not on the board.  Separate entity that gets its own 3.3V.  I'll run thru this exercise and let you know what shakes out. 

  • Sounds good, looking forward to the results.

    Thank you,

    Evan

  • Evan,

    Both loopback modes on the custom board DP83822 tested successfully.  I got the receive LED activity I was looking for and Chipscope showed the received bits.

    However, reverse loopback on the EVM failed just like you expected.

    Where in the circuit should we start probing?

  • Hi Craig,

    Is it possible to share scopeshots before and after the termination on TD/RD?

    Thank you,

    Evan

  • Hi Evan,

    It will take me some time to get these probes installed.  I have two agilent 1130A differential probes.  Each lead will connect with a resistor soldered on to the board.

    Since I only have the two probes does it make sense to do either the two RX or two TX pairs.  Is there a preference?  Or do we want to get one RX pair and a TX pair?  Maybe it makes no difference at all.

  • Hi Craig,

    Evan is out on Time bank until Tuesday, March 5th. Please allow him until then to continue supporting you.

    Regards,

    Alvaro

  • Thanks for the head's-up Alvaro.  Evan and I can pick back up on Tuesday.

  • FYI for Tuesday, I've got the probes installed here:

  • FYI for Tuesday, I've got some results.  Unfortunately, I have only one probe that works.  Can't find the special leads for the other probe.

    Probed LVP_RDM/LVP_RDP:  713mV swing

    Vin = MDI 100BASE-FX receiver input swing 220 to 1800mV (Vpk-pk)

    Probed LVP_TDM/LVP_TDP:  1550mV swing

    VOD = MDI 100BASE-FX transmitter swing 900 to 1100mV (1000mV typical) Vpk-pk

  • Hi Craig,

    Thanks for sharing the results. I will review and look to have feedback for you by tomorrow.

    Regards,

    Evan

  • Hi Craig,

    The output swing is strange, I would expect it to be closer to the datasheet spec of 9-1.1V, especially probed on the PHY-side.

    Can you probe the input of the Broadcom PHY and check the swing level while connected to DP83822? 

    The line driver swing can also be tuned via 0x403. Although I'm still unclear on what the swing levels should be for link between TI <-> Broadcom PHY schemes, if possible please iterate through swing values 0x403[11:8] to see if link is affected.

    There is also one more quick software check for DP83822 fiber - please try writing 0x1F = 0x4000 while connected to Broadcom PHY before checking link status.

    Thank you,

    Evan

  • Do we want to get the TI PHY terminations right first - before we move to the Broadcom PHY?  Right now I'm at the custom board TI PHY connected to the EVM thru media converter.

    But if it makes sense to check the Broadcom PHY, I'll need to solder on resistors for the probe.  Just to confirm, is this where you think I should probe?

  • I managed to get a trace at the Broadcom PHY receive input using the differential browser probe head on the pair I circled in blue in last post.

    Now the trouble is with the USB-2-MDIO tool - I need to debug that before I get much further.  Doesn't even work with the EVM.  Probably some USB issue with my laptop.  

  • Do we want to get the TI PHY terminations right first - before we move to the Broadcom PHY?  Right now I'm at the custom board TI PHY connected to the EVM thru media converter.

    Yes this sounds good, I was curious what the voltage levels were on the receiving end of TI vs. Broadcom scheme, but it seems more efficient to focus on EVM to custom board for now. 

    What issues are you running into with USB-2-MDIO? Does your laptop detect the serial port, with register reads/writes failing?

    Thank you,

    Evan

  • I've got the USB-2-MDIO working again.  What has happened to me several times already is the launchpad appears to NOT be communicating.  I uninstall the tool.  And uninstall the USB drivers.  Once I reinstall all is good for some time.  Maybe it's something with Windows.  All I know is the workaround works.

  • Maybe I try and probe everything that needs probing using the browser probe in hand.  Would be quicker than soldering on resistors and using the other leads.  The geometry is such that the browser probe should work for the most everything we need to do.

  • Hi Evan,

    I've been doing some probing at the TI PHY on the custom board using the browser probe.  This is going to be much more efficient than soldering in resistors especially with how congested it is in the area we're probing.

    I'm connected to the EVM and I confirmed link status is OK.

    I put the screenshots in numerical order 1 thru 4 below:

    1:

     

    2: 

    3: 

    4:

  • Since I got USB-2-MDIO working again, I can do that sweep you mentioned.  However, It's not clear what I'm looking for when doing so.

    Here's a block diagram of my test setup:

  • Hi Craig,

    Thanks for the quick share on the scope-shots. Referring to the Pericom appnote previously shared, can you help confirm if LVDS spec violations are occurring?

    I'd like to summarize the current status of custom board <-> DP83822EVM bring-up, let me know if you agree:

    - Link is up between boards, but data transmission/throughput tests are failing.

    If this is the case, we can run through some swing adjustments on software end to see if we can land on a swing value that works for link+throughput tests.

    For both custom board and DP83822EVM, please iterate through FX swing register 0x403[11:8] values and note if any are successful for throughput tests.

    Thank you,

    Evan

  • Yes, it does appear the LVDS spec is being violated.  LVDS_RX Vpk-pk = 970mV and LVDS_TX Vpk-pk = 463mV

    I agree.  Link is up between the boards but data transmission/throughput tests which I haven't checked I will now check.  These are the loopback tests we did previously. I'll iterate thru the different voltage levels and check loopback tests at each level to see if we have successful data transmission.

  • Evan,

    Here is the procedure I used.  Let me know if you had something different in mind.  Unfortunately, I did not notice any affect.  Using LEDs on custom board and Chipscope looking for RX data from the EVM.

    1. Confirm link up at EVM
    2. Write 4000 to register 001F (do this first before checking link status)
    3. Read register 0001 (bit 2 high means link ok)
    4. Write 1 to 0016 bit 4 to enable reverse loopback
    5. Move MDIO/MDC leads to the custom board #1
    6. Confirm link up at TI PHY (board #1)
    7. Write 4000 to register 001F (do this first before checking link status)
    8. Read register 0001 (bit 2 high means link ok)
    9. Set register 0403 next value lower than default setting
      1. Read register 0403 - bits 11:8 default to 1111 or 1.033V default
      2. Set register 0403 to bits 11:8 to 1110 (1.000V)
      3. Look for signs of communication
    10. Repeat step 9 for all values of swing voltage
  • Hi Craig,

    This procedure looks good, sorry to hear it didn't have an impact.

    As the end goal is TI <-> Broadcom PHY comms, I'm hesitant to suggest hardware changes to help TI <-> TI PHY communicate as both are LVDS and do not require translation.

    I'd like to go back to validating the translation scheme between TI <-> Broadcom if that's okay.

    Do you have more context on how the termination values were chosen, in addition to the Pericom appnote?

    Here are my current doubts about the scheme used:

    - LVDS to LVPECL in appnote scheme is Figure 6, however the scheme referenced on DP83822 side looks to follow Figure 5:

    - Assuming LVDS <-> LVPECL translation is occurring on TI PHY TX side, it's unclear why another voltage translator used on Broadcom RX side (U8)

    We do not have much experience with this type of translation as the most common application is with back-to-back PHYs - please help confirm what resources you have available to validate this.

    Thank you,

    Evan

  • As for TI PHY to TI PHY, I’m considering going back to the resistors as they were placed prior to adding parallel resistance manually (noted in schematic).  That was successful in that the two were transmitting and receiving.  I’m not saying that’s the final circuit, but it gets me closer.  This scheme from Pericom was something our hardware designer wanted to try.  I think all it did was confuse the issue.  Because now I’ve more-or-less matched the resistances as specified, it’s NOT working.  Implementing the Pericom circuits is not a requirement for me.

    Unless you have a better recommendation, my next step with TI PHY to TI PHY, is to put the resistors back to their previous values.  Going forward on that debugging exercise, I was thinking of going thru troubleshooting guide app note snla437.  Specifically, using some of the tests in section 2.6 and 2.7.  I’m hoping it will become apparent what resistance changes need to be made to get the best quality.  I also have the 0x0430 swing level adjustments I could iterate thru again.

    As for TI PHY to Broadcom PHY, I agree.  Let’s proceed with our troubleshooting there. 

    I also think it’s strange that with the Broadcom PHY circuit we use a level shifter (voltage translator) on only the RX pair.  Our proven production circuit is the Broadcom PHY.  This device uses LVPECL.  PECL has a wider voltage swing than LVDS.  The transceiver expects a smaller voltage swing.  But in the other direction we use the voltage translator (U8) to step up to the PECL levels expected by the PHY.   We worked with Broadcom on this circuit back when we started using the AFBR-5972EZ maybe 6-7 years ago.  I guess you could say it’s due to the characteristics of the AFBR-5972EZ?

     

    Maybe we find the translator is an unnecessary complication but I’d like to debug using this circuit primarily because this circuit works and is in production.  I figure I might learn enough from this exercise that perhaps I could eliminate the translator but I’ll save that for another time.

    Here is that schematic.  There are a variety of places I can probe.  Can you circle the areas of probing interest?

    Broadcom 5241 specs:

    • minimum 800mVpk-pk for differential input voltage RD+/-
    • typical 2000mVpk-pk for differential output voltage TD+/-

    I’ve got one individual who is still with us that was directly involved with this circuit.  I have him and his Broadcom FAE contact.

  • Hi Craig,

    If you are able to revert and test with the previous resistance values, I agree that would help add insight.

    Running through the noted troubleshooting guide sections is a good exercise as well to compare link quality and validate the signal path with each termination scheme.

    Regarding the Broadcom-side, I'm curious of the voltage swing and DC-offset both on the connector-side and PHY-side:

    Thank you,

    Evan