FPGA on-die LVDS termination issues
in [FPGA]
|
Prev: floating point operation in interrupt handler on ML403
Next: Problem with Black Box in VHDL in ISE 11.2 :: ERROR:NgdBuild:604
From: dc207 on 13 Oct 2009 08:15 Hello, We use several source-synchronous LVDS-based interfaces in several PCB designs, such as a unidirectional interface from several multi-channel ADC devices (TI ADS725x) towards FPGA (Xilinx Virtex4 family, SX subfamily), or a full-duplex interface between high-end DSP devices (ADI ADSP-TS201S) and FPGA (Xilinx Virtex4 family, FX subfamily). In both mentioned cases, we use on-die LVDS termination on the FPGA side, e.g. the LVDS receiver side. The used I/O standard is LVDS25, with the attribute DIFF_TERM set to TRUE. In both cases, the (data)bitrate is about 500 MHz, both using DDR techniques, e.g. the clock-rate is half of this (250 MHz). The data-clock provided by the ADCs to FPGAs has a continous nature, the data-clock provided by the DSPs to the FPGAs is non-continuous, e.g. only active when there are databits (1 or 4 bits) to be transmitted, else in an idle state. In all cases, we have performed SI simulations with IBIS models provided by the vendors (TI/ADI/Xilinx), and the exact transmission line details extracted from our PCB layout, e.g. microstrip/vias/stripline, etc. Of course, the nets have been routed according to the requirements, e.g. with correct differential impedance, matched lengths, etc. etc. SI simulation was succesful, simulated eye-diagrams etc. were OK. Note: the on-die termination resistor (100 ohm) was not included in the IBIS model of the Xilinx LVDS receiver, and needed to be added manually. Based on the good simulation results and the overall lack of available PCB area, we decided to use on-die termination. On the physical target boards however, we encountered difficulties on these LVDS interfaces, and the measured signals do not look good at all. In the time-domain, we are measuring (with Lecroy SDA) RC-like curves on the (data)signals, when they have been stable (either 0 or 1) for a while and when they start switching again (to 1 or 0 respectively). We are aware that the 100 ohm on-die termination "resistor" is in reality not a physical resistor between the P- and N terminal(s) of the LVDS pair(s), at least not in case of FPGA devices. In reality, both terminals have a Thevenin-equivalent circuit, each consisting of two other "resistors", one from the terminal upto the I/O supply voltage, and another downto ground. In reality, these "resistors" are one or more FETs, switched on/off by the FPGA configuration bitstream to achieve the right termination scheme for the chosen I/O standard. We are almost running out of things we can still check, e.g. all FPGA connections, power supply/integrity, decoupling, trace impedances, FPGA configuration, etc. etc. The FPGA vendor is involved since several weeks now, but they seem to be as flabbergasted by our observations as we are ourselves.... ;-) My questions are: - does anybody as a user of FPGA devices (or LVDS in general) recognize the observations mentioned above, preferably from own experience/measurements? - are the assumptions regarding the internal FPGA termination circuits correct? - can it be than any non-linearity of the Thevenin FETs causes these problems? - any other brilliant ideas, hints, etc. Any help is welcome. Best regards, Jaap
From: austin on 13 Oct 2009 10:45 Jaap, The waveforms will look different at any point OTHER than across the termination. You can see this for yourself in the simulation, by placing the package element in the simulation (i.e. two short -- 10-20mm t-lines before the termination and IO pin loading model). If you have already done this, then you are aware of where you look influences what you see. Looking directly across the termination is what the receiver sees, so that is what matters. The termination is not a carbon resistor, but it is as good as one when it comes to looking like a resistor, so that is not the issue. Often, the attribute is not set properly, and the resistor is not enabled. Have you checked in FPGA_editor, and do you clearly see the resistor termination enabled? Does the receive voltage appear twice as high as it is indicated in the simulation? (clearly indicating the resistor is not enabled) You do not mention the problem: bad data, occasional incorrect data, bad data when other IOs switch only, etc. As a customer, the magic words are "lines down." If you say this, the case MUST be escalated. If unresolved, it must be escalated again and again, until it gets to the "Fire Marshall" who reports to the Senior VP and CEO on unresolved cases, and their status. Since I invented, implemented, this system, and was the first Fire Marshall, I am very familiar with the system, and it works really well -- use it! A case number is very useful: if you email it to me, I can check on its status, and help get it escalated.
From: Symon on 13 Oct 2009 11:10 Jaap, You can't just probe in the middle of the trace and expect to see on your 'scope what the receiver sees. The 'scope will introduce an impedance discontinuity. What probe are you using? This is particularly the case with FPGAs; the Xilinx Virtex 4 has about 10pF of input capacitance per pin which is produced by all those other IOBs configuration options, specifically 24mA output FETs. High speed signals hit those 'caps' and reflect back. If you really want to probe the signals, you could add an attenuator to your design. So, is it working or not. You don't seem to describe your problem except the signal doesn't look good on your 'scope. HTH., Syms. p.s. Brian Davis posted on CAF about using attenuators for probing, you might be able to google for it.
From: dc207 on 13 Oct 2009 15:10 >Jaap, > >The waveforms will look different at any point OTHER than across the >termination. > >You can see this for yourself in the simulation, by placing the >package element in the simulation (i.e. two short -- 10-20mm t-lines >before the termination and IO pin loading model). > >If you have already done this, then you are aware of where you look >influences what you see. > >Looking directly across the termination is what the receiver sees, so >that is what matters. OK, clear from a simulation point of view. We are measuring as close as possible to the receiver e.g. the termination, but this is not always possible, due to the location of via's (micro-strip to stripline and v.v.), which may not always be as close to the termination as you would like them to be. Anyhow, what we see is not a "normal" reflection, but a RC-curve on top of the reflection. This RC-curve is "killing", the reflection itself is more or less as expected. If we manually place a 100 ohm resistor on the board, and disable the on-die termination, the RC-curve has disappeared, and the signal looks as neat as you can possibly expect. In this case, the reflection is there but very OK, and the eye-diagram is well open. The problem is that we need about 40 of these extra 100 ohm resistors, on a board which is already loaded.... > >The termination is not a carbon resistor, but it is as good as one >when it comes to looking like a resistor, so that is not the issue. >Often, the attribute is not set properly, and the resistor is not >enabled. Have you checked in FPGA_editor, and do you clearly see the >resistor termination enabled? Yes, we did this check, the attribute was set both in the VHDL as in the UCF, and we checked the results using the FPGA Editor, and the pinning file. >Does the receive voltage appear twice >as high as it is indicated in the simulation? (clearly indicating the >resistor is not enabled) > >You do not mention the problem: bad data, occasional incorrect data, >bad data when other IOs switch only, etc. Basically all of the items mentioned above. Bad data could be the result of many issues (internal FPGA I/O timing, SSN, clock jitter requirements, etc.). We are trying to eliminate them one by one, to narrow down on the real cause(s). > >As a customer, the magic words are "lines down." If you say this, the >case MUST be escalated. If unresolved, it must be escalated again and >again, until it gets to the "Fire Marshall" who reports to the Senior >VP and CEO on unresolved cases, and their status. > >Since I invented, implemented, this system, and was the first Fire >Marshall, I am very familiar with the system, and it works really well >-- use it! > >A case number is very useful: if you email it to me, I can check on >its status, and help get it escalated. OK, thanks. As I said, Xilinx is already involved, a RMA procedure was started but temporary halted on our request because we needed more time to do our homework. Until now, we haven't been able to find anything that we have done wrong ourselves. Today, I have been working with some collegues to connect a DSP evaluation board (ADI EZ-Lite TS201) with LVDS-based DSP Link Ports direcly to a FPGA evaluation board (Xilinx ML403), e.g. without any hardware being designed by ourselves (only interconnect consisting of two RJ45/UTP cables). The FPGA only will contain a loopback (TX to RX and v.v.), elimination any possible internal timing issues. If we encounter the same RC-curves on this design, we can stop our attempts to find the error in our own designs (PCB/board/FPGA), and redesign/relayout all our boards, which will be extremly costly and also time consuming. We have already started these redesigns (in parralel), to reduce leadtime and risk. We are finishing a report on our measurements, simulations, etc this week, and we will forward it to our Xilinx representatives. > > --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.com
From: dc207 on 13 Oct 2009 15:20
>Jaap, > >You can't just probe in the middle of the trace and expect to see on >your 'scope what the receiver sees. The 'scope will introduce an >impedance discontinuity. What probe are you using? We are aware of that. It is impossible to probe at the ideal location, due to the layout, vias positions, etc. We are using a LeCroy SDA 6000A with a D600A differential probe. I believe these devices suitable (if not over-qualified) for these measurements.... ;-) > >This is particularly the case with FPGAs; the Xilinx Virtex 4 has about >10pF of input capacitance per pin which is produced by all those other >IOBs configuration options, specifically 24mA output FETs. High speed >signals hit those 'caps' and reflect back. Is this 10 pF input capacitance per pin based on having on-die termination enabled, disabled or perhaps both? > >If you really want to probe the signals, you could add an attenuator to >your design. So, is it working or not. You don't seem to describe your >problem except the signal doesn't look good on your 'scope. The problem is bad/corrupted data (occasionally), for more details see my follow-up to the Austin in this same thread. > >HTH., Syms. > >p.s. Brian Davis posted on CAF about using attenuators for probing, you >might be able to google for it. OK, thanks, we will do that. > > > --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.com |