Simple ADS5273 -> Xilinx Interconnect Model

> One thing that jumped out at me from the ADS5273 datasheet >was the output slew rate and impedance specs: > > LVDS Outputs Rise/Fall Time (typ) > 2.5mA 400 ps > 3.5mA 300 ps > 4.5mA 230 ps > 6.0mA 180 ps > > Differential Output Impedance > 13 Kohm > > If you hook such a part directly to an FPGA with 10 pF of >input capacitance, Very Bad Things will happen to your >840 Mbps data due to the input reflections off the FPGA. >

I've put together a simple LTSpice simulation model of that interconnection ( model is completely unverified )

slides at:

formatting link

zip including .pdf and LTSPICE files

formatting link

Brian

Reply to
Brian Davis
Loading thread data ...

Brian, Top-notch post! You demonstrate the problem perfectly and describe how to work around it. It's a shame that this kind of thing tends not to appear from the FPGA manufacturers. Rather than admit their parts sometimes have to be a compromise between the needs of many diverse users, they seem to prefer to say their devices are all things to all men. What you've so ably shown is how, by being aware of the FPGAs' limitations, a solution to the 'bleak' Cpin is possible. Thanks for taking the time to produce and publish your results. Cheers, Syms. p.s. And ta for the reference[4]!

Reply to
Symon

manufacturers.

Yes, one would certainly expect to see some IBIS or SPICE simulations provided along with XAPP774.

Unlike the current crop of app notes and marketing fluff, the original Virtex-E LVDS app notes weren't afraid to plot LVDS waveforms at points other than only the on-die receiver input of a perfectly back terminated line. ( Speaking here of the general purpose LVDS I/O app notes; the Rocket I/O stuff is generally better done. )

For a real chuckle, read :

XAPP756 Transmitting DDR Data Between LVDS and RocketIO CML Devices

Surely you'd see plenty of reflections with a 60 ps rise time CML driver whacking a 10 pf LVDS input pin, right?

But not when the only waveform plotted is a worst-case loss situation, showing only the receiver inputs, after driving four feet of FR4...

I liked that "c{r}appy LVDS" pun.

Brian

Reply to
Brian Davis

Thanks for putting together that info, Brian.

Is the ADS5273 a non-standard LVDS "style" of driver? The lack of back termination that you included in the "normal" LVDS driver makes me wonder if the greater problem is with the ADS5273 rather than the non-ideal FPGA input. Two non-ideal ends gives an ugly signal it seems!

A technique used in telecomm systems that might be helpful for probing: rather than using a large attenuator between Rx and Tx with the raw probe point somewhere along the transmission line, consider using a reduced-amplitude probe point. By using a power splitter rather than a raw attenuator with most of the power getting to the Rx, the presense or absence of the probe makes little difference. Reflections are an issue for probes in any system, some come out better than others. If the power splitter is close to the Rx side, the nearby probe may show better results without affecting the signal.

Good SI analysis is so critical these days; it's nice to see someone else's results.

- John_H

Reply to
John_H

John,

I went and downloaded:

formatting link

the IBIS model. I also downloaded the internal termination V4 IBIS model.

I then used Mentor Hyperlynx to simulate the interface. A nice short 3" trace.

Eye pattern looks plenty open for a 0 bit error rate recovery. Looks just fine to me. Is it perfect? No. But who needs perfect? All you need is good enough to be recovered with no fancy tricks. Go to the center of the eye, and sample.

I don't know about anyone else, but it works fine, and posts like this of sims poorly done are not helpful to anyone.

Anyone want my screenshot can email me directly, as posting big graphis files is bad newsgroup behavior (and is blocked).

Austin

John_H wrote:

Reply to
Austin Lesea

Well, there's another apology that you owe me. I'll add it to your tab.

Quickly done, yes. Inexpensively done, sure. Unverified, yes, but clearly labeled as such.

How about you put your money where your mouth is and go ahead and show us all your IBIS sim model, assumptions, and nodes plotted.

What, you don't know how to upload a file and post a link?

Tell you what, instead of you breaking out into a sweat, just go ahead and answer my question from last year [1]:

"Where in Xilinx's V4 documentation might one find these pictures and eye diagrams, including real world vs. simulated waveforms at the driver, receiver, and points in between ? "

and post us a link to any Xilinx app note for V4 that shows nodes along the entire net using a fast LVDS/PECL/CML driver with less than ideal back termination.

Brian

[1]
formatting link
Reply to
Brian Davis

John,

I wouldn't consider those "results" yet, more of a "preliminary model".

But I have used those attenuators in several real-world designs.

I have also done similar models in the past, and after a round of lab verification, additions, and tweaking, they worked far better than the Xilinx IBIS LVDS models/Hyperlynx of the time.

And just try modeling SSO, noise injection from DCI modulation, and other such beasties with your typical combination of IBIS model/simulator versions and feature support.

The appellation "LVDS" has been applied to many parts that swing to LVDS levels into a 100 ohm load, but don't have the expected back termination or driver design.

IIRC, 40-140 ohm Rdiff was expected in one of the early LVDS standards.

Unless I'm misinterpreting the ADS5273 datasheet, the part is NOT back terminated:

Differential Output Impedance : 13 kohm

"The single-ended output impedance of the LVDS drivers is very high because they are current-source driven. If there are excessive reflections from the receiver, it might be necessary to place a 100 ohm termination resistor across the outputs of the LVDS drivers to minimize the effect of reflections."

As I suggested in the 527x thread, I suspect TI intentionally avoided the internal back termination to avoid coupling the unpredictable and ugly reflections off your typical FPGA input back into the analog stuff.

The reflection arrival time is not under the control of the A/D chip designer, unlike the internal sequencing of the front end sampler and output driver switching, and the incoming reflections might hit say 50-60% of the original output step amplitude.

Good point, I didn't mention probes or probe loading models. I'll try to keep a list of things to add to that document.

At 840 Mbps, a decent active or Zo probe should work fine. I did have some notes on probing in one of the reference links; I've copied them below.

I've also used broadband resistive couplers and power splitters for really fast stuff like OC192.

If only this were microwave, I could break out the directional couplers and isolators :)

Brian

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

Reply to
Brian Davis

Brian,

Here are the apologies:

I am sorry that you feel compelled to post on this subject compulsively.

I am sorry to see that you discredit yourself in public by posting a spice fantasy.

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

I am sorry that I have been unable to resolve this issue with you in a mutually positive way.

Austin

Reply to
austin

The only compulsive behavior demonstrated here is your continuing, insulting, and unwarranted attacks on me when I suggest a simple method to make your parts work better.

You've had over five years to produce some sort of V2 app note on how to deal with high speed drivers, but haven't; instead, you flame up my posts when I point out problems and workarounds.

Better a SPICE fantasy than an IBIS nightmare.

I wouldn't trust any results until confirming them in the lab on actual hardware, which I stated quite clearly in those simple simulation models.

Regardless of the exact accuracy of the simulation, the advantages of adding extra attenuation (when the drive strength is available) should be clear with either method of simulation.

For SI work, IBIS is basically a faster SPICE with blinders on. It has merits in certain situations, like automatic SI verification of a massive autorouted line card, but I prefer to start in SPICE, verify in the lab by prototyping, then use those results to guide and cross-check any post-layout IBIS simulations.

You didn't show us anything!

You just made a lot of noise, insulted me yet again, and once again lacked the backbone to back up, with data, your ridiculous claims that there's nothing wrong with having a Cin of 10 pf (single ended) when dealing with sub-200 ps input edge rates from a fast driver.

Making parts with better Cpin would resolve things quite nicely.

Brian

Reply to
Brian Davis

I've put together a preliminary slide showing before/after eye diagram comparisons of the ADS5273 -> V4 interface:

- IBIS/HyperLynx models vs. simple SPICE model - no back termination vs. 6mA back term + attenuation scheme

Plots are temporarily at the following location until I update the original file: ftp://members.aol.com/fpgastuff/temp_plots.pdf

Many thanks to Symon for running those HyperLynx sims for me, and for reminding me that real world current sources are less reflective away from midstream than ideal ones .

Setup: - simple lossless models as originally described in - PRBS-5 data pattern - note varying scales on plots

Comments:

Again, I'd not trust either method without lab verification; see notes below for specific concerns, particularly regarding the DC offset seen on the Xilinx IBIS input models.

In any case, I'd say the plots clearly show the improvement in ISI crossing jitter and eye closure over the direct connection.

The back terminated version also significantly reduces the peak-peak reflected junk at the pins of the precision mixed signal A/D. (bearing in mind real world Tlines have more loss)

The two simulation methods match fairly well, but there's a smaller eye opening in the SPICE model than in the IBIS plots.

I think they'd match much better without the huge DC offset in the IBIS models, which seems to be causing the driver to saturate and/or clamp in the Hyperlynx sims.

This causes the asymmetrical TX overshoot in the lower left IBIS plots, the imbalance from which then causes the squiggle in the leading edge of the IBIS Rx crossing waveform.

IBIS model concerns:

- Xilinx v4 IBIS model for LVDS inputs generates IBIS parser warnings about non-zero clamp currents

- V4 IBIS model pulls up LVDS driver output common mode from the expected 1.2V to around 1.5V

- DT terminator modeled as simple resistor in IBIS files; how much does it vary over allowed input range of diff Rx?

Spice model concerns:

- ideal current source model of the driver is perfectly reflective, unlike an actual device which can't swing past its headroom

- 9 db may be too much with real world Tline loss at weak driver corner ( reduce attenuation or remove/change 100 ohm back term )

Brian

Reply to
Brian Davis

Brian -

Somehow I managed to miss this series of posts earlier, but found them today. Thanks very much for posting your simulations.

Bob Perlman Cambrian Design Works

Reply to
Bob Perlman

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.