Virtex4 running at 360Mhz DDR

"Austin Lesea" <austin@xilinx.com> wrote in message
news:d5teda$2vn1@cliff.xsj.xilinx.com...
> Symon,
>
> What is 12.5pF in series with 12.5pF?
>
> Yes, that is right, 6.25pF differential load, not 12.5pF.
>
> Falling for the A FUD is especially embarrassing when you just repeat
> things which are factually incorrect.
>
> All these things are taken into account from the simulation.
>
> Austin
>
OK, I'm not sure where that came from, but let me explain. Each pin of the
pair is driven by a 50 ohm line. Taken together, these two 50 ohm lines make
a 100 ohm differential pair. At one single pin you've got a 12.5pF capacitor
being driven from 50 ohms. If you view the pair together, you've got 6.25pF
driven by 100 ohms. The return loss is the same in both cases. As is the
rise time (RC = 625ps). So, Altera's 6.1pF per pin turns into 3.05pF when
viewed as the termination to a pair. In the 1Gbit region, their return loss
is much better. Their rise time is twice as fast. (RC=305ps).
Now, pay attention. I can make your c(r)appy LVDS work better. Given the
problem is that you've got a large Cpin because (I guess) of all the other
attached goodies, a way to improve things is to drive this capacitance with
a lower impedance. For an FPGA to FPGA connection, use a 50 Ohm differential
transmission line instead of 100 Ohms. If you place an extra external 100
Ohms differential termination resistor at _BOTH_ end of this t-line, you
have a pretty well matched 50 Ohm connection. The pole caused by the
parasitic capacitance has moved out to double the frequency it was at. Of
course, the signal amplitude has halved, which tends to make the eye close
vertically, but it will open horizontally, which is the limiting factor in
this case. Maybe LVDS_EXT would be a good idea too.
There are also other methods to open the eye for specific bitrates if the
t-line characteristics and parasitics of the parts are known. You need to
use an application specific filter at the end of the t-line.
HTH, Syms.

Symon,

All true.

I would suggest that you should have more of a differential line, than 
two single ended 50 ohm lines, but it doesn't change anything at all 
(you still end up being differentially terminated at the receiver, with 
6.25pF across 100 ohms).

The eye is plenty good for up to 1 Gbs (see the ML450).

It does not work up to 1.3 Gbs, because we didn't design it to work up 
to there:  that is what the MGTs are for.

If there is a 'beauty contest' for the 'best LVDS eye pattern', I will 
admit we come in second (due to increased Cpin), but I will not admit 
that it matters so far as use, function, or anything important is 
concerned.  The Idly feature that allows for independent skew adjustment 
for each IO pin (pair) to center the eye sampling point to within 
+/-78ps is a far more useful feature than having 'pretty eyes'.

Austin

Symon wrote:
>
>Taken together, these two 50 ohm lines make a 100 ohm
>differential pair. At one single pin you've got a
>12.5pF capacitor being driven from 50 ohms. If you view
>the pair together, you've got 6.25pF driven by 100 ohms.
>The return loss is the same in both cases. As is the rise
>time (RC = 625ps). So, Altera's 6.1pF per pin turns into
>3.05pF when viewed as the termination to a pair.
>
nice explanation...

Best wishes on getting Austin to stop with his
"but it's really half, differentially" handwaving.

I've tried before, with results similar to that
"but it goes to Eleven" bit from "Spinal Tap".

>
>a way to improve things is to drive this capacitance
>with a lower impedance
>

 Also, when you've got plenty of drive margin, a differential
attenuator ahead of the FPGA (with internal termination) works
nicely to attenuate the reflection, and also makes for a convenient
differential probe point.  If you have 6dB to spare, even the most
horrible of loads presents at least 12dB return loss, with the probe
seeing 1/4 the reflection voltage of the original circuit.(however, the
attenuator doesn't lower the drive impedance as does your suggestion )

Brian

Austin,
>
>Lots of scope shots are available (ask your FAE).
>
Then why not publish them, along with a comparison of IBIS/HSPICE
simulations versus the real world measurements?

>
>But, I am sure our Marketing Folks will be rolling our scope shots
>as part of pitch-packs, etc. for those who are unable or unwilling
>to do the SI engineering that their job requires of them.
>

Let's see if I've got this straight [1]:

A) Xilinx publicly posts in FPGA and SI forums touting their
   real world X vs. A package testing, and asks for feedback [2]

B) Forum users post some suggested measurements, which a
   certain Xilinx employee says they can make

C) Two months later, when asked when said measurements might
   be published, the very same Xilinx employee cops an attitude

>
>Get the ML450 board, or ask for the documentation.
>

 That would be the same manual (UG077 v1.2) that mentions a
HyperTransport compliant DUT interface connector, without
pointing out that the the specified V4 FPGA Cin is 5x the
allowed HyperTransport max Cin for a 1 Gbps part ???

 As to why that matters: a HyperTransport test probe attempting
to monitor the input link to the FPGA can't function properly
because Cin reflections off the FPGA would prevent the probe from
properly clocking the data at the mid T-line probe sampling point.

 There are ways around this, but life would be easier if Xilinx
actually bothered to meet the spec in the first place.

  Lacking that, proper documentation of your part's shortcomings,
and how and when to work around them, would be appropriate.


Brian


[1] Speaking of those unable to perform the SI engineering that is
required of them : when might we expect publication of characterized
static DCI power and DCI impedance modulation limits for the five year
old Virtex2 FPGA family ?

[2]
http://groups-beta.google.com/group/comp.arch.fpga/msg/d1004ae1fdca9825?hl=en

Brian,

All I am trying to point out is that the load is 6.25pF + 100 ohms, not 
12.5pF + 100 ohms.

When folks wave their arms and state 12.5pF is the LVDS load, they are 
miss-stating it.

Simple point.

And once you do the simulations, or look at the actual waveforms, you 
realize that it is mostly just a beauty contest.  In communications 
theory, excess bandwidth in the channel only adds to the error rate (due 
to noise).  Some band limiting is a good thing.  Too much is a bad thing 
(eg using the LVDS at 1.3 Gbs where it wasn't designed to be used, that 
is where our MGTs are to be used).

Austin

Brian,

Sigh.

See below.

Austin

Brian Davis wrote:

> Austin,
> 
>>Lots of scope shots are available (ask your FAE).
>>
> 
> Then why not publish them, along with a comparison of IBIS/HSPICE
> simulations versus the real world measurements?
All I can say, is that they are coming.  Just takes awhile.  Right now 
we have much more important things to do: tout our power advantage, our 
static current advantage, our speed advantage, our MGT advantage, our 
PPC advantage, our SI packaging breakthrough ...
Showing an IBIS simulation of a five year old interface is just not high 
on our list -- too many customers use it, and are perfectly delighted 
with it.  We do not want to be defocused and stop pointing out the areas 
where we are clearly superior.
> 
> 
>>But, I am sure our Marketing Folks will be rolling our scope shots
>>as part of pitch-packs, etc. for those who are unable or unwilling
>>to do the SI engineering that their job requires of them.
>>
> 
> 
> Let's see if I've got this straight [1]:
> 
> A) Xilinx publicly posts in FPGA and SI forums touting their
>    real world X vs. A package testing, and asks for feedback [2]
Sure.
> 
> B) Forum users post some suggested measurements, which a
>    certain Xilinx employee says they can make
I did. Yes.
> 
> C) Two months later, when asked when said measurements might
>    be published, the very same Xilinx employee cops an attitude
OK, so I was snippy.  I am told that the measurements will be done, but 
again, it isn't a high priority.
> 
> 
>>Get the ML450 board, or ask for the documentation.
>>
> 
> 
>  That would be the same manual (UG077 v1.2) that mentions a
> HyperTransport compliant DUT interface connector, without
> pointing out that the the specified V4 FPGA Cin is 5x the
> allowed HyperTransport max Cin for a 1 Gbps part ???
True:  we are not an ASIC/ASSP.  That is the one area where they win 
(they can make these specs as tight as they please).  But guess what? 
We are growing, increasing sales, and ASICs are not.  Our real 
competition now is no longer other FPGA companies; it is the ASIC/ASSP 
providers.  We can supply features and circuits on technologies they 
can't (yet).  Who has 10 Gbs transceivers?  Who has the lowest power 
405PPC?  Who has the lowest power/highest performance DSP48 blocks for 
DSP applications?  We do, they don't.
> 
>  As to why that matters: a HyperTransport test probe attempting
> to monitor the input link to the FPGA can't function properly
> because Cin reflections off the FPGA would prevent the probe from
> properly clocking the data at the mid T-line probe sampling point.
I claim in a real system, with a compliant transmitter, there will be 
sufficient return loss matching to make the eye visible, and useful. 
But, I agree, that in some cases, what you see is not what you get. 
That can happen with a simple single ended input pin, and is definitely 
true about 1Gbs, where observing it, breaks it (often).  I think that 
there is a whole class of people out there who have to see it to believe 
it.  OK.  But, they should get used to the fact that none of the test 
equipment is really fast enough to show them what they want to see.  And 
it is only getting worse.
> 
>  There are ways around this, but life would be easier if Xilinx
> actually bothered to meet the spec in the first place.
Already explained why we can't do that:  35 IO standards in one pin has 
to make some compromises.
> 
>   Lacking that, proper documentation of your part's shortcomings,
> and how and when to work around them, would be appropriate.
We got all that.  That is what the user's guide is for.  That is what 
the datasheet is for.  Should we place a billboard on 101 South that 
states the IOB pin capacitance is ~ 12pF?  It is already in the 
datasheet.  So is the MGT, PPC, DSP48, etc.  What do you think we should 
spend time on?
> 
> 
> Brian
> 
> 
> [1] Speaking of those unable to perform the SI engineering that is
> required of them : when might we expect publication of characterized
> static DCI power and DCI impedance modulation limits for the five year
> old Virtex2 FPGA family ?
I think all this is now covered between data sheets, user's guides, and 
technical answers on our website.  Let me know if there is something 
missing between those three resources.

Generally speaking, if we don't specify it, then you are on your own to 
use it there.  For example, if you chose to set the resistance to 100 
ohms, to match a 100 ohm single ended line, we are not going to claim we 
meet any standard (there isn't any), and we aren't going to spend time 
characterizing all the silicon for it.  I believe we state the range of 
the resistance from 40 ohms to 150 ohms, but when you use it at anything 
other than 50 ohms, you are required to check it out (I would run the 
spice simulations -- you may request impedances other than 50 ohms for 
the spice models of DCI, 40, 50, 68, and 75 are the ones we have if I 
recall correctly), as that is not any one of the 35 IO standards that we 
designed the IOB to support.

A small change, such as using the DCI at 68 ohms instead of 50 ohms is 
used by quite a few (to save power).  You can characterize it if you 
need to, and if you feel there is a benefit you can derive, but unusual 
usage of a feature in an area it was not intended to be used (not 
specified), is not guaranteed.

Thank you all for responses.  I didn't mean to start a spark, even
though I was curious about what Stratix/II could do in comparison.

I'm now leaning toward doing it - parts of core @360, DDR data output
@360 (720, effectively) along with forwarded clock @360.  I'd be
running simulation to make sure there isn't any big issue at 720Mbps,
but since it's much lower than 1.2Gbps, I'm optimistic.

Can't say Altera is out of running, however.  I just wanted to make
sure I could do it in some FPGA device before committing to the
interface.  

Thanks again.

"Brian Davis" <brimdavis@aol.com> wrote in message
news:1115862089.794227.150660@f14g2000cwb.googlegroups.com...
>
> Best wishes on getting Austin to stop with his
> "but it's really half, differentially" handwaving.
>
> I've tried before, with results similar to that
> "but it goes to Eleven" bit from "Spinal Tap".
>
Brian, LOL, I'm beginning to feel the same way. It's interesting that almost
all the PCB differential pairs I've seen are edge coupled striplines or
microstrips, very few are broadside coupled. Of course, usually with edge
coupled lines most of the coupling is to the ground plane, and very little
between the conductors. So, it's much more like two 50 Ohm lines rather than
a 100 Ohm pair. Not that it makes any difference, of course.
> >
> >a way to improve things is to drive this capacitance
> >with a lower impedance
> >
>
>  Also, when you've got plenty of drive margin, a differential
> attenuator ahead of the FPGA (with internal termination) works
> nicely to attenuate the reflection, and also makes for a convenient
> differential probe point.  If you have 6dB to spare, even the most
> horrible of loads presents at least 12dB return loss, with the probe
> seeing 1/4 the reflection voltage of the original circuit.(however, the
> attenuator doesn't lower the drive impedance as does your suggestion )
>
Yep!
Cheers, Syms.

Austin Lesea wrote:

<snip>
>>  There are ways around this, but life would be easier if Xilinx
>> actually bothered to meet the spec in the first place.
> 
> Already explained why we can't do that:  35 IO standards in one pin has 
> to make some compromises.

  Perhaps it is time to make some pins less "jack of all trades, master 
of none", and provide some with more focus ?

-jg

Jim,

It is something we agonize over everytime we look at a new family.

Should we add IO standard specific IOB's?  How many?  How are they to be 
organized?

What should the IO/CLB ratio be?

Or, should we continue with the present plans (if it ain't broke, don't 
fix it)?

What business did we lose because we could not meet a customer's 
requirement?  How do we know we even lost any business at all?

We did add MGTs (and PPC's, EMAC's, DSP48's, ECC_BRAM's, FIFO_BRAM's, 
etc), so it isn't like we are not looking at adding new things, or 
mixing things up (the patented ASMBL architecture for example).

360 MHz, 720 Mbs DDR LVDS is now over five years old as something that 
either X or A has provided with their devices.  One can argue the fine 
points, but as a gross capability, it has been there for quite awhile.

Austin

Jim Granville wrote:

> Austin Lesea wrote:
> 
> <snip>
> 
>>>  There are ways around this, but life would be easier if Xilinx
>>> actually bothered to meet the spec in the first place.
>>
>>
>> Already explained why we can't do that:  35 IO standards in one pin 
>> has to make some compromises.
> 
> 
>  Perhaps it is time to make some pins less "jack of all trades, master 
> of none", and provide some with more focus ?
> 
> -jg
>