Some additions to John's advice, assuming we are talking
of an original S3 family device ( not E,A,AN,... )
John_H wrote:
>
> The receiver should be the differential impedance of the cable and of
> the transmitter - they should all (roughly) match. If you have an
> external termination at the receiver, change it to the 173 ohm value if
> that's the true differential impedance. If the termination is internal
> at 100 ohms, add two 36 ohm resistors (or thereabouts) to get the
> impedance match, albeit at a reduced signal amplitude.
>
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.
>
> On the transmitter, you want a 100 ohm to 173 ohm impedance match so the
> transmitter sees 100 ohm but the transmission line sees 173 ohm. You'll
> need a differential termination on the transmitter side of this network
> and two series resistors to the ribbon cable. The signal amplitude will
> again be reduced.
>
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 by Brian Davis●May 31, 20072007-05-31
John_H wrote:
>
>Since the transmitters will tend to have high C as well
> in Xilinx transmitters, reflections should be expected.
>
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.
>
> 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.
> <snip>
> The SI results will often provide much better response than your
> practical observations.
>
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.
>
> 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.
>
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 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.
>
I also think the S3E's are great.
C_PKG + C_COMP ~= 3 pf, $$ < 10, at quantity 1 in VQ100
Brian
Reply by Jim Granville●May 31, 20072007-05-31
Symon wrote:
> 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.
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 by Symon●May 31, 20072007-05-31
"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.htmhttp://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! :-)
Reply by Brian Davis●May 31, 20072007-05-31
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).
>
> 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
Reply by austin●May 31, 20072007-05-31
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 by Brian Davis●May 31, 20072007-05-31
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
Reply by John_H●May 31, 20072007-05-31
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