DP83822IF: Talking with Broadcom 5241

Hi Craig,

Sorry for the inconvenience, threads automatically lock after a certain period of inactivity. Please share the latest update here so we may continue the discussion.

Thank you,

Evan

I tried the PRBS packets to no avail.  The FPGA is generating traffic.

I'm unclear on the intended signal path for the throughput test with MAC loopback on the Broadcom side, and reverse loopback on the DP83822.

How is throughput being verified in this case? The Broadcom PHY will immediately loopback the FPGA's packets through the MAC, where the full link path isn't tested. Please correct me if I misunderstood.

Thank you,

Evan

I put in a link to our earlier closed thread: (+) DP83822IF: Talking with another mfg PHY - Interface forum - Interface - TI E2E support forums

Maybe I did this incorrectly.  I configured the DP38322 for reverse loopback.  I also enabled loopback mode on the Broadcom 5241.  The other complicating factor is the FPGA which is running transmitting packets and waiting to receive packets.  Perhaps I should not put the 5241 in loopback?  I think I'll draw a block diagram of this setup.  Sometimes I need a picture.

I think this drawing is accurate.  FPGA generates TXD.  It gets reflected back ultimately to the FPGA as RXD.  That is, when reverse loopback is enabled on the DP83822.  This will not work when the 5241 is in loopback mode.

Thanks for clarifying here. I agree that this config is valid for loopback testing, with just DP83822EVM reverse loopback enabled.

Please let me know the result when testing with just reverse loopback. Is it possible to measure throughput or check if the same packets are returned back to the FPGA?

Thank you,

Evan

When I test with reverse loopback enabled on the EVM, I'm not getting anything coming back to the 5241.  The 5241 is not configured in loopback.  I'm looking at FPGA signals in the Chipscope logic analyzer.  I expect to see data on PHYE_RX_D:

I'm starting to question whether something is wrong with the media converter or I need a crossover cable instead of straight thru.  

Hi Craig,

Where along the signal chain is the data interrupted? Do the packets make it to the input of the DP83822 MAC, and does DP83822 register 0x15 increment in response to receive errors?

Thank you,

Evan

What is the best way to check the signal chain - probe it?  I checked register 0x15 and it is NOT incrementing.  Which means no receive errors but that could be the case also when not receiving data.

Hi Craig,

Probing it is a valid approach. If there is valid data on both TD/RD, and RX_ER is not incrementing, then the MDI-side of DP83822 is valid.

Thank you,

Evan

I decided to probe RX and TX pairs at the extremes first - at the EVM ethernet connector and at the VersaLink POF connector on the BCM5241.  EVM DP83822 is in reverse loopback.  I swept thru the voltage swing levels in register 0x0403.  The scope screenshots all looked the same at each level.  

EVM DP83822 RX pair:

EVM DP83822 TX pair:

Broadcom 5241 RX pair:

Broadcom 5241 TX pair:

It looks like the Broadcom RX is getting idle characters?  This is consistent with what the FPGA is telling me.  RXER = 0 but RXDV = 0.  The FPGA is not receiving any data from the Broadcom PHY.

The EVM appears to be receiving and transmitting (error counter not incrementing).  Makes sense because we put it in reverse loopback mode.

Data is effectively being transmitted from the 5241 to the DP83822 on the EVM and that signal is looped back and goes out the DP83822 transmitter.  But it's not showing up at the Broadcom 5241 receiver.

So the DP83822 understands the 5241 but not the other way around.  Would the next place to look be at the media converter?

Also I've been thinking that maybe there is some incompatibility with the way we configure the Broadcom 5241 PHY.  The comments in this blob of verilog  are accurate.  Does anything jump out at you that could be a problem?

Hi Craig,

Thanks for sharing the detailed explanation and scope-shots. Nothing sticks out to me for the 5241 configuration, this looks correct with the swing level at 1V and forced 100-FX.

Valid data is seen from 5241 -> Media Converter -> DP83822EVM, and DP83822EVM -> Media Converter, but not the last Media Converter -> BCM5241 connection?

It does seem isolated to the media converter in this case, can you share the schematic for this block? I'd like to investigate why the 822's TX data seems to get translated into the idle characters shown on the last scope-shot.

Thank you,

Evan

Thanks for looking over those settings.  I think we are both suspecting a problem with the media converter.  I cannot determine a thing about the media converter I've been using.  None of the markings or codes turn up anything on an internet search.  As a result, I'm doing something I should have done in the first place - buying a media converter kit from Broadcom.  I should get this in a couple of days.  There is a schematic.  And this kit uses the e IC Plus IP113ALF PHY.  Not a Broadcom PHY.  This is an older AVAGO kit.  We ordered two from Mouser and they were not cheap.

Is there anything else I could be doing in the interim?

Hi Craig,

One option is to configure DP83822EVM for a direct Fiber connection to BCM5241, although with the amount of hardware changes this might not be worth the time unless you have multiple 822EVMs to test with:

In the DP83822EVM User's Guide, we have these changes listed along with the DNP'd LVPECL terminations shown in Figure 19. Does this seem like a viable option to work on in parallel with Broadcom's media converter kit?

Thank you,

Evan

I thought about that.  I have two EVMs.  The problem is finding an SFP module that works with the VersaLink connector style.  I'm not sure such a thing exists but I'll do some research.  

I see, thank you for clarifying. I'm also unfamiliar with this VersaLink connector - can you share the media converter schematic from Broadcom so I may review in the meantime while we wait for it to arrive?

Thanks,

Evan

It seems that we chose these connectors to save money on glass fiber which is much more expensive than POF.  But then we have to deal with the consequences of having a single vendor and more expensive transceiver/connector.

Here is schematic of the new media converter:

I follow. Please let me know when you are able to share results when testing with this converter, I do not think there are any productive tests in the meantime without significant HW reworks.

Thanks,

Evan

I agree.  The media converter was delivered late Friday.  I'll have time to dedicate to this on M-W.  I may have some preliminary results early- to mid-week.   Then I'm traveling and back in the office 5/15.  

These results are for the test setup we've been discussing with the DP83822 EVM configured for reverse loopback.  The 5241 board (X187) is transmitting.  The media converter was replaced with the new unit.  I get a solid D100 (TP link/activity).  I get an occasionally weakly flashing D101 (FX link activity).  Quick test using DP83822 on X187 board to connect to media converter.  This caused a much stronger and regular flashing of D101.  Below are some scopeshots for connection with 5241.

FXRD at R112:

FX-TD at R103:

Interesting that one side is about twice the voltage we expected and the other side is half of expected.

Hi Craig,

Thanks for the quick turn-around on these tests. Is this understanding of the two setups correct?

[1] DP83822EVM <-> BCM Converter <-> X187 (inconsistent FX link?)

[2] X187 (DP83822) <-> BCM Converter <-> X187 (consistent FX activity?)

Is the voltage swing more closely following expected LVPECL levels on the second setup?

Thank you,

Evan

The first setup is how it's been for a while but new media converter - inconsistent FX link:

The second setup is plugged into the DP83822 on the X187 also new media converter - consistent FX activity:

My earlier scopeshots are from the first setup.  But, yes, the FX side of the media converter was in line with the PECL voltage swings we measured at the 5241 - almost 2V.

This is great to hear - it seems the terminations between X187 and the EVM are much closer to what's required for the LVPECL fiber connection.

If the setup is meeting the required PECL levels and passing all functional tests (ping, throughput, signal quality, ...), please let me know what else is required to begin a new design revision.

Thank you,

Evan

I think we are heading in the right direction for sure.  However, I still have the problem where I'm not getting thru to the BCOM PHY on the X187.  Here's a fresh shot of BCOM RX:

Here's the shot of media converter FX-TD at R103:

Is it too weak to get thru?

It does look too weak, LVPECL voltage swing is ~800mV.

I'm unsure what termination modifications are required to help improve the amplitude here.

Here is the schematic chunk for the BCOM5241 on X187:

I took my scopeshot - first in the previous post - at R138 and R139.  This is on the LVDS side.  

I took a scopeshot on the PECL side:

Hi Craig,

I need some time to review with team, please expect a follow-up later today.

Thanks,

Evan

Hi Craig,

We can continue this discussion over email or this thread when you are back.

It's still unclear to me what modifications can be made to improve the signal amplitude on the BCM receiver side.

Thank you,

Evan

Hi Evan,

I've been going over results from last week and I'm coming to the same conclusion - that it's a problem with the voltage level at the receive side of the BCM.  We are on the same page.  Are we looking at modifications to R134/135 and/or R138/139?  This would be done in an effort to push up the voltage swing at the receiver? 

Hi Craig,

Yes, I think all four resistors here can be adjusted to tune the receiver swing level. The circuit is not one-to-one with the translation scheme shown in Pericom's LVDS <-> PECL appnote, so some iterations may be required to tune the resistance for an appropriate swing level:

Thank you,

Evan

It's not clear to me which way to go in impedance/resistance to get the desired voltage swing.  But I can modify both X187 boards.  One changing R134/5/6/9 from 130 to 82 ohms and the other from 130 to 180 ohm.  Going 1/3 in either direction ought to be enough to see improvement in one versus the other?

This looks like a good strategy for the first iteration. Do you have access to the IBIS model for SY55857L? Reviewing the datasheet for this translator, I see the X187 board loosely follows the output termination shown:

Is simulation a possible approach here to help reduce iterations?

I'm not able to find a model for this part.  Maybe I can find a model for a similar part that would work.  Probably take me a few days to changeout the resistors.  and I have another task that needs attention.  I expect I'll have some results by later in the week.

Sounds good, please share results when able.

Thanks,

Evan

I found some time to work on this today. 

Changed out R134/5 and R138/9 which were all 130 ohm with 82.5 ohm resistors.  And it looks a lot better.

130 ohm:

82.5 ohm:

And the activity LED on the media converter is stronger.

Also encouraging is that I periodically get RX bits in chipscope.  First time.

How should we proceed from here?  I could try 49.9 ohm for example.

Hi Craig,

This looks good, do you see any difference with functional link/throughput tests for this swing?

If there is still issues with valid throughput, we can try adjusting to 50ohm.

Thank you,

Evan 

Hi Evan,

It appears I made a measurement error.  The shot with 82.5 Ohm showing 919mv.  Not sure if I got my files mixed up or measured at a different node.

I re-measured again today several times and it's more like 250mv:

I modified the other X187 to 39.2 Ohm and the results were worse at about 200 mv:

We originally started at 130 Ohms and we found lower resistance improved the signal.  We also found 82.5 Ohms is marginally better than 39.2 Ohms.  Although 82.5 Ohms does not yet give us the throughput we need. 

Does this mean we are looking for a termination resistance between 82.5 and 130 Ohms?

Can you share the throughput results for different resistor / swing values tested? For the given throughput, are you seeing errors or clean data?

It's not clear to me if the desired termination value is in range [39.2 , 82.5] or [82.5 , 130].

Here is schematic for completeness.  My scope traces below were probed at R138/139.

Both pairs R134/135 and R138/139 were changed in these board modifications.

130 ohm:

Nothing getting thru - idle characters on RX side.

82.5 ohm:

Weak signal getting thru per media converter activity LED.  Intermittent RX data seen in chipscope on FPGA.  RX_ER in chipscope was NOT asserted.  Was also seeing intermittent LED activity on X187 consistent with RX data. 

39.2 ohm:

Weak, intermittent signal getting thru per media converter activity LED.  No RX data seen in chipscope on FPGA.  RX_ER in chipscope was NOT asserted.  No intermittent LED activity on X187 consistent with RX data. 

Somewhere between 82.5 and 130 ohm? 

Thanks for compiling the results altogether for faster review.

I am checking with team to verify the range of values appropriate to try here.

100 ohm termination should increase the swing, could we test this?

It's unclear to me why decreased swing with 82.5ohm termination results in intermittent RX data, while 130ohm has no data pass through.

Assuming we iterate through termination resistors and find an acceptable swing for valid throughput from DP83822 <-> BCM5421, what is the next step on your end for this design? Is this process intended only for proof of concept to function with X187 termination scheme?

Thank you,

Evan

I'll get to the lab as soon as I can and make this modification.  I feel like we are getting close.

This is all part of our investigation into a suitable replacement for the Broadcom 5241.  I expect we will replace with the DP83822IF.  We just need to ensure our designs with 5241 are compatible with DP83822IF because we know we will have a mix of these in the field.  This was the step where we determine WHETHER we can communicate.  The next step is to determine the QUALITY of communication.  I was planning to make use of the BIST function in the DP83822IF.  I can also monitor receive error counts in the FPGA.  We're using the X187 to prototype the design for subsequent use in production.

Thanks for sharing the context.

I also feel we are converging on the termination that will give passable throughput, hopefully without many more iterations.

Hi Evan,

The last experiment with 100 ohm was no better or worse than 39.2 or 82.5 ohm.  I was discussing with a colleague who was confronted with a similar situation a few years ago.  He suggested a level shifter on the RX side of the DP83822IF to get the signal up in the middle of the range it's expecting.  I've pursued this experiment, and the prelim results look promising.  I'll share details when get it working.  The circuit modifications are extensive and there's some challenging soldering.  It's possible we have something by the end of this week.

Hi Craig,

I appreciate the update here, glad to hear the results are positive.

Please let me know if you need further input on any PHY-level tuning during these tests.

Thank you,

Evan