DisplayPort TX subsystem AUX channel influencing other LVDS signals

[davlag-prodrive]

Hi,

Our custom board uses XC7Z035-2FFG676E, with the following interfaces:

• 1x DisplayPort dual lane output (DP_SRC0) using DisplayPort TX subsystem
• 1x DisplayPort(++) quad lane output (DP_SRC1) using DisplayPort TX subsystem

During qualification it appeared that;

• When the bi-direction AUX channel of DP_SRC0 is used, a clock output at the same bank is influenced by it. The clock input which uses this clock loses lock at that time, which makes the clock unusable.
• For the AUX channel we use the LVDS bi-directional I/O of the Xilinx DisplayPort TX subsystem.

After performing measurements at the relevant signals it looks like the AUX channel interface is influencing the output clock signals when switching input/output direction.

See measurements below.

Note that the AUX signals and DP++ clock outputs share the same FPGA bank and voltage rail. Although during measurement the voltage rail does not show any drop. See schematics part on the bottom of this document.

Questions:

• Is it possible/expected that the AUX channel driver/receiver has influence on the clock output at the same bank?
• Is there internally in the FPGA a common interface (e.g. reference voltage or LDO) which is shared between LVDS configured I/Os at the same bank?
• Are there possibilities to change or improve anything on the AUX channel either in FW or in HW?

Thanks in advance!

DP_SRC0_AUX_vs_CLK_SRC1_DP++DP_SRC0_AUX_vs_CLK_SRC1_DP++_zoom_outCLK_SRC1_DP++_p_vs_CLK_SRC1_DP++_nCLK_SRC1_DP++_p_vs_+2V5_supplyCLK_SRC1_DP++_p_vs_XGBE0_TX_ACTDP_SRC0_AUX_p_vs_n_vs_CLK_SRC1_DP++Schematics part

[florentw]

Hi @davlag-prodrive 

This is not a behaviour I would expext. I looks like a SSN issue.

You might want to ask your FAE run a review of the PCB, make sure you are following the PCB guidelines. Make sure the termination of the AUX line is correct.

You might want to check on a Xilinx evaluation board, I do not think you will see the same behaviour.

Regards

[davlag-prodrive]

Hi Florent,

What do you mean with 'SSN'?

We removed the external connection from the AUX channel and even when there was nothing attached the FPGA pins the AUX data was visible at the other clock output.

It might be hard to reproduce at the reference design since we need an additional clock output on the same FPGA bank at which we can measure. Besides that the reference design has DisplayPort connected to the HP 1V8/2V5 bank instead of HD 2V5. Is it correct that the evaluation board by default uses the single ended AUX implementation as well?

I will ask our FAE to review the PCB design anyway.

Thanks!

Regards,

Dave

[florentw]

Hi @davlag-prodrive 

My colleague @klumsde  might be able to give more detail about the SSN.

From what remains from my knowledge from college is that if the termination is not correct you can have the signal propagated on a parallel line.

The example design is indeed using single ended AUX implementation but both options should be available on the FMC card.

Regards

[davlag-prodrive]

Hi Florent,

Thanks!

I understand that you are referring to crosstalk related issues. Since we were also afraid of that we disconnected the AUX channel by removing the AC coupling. To isolate the FPGA pins from the rest of the board. Still the influences where visible.

I notice that the FMC card DP source uses AC termination (49.9R + 100nF/10uF) together with a voltage divider (3.3*(1.5k/3.99k)= 1.24V (half of 2.5V) at the AUX channel. Is this termination scheme required for proper functioning when using the LVDS I/O for the AUX channel?

Regards,

Dave

[florentw]

Hi @davlag-prodrive 

Xilinx recommends that you follow the FMC card as it was validated in compliance testing.

I believe you description of the termination is correct. This should be following the section 3.4 of the DP1.2 spec which requires a 50 ohm termination (on both ends).

And the peak to peak voltage should be between 0.29V and 1.38V, thus the voltage divider

[davlag-prodrive]

Hi Florent,

The 50R both ends is available in the FPGA since it terminates to 100R differential and provides its own voltage divider when enabled. As I understand internal termination can not be used in this case and FMC card proposal should be followed?

I will rework our board with this termination and divider anyway, I agree it could make a difference to the behavior when switching AUX from input to output.

Thanks for the help, I will let you know the outcome.

Regards,

Dave

[davlag-prodrive]

Hi Florent,

In the mean time I have reworked our board with the exact termination as used on the FMC board.

I measured the signals again and it appears that applying the termination externally, instead of using the internal termination, does not make any difference.

The AUX channel still seems to influence the output clock the same way as before.

Regards,

Dave

[watari]

Hi @davlag-prodrive 

Did you follow clearance rule on PCB ?

Best regards,

[davlag-prodrive]

We were able to reproduce it at multiple boards which are routed entirely different due to use 900 pins vs. 676 pins packages.

Board 1: Differential to differential spacing of AUX / clock traces is ~5 times the trace width for these signals.

Board 2: No AUX / clock traces are routed horizontically or vertically in parallel.

Both boards show the same sympthoms.

Regards,

Dave

[florentw]

HI @davlag-prodrive 

Can you run a DRC repport (Reports > Report DRC) and share the result?

You migth want to check if the device you are using can do a SSN repport as per UG899 p78

In general, I would recommend to go through UG899 and see if anything can help

Regards

[davlag-prodrive]

Hi Florent,

We have performed this SSN report, however it does not tell us a lot about the bank we are looking at.

For most signals the margin seems calculated, however for bank 13 all results are 80.1% margin.

See results below:

Created on: Tue Nov 19 11:54:05 2019
Results Name: ssn_1
Project Family: Zynq-7000
Project Part: xc7z035ffg676
Temperature Grade: commercial
SSN Data Version: Production
Package Version: FINAL 2012-10-23

Status: Full Analysis;Passed
Messages:

• 0 critical warning(s)
• 0 warning(s)
• 2 info(s)

Name Port I/O Std Vcco Slew Drive Strength (mA) Off-Chip Termination Remaining Margin (%) Notes Phases (Group:Period (ns):Shift (degree):Duty (%))

AE25	CLK_GTXREF_p	LVDS_25	2.5			FD_100	80.1		bd_avo_2dp_4k_design/c_vidout_dp1/CHECK_DVI_Capable.c_refclk_gen/inst/CLK_CORE_DRP_I/clk_inst/mmcm_adv_inst:6.734:0:50
AE26	CLK_GTXREF_n	LVDS_25	2.5			FD_100	80.1		bd_avo_2dp_4k_design/c_vidout_dp1/CHECK_DVI_Capable.c_refclk_gen/inst/CLK_CORE_DRP_I/clk_inst/mmcm_adv_inst:6.734:0:50
AD25	DP_SRC0_AUX_p	LVDS_25	2.5			FD_100	80.1
AD26	DP_SRC0_AUX_n	LVDS_25	2.5			FD_100	80.1
AA25	DP_SRC1_AUX_p	LVDS_25	2.5			FD_100	80.1
AB25	DP_SRC1_AUX_n	LVDS_25	2.5			FD_100	80.1

[florentw]

Hi @davlag-prodrive

That looks great. Do you have also the report DRC as well? 

[davlag-prodrive]

Hi Florent,

Yes, I have added it to the post.

We noticed this warning:

LVDS-1#1 Warning
Bidirection LVDS IOs 
The following port(s) use the LVDS_25 I/O standard and have bi-directional differential usage. Please note that LVDS_25 is a fixed impedance structure optimized to 100ohm differential. This is only intended to be used in point-to-point transmissions that do not have turn around timing requirements. If the intended usage is a bus structure, please use BLVDS/BLVDS_25, instead. DP_SRC0_AUX_n, DP_SRC0_AUX_p, DP_SRC1_AUX_n, DP_SRC1_AUX_p.
Related violations: <none>

Should we use this BLVDS_25 I/O standard instead, for our AUX topology (which is actual bi-directional poin-to-point and not a bus)?

[davlag-prodrive]

Hi Florent,

In the meantime we tested the AUX channel with a BLVDS_25, this fixes the issue. Influence is no longer seen and functionally the interfaces work.

When looking further into the BLVDS_25 transmitters, according to the documentation this requires a certain termination scheme.

As defined in UG471_7Series_SelectIO (v1.10), page 96.

Ofcourse this termination scheme is not on our board since we were planning to use LVDS_25 (as suggested by the DisplayPort reference design) for this signal.

However, since we have a functional solution now;

• Is is allowed to use BLVDS_25 for this AUX signal?
• Is the termination required for the output driver, or can internal termination (100R only, on both TX and RX) be used as well?

Thanks!

BLVDS transmitter termination

[florentw]

Hi @davlag-prodrive 

I am not sure if you can use BLVDS. I believe there was some caracterizations done and use LVDS because we found that BLVDS swing is marginally higher than recommended DP specification. So I am not sure if this will be fully compliant with the DP spec.

Maybe you should consider using unidirectional AUX in the Dp configuration and do the IO buffer externally.

I do not know if the internal termination could be used

[davlag-prodrive]

You are correct. The output swing of the BLVDS_25 buffer is way too large to meet DisplayPort compliance eye of the AUX channel.

So, that is not a fix we can implement.

Using the external AUX buffer solution is not preferred since it would mean a change to the hardware. I would expect the differential AUX buffer in the FPGA should be able to function correctly without influencing any other signals at the FPGA bank.

[florentw]

HI @davlag-prodrive 

I need to check with my colleagues from the silicon team is anything can be done with LVDS signals. I will get back to you once I have some details

[florentw]

Hi @davlag-prodrive 

Sorry about the delay. We are still looking into this but for the moment we are failing to understand why using BLVDS will resuce the SSN.

What was the DIFF_TERM setting for the IOs in both senario?

[davlag-prodrive]

Hi Florent,

No problem, for now we made a workaround (generating the output clock with a different device) which works for our application, so for us it is not time critical.

The DIFF_TERM setting is in both scenario's enabled. Since we have no external differential termination placed.

[bartvandongen]

hello @florentw ,

Do you have an update on this?

The workaround we have implemented now in hardware adds cost per unit, so although not time critical we would like to have the problem solved.

[sandrao]

Hi @bartvandongen 

After talking with Florent I tried some hardware testing here and I cannot reproduce the issue. However my setup does not have the biasing circuit that Aux channel has. I will do some more investigating to try to figure out why you are seeing this behaviour.

[sandrao]

For the rest of the Community to be aware we have now published an AR to explain the behavior that was seen here :https://www.xilinx.com/support/answers/61417.html