LVDS_25_DCI : Top Ten List

Brian,

I completely agree that Xilinx should document these errata in one place, AND make it easy to find. Having to search for these implies that you suspect the problem to-begin-with.

There's another nasty gotcha (Virtex-II and above) which still isn't documented as such -- the issue of requiring that the P and N pin pairs use the same clock domain (per direction) if either of those pins utilize the DDR registers in that IOB.

Thanks for pointing these out to us.

Bob

Brian,

Excellent list.

But I have one correction, the capacitance to ground is ~ 8pf, thus the differential capacitance is 4 pf (two 8 pf in series). Unfortunately, to meet ESD, and have the IOB also do the other 35 standards, the capacitance is not as low as everyone would like. Simulations at the die, however, show a very nice waveform, even though it may look questionable at the pins of the device (due to the t-line effects).

Nothing beats an on die 100 ohm termination.

LVDS_25_DCI was never intended to replace a simple 100 ohm external termination. That was reserved for the improved input terminator (a simple 100 ohms) that was added to Virtex 2 Pro. It was also an afterthought, that was suggested to us by a customer, when they messed up, and forgot all the resistors. It is VERY ugly in the power department, and we did not realize that the power could be as high as ~85 mW per pair due to the way the DCI circuit operates. Also, freezing DCI does mean that you might be trying to measure the 25 ohm termination voltage with the reference resistors, so the current in them does increase, too.

If I may suggest, use LVDCI_25_DCI only for clock inputs, or a few signals. Always use DCI_Freeze to reduce the jitter. Also look at what happens when you do not have a 100 ohm termination. For some signals, and lengths of pcb, it may not be required. And we will check out the IBIS model issue.

As for allowing the power estimator, spreadsheet, answers, etc. to all catch up with all of the "top ten" list: that is just tough to do, but you are right, we should do it (and will).

Spartan 3 addresses a different market than Virtex II, or II Pro, and was never intended to replace them. We reserve the right to differentiate product lines by having different features. I am sure everyone would like to have a Spartan 3 that could replace a Virtex II or II Pro, but that was a) not the market we were after, and b) not possible with the process/design/technology we chose.

The Spartan folks are busily planning and designing their next chip(s), and we in the Virtex camp are busy with our next product offering.

Thanks for your comments,

Austin

Brian Davis wrote:

First, thanks for your post; it's very informative.

Second, how much offset voltage modulation are you seeing with DCI update enabled? Is it enough to justify all the difficulties you're experiencing with FreezeDCI?

Thanks, Bob Perlman Cambrian Design Works

Austin,

The 8pf C_COMP number I quoted was the max value from the latest Xilinx IBIS file; that's about as 'correct' as I can get.

I agree with your observation that Cdiff = 1/2 C_COMP for a differential input propagating entirely in odd mode.

However, please don't overlook the main point of item #13 :

Although you market these as "840 Mbps" devices, the input capacitance of the general purpose LVDS IOBs is so high as to make it extremely difficult to drive the FPGA inputs from the latest generation of high speed LVDS drivers without well planned back termination and/or input matching.

See for instance Table 13, footnote 1 of XAPP622, which clearly states that, although tested interoperable, the V2 devices do not meet the rise/fall requirements of the SFI-4 specification.

I realize there's a lot of baggage in there, but the "Brand L" C_COMP of 2pf that I quoted shows that others have done much better in a similar generation of FPGA (and they also included one-reference-resistor-per-chip adjustable differential input terminators ).

The die input might look 'nice' on the very first edge, but not when the round trip reflection returns from the far end...

( In my first tests, the FPGA input reflection completely closed the data eye at the driver output when using a TI 65LVDS100 driving about 2" of coupled microstrip into the V2. )

Xilinx already knows about this one; see Answer Record 1782 in the Answer Archive. Although archived, it does not list a solution other than the cheesy 'stick a dummy terminator into the model' approach. I can confirm that this was still broken in the March-April '03 time frame when using the latest Xilinx V2 IBIS models and Hyperlynx version available at the time.

See Webcase 467802 (March '03), Webcase 476968 (May-August '03), CR 170813, CR 171469

For frills like PowerPCs, differentiate away...

But, if you think having a decent differential DCI input termination solution for Spartan-3 is a luxury, you're way off target.

The alternative of placing external resistors on the high pin count BGA packages being offered in the Spartan-3 family quickly gets to be unoptimal/unworkable.

Many of the high speed parts that were formerly (P)ECL are now moving to LVDS for high speed I/O ( A/D, D/A, mux/demux, etc ).

The first page of your Spartan-3 datasheet lists the following: - 622 Mb/s data transfer rate per I/O - Six differential signal standards including LVDS - Termination by Digitally Controlled Impedance

How is it that you can tout the resistor-saving advantages of DCI for single ended I/O, but then ignore the most critical, higher speed, differential I/O standards?

Brian

Enough to scare me bitless.

I don't have a plot at hand, IIRC one side of a quiescent undriven LVDS_25_DCI input exhibited pulse modulation with a peak amplitude of about +/-100 mV away from nominal Voffset for a duration of ~2 us at ~25 kHz rate.

For a better idea of the pulse width and rate of the modulation waveform, look at the plot of Answer Record 12573 and imagine that for the entire duration of one of those VRP/VRN stairsteps, your DCI resistor(s) suddenly modulate +/- 20% in value.

Personally, I would not use any of the DCI standards without using FreezeDCI (or the DCIUpdateMode of the newer V2P parts).

Although the problems I described yesterday pertained to one of the parallel termination standards, the underlying problem exists for the series terminators as well, it's just not as visible, but could easily affect output edge jitter.

Brian

Brian,

First, I checked the IBIS model in Hyperlynx v7, and it works fine.

Next, the driver for LVDS is required to have a 100 ohm drive impedance. If you use a device that does not comply to this, then you most definitely can and will get reflections shot back to the input.

I can not comment on parts that do not meet the LVDS specifications when connected to the FPGA: that requires some engineering (as always).

I have received back confirmation that the issues are being worked on from the support group, and I also notified the apps folks about some kind of app note for use of the LVDS DCI feature, since it is not as clean as the internal solution (in Virtex II Pro).

Not ignored at all.....

Aust> Austin,

Austin: Market will decide!

-qlyus

: Austin: Market will decide!

qlyus: Wow!

About 170 line quoted to add one single line. Please don't spoil the archives that way!

Bye

Austin,

That's good news; was that a coupled-line simulation in BoardSim of a fast driver whacking a LVDS_25_DCI input? Or, an uncoupled LineSim model with a V2 for both driver and receiver?

I don't currently have access to Hyperlynx or the problematic design files (previous employer), but as I recall it was v7-beta with which I had encountered problems.

That's quite a stretch: blaming the hypothetical faults of the driver for not correcting the known sins of the receiver...

Please re-read my original post, and notice that when I mentioned the impact of the large C_COMP values in the presence of a high speed driver, I used the phrase "requires external back termination and/or input matching".

Firstly:

Yes, a perfect 100 ohm transmission line back terminated with a perfect 100 ohm source impedance can completely absorb the large reflection generated by a highly capacitive input.

Personally, I prefer not to generate (or propagate) such massive ringbacks in the first place.

Secondly:

To the best of my recollection, the output impedance specified by the original LVDS spec was fairly broad- in the presence of a 50%-60% ringback, another 40% re-reflection can be significant.

Thirdly:

Although the original LVDS specification did not directly specify a max Cin value, newer specifications such as HyperTransport do; for example, HyperTransport requires a maximum 2pf (single-ended) Cin for receivers rated > 800 Mbps.

Fourthly:

Left uncompensated, the reflections created by a large input capacitance can render the part useless for multidrop topologies. The back propagation of the reflection makes the signal on the line unusable except at the die input ( ignoring here any reflections off any mid-stream taps, which would be just as bad.) Before you attack a multidrop system as being a special case, let me point out that the simple act of probing the line will create a multidrop system out of a point to point link. Also, in most high speed systems, there is a need to monitor the link in some fashion, either as part of a system jitter/skew or setup/hold verification, or perhaps a non-intrusive signal tap for operational monitoring.

This is often done by placing a passive resistive coupler in-line with the signal, or perhaps probe pads for one of the low-loading differential active probes.

If the tap is placed close to the highly capacitive receiver input, the ringback can leave the differential signal in limbo at the probe point ( both inputs within the differential Vih/Vil hysteresis switching threshold ) until the reflected pulse has passed; if you place it farther up the line, the reflection can re-clock the probe, or interfere with the next incoming bit.

Fifthly:

You seem to be suffering from a bad case of input capacitance denial here- admit that the V2 LVDS inputs are far from perfect for 840 Mbps operation, and put that energy to use identifying the problem to your customers, and explaining how to work around it, instead of propping up your straw men.

At no point have I claimed that the V2 inputs are unusable, but only that, in the presence of high speed drivers, extra engineering effort needs to be expended to both understand the impact of the V2 input capacitance on the interconnect, and find a work-around that is appropriate for the design at hand.

Might I suggest splitting that into two app notes: one explaining the various DCI problems in general (they affect more than just the LVDS_25_DCI standard), and another for the particular quirks of high speed differential signaling with a V2.

Where did I say that? However, since you bring it up, I might point out that the wheels of documentation update at Xilinx seem to grind quite slowly - what prompted me to write up my original post was noticing last week,

Brian

Brian,

Wow. I agreed to move this up the list, and thanked you. Various CR (change requests) are now in progress.

I am so dissapointed. I agreed with you. I thanked you for putting all of the items in a nice concise list.

No denial here. I explained why the capacitance is high. In fact, why in must be high, and why we (and others) have no choice unless the LVDS inputs are dedicated in their own bank, with no other standards attached (which no one wants in the FPGA world).

Our parts meet the LVDS standard, they work. If you use them wrongly, they don't work. If you want 2pF inputs, go make your ASIC. That is how the ASIC/ASSP folks try to lock us out of their markets. Unfortunately for them, there are plenty of folks who can not afford their devices, and know how to properly simulate, and terminate and use capacitive inputs.

As for wanting to "observe" the signal, that is about the best way to mess it up (which you aptly point out). Rather than do that, how about using the existing variable phase shift feature to measure the actual eye opening at the place where it counts: in the FPGA? Our customers that do that are delighted that they no longer have to lose sleep over how much margin they have: they measure it directly in the device itself.

You asked about the IBIS model, so I checked that. If the coupled/uncoupled t-line are an issue, that is Mentor's responsibility. I hope you file bug reports with them if that is the case.

Sorry you are not satisfied with the agreement, and the positive response, and the acknowledgement and appreciation.

Austin

Austin,

I never said any of those things.

I certainly appreciate your (and Peter's) time spent monitoring the newsgroup.

Thank you for the 'excellent list' comment.

I ( and any future users of the LVDS_25_DCI standards ) also appreciate any prodding you can do to speed up the documentation process so others can have a less painful experience.

However...

I stand by Item 13 as originally written.

It is an alert to potential users of V2 differential I/O of a critical component specification that they should be aware of before starting a design.

You disagreed with me on this issue, so in subsequent posts I refuted the various arguments that you made contending that the high V2 C_COMP value is unavoidable/not a problem/etc.

Instead of responding to my rebuttals, you changed the subject, ignored those portions of my posts, and now threaten to take your bat and ball and go home.

why in must be high, and why

in their own bank, with no

Instead of ignoring my previous posts, go download the ORCA-4 IBIS files, and take look at them:

ALL OF THE GENERAL PURPOSE, NON-DEDICATED I/O STANDARDS HAVE A C_COMP VALUE OF 2pf.

If they can do it, why can't you?

I realize that the older families are unlikely to be improved, but if Xilinx won't admit the problem, at least internally, there's not as much hope for improvement in generation N+1.

What about the other specs I have mentioned, such as HyperTransport, that have a tighter Cin or slew rate specification?

They work just fine, but only with proper care and feeding.

mess it up (which you aptly

variable phase shift feature to

FPGA? Our customers that do

much margin they have: they

Amazing: I write a clear, concise (IMHO) explanation of how having a BMFC on the device inputs make it impossible to probe, and you blame the probe!!!

Life without probes is a fantasy: without a probe, I could have run IBIS simulations from here to eternity without finding out about the DCI amplitude modulation.

The DCM phase shift is a very handy feature, but one must bear in mind that any measurements made in such a fashion, such as your SST IOB timing numbers, will also include DCM jitter.

How is such an internal probe going to tell you anything about the input waveform other than its' threshold crossing time? What about amplitude, ringing, noise margin, or wacky, unexpected problems like the DCI modulation?

coupled/uncoupled t-line are an issue,

them if that is the case.

Ah, your response to this one quite aptly describes the sophisticated, iterative IBIS model debugging process that has been honed through years of industry experience:

( apologies for the sarcasm, but I'm tired of arguing about this )

Brian

Aust>

(change requests) are now in

all of the items in a nice

why in must be high, and why

in their own bank, with no

wrongly, they don't work. If you

try to lock us out of their

not afford their devices, and

inputs.

mess it up (which you aptly

variable phase shift feature to

FPGA? Our customers that do

much margin they have: they

coupled/uncoupled t-line are an issue,

them if that is the case.

response, and the acknowledgement

Brian,

Comments below,

Aust> Austin,

You are welcome.

Will do.

No problem: it is in the spec sheet, and users guide. An it is obvious in simulations.

It is.

Really?

Since I can not see their data sheet (they block Xilinx domain), I have no means of verifying your claim. Have you simulated their IOB with IBIS?

As I already said, when you can drive GTL, SSTL, HSTL, PCI all from the same IOB, you have to make some trade-offs.

For dedicated inputs, it is not an issue (ie for the serdes).

Get off that boat: I have admitted it many times now. It is you who seems to persist in dragging it on, and on, and on, and on, and on.....

Then we don't meet the "specs". Wasn't that simple? But we do interoperate, and many people choose to do so.

I think we are in "violent agreement."

No, it is just physics. Can't probe anyones 840 Mbs lines without affecting them.

Gee, I designed digital microwave radios for 5 years, and I never could "see" anything. Only could sniff at it with a spectrum analyzer. Everything was simulated. Guess where we are all headed?

It all shows up in the error rate, and the timing margin. True, observing the signal is really nice (I try like hell to do that), but sometimes it isn't possible. For example, looking at the signal at the actual input itself is impossible, yet that is the only place where it counts.

Apology accepted, but I tried the model in a number of ways, and did not see a problem. Did it work for the simple t-line case? It did for me.

Austin,

Perhaps when you stop posting the same poorly reasoned arguments over and over again, I'll stop correcting them over and over and over again.

You claim to have "admitted" that the input capacitance is a problem, yet here you go again with your denials:

If you can't form a coherent argument, don't bother posting grade school "is too, is too, is too" nonsense.

That information was in my very first post; you ignored it, continued denying it, yet still can't be bothered to check?

Get a real excuse. Do you honestly expect us to believe that you have no Internet access outside of work?

Or, that nobody at Xilinx keeps up on competitor's products?

Interoperate where? In one reference design, with one vendor's parts? Or, in all the potential configurations considered by the standards committee when they wrote the spec?

May the spirits of the all the anonymous standards weenies, who worked so hard to incorporate those specifications that you so blithely dismiss, haunt your designs until you repent.

How can you argue on one hand that the ~10pf total Cin of your receiver inputs is not a problem, yet claim the fraction of a pf imposed by a decent probing scheme will somehow be significant in the same system?

A well designed resistive coupler, properly packaged, will work at OC-192 rates and beyond.

You may be stuck with doing simulations at the chip level, except for perhaps the guys doing wafer probe for low level device model correlations, but the users of your parts still have the luxury of testing and measuring directly in the real world.

We will continue to use those tools that are most appropriate to the task at hand, rather than blindly placing our faith in IBIS models and simulators alone.

Brian

Brian,

You are absolutely correct in everything you say*.

Please do not bother to reply or acknowledge, as I am not worthy of your attention.

Austin

Austin,

"Xilinx is always right" is your personal credo, as evidenced by this thread and many others.

The next time you're about to post a sarcastic, condescending, knee-jerk response to a thread based soley on the fact that it is somehow critical of Xilinx's parts, tools, or customer support, stop to consider whether you can back up your post with an argument any more compelling than "because I said so".

Brian

Brian,

You are pretty much wasting your breath. There are always people in any newsgroup who feel they own the truth and have a lock on reality. Trying to have a reasonable discussion can be very hard. But that effect can be magnified by the issues of posting in a public forum as a representative of a company. So don't expect to get the same type of answers from an FAE in this venue that you would get from another engineer or that you might get when discussing an issue in private.

I know I have spent more of my time then I should trying to get "straight" answers here after the real answer was already clear, even if it had not been stated outright.

But I do appreciate the info you have posted in this thread and the light you have allowed to shine.

Brian Davis wrote:

Rick,

Now you, I can have a discussion with.

Anything that is unlcear or still in doubt about the input C issue that I might explain?

After all, many posts ago I explained why the C was what it was, how it is documented, and made comment that there are ways to deal with it, but Brian just seems to be stuck, and is unwilling to grant that there are ways to make it work just fine, and that perhaps there are valid reasons why the C input can not be 0.5pF.

Do you have, or have you run an IBIS simulation of the ORCA-4 IOB and looked at how its input C affects the signal?

Aust> Brian,

????

Further, I downloaded the IBIS files (just broke down and logged into their site but I had to fill out the long form with all of the required fields to get a username and password.....I just hate that! There should always be a way to get around the "salesman at the door" and go direct to what you want!!!), and ran some simulations taking into account the package stub t-line (critically important in this case, and described in our guidelines of how to do these simulations in our IBIS documentation), and the results look acceptable (nice eye opening with pseudorandom data) for both parts. Theirs has more L and inductive kicks going on, and ours has more C, and less kicks. I naturally prefer our eye as it is far less "spikey" but that is probably my obvious bias.

So, the actual Cload of the input is buried in the IBIS spice2ibis tables (not listed in the file anywhere), so one has to infer it by examining the responses. The files do list the package C, which is silly, as the package is a transmission line (which we have accounted for in our recommendations of how to use IBIS). Further, their estimation of Lpkg must be wrong, as it is

Aust> Rick,

might explain?

documented, and made

and is unwilling to

are valid reasons why

at how its input C

Austin,

Exactly what part of "requires external back termination and/or input matching scheme when driving FPGA inputs from a modern high speed LVDS driver" didn't you read?

The way you "make it work just fine" with a high speed driver is by adding "external back termination and/or input matching" - that's what I've been saying, repeatedly, since my first post. Item 13 from my original post:

Why did I feel it necessary to include this item on the list:

Because inexperienced designers wouldn't know any better, and even experienced designers with ECL/GaAs/SiGe high speed digital components may be caught off guard by such a high Cin spec - when first reading the Virtex2 datasheet, I thought it was a tester specification limit until I did initial system SPICE modeling and real world driver/TDR testing on a Virtex2 prototype board.

Brian

might explain?

documented, and made

and is unwilling to

are valid reasons why

at how its input C