I'm about to use Virtex 4, and wonder if this is achievable. All literature seems to indicate that it is, but I'd like hear what others think and perhaps point out where I need to be careful in the design. I'd be receiving an LVDS clock pair @ 360Mhz, running part of the internal logic at 360. This internal logic includes DSP48 slices (but need to be pipelined in the fabric since I need more than 48-bit 'C' input for adder). Preliminary testing indicates that it can go above 360 with light user intervention. One thing I'm cautious about is, the rest of logic runs much slower, at 90Mhz. Initially was thinking of using /4 version, but Peter Alfke's post regarding added skews due to loading differences in DCM outputs is making me think about it carefully. For otuput, I'd be using ODDR to multiplex 360 Mhz logic, to send the data out at 360Mhz DDR (so the data can look like 360Mhz 'clock'). Data is LVDS, so is the forwarded LVDS clock pair @ 360Mhz. The receiving device will use both edges of the forwarded 360 Mhz clock to sample the data. Clock to output delay is not good, 3+ ns, but since the clock will be forwarded and will incur effectively the same delay as data (other than IOB-IOB clk skew), as long as I send out 180 deg version of internal 360 clock using ODDR, it should be ok. Not sure what kind of SI issue there will be, however. I have an option of running it at 180Mhz if 360 is risky. External device will be different. Am I playing too safe by going to 180? Will 360 be a challenge? I'd appreciate feedback.
Virtex4 running at 360Mhz DDR
Started by ●May 10, 2005
Reply by ●May 10, 20052005-05-10
<fastgreen2000@yahoo.com> wrote in message news:1115750937.589232.47940@f14g2000cwb.googlegroups.com...> I'm about to use Virtex 4, and wonder if this is achievable. All > literature seems to indicate that it is, but I'd like hear what others > think and perhaps point out where I need to be careful in the design. > > I'd be receiving an LVDS clock pair @ 360Mhz, running part of the > internal logic at 360. This internal logic includes DSP48 slices (but > need to be pipelined in the fabric since I need more than 48-bit 'C' > input for adder). Preliminary testing indicates that it can go above > 360 with light user intervention. One thing I'm cautious about is, the > rest of logic runs much slower, at 90Mhz. Initially was thinking of > using /4 version, but Peter Alfke's post regarding added skews due to > loading differences in DCM outputs is making me think about it > carefully. >Clock everything at the higher rate, use a clock enable for the /4. IIRC V4 can use a global clock net as an enable net. Well done Xilinx!> > For otuput, I'd be using ODDR to multiplex 360 Mhz logic, to send the > data out at 360Mhz DDR (so the data can look like 360Mhz 'clock'). > Data is LVDS, so is the forwarded LVDS clock pair @ 360Mhz. The > receiving device will use both edges of the forwarded 360 Mhz clock to > sample the data. Clock to output delay is not good, 3+ ns, but since > the clock will be forwarded and will incur effectively the same delay > as data (other than IOB-IOB clk skew), as long as I send out 180 deg > version of internal 360 clock using ODDR, it should be ok. Not sure > what kind of SI issue there will be, however. > > I have an option of running it at 180Mhz if 360 is risky. External > device will be different. Am I playing too safe by going to 180? Will > 360 be a challenge? >It's certainly within the realms of possibility. I do stuff like this at clocks >300MHz in V2PRO, with >600 Mbit outputs. So, gamble! You'll learn enough to get another job if it goes bad! ;-) Cheers, Syms.
Reply by ●May 10, 20052005-05-10
Thanks for the reply. Questions about the clock enable : - Is there an easy way to specify it as clock enable, so the tool knows about it for timing analysis, and so you don't have to specify multi-cycle constraints for gobs of FFs? - And how do you make the enable signal go on the global clock net?
Reply by ●May 10, 20052005-05-10
<fastgreen2000@yahoo.com> wrote in message news:1115753454.386148.6960@f14g2000cwb.googlegroups.com...> Thanks for the reply. > > Questions about the clock enable : > > - Is there an easy way to specify it as clock enable, so the tool knows > about it for timing analysis, and so you don't have to specify > multi-cycle constraints for gobs of FFs? >In Synplify there's an attribute, syn_direct_enable . Check out the reference manual. I imagine other synthesis tools provide something similar. In the UCF you then do something like:- NET "ENABLE_NET_NAME" TNM=FFS "ENABLED_FFS"; TIMESPEC TS1000 = FROM : ENABLED_FFS : TO : ENABLED_FFS : 11.1ns;> > - And how do you make the enable signal go on the global clock net? >You ask someone from Xilinx! I've not yet started my V4 design. I just remembered that from the marketing spiel we had. Cheers, Syms.
Reply by ●May 10, 20052005-05-10
Look at http://www.xilinx.com/products/virtex4/capabilities/selectio.htm#chipsync and http://www.xilinx.com/products/design_resources/conn_central/resource/ssio_resources.htm for discussions on the 1 Gbit/s/pin Virtex-4 differential I/O and you may get a better feel for the margins you can get in your design. If all your LVDS are at the same clock rate, the DCM skews shouldn't be a problem and could easily be registered back to the slower domain if the skews were an issue. Xilinx went to great lengths to make the Virtex-4 I/O capable of some pretty high speeds without taxing the designer. <fastgreen2000@yahoo.com> wrote in message news:1115750937.589232.47940@f14g2000cwb.googlegroups.com...> I'm about to use Virtex 4, and wonder if this is achievable. All > literature seems to indicate that it is, but I'd like hear what others > think and perhaps point out where I need to be careful in the design. > > I'd be receiving an LVDS clock pair @ 360Mhz, running part of the > internal logic at 360. This internal logic includes DSP48 slices (but > need to be pipelined in the fabric since I need more than 48-bit 'C' > input for adder). Preliminary testing indicates that it can go above > 360 with light user intervention. One thing I'm cautious about is, the > rest of logic runs much slower, at 90Mhz. Initially was thinking of > using /4 version, but Peter Alfke's post regarding added skews due to > loading differences in DCM outputs is making me think about it > carefully. > > For otuput, I'd be using ODDR to multiplex 360 Mhz logic, to send the > data out at 360Mhz DDR (so the data can look like 360Mhz 'clock'). > Data is LVDS, so is the forwarded LVDS clock pair @ 360Mhz. The > receiving device will use both edges of the forwarded 360 Mhz clock to > sample the data. Clock to output delay is not good, 3+ ns, but since > the clock will be forwarded and will incur effectively the same delay > as data (other than IOB-IOB clk skew), as long as I send out 180 deg > version of internal 360 clock using ODDR, it should be ok. Not sure > what kind of SI issue there will be, however. > > I have an option of running it at 180Mhz if 360 is risky. External > device will be different. Am I playing too safe by going to 180? Will > 360 be a challenge? > > I'd appreciate feedback.
Reply by ●May 10, 20052005-05-10
"fastgreen2", your design looks just right for the Virtex-4 capabilities. Keep the pc-board data skew reasonable. You can use a DCM to divide the clock, or you can go with the CE scheme, whatever you prefer. Should work with a reasonable amount of attention to detail. Peter Alfke, Xilinx Applications (I passed this by several experts...)
Reply by ●May 10, 20052005-05-10
"John_H" <johnhandwork@mail.com> wrote in message news:fyage.14$p%5.114@news-west.eli.net...> Look at > http://www.xilinx.com/products/virtex4/capabilities/selectio.htm#chipsync > and > >http://www.xilinx.com/products/design_resources/conn_central/resource/ssio_resources.htm> > for discussions on the 1 Gbit/s/pin Virtex-4 differential I/O and you may > get a better feel for the margins you can get in your design. > > If all your LVDS are at the same clock rate, the DCM skews shouldn't be a > problem and could easily be registered back to the slower domain if the > skews were an issue. > > Xilinx went to great lengths to make the Virtex-4 I/O capable of somepretty> high speeds without taxing the designer. > >You might also like to look at this link. http://www.altera.com/products/devices/stratix2/utilities/st2-signal_integrity.html?f=tchio&k=g3 Altera claims their parts have a better LVDS 'eye' because they have superior (i.e. less) pin capacitance. The capacitance gives a lot of ISI. I've been bitten by Xilinx FPGA pin capacitance before, albeit in a slightly different situation. I guess it's the inevitable consequence of trying to fit every possible I/O standard onto every pin. If I'm reading the page properly, Altera mitigate this by having different sets of pins which are capable of different I/O standards. Separate 'Rocket I/Os' also solve this problem. Of course, the OP's data rate is significantly lower than the rate shown in the link, so should be no problem! ;-) Cheers, Syms.
Reply by ●May 10, 20052005-05-10
"Symon" <symon_brewer@hotmail.com> wrote in message news:42813fd3_2@x-privat.org... <snip>> You might also like to look at this link. >http://www.altera.com/products/devices/stratix2/utilities/st2-signal_integrity.html?f=tchio&k=g3> > Altera claims their parts have a better LVDS 'eye' because they have > superior (i.e. less) pin capacitance. The capacitance gives a lot of ISI.<snip> But doesn't the Altera information use external LVDS terminations and monitor external to the part rather than internal terminations and the eye seen by the receiver? By looking outside the package that has an embedded differential termination, isn't the data skewed?
Reply by ●May 10, 20052005-05-10
"Symon" <symon_brewer@hotmail.com> wrote in message news:4281198e$1_2@x-privat.org...> > > > - And how do you make the enable signal go on the global clock net? > > > You ask someone from Xilinx! I've not yet started my V4 design. I just > remembered that from the marketing spiel we had. > Cheers, Syms. >Hmmm, I might have given you a bum steer there. I just looked at the FPGA editor view of V4 and it seems there's NOT a path from the GBUFs to the CLB CE. You can control a CE pin on the GBUF, but that's about as useful as a chocolate teapot in this case. Sorry about that, Syms.
Reply by ●May 10, 20052005-05-10
"John_H" <johnhandwork@mail.com> wrote in message news:OZbge.15$p%5.117@news-west.eli.net...> "Symon" <symon_brewer@hotmail.com> wrote in message > news:42813fd3_2@x-privat.org... > > <snip> > > > You might also like to look at this link. > > >http://www.altera.com/products/devices/stratix2/utilities/st2-signal_integrity.html?f=tchio&k=g3> > > > Altera claims their parts have a better LVDS 'eye' because they have > > superior (i.e. less) pin capacitance. The capacitance gives a lot ofISI.> > <snip> > > But doesn't the Altera information use external LVDS terminations and > monitor external to the part rather than internal terminations and the eye > seen by the receiver? By looking outside the package that has an embedded > differential termination, isn't the data skewed? > >I don't think so John. I think the whole white paper is based on a simulation using the published Xilinx IBIS files. The terminations are simulated as being on-chip. The Figure 1. in this document:- http://www.altera.com/literature/wp/signal-integrity_s2-v4.pdf is in the mind of an IBIS simulator, I guess. So, there are no physical measurements. Their data doesn't surprise me; 12.5pF of pin capacitance will really screw with inter-symbol interference at Gbit rates. Best, Syms.