| Author |
Message |
Viktor Steinlin
Guest
|
 Posted:
Fri Dec 03, 2004 2:32 am Post subject:
Virtex-II PRO, DDR2 SDRAM, RocketIO |
|
|
Hello,
I'm about to design a frame grabber where I need high memory bandwidth.
Does anybody has already implemented a design with Xilinx Virtex-II PRO and
DDR2 SDRAM. Have you encountered major problems with DDR2 controller
provided by Xilinx EDK? Some design hints?
What about Rocket IO. Did you encounter problems on connecting two FPGAs
over short (50cm) cable? Or does it work on first try, if the layout is
done properly?
Thanks for all infos.
Viktor Steinlin
---
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.802 / Virus Database: 545 - Release Date: 11/26/2004 |
|
| Back to top |
|
 |
Marc Randolph
Guest
|
| Posted:
Sat Dec 04, 2004 8:41 pm Post subject:
Re: Virtex-II PRO, DDR2 SDRAM, RocketIO |
|
|
Viktor Steinlin wrote:
| Quote: | Hello,
I'm about to design a frame grabber where I need high memory bandwidth.
Does anybody has already implemented a design with Xilinx Virtex-II PRO and
DDR2 SDRAM. Have you encountered major problems with DDR2 controller
provided by Xilinx EDK? Some design hints?
What about Rocket IO. Did you encounter problems on connecting two FPGAs
over short (50cm) cable? Or does it work on first try, if the layout is
done properly?
|
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 |
|
| Back to top |
|
|
Viktor Steinlin
Guest
|
| Posted:
Tue Dec 07, 2004 1:02 am Post subject:
Re: Virtex-II PRO, DDR2 SDRAM, RocketIO |
|
|
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
"Marc Randolph" <mrand@my-deja.com> wrote in message
news:w5udnSU8EtsLRyzcRVn-vQ@comcast.com...
| Quote: | Viktor Steinlin wrote:
Hello,
I'm about to design a frame grabber where I need high memory bandwidth.
Does anybody has already implemented a design with Xilinx Virtex-II PRO
and DDR2 SDRAM. Have you encountered major problems with DDR2 controller
provided by Xilinx EDK? Some design hints?
What about Rocket IO. Did you encounter problems on connecting two FPGAs
over short (50cm) cable? Or does it work on first try, if the layout is
done properly?
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
|
---
Checked by AVG anti-virus system (http://www.grisoft.com).
Version: 6.0.802 / Virus Database: 545 - Release Date: 11/26/2004 |
|
| Back to top |
|
|
Marc Randolph
Guest
|
| Posted:
Tue Dec 07, 2004 6:14 pm Post subject:
Re: Virtex-II PRO, DDR2 SDRAM, RocketIO |
|
|
Viktor Steinlin wrote:
| Quote: | 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.
|
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.
| Quote: | 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.
|
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.
| Quote: | Did you already use RocketIO? Which speed? Did you encounter any
problems? |
You may be interested in a few other responses to the same question a
few weeks ago:
http://groups.google.com/groups?selm=cnsj5c%24dqr%241%40sunnews.cern.ch
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:
http://www.getFirefox.com/ |
|
| Back to top |
|
|
Hal Murray
Guest
|
| Posted:
Tue Dec 07, 2004 9:45 pm Post subject:
Re: Virtex-II PRO, DDR2 SDRAM, RocketIO |
|
|
| Quote: | 2. Use a low jitter clock reference for the MGT. No PLL or DLL
sources. A cheap crystal osc will do just fine.
|
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. |
|
| Back to top |
|
|
Sean Durkin
Guest
|
| Posted:
Wed Dec 08, 2004 12:14 pm Post subject:
Re: Virtex-II PRO, DDR2 SDRAM, RocketIO |
|
|
Viktor Steinlin wrote:
| Quote: | Hello,
I'm about to design a frame grabber where I need high memory bandwidth.
Does anybody has already implemented a design with Xilinx Virtex-II PRO and
DDR2 SDRAM. Have you encountered major problems with DDR2 controller
provided by Xilinx EDK? Some design hints?
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 |
|
| Back to top |
|
|
Marc Randolph
Guest
|
| Posted:
Thu Dec 09, 2004 6:11 pm Post subject:
Re: Virtex-II PRO, DDR2 SDRAM, RocketIO |
|
|
Hal Murray wrote:
| Quote: | 2. Use a low jitter clock reference for the MGT. No PLL or DLL
sources. A cheap crystal osc will do just fine.
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?
|
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 |
|
| Back to top |
|
|
Tullio Grassi
Guest
|
| Posted:
Mon Dec 13, 2004 3:03 am Post subject:
Re: Virtex-II PRO, DDR2 SDRAM, RocketIO |
|
|
On Tue, 7 Dec 2004, Marc Randolph wrote:
| Quote: | ... 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.
|
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 |
|
| Back to top |
|
|
Al Gosselin
Guest
|
| Posted:
Mon Dec 13, 2004 4:38 am Post subject:
Re: Virtex-II PRO, DDR2 SDRAM, RocketIO |
|
|
Tullio Grassi wrote:
| Quote: | On Tue, 7 Dec 2004, Marc Randolph wrote:
... 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.
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. |
|
| Back to top |
|
|
Marc Randolph
Guest
|
| Posted:
Tue Dec 14, 2004 4:40 am Post subject:
Re: Virtex-II PRO, DDR2 SDRAM, RocketIO |
|
|
Al Gosselin wrote:
| Quote: | Tullio Grassi wrote:
On Tue, 7 Dec 2004, Marc Randolph wrote:
... 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.
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.
|
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 |
|
| Back to top |
|
|
|
|
|
|
FAQ
Memberlist
Register
Profile
Log in to check your private messages
Log in