FPGARelated.com
Forums

LVDS termination scheme to nonstandard ribbon cable

Started by Unknown May 24, 2007
Thanks guys for all your comments.
I have been away on an urgent business trip, so I have not been able
to watch the replies before now.

Below are answers for posts that I find I could reply back to and in
the same order as the postings.

Symon:
Yes the impedance is high (if the supplier given numbers for
unbalanced and balanced impedance apply).
It is a 0.50 pitch flexible flat cable used in the configuration
GPNGPNG where P is positive part and N inverted signal.

John H:
Your solution looks promising and to some degree as my first mock-up
trial.
The reduced swing should not be a problem, as long as it does not
alter the signal to much to my low-speed application.

Austin:
You are right. But it should also be possible to do without in a low
speed LVDS scenario.
And we are looking into buying Hyperlynx....But the SI's weak point is
that you should know the correct properties of your whole path.
Thanks for your comment regarding the transmitter matching.
I have requested a Hyperlynx eval license, then it is just the whether
I am able to use it straightaway to simulate LVDS pairs:-)
And as the others said earlier, I wanted some feedback before trying
Hyperlynx, since I would need an idea of what to simulate, since
Xilinx only mention the need for Receiver diff termination.

Thanks again for all of your.

Stefan,

You are welcome.

Out of the box evaluation version may not have all the features, but it
will be useful.  What is included: some ribbon cables, coax, etc.  PCB
trace configurations for stripline, micro-strip, etc.  Connectors.  The
linsim package will extract from layout to check that your PCB is OK
before you fabricate it.

Slow enough speed, and SI is pretty much a "don't care" except for
things like SSO (which LVDS has no restrictions on).

Austin

stefan.elmsted@gmail.com wrote:
> Thanks guys for all your comments. > I have been away on an urgent business trip, so I have not been able > to watch the replies before now. > > Below are answers for posts that I find I could reply back to and in > the same order as the postings. > > Symon: > Yes the impedance is high (if the supplier given numbers for > unbalanced and balanced impedance apply). > It is a 0.50 pitch flexible flat cable used in the configuration > GPNGPNG where P is positive part and N inverted signal. > > John H: > Your solution looks promising and to some degree as my first mock-up > trial. > The reduced swing should not be a problem, as long as it does not > alter the signal to much to my low-speed application. > > Austin: > You are right. But it should also be possible to do without in a low > speed LVDS scenario. > And we are looking into buying Hyperlynx....But the SI's weak point is > that you should know the correct properties of your whole path. > Thanks for your comment regarding the transmitter matching. > I have requested a Hyperlynx eval license, then it is just the whether > I am able to use it straightaway to simulate LVDS pairs:-) > And as the others said earlier, I wanted some feedback before trying > Hyperlynx, since I would need an idea of what to simulate, since > Xilinx only mention the need for Receiver diff termination. > > Thanks again for all of your. >
John_H wrote:
> > If it's important to not have reflections, the R-only equivalent > termination is superb. > > If it's important to have the high slew rate, the standard > termination with the associated pin capacitance is the way to go > because the reflection *will* be absorbed by the transmitter's > impedance if it's properly matched. >
As an aside, if you're feeling bold, and have board space to spare, a T-coil termination network theoretically could both peak the load AND terminate the line all in one fell swoop. I posted about this on the si-list last year, and one of the Teraspeed guys provided some more T-coil references: http://www.freelists.org/archives/si-list/03-2006/msg00153.html http://www.freelists.org/archives/si-list/03-2006/msg00162.html I've considered this impractical at the board level with wide LVDS buses, but the T-coil papers make for fun reading nonetheless!
> > If it's important to have the high slew rate, the standard > termination with the associated pin capacitance is the way to go > because the reflection *will* be absorbed by the transmitter's > impedance if it's properly matched. >
At the 1 Gbps rates claimed by Xilinx, the typical Rx Cin of ~10 pf (single ended) [Note 1] often presents difficulties that need to be addressed during the board design phase, particularly when using fast drivers from other logic families. IIRC, the 500 Mbps 1995 ANSI LVDS spec called out: output swing: 250 mV min differential source impedance: 40-140 ohm single ended termination impedance: 90-110 ohms differential driver rise/fall time: 300 ps min, 500 ps max Even within the range of allowed values for this old, slow spec, a 300 ps edge WILL reflect off of the 10 pF Cin (single ended) of a Xilinx pin, and then subsequently re-reflect off any 80-280 ohm (differential) impedance mismatch at the driver. Later, faster specs such as HyperTransport tighten these requirements even more to help deal with the faster edges of a 1 Gbps driver. Despite newsgroup claims that Xilinx parts "meet all specs and standards", they do not in fact meet many of the Cin, Rdiff, rise/fall, and even Vod (in S3) of the relevant standards for the claimed input data rates. Xilinx _DT input terminations are 100 ohm +/-20%, or worse, depending upon family and common mode input voltage [Note 2]. Brian Note 1: Cin (single ended) vs. Cin (differential) If the input signal is perfectly differential, the reflections will be IDENTICAL regardless of whether input C is modeled as two 10 pf shunt Cin (as specified in both the datasheet and the IBIS models) or as one 5 pf Cdiff. Calling it 5 pF doesn't make the parts work any better. If the input signal is NOT perfectly differential, the 10 + 10 = 5 simplification does not apply. Note 2: The _DT terminators seem to be implemented using FETs, producing a bowed termination curve that is near 100 ohms only when Vicm is somewhere near the output driver's specified Vocm. The actual Rdt value varies family to family, and changes with VCCO and Vicm. Measurements of a sample-of-one FX12 LVDS_25_DT, at nominal 2.5V VCCO supply, at room temp: Vicm Rdt ----------------------- 0.50 V ~ 74 ohms 0.75 V ~ 78 ohms 1.00 V ~ 94 ohms 1.25 V ~ 125 ohms 1.50 V ~ 157 ohms using a 7CT1N curve tracer with two 100 ohm series R's to reduce Vdiff to about Vin/3 Sweeping Vin 0-3V => Vicm 0-1.5V : : 7CT1N + ----/\/\----- : 100 | : / : Vin \ Rdt : / : | : 7CT1N - ----/\/\----- : 100
Forgive the top posting, please.

Brian, I always appreciate a well-considered discussion and hope to look 
at the T-coil references.  Beyond these references I don't know that the 
rest of the discussion does much more than stir the bees nest though I 
do also appreciate the perspective from the curve tracer.

Austin, I'm sure you want to retort.  Could you let this one go by 
without a response?  It's feeling old.

- John_H


Brian Davis wrote:
> John_H wrote: >> If it's important to not have reflections, the R-only equivalent >> termination is superb. >> >> If it's important to have the high slew rate, the standard >> termination with the associated pin capacitance is the way to go >> because the reflection *will* be absorbed by the transmitter's >> impedance if it's properly matched. >> > As an aside, if you're feeling bold, and have board space to spare, > a T-coil termination network theoretically could both peak the load > AND terminate the line all in one fell swoop. > > I posted about this on the si-list last year, and one of the > Teraspeed guys provided some more T-coil references: > > http://www.freelists.org/archives/si-list/03-2006/msg00153.html > http://www.freelists.org/archives/si-list/03-2006/msg00162.html > > I've considered this impractical at the board level with wide > LVDS buses, but the T-coil papers make for fun reading nonetheless! > >> If it's important to have the high slew rate, the standard >> termination with the associated pin capacitance is the way to go >> because the reflection *will* be absorbed by the transmitter's >> impedance if it's properly matched. >> > At the 1 Gbps rates claimed by Xilinx, the typical Rx Cin of > ~10 pf (single ended) [Note 1] often presents difficulties that > need to be addressed during the board design phase, particularly > when using fast drivers from other logic families. > > IIRC, the 500 Mbps 1995 ANSI LVDS spec called out: > output swing: 250 mV min differential > source impedance: 40-140 ohm single ended > termination impedance: 90-110 ohms differential > driver rise/fall time: 300 ps min, 500 ps max > > Even within the range of allowed values for this old, slow spec, > a 300 ps edge WILL reflect off of the 10 pF Cin (single ended) > of a Xilinx pin, and then subsequently re-reflect off any > 80-280 ohm (differential) impedance mismatch at the driver. > > Later, faster specs such as HyperTransport tighten these > requirements even more to help deal with the faster edges > of a 1 Gbps driver. > > Despite newsgroup claims that Xilinx parts "meet all specs > and standards", they do not in fact meet many of the Cin, Rdiff, > rise/fall, and even Vod (in S3) of the relevant standards for > the claimed input data rates. > > Xilinx _DT input terminations are 100 ohm +/-20%, or worse, > depending upon family and common mode input voltage [Note 2]. > > > Brian > > > Note 1: Cin (single ended) vs. Cin (differential) > > If the input signal is perfectly differential, the reflections > will be IDENTICAL regardless of whether input C is modeled as > two 10 pf shunt Cin (as specified in both the datasheet and > the IBIS models) or as one 5 pf Cdiff. > > Calling it 5 pF doesn't make the parts work any better. > > If the input signal is NOT perfectly differential, the > 10 + 10 = 5 simplification does not apply. > > > Note 2: > > The _DT terminators seem to be implemented using FETs, > producing a bowed termination curve that is near 100 ohms > only when Vicm is somewhere near the output driver's > specified Vocm. > > The actual Rdt value varies family to family, and changes > with VCCO and Vicm. > > Measurements of a sample-of-one FX12 LVDS_25_DT, > at nominal 2.5V VCCO supply, at room temp: > > Vicm Rdt > ----------------------- > 0.50 V ~ 74 ohms > 0.75 V ~ 78 ohms > 1.00 V ~ 94 ohms > 1.25 V ~ 125 ohms > 1.50 V ~ 157 ohms > > using a 7CT1N curve tracer with two 100 ohm > series R's to reduce Vdiff to about Vin/3 > > Sweeping Vin 0-3V => Vicm 0-1.5V > > : > : 7CT1N + ----/\/\----- > : 100 | > : / > : Vin \ Rdt > : / > : | > : 7CT1N - ----/\/\----- > : 100
John_H  wrote:
> > Brian, I always appreciate a well-considered discussion and hope to look > at the T-coil references. Beyond these references I don't know that the > rest of the discussion does much more than stir the bees nest though I > do also appreciate the perspective from the curve tracer. >
If you really believe "Cin doesn't matter", and that all drivers are perfectly balanced with ideal back terminations, then best of luck with your high speed designs; somehow, I suspect you are more pragmatic.
> > Austin, I'm sure you want to retort. Could you let this one go by > without a response? It's feeling old. >
What I find old is vendor employees continuing to make known false or misleading claims like "(We) meet all specs and standards", "Cin doesn't matter", and "but it's really Cin/2". If I occasionally point out the real-world issues on a thread where the subject comes up, it's only after I've counted slowly backwards from 200 by two's and deleted most of my original response. Brian
John,

No, I am tied of the ranting.  Fact is, it works.

Also, there were some customers that had really bad experiences trying
to make their boards work.

Far be it from me to suggest that these folks did something wrong, but I
have to wonder why other customers have this working.

All I can say is that we have demo boards, with network interfaces,
running at DDR rates of 800 Mbs, and on V5, at 1 Gbs.  So, it is more
than a data sheet claim, it is working, proven across PVT, with HDL
code; solutions.

Austin
Brian Davis wrote:
> John_H wrote: >> Brian, I always appreciate a well-considered discussion and hope to look >> at the T-coil references. Beyond these references I don't know that the >> rest of the discussion does much more than stir the bees nest though I >> do also appreciate the perspective from the curve tracer. >> > If you really believe "Cin doesn't matter", and that all drivers are > perfectly balanced with ideal back terminations, then best of luck > with > your high speed designs; somehow, I suspect you are more pragmatic. > >> Austin, I'm sure you want to retort. Could you let this one go by >> without a response? It's feeling old. >> > What I find old is vendor employees continuing to make known > false or misleading claims like "(We) meet all specs and standards", > "Cin doesn't matter", and "but it's really Cin/2". > > If I occasionally point out the real-world issues on a thread where > the subject comes up, it's only after I've counted slowly backwards > from 200 by two's and deleted most of my original response. > > Brian
Cin matters but - in a properly designed system - it doesn't matter so much. If the impedances in the system - source, transmission line, receiver - are crap, then the C will have a huge impact. Since the transmitters will tend to have high C as well in Xilinx transmitters, reflections should be expected. One thing you appear to rely on from previous posts is probing of the signal at a point external to the receiver silicon, the only place practical to probe. This will always result in a signal that's worse than the actual received signal when high Cs (or other impedance mismatches) are involved. Since these are digital systems, *some* reflections are acceptable. Having a signal without extremely well defined highs and lows are typically acceptable. The impact on the time-domain is where the interference will often be noted the most and transmission systems with much better analog performance (including the C and R termination values) are required to maintain a low phase noise. It really is C/2 for those who are thinking 100 ohm impedance. It really is C for those who are thinking 50 ohm impedance. Where are peoples' minds normally on the impedance for LVDS? There are no lies here. I've been impressed with an engineer's approach within my own company to try to reduce common-mode artifacts and EMC issues by filtering from the midpoint of the differential termination. It becomes less obvious why a well-matched C value is so critical when his termination scheme is scrutinized. I was impressed. Your real-world issues are flavored by the way you observe your system. The SI results will often provide much better response than your practical observations. That appears to be a thorn in Austin's side in the same way his C/2 "claims" are a thorn in yours. I have always found your responses to be well considered and sincerely appreciate your self-editing: a rare talent on a forum like this. While you may hate the impairments induced by the LVDS transceivers that are hampered by a design that supports multiple I/O standards, it impresses the hell out of me just how open the data eyes are in the chip. Take a sample of your high-speed data with a carry-chain as a delay element and accumulate. You'll see how good or bad the time-domain is. You can futz with the common-mode, add an offset to the differential, or reduce the transmitter swing to see when and how this eye starts to break down. I love that a 600 Mbit link in the "cheap" S3E devices hampered not by one but by TWO DCMs can result in an eye that's still half open; I could blame just about all of that mess on the DCMs, not the LVDS transceivers. - John_H
Austin wrote:
> > No, I am tied of the ranting. >
And I am tired of your marketing misdirections.
> > Also, there were some customers that had really bad experiences trying > to make their boards work. > > Far be it from me to suggest that these folks did something wrong, > but I have to wonder why other customers have this working. >
My boards work great, because I know when and how to be cautious when driving FPGA inputs from fast logic. When's the last time YOU actually designed a PCB? The boards I've had problems with have been various Xilinx sanctioned "high speed" boards, with terminators hanging off big stubs, or similar mistakes [1].
> > All I can say is that we have demo boards, with network interfaces, > running at DDR rates of 800 Mbs, and on V5, at 1 Gbs. So, it is more > than a data sheet claim, it is working, proven across PVT, with HDL > code; solutions. >
But where are your simulations and real-world test data [2] ? Take a look at XAPP774 and the associated board schematics for TI's ADS5273 EVB combo <sbau091.pdf> and <sbau093a.pdf> Where are the IBIS sims or real-world plots of input signal timing and margin when driving the FPGA? As I pointed out last spring, driving 10 pF Cin from an ADS5273 without back termination is a recipe for disaster [3]. And if you ever have the technical integrity to post a link to your 'works fine' IBIS simulation, I'd be happy to explain the mistakes you made when you penned these nasty remarks [4]:
> > I don't know about anyone else, but it works fine, and posts > like this of sims poorly done are not helpful to anyone. > > I am sorry I took your posting seriously enough to do a real > simulation and show that there is no problem (which I knew > already from the customers that are using our parts successfully). >
Brian [1] Big stubs on ML450 HyperTransport interface http://groups.google.com/group/comp.arch.fpga/msg/3654e1982a62ea81 [2] V4 thread looking for real-world measurements http://groups.google.com/group/comp.arch.fpga/msg/3dc2fc501b48d9b7 [3] updated ADS5273 simulation, IBIS vs. simple SPICE model http://groups.google.com/group/comp.arch.fpga/msg/5a8720eec942612e [4] Austin's attacks on my ADS5273 simulation http://groups.google.com/group/comp.arch.fpga/msg/33e48c977fa78001 http://groups.google.com/group/comp.arch.fpga/msg/6b33bab4a35999bf
"Brian Davis" <brimdavis@aol.com> wrote in message 
news:1180632225.125517.204220@h2g2000hsg.googlegroups.com...
> Austin wrote: >> >> No, I am tied of the ranting. >> > And I am tired of your marketing misdirections. > >> >> Also, there were some customers that had really bad experiences trying >> to make their boards work. >> >> Far be it from me to suggest that these folks did something wrong, >> but I have to wonder why other customers have this working. >> > My boards work great, because I know when and how to be cautious > when driving FPGA inputs from fast logic. >
Right, you beat me to it! This is the reason that I post on CAF; to share my experiences(whether good or bad). It seems to me that we all know _why_ the pins have high capacitance. It's because the chips are a compromise to work with many different I/O standards. Some of these standards require big FETs with high capacitance. That's fair enough, I'm sure FPGA vendors spend a lot of time and effort on marketing research and know that this is the best mix. However, I share Brian's frustration when it's implied that the Cpin is a 'good thing' because, for example, "cross talk is reduced". Not powering the part is another way to reduce crosstalk, and only a little less practical. Why not just say why the Cpin is 10pF, when this matters, and how to deal with the (hopefully few) cases where it may be a problem? IMO, this would be better than denying the problem exists at all. Indeed, this is the approach of this guy, who I believe consults for Xilinx. http://sigcon.com/Pubs/edn/TerminatorOne.htm (Look at the figure, is he timing 8ns with an egg timer? :-) http://sigcon.com/Pubs/edn/TerminatorTwo.htm http://sigcon.com/Pubs/edn/TerminatorThree.htm In summary, nobody expects FPGA parts to be the best at everything, and it's important to be careful when designing at the limits of performance. Best regards, Symon. p.s. God only knows what the OP thinks of this thread! I hope we haven't scared him off for good! :-)
Brian,

I do SI simulations almost daily.  I review PCB designs almost weekly.
All boards get built.

That is ~ 50 pcbs a year.

Many of them for people like C****, A******-L*****, N*****, F******,
N**, S***.  They ask my shop to confirm that they will have a working
pcb when they get it back, and I am happy to help them out.  That way,
the parts go on, the next order is received, and we sail into
qualification, testing, and production release.  I just love big orders
for parts.

I also get to see every pcb that fails SI, for any reason.  And, I am
often required to find the solution to fix it (which as you know can be
impossible once the board is fabricated to fix anything).

Customers are not shy when it comes to complaining when something
doesn't work.  When I go to Xilinx, we had 0 SI experts working for us.
 We now have SI people on the hotline, SI people in the applications
group, SI people in the packaging group, SI people in the IO group, SI
people in the field offices, SI FAE's, the RocketLabs facilities.  Who
do you think planned this all out, and created the system?  I am bored
by SI challenges, and I made sure there were trained experts who enjoyed
SI challenges for customer support, so I can move on to things that are
more fun (like the cases they couldn't solve).

There are numerous pcbs that Xilinx makes for characterization, testing,
SEU, signal integrity package validation, etc.  I have to do the SI on
them with my team, which also has a top notch SI engineer on it.  My pcb
designer did microwave radios for years and years.  He solves wave
equations in his head naturally (it is scary!).

Do I qualify per your criteria?  Does having (and using) my
undergraduate degree in E&M theory enable me to say something?  Is 31
years designing real products that people buy, mean anything to you?


Just agree to disagree, and drop it.  OK?


Or, you agree that we are both a**h****, and just move on?


Either is fine with me.

Austin