LVDS_25_DCI : Top Ten List
Brian Davis
1) Parallel DCI input standards in Virtex2 continuously modulate
the input termination offset voltage unless you enable bitgen's
FreezeDCI option
2) With FreezeDCI on, the entire bottom half of 2V40, 2V80, and
any CS144 packages are unavailable for LVDS_25_DCI inputs (this
includes half the global clock inputs to the chip) due to DCI
unavailability in banks having only ALT_VRP/N pins
3) With FreezeDCI on, dual purpose config pins cannot be used as
LVDS_25_DCI inputs
4) 5.2i S/W doesn't catch illegal pin assignments due to #2 and #3
5) With FreezeDCI on, input terminator accuracy for 2R values
degrades to +/-20%
6) With FreezeDCI on, each bank will have a (different) random
input offset voltage due to split terminator 2R variations
7) LVDS_25_DCI terminator overhead power per input pair far exceeds
the theoretical 62.5 mW number published in Answer Record 15633
8) With FreezeDCI on, worst case VCCO power overhead per
LVDS_25_DCI input pair approaches 100 mW
9) With FreezeDCI on, worst case DCI VRP/N VCCO power overhead
per I/O bank approaches 200 mW
10) 5.2i Xpower incorrectly assigns DCI power to the 1.5V VCCINT
supply, and it doesn't use the worst case DCI power numbers
11) V2 Power Estimator spreadsheet doesn't support LVDS_25_DCI,
but if you fake it by using two single ended DCI 2R split
terminated inputs per actual LVDS pair, it also uses the
wildly optimistic power numbers
12) LVDS_25_DCI IBIS models don't work in HyperLynx
13) Massive 8pf IBIS C_COMP input capacitance value for the
V2 LVDS inputs requires external back termination and/or
input matching scheme to achieve reasonable signaling when
driving FPGA inputs from a modern high speed LVDS driver
Interesting Answer Database Search Keywords:
FreezeDCI
LVDS AND DCI AND termination
DCI AND power
IBIS AND Hyperlynx ( in answer archive )
Suggestions to Xilinx:
- Have somebody document the plethora of V2 DCI hardware
and software problems ('challenges'? 'features'?) in one
place ( a detailed application note? ) ASAP.
- Hiding the FPGA IOB/CLB/FF/interconnect power consumption
numbers within an encrypted spreadsheet and buggy SW makes
it impossible to cross-check the resulting power calculations.
- Please take a look at page 145 of the ORCA-4 datasheet
("Package Parasitics"): there, in human readable form, is a
usable package model that can be simulated in any SPICE.
- Also note that the ORCA-4 IBIS C_COMP value for the general
purpose LVDS inputs is a much more reasonable 2 pf.
- Real differential LVDS input terminators are quite wonderful
(no VCCO power hit, no split terminator DC offset problems).
Making them available (LXXX_25_DT) only in the V2Pro, and
not in the Spartan3, is an exceptionally HUGE mistake.
Brian
Bob
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 Davis" <brim...@aol.com> wrote in message
news:a528ffe0.03100...@posting.google.com...
Austin Lesea
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
Bob Perlman
>Top Ten Things I wish I never had needed to learn about LVDS_25_DCI:
>
>
> 1) Parallel DCI input standards in Virtex2 continuously modulate
> the input termination offset voltage unless you enable bitgen's
> FreezeDCI option
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
Brian Davis
>
>But I have one correction, the capacitance to ground is ~ 8pf,
>thus the differential capacitance is 4 pf (two 8 pf in series).
>
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.
>
>Unfortunately, to meet ESD, and have the IOB also do the
>other 35 standards, the capacitance is not as low as
>everyone would like.
>
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 ).
>
>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).
>
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. )
>
>And we will check out the IBIS model issue.
>
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.
>
>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).
>
See Webcase 467802 (March '03), Webcase 476968 (May-August '03),
CR 170813, CR 171469
>
>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.
>
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 ).
>
>but that was a) not the market we were after,
>
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
Brian Davis
>
>Second, how much offset voltage modulation are you seeing with DCI
>update enabled?
>
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.
>
>Is it enough to justify all the difficulties you're
>experiencing with FreezeDCI?
>
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
Austin Lesea
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.....
Austin
qlyus
> 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).
Austin: Market will decide!
-qlyus
Uwe Bonnes
: Austin Lesea <Austin...@xilinx.com> wrote in message news:<3F7DA078...@xilinx.com>...
:> 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).
: Austin: Market will decide!
<lots of quote deleted>
qlyus: Wow!
About 170 line quoted to add one single line.
Please don't spoil the archives that way!
Bye
--
Uwe Bonnes b...@elektron.ikp.physik.tu-darmstadt.de
Institut fuer Kernphysik Schlossgartenstrasse 9 64289 Darmstadt
--------- Tel. 06151 162516 -------- Fax. 06151 164321 ----------
Brian Davis
>
>First, I checked the IBIS model in Hyperlynx v7, and it works fine.
>
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.
>
>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).
>
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.
>
>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).
>
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.
>
>Not ignored at all.....
>
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,
5-6 months after informing Xilinx of the DCI power problem, that
Answer Record 15633 STILL had that worthless 62.5 mW number with
no mention of the ~200 mW per bank VRP/VRN overhead.
Brian
Austin Lesea <Austin...@xilinx.com> wrote in message news:<3F7DA078...@xilinx.com>...
Austin Lesea
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
Brian Davis
>
>Sorry you are not satisfied with the agreement, and the positive
>response, and the acknowledgement and appreciation.
>
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.
>
>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).
>
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.
>
>Our parts meet the LVDS standard, they work.
>
What about the other specs I have mentioned, such as HyperTransport,
that have a tighter Cin or slew rate specification?
>
>If you use them wrongly, they don't work.
>
They work just fine, but only with proper care and feeding.
>
>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.
>
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?
>
>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.
>
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:
1) Customer finds problem and calls IC vendor
2) IC vendor blames simulator vendor
3) Simulator vendor blames customer
4) Goto 1
( apologies for the sarcasm, but I'm tired of arguing about this )
Brian
Austin Lesea
Comments below,
Austin
Brian Davis wrote:
> Austin,
>
> >
> >Sorry you are not satisfied with the agreement, and the positive
> >response, and the acknowledgement and appreciation.
> >
>
> 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.
You are welcome.
>
>
> 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.
Will do.
>
> 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.
No problem: it is in the spec sheet, and users guide. An it is obvious
in simulations.
>
> 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.
It is.
>
> 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.
Really?
>
> >
> >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).
> >
>
> 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?
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).
>
>
> 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.
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.....
>
> >
> >Our parts meet the LVDS standard, they work.
> >
> What about the other specs I have mentioned, such as HyperTransport,
> that have a tighter Cin or slew rate specification?
Then we don't meet the "specs". Wasn't that simple? But we do
interoperate, and many people choose to do so.
>
> >
> >If you use them wrongly, they don't work.
> >
> They work just fine, but only with proper care and feeding.
I think we are in "violent agreement."
>
> >
> >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.
> >
>
> 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!!!
No, it is just physics. Can't probe anyones 840 Mbs lines without
affecting them.
>
> 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.
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?
>
>
> 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?
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.
>
> >
> >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.
> >
>
> 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:
>
> 1) Customer finds problem and calls IC vendor
> 2) IC vendor blames simulator vendor
> 3) Simulator vendor blames customer
> 4) Goto 1
>
> ( apologies for the sarcasm, but I'm tired of arguing about this )
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.
Brian Davis
>
>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.....
>
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:
>>
>> 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.
>
>It is.
>
If you can't form a coherent argument, don't bother
posting grade school "is too, is too, is too" nonsense.
>
>Since I can not see their data sheet (they block Xilinx domain),
>I have no means of verifying your claim.
>
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?
>> >
>> >Our parts meet the LVDS standard, they work.
>> >
>> What about the other specs I have mentioned, such as HyperTransport,
>> that have a tighter Cin or slew rate specification?
>
>Then we don't meet the "specs". Wasn't that simple? But we do
>interoperate, and many people choose to do so.
>
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.
>
>No, it is just physics. Can't probe anyones 840 Mbs lines
>without affecting them.
>
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.
>
>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?
>
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
Austin Lesea
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
*Note: "customer is always right"
Brian Davis
"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
Austin Lesea <Austin...@xilinx.com> wrote in message news:<3F842707...@xilinx.com>...
rickman
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.
--
Rick "rickman" Collins
rick.c...@XYarius.com
Ignore the reply address. To email me use the above address with the XY
removed.
Arius - A Signal Processing Solutions Company
Specializing in DSP and FPGA design URL http://www.arius.com
4 King Ave 301-682-7772 Voice
Frederick, MD 21701-3110 301-682-7666 FAX
Austin Lesea
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?
Austin
Austin Lesea
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 10-12nH, which is clearly
not possible (unless you do not care about high speed signals at all). Of course, series 10nH will
sure make the input look less capactive! so maybe this is how they have "less C" by resonating it out.
Austin
Brian Davis
>
> Brian just seems to be stuck, and is unwilling to
>grant that there are ways to make it work just fine
>
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:
>
>13) Massive 8pf IBIS C_COMP input capacitance value for the
> V2 LVDS inputs requires external back termination and/or
> input matching scheme to achieve reasonable signaling when
> driving FPGA inputs from a modern high speed LVDS driver
>
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
Austin Lesea <Austin...@xilinx.com> wrote in message news:<3F8578D1...@xilinx.com>...