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?
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.
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.
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, 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.
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:
If there are specific questions, then maybe we can try to answer them Good luck, Adarsh
Although I don't dispute some of the success stories of RocketIO, I would like to point out of the following:
The reference clock requirement for RocketIO is very tight (=expensive). Xilinx has been recommending an oscillator from EPSON with very low jitter.
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.
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.