• Resolved

DP83869HM: 1000Base-X to 1000Base-T Media Converter

Prodigy 60 points

Replies: 8

Views: 94

Part Number: DP83869HM

Hello,

I am having some trouble with my design using the DP83869HM.  My design is based on the DP83869EVM evaluation board.  I have set my design so a simple jumper setting can switch the board from 100M Media Converter to 1G Media Converter.  

I am using an EXFO AXS-200/850 Ethernet Test set with an EXFO ETS-1000L Ethernet loopback module to generate and analyse Ethernet traffic though the system.

The EXFO test equipment measures data rate and bit errors.  There is no problem what-so-ever in 100M media converter mode.  The data rate happily runs at 100 Mb/s and is completely error free.

Similarly, when I use a single board operating at 1G Media Converter and loopback the fibre signal (either with or without the EXFO loopback module) there is also no problem; it runs consistently at 1 Gb/s and is error free.  I only begin to run into issues when trying to use 2 of my boards in the system.  In this case when they are set to 1G Media Converter, the best data rate I can achieve floats around 998 - 999 Mb/s.  I can run the test at a reduced data rate and there is no problem, but I simply have been unable to achieve a maximum data rate of 1Gb/s with 2 boards.

Admittedly, I only have 1 evaluation board so I am unable to test if 2 evaluation boards connected together work any better.

My question is why would the data rate drop to 998Mb/s?  Is this a timing issue between boards?

Best regards

Gareth Foster

  • Hi Gareth,

    How are you calculating the data rate seen by each PHY? Are you able to detect if there are packet errors, CRC errors/undersized/or dropped packets? 

    The PHY should just act as a pass through in converting the copper to fiber signal, so if it operating normally in 1Gbps mode, I would not expect it to be decreasing the data rate of the stream.

    Regards,
    Justin 

  • In reply to Justin Lazaruk:

    Hi Justin,

    Using the EXFO AXS-200/850 I have carried out a bit-error-rate-test, a traffic gen. & monitoring test and a RFC_2544 test.  This is when 2 boards picked at random are communicating with each other.  I did do loopback tests on each board individually to make sure there were no errors before testing the pair together.

    I had some trouble attaching the reports so instead I have copied the contents of the RFC report below:

    EXFO Electro-Optical Engineering Inc.

    User Information:
    Report Date: 1/7/2021 11:51:53

    ------------Test Configuration------------
    Type: RFC 2544
    Throughput Test Time(MM:SS) 00:01
    Throughtput Max Rate (Mbps) 1000.0
    Throughput Threshold (Mbps) 1000.0
    Back-to-Back Max.Dur.(MM:SS) 2
    Back-to-Back Threshold (%) 100.0
    Frame Loss Test Time(MM:SS) 00:01
    Frame Loss Max. Rate (Mbps) 1000.0
    Frame Loss Threshold (%) 0.1
    Latency Maximum Rate (Mbps) N/A
    Latency Test Time (MM:SS) 00:01
    Latency Threshold (ms) 125.0
    Test Interface:
    Port: Electrical 1Gbps Full
    Source MAC Address: 00:03:01:FF:25:63
    IP Version: IPv4
    IP Address: 10.10.0.0
    Source UDP Port: 49184
    VLAN ID/Priority:
    None
    Stream Info:
    Dest. MAC Address: 00:03:01:FF:25:63
    Dest. IP Address: 10.10.0.0
    Dest. UDP Port: 7
    Remote ID: Disabled

    ---------------Test Results---------------
    Start Time: 11:19:09
    Status:
    Throughput Completed
    Back-to-Back Completed
    Frame Loss Completed
    Latency Completed
    Duration:
    RFC 2544 0d 00:32:05
    Throughput 0d 00:07:15
    Back-to-Back 0d 00:19:35
    Frame Loss 0d 00:03:44
    Latency 0d 00:01:25
    Pass/Fail Verdict:
    Throughput Fail
    Back-to-Back Fail
    Frame Loss Fail
    Latency Pass

    ------------------Alarms------------------
    Alarm Seconds
    LOS N/A
    Link Down 0
    Frequency 0

    ------------------Errors------------------
    Error Count Error Count
    Symbol 88402689 Jabber 4532
    Undersize 0 Late Coll. N/A
    FCS 36802 Runt 70
    Collision N/A Exc. Coll. N/A
    Alignment --

    ----------------Statistics----------------
    Throughput (Mbps,All Layer):
    64: 943.82
    128: 961.038
    256: 982.206
    512: 988.847
    1024: 994.285
    1280: 993.883
    1518: 994.182
    Back-to-Back (Mbps,All Layer):
    64: 0.128
    128: 0.03
    256: 0.112
    512: 0.055
    1024: 0.125
    1280: 0.047
    1518: 0.062
    Frame Loss (% Loss):
    64: 0.399
    128: 0.577
    256: 0.754
    512: 1.317
    1024: 2.528
    1280: 3.142
    1518: 3.676
    Latency (ms, S. & F.):
    64: 0.00144
    128: 0.00088
    256: < 0.0005
    512: < 0.0005
    1024: < 0.0005
    1280: < 0.0005
    1518: < 0.0005

    ------------System Information------------
    Module Information:
    Module ID: AXS-850
    Revision Number: 67
    Serial Number: 418803
    Calibration Date: 2/8/2010
    Software Information:
    Software Version: 1.5.0.36

     

    So it is definitely dropping frames or receiving invalid frames back through the system during the test, which does not happen when looping back on a single board.  If the data is just passively passing through from copper to fibre back to copper again (actually it's copper -> fibre -> copper -> fibre -> copper), why would there be such a difference between using 1 board and 2 boards unless there is some kind of timing issue between the boards?

    Best regards

    Gareth

     

  • In reply to Gareth Foster:

    Hi Gareth,

    I would like to confirm I understand the setup, you have two custom DP83869 media converter boards, and one DP83869 EVM. 

    It would appear to me there is a timing issue between some link over the system. Can you enable the Ethernet packet generator on one side of the link and evaluate the data on the other end, without looping back? Putting the far end DP83869 media converter in a reverse loopback mode would also help to isolate the location of the packet errors.

    Regards,
    Justin 

  • In reply to Justin Lazaruk:

    Hi Justin,

    Correct, I have 1 DP83868EVM evaluation board and I am using 2 of my custom boards using the DP83869 device.

    Unfortunately we only have 1 piece of test equipment and it relies on looping back the signal at the far end.  We are currently looking at whether there is something clever we can do with a Network port on a Laptop/PC that will allow us to interrogate the frames/packets/data rate at the far end of the system. I have also tried different ways to clock the boards in order to eliminate any timing mismatch and have found that the data rate/error count can vary (even improve) with certain set-ups but still not able to achieve 1Gb/s.

    I did notice that the capacitors I am using on the clocking circuit are slightly higher than they should be; the CL of my crystal is 9pF but the caps either side of it are 22pF.  I am going to try some lower values: 20pF, 18pF, 15pF and 12pF to see which value gives the best performance.  Maybe the right capacitor value will even fix the problem.

    Best regards

    Gareth

  • In reply to Gareth Foster:

    Hi Gareth,

    Please let me know the results of the BER tests with the corrected loading capacitors on the XI pin. This will have an effect on the MDI link quality and is a good catch. Please also let me know if you are able to put the far end PHY in a reverse loopback mode to isolate the copper to external loopback from the test and see if the errors persist?

    Regards,
    Justin 

  • In reply to Justin Lazaruk:

    Hi Justin,

    No problem.  It will take me a day or two to get the replacement parts in and try them.  I haven't been able to monitor data at the far end yet but will continue to work on that in the mean time.

    Best regards

    Gareth

  • In reply to Gareth Foster:

    Hi Gareth,

    Thank you, I will look for your update. 

    Regards,
    Justin 

  • In reply to Justin Lazaruk:

    Hi Justin,

    We appear to have had some success, and it looks likely that the issue we were seeing was more to do with the limitations of our loopback module more than anything else and perhaps our test was asking too much of it.

    We very recently acquired another EXFO test module; the FTB-8510B Packet Blazer (we are using it on a FTB-200 base).  This has dual RJ45 and SFP ports.  With this equipment we are able to run bi-directional BER and RFC 2544 tests (no loopback).  This can be considered a more real world set-up.  

    With this setup there were no drops in data rate or other errors and so we can only consider this to be a success.

    Unfortunately I cannot explain why exactly the loopback was the cause of the failure, but I can only assume it is to do with the complexities of the signal on the copper side of gigabit ethernet.  Is this a common problem do you know?

    Best regards

    Gareth