LVDS termination scheme to nonstandard ribbon cable

Hi John, Have a look at the link I posted yesterday. This one:-

formatting link
It shows the output structure for LVDS. The (12mA) current source has high impedance, so the output impedance is determined by the resistors show. I think the LVDS transmitters you mention must have some other type of structure. Can you post what they were? HTH, Syms.

Reply to
Symon
Loading thread data ...

Whoops, forget that, I just read the rest of the thread. Cheers, Syms.

Reply to
Symon

Hi John, Right. My point exactly.

Also, many thanks for those links, looks like I found, and posted a link to, the only manufacturer that shows LVDS outputs including the resistors. However, if you revisit the pictures in your links, I think you'll see that they paint a simplified picture. If you go to the National link you posted, it's clear that the lower MOSFET isn't just a short to ground when it's on. Otherwise the device would not be meeting the output common mode voltage spec. There's maybe(?) a resistor in there somewhere, and this provides the required output impedance. The Analog device links show a current source top & bottom, which would suggest the Vcm could be anywhere.

So, I think we need to view these diagrams as not the full picture. However, I agree with you that it seems most manufacturers aren't all that concerned with output impedance, which is interesting. Cheers, Syms.

Reply to
Symon

Symon,

I agree. (Twice? I must be slacking...)

To meet the IEEE/ANSI specification, there is a transmit termination.

If not internal, it would be specified as external.

If not shown, it still may be present.

Diagrams in data sheets are often simplified.

Austin

Reply to
austin

Yup, the common-mode setting thing is an obvious omission.

John

Reply to
John Larkin

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.

Reply to
stefan.elmsted

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).

Aust> Thanks guys for all your comments.

Reply to
austin

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:

formatting link
formatting link

I've considered this impractical at the board level with wide LVDS buses, but the T-coil papers make for fun reading nonetheless!

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

Reply to
Brian Davis

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:

Reply to
John_H

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.

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

Reply to
Brian Davis

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

Reply to
austin

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

Reply to
John_H

And I am tired of your marketing misdirections.

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].

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 and

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]:

Brian

[1] Big stubs on ML450 HyperTransport interface
formatting link
[2] V4 thread looking for real-world measurements
formatting link
[3] updated ADS5273 simulation, IBIS vs. simple SPICE model
formatting link
[4] Austin's attacks on my ADS5273 simulation
formatting link
formatting link
Reply to
Brian Davis

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.

formatting link
(Look at the figure, is he timing 8ns with an egg timer? :-)
formatting link
formatting link

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! :-)

Reply to
Symon

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

Reply to
austin

:)

Yup, the original 'silicon chips' timer ;)

-jg

Reply to
Jim Granville

FPGA driving FPGA, or FPGA driving non-FPGA, are usually much easier to deal with.

My posts cautioning about Cin have always been in the context of a fast, non-FPGA driver (LVDS, LVDS-ish, ECL, etc. ) into a FPGA input with big Cin.

When the thread discussion turned to external matching networks for ECL drivers, I thought the T-coil Cin matching scheme would be of interest.

I use lab measurements to verify my simple first or second order SPICE simulation models at the points I CAN observe, after which I can then experiment in simulation with some comfort of reality being conserved at the receiver input.

I 'forward' clock and test signals on/off chip using LVDS DIFF_OUT buffers and OFDDR's, letting me measure clock distribution without the need for a DCM.

A mechanical trombone line allows an internal sample clock to be offset without any need to worry about DCM jitter or other on-chip delay techniques.

Tek probes of 15-20 years ago in the form of an SD-14 or P6150 (with bias offset), on an 1180x or CSA803 sampler, can easily measure 1 Gbps LVDS, with minimal loading impact, and are practically free since the dot com telecom bust.

Note that sometimes my use of the word "probe" is intended in the context of "bus probe", in which case the external probe is capturing and analyzing the bus traffic- this requires the reflections be damped or otherwise equalized at the point of probe attachment so that the sample clock is usable.

When I say "10 pf Cin (single ended)", I am specifically referencing Xilinx's only datasheet spec for capacitance, called Cin, which is a single-ended specification.

I have pointed this out to Austin numerous times, yet he still insists on "correcting" ( his term ) any references to Xilinx's published Cin values, even after I started explicitly postfixing the '(single ended)' whenever I reference Cin.

My references to C_COMP and C_PKG are also, like their IBIS values, single ended.

I am loath to quote the calculation Cin/2 instead of the actual specification values because :

1) It's only valid if the input is perfectly differential 2) A more realistic input model includes pin-pin capacitance separately as Cdiff, giving a calculated total differential capacitance Ccalc = Cdiff + Cin/2

IIRC, one of the IBIS summit papers discussed LVDS modeling using a C_DIFF, C_PKG, and C_IN, but I can't turn up the paper just now.

I also think the S3E's are great.

C_PKG + C_COMP ~= 3 pf, $$ < 10, at quantity 1 in VQ100

Brian

Reply to
Brian Davis

If this is an original Spartan-3, the differential terminations are not available, so external terminations will be needed.

Put them as close to the package as you can, especially for any clock or strobe signals.

Here, I'd suggest a switch to the LDT output standard instead of LVDS, which will give you higher minimum drive and will help make up for the lower output amplitude caused by the series matching resistors.

I'd normally suggest using LVDS_EXT, another variant of LVDS with extra drive, but in the original S3, the differential output specs are a bit odd, with Vod(min) of only 100 mV for both LVDS and LVDS_EXT, unless you have a certain mask revision. ( See table 37 of DS099 v2.2 )

As you are going FPGA to FPGA, you can switch the I/O standards on both ends, but watch the change in SSO limits for the various differential standards ( See table 49 of DS099 v2.2 )

Brian

Reply to
Brian Davis

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.