FPGARelated.com
Forums

RocketIO success?

Started by Paul Smith November 19, 2004
I'm considering the V2pro series for several projects.

I've heard from someone with experience that there are problems with the 
RocketIO when a lot of other things are happening on the chip.  This is 
thought to be a problem with the V2pro package.  The evaluation boards 
only implement the RocketIO without a lot of other things going on in 
the part.

Can anyone provide an example of a successful RocketIO implementation on 
a real board that also has a lot of parallel IO and heavy use of 
internal block RAM, etc?

Paul Smith
Indian University Physics

Paul,

There are many such applications that are successful, and I will let 
others respond here to that point.

As to the use of the MGTs and also using the parallel IOs at or near 
their SSO guideline limits:  yes, this can be an issue.  Blame in on the 
package, blame it on the board, blame it on Xilinx by all means (heck, 
we put the two in the same package didn't we), but be aware that the 
customer does have ultimate control over their destiny.

What do I mean by that?  Well, if you need to use many IOs, near the SSO 
limits, next to the MGTs, with lots of attenuation on the MGT signals, 
you should probably be doing a lot of pcb power distribution system 
simulations, (not to mention full hspice sims of the MGT channels as 
well!).  You should also be looking carefully at all sources of coupling 
(cross talk, etc.) not just on the board (connectors, vias, grounding, 
package).  Perhaps, one would say that the use of virtual grounds (IOs 
intentionally set to drive a '0' and then externally grounded) is a good 
idea bracketing the MGT IOs if simulations are showing a lot of ground 
and Vcco bounce due to all of the IOs switching?

Here, "a lot" is defined as more than 100 mV peak to peak.  I mean, when 
the core voltage is 1.5 volts, or even 1.2 volts, 100 mV of ground 
bounce is now a significant factor, and not just for the MGTs!  Any 
bounce not addressed increases the system jitter, and hence requires 
more timing slack for a design to operate reliably.  Perhaps you need to 
double up on ground planes for lowering the return inductance?

Xilinx FAEs are more than willing to help customers with challenging SI 
issues.  The user's guides, the demonstration boards, and the 
RocketLabs(tm) are all their to help you succeed.  These represent best 
practices that should be transferable to your applications.

We would much rather have a successful design using lots of chips, than 
an unsuccessful design with cross talk, ground bounce, and jitter problems.

Austin

Paul Smith wrote:
> > I'm considering the V2pro series for several projects. > > I've heard from someone with experience that there are problems with the > RocketIO when a lot of other things are happening on the chip. This is > thought to be a problem with the V2pro package. The evaluation boards > only implement the RocketIO without a lot of other things going on in > the part. > > Can anyone provide an example of a successful RocketIO implementation on > a real board that also has a lot of parallel IO and heavy use of > internal block RAM, etc? > > Paul Smith > Indian University Physics >

Austin Lesea wrote:

(snip)

> Here, "a lot" is defined as more than 100 mV peak to peak. I mean, when > the core voltage is 1.5 volts, or even 1.2 volts, 100 mV of ground > bounce is now a significant factor, and not just for the MGTs! Any > bounce not addressed increases the system jitter, and hence requires > more timing slack for a design to operate reliably. Perhaps you need to > double up on ground planes for lowering the return inductance?
Some time ago I had suggested using thicker copper to reduce inductance, before realizing that it really doesn't help. (The inductance of a rectangular bar is proportional to the sum of the height and width.) I believe that parallel ground planes will have the same effect. The reduction in resistance might help, though. -- glen
Glen,

It does help.  Two inductors in parallel is half the inductance.

Place them with the power planes next to them, and you also get added 
bypass capacitance (power/ground sandwiches).

Austin

glen herrmannsfeldt wrote:
> > > Austin Lesea wrote: > > (snip) > >> Here, "a lot" is defined as more than 100 mV peak to peak. I mean, >> when the core voltage is 1.5 volts, or even 1.2 volts, 100 mV of >> ground bounce is now a significant factor, and not just for the MGTs! >> Any bounce not addressed increases the system jitter, and hence >> requires more timing slack for a design to operate reliably. Perhaps >> you need to double up on ground planes for lowering the return >> inductance? > > > Some time ago I had suggested using thicker copper to reduce > inductance, before realizing that it really doesn't help. > (The inductance of a rectangular bar is proportional to the > sum of the height and width.) I believe that parallel ground > planes will have the same effect. The reduction in resistance > might help, though. > > -- glen >

Austin Lesea wrote:


> It does help. Two inductors in parallel is half the inductance.
> Place them with the power planes next to them, and you also get added > bypass capacitance (power/ground sandwiches).
That was what I thought, to, until someone reminded me that increasing the wire size for coil inductors doesn't decrease inductance proportionally. It is the mutual inductance, the interaction of the magnetic field between the two, that changes it. If you have alternating ground and power, and the currents are equal (and opposite) then it might be true. (That is, more transmission line like, and less wire like.) For I/O pin current, going out traces that can't cancel the magnetic field of the ground plane current, I think it isn't true. The additional capacitance does help, though. -- glen
Glen,
That's right. The inductance depends on the area of the loop the current
takes. The plane inductance on it's own isn't important, it's the loop area
of the trace and the plane that matters.
What another plane can do is lower the loop area. If a trace always close to
one or other tightly coupled planes, the loop area is small. If you only
have one ground plane, it can be harder to keep the trace close to it on a
multi-layer board.
Also, forget about making bypass capacitors out of power and ground planes
at the frequencies of interest for FPGAs. The tiny amount you can make is
pissed away by the inductance of the vias, PCBs traces and FBGA traces.
Best, Syms.

"glen herrmannsfeldt" <gah@ugcs.caltech.edu> wrote in message
news:cnm07f$nv3$1@gnus01.u.washington.edu...
> > > Austin Lesea wrote: > > > > It does help. Two inductors in parallel is half the inductance. > > > Place them with the power planes next to them, and you also get added > > bypass capacitance (power/ground sandwiches). > > That was what I thought, to, until someone reminded me that increasing > the wire size for coil inductors doesn't decrease inductance > proportionally. It is the mutual inductance, the interaction of the > magnetic field between the two, that changes it. > > If you have alternating ground and power, and the currents are equal > (and opposite) then it might be true. (That is, more transmission line > like, and less wire like.) For I/O pin current, going out traces > that can't cancel the magnetic field of the ground plane current, > I think it isn't true. The additional capacitance does help, though. > > -- glen >
On Fri, 19 Nov 2004 11:37:39 -0500, Paul Smith wrote:

> > I'm considering the V2pro series for several projects. > > I've heard from someone with experience that there are problems with the > RocketIO when a lot of other things are happening on the chip. This is > thought to be a problem with the V2pro package. The evaluation boards > only implement the RocketIO without a lot of other things going on in > the part. > > Can anyone provide an example of a successful RocketIO implementation on > a real board that also has a lot of parallel IO and heavy use of > internal block RAM, etc? > > Paul Smith > Indian University Physics
One of my InfiniBand Core customers is using RocketIO on the V2P20-6, it's working fine for them. http://www.polybus.com/ib_link_layer_website/

Symon wrote:

> That's right. The inductance depends on the area of the loop the current > takes. The plane inductance on it's own isn't important, it's the loop area > of the trace and the plane that matters.
OK, yes, I agree. A ground plane closer to the signal lines will reduce the inductance.
> What another plane can do is lower the loop area. If a trace always close to > one or other tightly coupled planes, the loop area is small. If you only > have one ground plane, it can be harder to keep the trace close to it on a > multi-layer board.
> Also, forget about making bypass capacitors out of power and ground planes > at the frequencies of interest for FPGAs. The tiny amount you can make is > pissed away by the inductance of the vias, PCBs traces and FBGA traces.
Well, put more vias in parallel, which will reduce the inductance somewhat. The inductance should depend on the length, but it is still likely higher than one would like it to be. -- glen
Hi Paul,
I am at CERN, Geneva. We recently successfully tested a VME 9U Board which
has 9 V2Pros and 3 Alteras.
We are using all 8 Rocket IOs present on the V2P7s in each of them except
for the last one in which we only use 6 of them (big deal ;) )
We are running the Xilinxs at about 80-85% of resource utilization(logic)
and use about 60-70% of Block RAMs. This will go further up as we proceed
with the production of the Board and we are confident that our board will
eventually do what it is supposed to !
Of course there were problems, some on the Xilinxs, some on the board. But
most of the problems (or rather our problems) we traced to the Refernce
Clock (mostly jitter). I was myself new to the Rocket IOs when i started
this project and so
there was a lot of trial and error. But eventually we did make the board
work.
We have an article in the current Xcell issue:
http://www.xilinx.com/publications/xcellonline/xcell_51/xc_particle51.htm

If there are specific questions, then maybe we can try to answer them
Good luck,
Adarsh

"Paul Smith" <ptsmith@nospam.indiana.edu> wrote in message
news:cnl7em$9q3$1@hood.uits.indiana.edu...
> > I'm considering the V2pro series for several projects. > > I've heard from someone with experience that there are problems with the > RocketIO when a lot of other things are happening on the chip. This is > thought to be a problem with the V2pro package. The evaluation boards > only implement the RocketIO without a lot of other things going on in > the part. > > Can anyone provide an example of a successful RocketIO implementation on > a real board that also has a lot of parallel IO and heavy use of > internal block RAM, etc? > > Paul Smith > Indian University Physics >
Hi,

Although I don't dispute some of the success stories of RocketIO, I
would like to point out of the following:

1. The reference clock requirement for RocketIO is very tight
(=expensive). Xilinx has been recommending an oscillator from EPSON
with very low jitter.

2. If your application is less than or equal to 6.5Gb/s, do not use
RocketIO. You will be paying a premium for a 10Gb/s transceiver.
Altera and Lattice have better alternatives.

3. Lastly, just to make it clear:
V2Pro uses an "old" transceiver, which has poor performance with
jitter tolerance and transfer, although it has very good jitter
generation
V2ProX uses RocketIO

10Gb/s technology for backplanes is here, but there are a lot of
challenges. One must utilize new backplane (PCB) material, new
connectors, new test/measurement equipment, and be extermely careful
with the board design since every little discontinuity will contribute
to eye closure. Obviously reference backplanes/boards for 10Gb/s exist
today, but the question is whether they are feasible and
cost-effective for production.

Just my two cents,

Zhi

Paul Smith <ptsmith@nospam.indiana.edu> wrote in message news:<cnl7em$9q3$1@hood.uits.indiana.edu>...
> I'm considering the V2pro series for several projects. > > I've heard from someone with experience that there are problems with the > RocketIO when a lot of other things are happening on the chip. This is > thought to be a problem with the V2pro package. The evaluation boards > only implement the RocketIO without a lot of other things going on in > the part. > > Can anyone provide an example of a successful RocketIO implementation on > a real board that also has a lot of parallel IO and heavy use of > internal block RAM, etc? > > Paul Smith > Indian University Physics