Virtex4 running at 360Mhz DDR
in [FPGA]
|
Next: FPGA Boards
From: fastgreen2000 on 10 May 2005 14:48 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.
From: Symon on 10 May 2005 15:02 <fastgreen2000(a)yahoo.com> wrote in message news:1115750937.589232.47940(a)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.
From: fastgreen2000 on 10 May 2005 15:30 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?
From: Symon on 10 May 2005 16:26 <fastgreen2000(a)yahoo.com> wrote in message news:1115753454.386148.6960(a)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.
From: John_H on 10 May 2005 18:26
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(a)yahoo.com> wrote in message news:1115750937.589232.47940(a)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. |