Virtex-II PRO, DDR2 SDRAM, RocketIO

Howdy Viktor,

I can't help you with the DDR2 SDRAM controller, but for as long as it has been out, I'd be surprised if there were any serious problems with using it.

As for the Rocket I/O over cable, what kind of cable are you going to use? Over what distance? At what speed? With which Xilinx part?

Good luck,

Marc

Hello Marc

The is that for the DDR2 SDRAM controller, the time constraints are such that the higher speed grade is required, which increases the FPGA cost by about $100. We would clock the DDR2 with a clock frequency at the lower bound (say 133 MHz), so that theoretically it should work with the lower speed grade. But we are not quite sure if this would really work. A distributor of Micron memory suggested to use DDR2 because normal DDR would solwly disappear during 2005.

For RocketIO board-to-board communication we plan to use serial ATA cables and connectors, with bandwidth up to 2Gbits/s, with a cable length around

50cm, using XC2VP30.

Did you already use RocketIO? Which speed? Did you encounter any problems?

Regards

Viktor

--
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.802 / Virus Database: 545 - Release Date: 11/26/2004

such

cost by

lower

lower

DDR

Howdy Viktor,

I would agree with the distributor - always go with the newest

*available* DRAM technology you can to insure future availability of the individual ICs. I say available, because if something that is just being rolled out, the big boys will get all the parts and leave none for you.

cables

around

I see that there is a serial ATA II spec out now... I don't know how it compares against the original serial ATA spec, but if it calls for improved cables, that may be something to check into. With the different pre-emphasis and signal swing options that are available with the Rocket I/O, I suspect you will not have any trouble going 50cm on such a cable. If you discovered that running at 2 Gbps didn't provide enough of an data eye, you could channel bond two or four RocketIO's together and run them at a slower speed.

problems?

You may be interested in a few other responses to the same question a few weeks ago:

Part of my response to him is below:

We have successfully used the RocketIO in the V2Pro in a number of applications. There was a small learning curve associated with getting it configured correctly in the HDL, but haven't had any problems with the physical parts. Here are the configurations we've run:

2VP7-6FG456I: dual OC-48 (2.488 Gbps) across 12" of trace and a 3" backplane. 2VP50-5FF1152I: dual GbE user interfaces connected directly to fiber transceivers 2VP4-6FG456I: dual OC-48 (2.488 Gbps) across ~40" of trace and 3" backplane 2VP40-5FF1152I: single GbE backplane interface

The most impressive app is the first one. The FG676 package is less than ideal for Rocket I/O since it is not a flip chip package. Not only that, but we have a 622 MHz global clock driving a little bit of logic, plus the device has a source-sync 4 bit x 622 SDR interface, in addition to something around 40% of the chip running at 311 MHz (including a number of the BRAM's). The rest runs a mix of 77 and 155 MHz. All BRAMs are used. In short, I think we're doing a pretty good job of exploring the limits on that chip, and the MGT keeps running error free, even at industrial temperatures (junction of 100C).

Having used them, here are my suggestions:

1. Follow the Xilnix guidelines for power filtering on the MGT and vccaux.
2. Use a low jitter clock reference for the MGT. No PLL or DLL sources. A cheap crystal osc will do just fine.
3. Use the BREFCLK pin for the MGT if possible.
4. Use the flip-chip package if possible. Not a requirement, but it'll just make signals, ground, and power just that much better.

Even just doing the first two items should result in the MGT working just fine for you.

My opinion changes slightly if you are considering the V2ProX (2.488 to 10 Gbps) devices. They can be made to work (at less than 10 Gbps), but there is some (or at least, was) errata, and possibly some trial and error involved, depending on which mode you are operating in.

Good luck,

Marc

-- Tired of popups and Microsoft security problems? Get the free Mozilla Firefox web browser:

Many of the fast delivery oscillator packages now include a PLL and get programmed at the last minute rather than grinding a special crystal.

What sort of jitter is acceptable? Are the PLLs in such an oscillator good enough if there aren't any other PLLs?

--
The suespammers.org mail server is located in California.  So are all my
other mailboxes.  Please do not send unsolicited bulk e-mail or unsolicited
commercial e-mail to my suespammers.org address or any of my other addresses.
These are my opinions, not necessarily my employer's.  I hate spam.

OK, I'm stupid: Where is this DDR2 SDRAM-controller you are talking about? It's not included in my EDK6.3... is this an add-on-option you bought from Xilinx separately?

I face the same decision (DDR1 vs. DDR2) at the moment... I do not believe, however, that DDR1 will disappear anytime soon... new computers shipped will have DDR2, but you can still buy SDR-SDRAM and even old PS/2-SIMMs today, and these technologies haven't been used in PCs, a.k.a. "the mass market", for quite awhile...

cu, Sean

Howdy Hal,

But there IS another PLL - it's in the RocketIO. If you want to place an analog PLL before the analog RocketIO PLL, you have to know how they are going to act as a pair... and I don't believe there are enough details released on the RocketIO PLL to be able to model that (as if

99% of the people would pull up SPICE to do it anyway).

I view the above point about PLL's as different than the jitter issue - I probably should not have grouped it with the DLL/jitter point since it has little to do with the RocketIO itself - it's really an issue of what the response of one PLL trying to follow another PLL is.

The RocketIO user guide lists a number for allowable jitter (dependant on bitrate... the lowest is 40ps, the highest is 120ps), but doesn't spec the frequency range over which it applies, which is probaby just as important.

Have fun,

Marc

What is your feeling about using RocketIO over 5 meters of copper cable ? Assuming we follow your suggestions and that we get good cables and connectors, what is the data rate that we could reach reliably ?

Thanks,

Tullio Grassi

What kind of copper cable? What sort of drive will you be doing? Any preemphasis?

This is a perfect thing to try in simulation. Set up your drivers, receivers, and cable, then look at some eyes. Don't forget the connectors and the traces on the PC boards.

cable ?

I agree with Al. 5 meters quite a distance, and there are way too many variables and potential gotchas to try to guess at what the limiting factor(s) are in your particular implementation. I'm certainly not saying that it won't work - only that you'll either have to build it and see, or simulate it. The second option is much cheaper, and generally faster.

Good luck,

Marc