TE0803 LVDS Output

[rkbluecubed]

Hello,

I have been struggling to generate an LVDS output signal from a TE0803-03-3BE11-A module.  I have set up a trivial design example in Vivado 2019.2 consisting of an input clock (1 MHz) driving an output LVDS buffer.  The TE0803 module is installed on a very simple carrier board based on the TEBT0808 project.  The output pins are constrained to what I believe to be an LVDS-capable high performance diff pair.

Some other details about my config:

• Output pin assignments are on Bank 65: IO_L20P_T3L_N2_AD1P_65 and IO_L20N_T3L_N3_AD1N_65
• VCCO on Bank 65 is attached to 1.8V
• VREF (i.e. pin J4-15 on the TE0803) is floating.  Not ideal, but I don't think a connection is required for output LVDS.
• The diff pair is terminated into a 100 ohm resistor

My RTL is:

Code: [Select]

module top(
    input refclk,
    output data_i_p,
    output data_i_n
    );
   
OBUFDS OBUFDS_inst (.O(data_i_p),
                    .OB(data_i_n),
                    .I(refclk)
);   
   
endmodule

My constraints are:

Code: [Select]

# Reference clock input (10 MHz):
#   TP77, J4-67, Global Clock, L3
set_property PACKAGE_PIN L3  [get_ports refclk];
set_property IOSTANDARD LVCMOS18 [get_ports refclk];

# Timing constraint set to 50 MHz (20 ns) so we can clock higher than 10M if we want.
create_clock -period 20.0 -name refclk_50MHz [get_ports refclk]

# I-channel output data
set_property PACKAGE_PIN J6  [get_ports data_i_p];   # TP60, J4-17,
set_property IOSTANDARD LVDS [get_ports data_i_p];
set_property IOSTANDARD LVDS [get_ports data_i_n];

I don't see any problematic warnings or errors during the build.

Yet here is the problem, the output signal is clearly not a well-formed LVDS signal.  The attached screenshot shows the P and N sides of the signal.  The vertical scales are matched, and the "ground point" of the two traces is overlapping.  Note that the signals are not moving in opposition to one another.  Also the common mode voltage is out of spec.

Scope screenshot: https://imgur.com/a/KKgqMSB
Implementation schematic: https://imgur.com/a/GKnGdsx

I must be missing something very simple here.  Any tips would be appreciated.

[JH]

Hi, which carrier did you use?
Which voltage did you set for the variable bank power?
Which external  termination did you add?
br
John

[rkbluecubed]

I am using my own slightly customized version of the TEBT0808.  The pinout on J4 has very few changes as compared to the regular Trenz TEBT0808.  Attached is a screenshot of my schematic page for J4.  VCCO for bank 65 is wired to PL_1V8. A 100 ohm differential term (shown as R99 on the schematic) was added across the LVDS output that I am measuring with the scope.  VREF_65 is floating, but I think that is OK in this case.

[JH]

Hi,

VREF (i.e. pin J4-15 on the TE0803) is floating.

That's no matter for LVDS
J6/H6 is also OK for B2B J4-17/19

IO Standard setup also, see: https://www.xilinx.com/support/documentation/user_guides/ug571-ultrascale-selectio.pdf

Maybe you has some bad contact? Do you have some other IOs where you can test LVDS?

Did you supply anything else with PL_1V8?


br
John

[Vadim Yunitski]

deleted

[Antti Lukats]

I am using my own slightly customized version of the TEBT0808.  The pinout on J4 has very few changes as compared to the regular Trenz TEBT0808.  Attached is a screenshot of my schematic page for J4.  VCCO for bank 65 is wired to PL_1V8. A 100 ohm differential term (shown as R99 on the schematic) was added across the LVDS output that I am measuring with the scope.  VREF_65 is floating, but I think that is OK in this case.

try to use single ended first to check that your clock signal is passing, then change to lvds,

from your description we really do not see why you have a problem seeing lvds signal

[Andrei Errapart]

I am as intrigued as anybody here.

Something simple could be one of the following:
1) What is the result of electrical check? Vias? Any shorts with a neighbouring pin (or pins)?
2) Can you check whether you have configured the FPGA with the right bitstream?
3) Cross-check - Are the waveforms on other pins as expected?

[rkbluecubed]

Ok, thanks for your patience while I collected some more observations on this problem.

Here's what I have accomplished since my last update:

• Reconfirmed (buzzed out) connectivity on my carrier board.  All looks good on that front.
• Built a custom image that drives LVCMOS18 rather than LVDS on the problematic pins on Bank 65. When I load this on the board I can see that the N side of the lane is failing to meet its output voltage specification.  P side looks good.  Attached is a scope screenshot of the LVCMOS18 outputs into an open. Note that these are the unloaded signals (Hi-Z scope input), V_OH,min is violating spec, V_OL,max is barely meeting spec even with no load.
• I removed the SOM from my carrier and replaced it with a second SOM that I have on hand.  This one shows the expected output voltage levels for the LVCMOS18 signals.
• I reverted back to the LVDS image on the second SOM and those also look just fine.  1.25 V common mode, and maybe 500 mVpp on each side.
• I went back to my first SOM, the one with the output problems, and loaded a new image that also drives the same signal out of an adjacent bank (Bank 64).  This bank is able to produce LVCMOS18-compliant output.

So I can conclude that one of my SOMs is damaged.  Certainly two diff pairs on Bank 65, possibly the entire bank.  Unfortunately it's not easy for me to access additional nets to assess further.

I am very confused as to how the bank became damaged.  The SOM was brand new as of last week and was installed on a known-good carrier board.  ESD precautions have been followed.  The signals in my design on Bank 65 consist of two LVDS outputs, one LVCMOS18 output and two LVCMOS18 inputs. These were the only signals connected to another piece of equipment, which has been interfaced with numerous FPGAs on other projects. I completed a quick "safe to mate" check on that interface to look for unexpected voltages but none were found.

Experience tells me that a fresh-from-factory chip such as the Zynq found on this SOM are rarely defective.  So the mystery as to how I got to this state remains.

I would be curious to learn if Trenz performs JTAG testing as part of PCBA validation?  If so, is there coverage of the IO pins accessible on J4?

[JH]

Hi,
we use boundary scan to test IOs on this series, maybe this pin went through the test, since it does not seem to be completely "dead". But the exact reason is difficult to say from a distance.

Can you send me the serial number of your failing module to "support@trenz-electronic.de".

br
John