LVDS_25_DCI : Top Ten List

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,

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

Brian,

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
>
> Austin wrote:
> >
> >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,

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

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

*Note: "customer is always right"

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


Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F842707.AB1AA4DA@xilinx.com>...
> 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
> 
> *Note: "customer is always right"

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:
> 
> 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
> 
> Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F842707.AB1AA4DA@xilinx.com>...
> > 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
> >
> > *Note: "customer is always right"

-- 

Rick "rickman" Collins

rick.collins@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

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?

Austin

rickman wrote:

> 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:
> >
> > 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
> >
> > Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F842707.AB1AA4DA@xilinx.com>...
> > > 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
> > >
> > > *Note: "customer is always right"
>
> --
>
> Rick "rickman" Collins
>
> rick.collins@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

????

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

Austin Lesea 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?
>
> Austin
>
> rickman wrote:
>
> > 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:
> > >
> > > 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
> > >
> > > Austin Lesea <Austin.Lesea@xilinx.com> wrote in message news:<3F842707.AB1AA4DA@xilinx.com>...
> > > > 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
> > > >
> > > > *Note: "customer is always right"
> >
> > --
> >
> > Rick "rickman" Collins
> >
> > rick.collins@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,

>
> 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.Lesea@xilinx.com> wrote in message news:<3F8578D1.AAB14B8B@xilinx.com>...
> 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?
> 
> Austin
>