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: Brian Drummond on 13 Oct 2009 19:12 On Tue, 13 Oct 2009 14:10:34 -0500, "dc207" <jaap.mol(a)planet.nl> wrote: >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. .... but do the data errors disappear? I may have a suspicious mind but it looks possible that the visible reflections are a red herring, and the internal termination works just fine ... but something else is causing data corruption. The best time to discover that is _not_ when you get the revised board layout back... - Brian
From: Symon on 13 Oct 2009 19:55 dc207 wrote: >> 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 Hi Jaap, OK, it sounds like you are more than a little experienced at this, apologies for teaching you to suck eggs with your probing! Also, apologies in advance if the following is all obvious! So, each pin has 10pF loading on it no matter what the IOB is set up for. Every single mode. There are a bunch of FET's connected to the signal to drive signals out if required by the configuration loaded into the device. Even if these are turned off, for example when the pin is an input, the capacitance is still there. It is the capacitance of the FETs' structure. Look at a datasheet for a discrete FET to see why this is. This should be modelled in the IBIS file. You could try simulating with the IBIS model replaced by a 10pF cap to ground, along with the 100 ohm resistive termination between pins. If this sim looks the 'scope picture, maybe the IBIS model isn't accurate, but I doubt this. FWIW, I've used the on chip termination for Virtex 4 FX devices many, many times without problems, within these limits:- < 667MBps data rate < 6 inches trace length. How good are your power supplies? Are your pairs tightly coupled? Are they routed away from any crosstalk hazards? Are the pairs routed on a layer next to a ground plane? Do they swap layers a lot? HTH, Symon.
From: austin on 14 Oct 2009 10:57 Jaap, An RMA is NOT the right way to go. Often people request an RMA when it is a technical problem, not an issue of wanting to return a part for failure analysis. GET OUT OF THE RMA queue, and get into the "solve the problem" queue by entering a webcase. We can't help you if you ask us to do the wrong things. RMA process is to find a supposed fault on a part. Given that faults on V5 parts are running less than 1 ppm right now, unless this is just one part with this problem, and you are sure that it is bad, do not request an RMA. Different people, different skills: they can not find the problem on your board, nor do they even know how to. Email me at austin(a)xilinx.com with the details (company, names, any case numbers) and I will help get this properly assigned. If you are in the RMA queue, I doubt that you will get any resolution until they reassign this to the right people. You never answered if the voltage swing is the same with the resistor, and also with the LVDS termination. You also never answered if you did the simulation of the resistor at the receiver, or 19-20mm away from the receiver (always observing 10-20mm away from the receiver). It could be you are just chasing this small reflection, that isn't the problem at all!
From: dc207 on 14 Oct 2009 16:35 >On Tue, 13 Oct 2009 14:10:34 -0500, "dc207" <jaap.mol(a)planet.nl> wrote: > > >>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. > >... but do the data errors disappear? Yes, the data errors disappear like "snow in the sun" with the external (on-board) termination resistor.... > >I may have a suspicious mind but it looks possible that the visible reflections >are a red herring, and the internal termination works just fine ... but >something else is causing data corruption. Today, we managed to get the ADI TS201 EZ-lite DSP eval board connected to the Xilinx ML403 board running without data errors, using the LVDS-based DSP Link Port, two RJ45/UTP cable to interconnect the DSP to the FPGA, and a simple loopback implemented in the Virtex4 (FX) FPGA. This is a confirmation that we are doing something wrong, but we have (re)verified so many possible causes already, and are running out of options. Tomorrow we will be testing a completly stripped-down FPGA, e.g. only with loopbacks implemented on multiple DSP Link Ports and absolutelly nothing else. As if we were connecting 6 UTP loopback cables to each DSP Link Port... We will see what will we measure. Meanwhile, somebody is performing Power Integrity simulations (Hyperlynx PI) on our PCB design, but until now the tool crashes due to shortage of memory, e.g. the design seems too big even for high-end (memory-rich) PC platforms (?). Sending the design to Mentor requires a signed NDA, which will probably take weeks to complete (based on our experiences with several NDA contracts)... ;-( > >The best time to discover that is _not_ when you get the revised board layout >back... > >- Brian > > --------------------------------------- This message was sent using the comp.arch.fpga web interface on http://www.FPGARelated.com
From: -jg on 14 Oct 2009 19:24
On Oct 15, 9:35 am, "dc207" <jaap....(a)planet.nl> wrote: > >... but do the data errors disappear? > > Yes, the data errors disappear like "snow in the sun" with the external > (on-board) termination resistor.... > What is the time-constant of the RC effect, and final peak/DC amplitudes ? Can you reproduce that same waveform and ~error rates with a deliberately incorrect termination ?. With multiple channels, you could run some external, some internal term, and a couple of 'experimental' ones that you tune to degrade the error rate to around the failing ones. That gives a feel for just how far off it needs to be to spawn the errors. -jg |