Virtex4 running at 360Mhz DDR

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 to
fastgreen2000
Loading thread data ...

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!

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 to
Symon

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 to
fastgreen2000

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;

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 to
Symon

Look at

formatting link
and

formatting link

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.

Reply to
John_H

"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 to
Peter Alfke

formatting link

pretty

You might also like to look at this link.

formatting link

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 to
Symon

formatting link

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 to
John_H

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 to
Symon

formatting link

ISI.

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:-

formatting link
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.

Reply to
Symon

Symon,

I am suprised at you. Their white paper clearly shows the simualtion is done with the external termination, and not the internal one.

Use the internal one, and the capacitance does not matter (do the sim yourself if you do not believe me).

Of course, you really should use the LVDS where it is specified. If you want 1.3 Gbs, use our MGTs .... oh, I forgot, then do not have 2-GX parts ....

The fact that their LVDS works up to 1.3 Gbs in simulation is nice, but can it be used in a real application on a real board?

We have our ML450 Network Board for V4 to demonstrate 1 Gbs DDR interfaces, and it works just fine. Ask your FAE for a demo, or go online and buy the board.

Austin

Sym>

formatting link

Reply to
austin

Austin,

Quoting Symon's last response [1] to such a misleading, incomplete, and inaccurate claim:

And, just recently, some other Austin from Xilinx wrote [2]:

Exactly the point I was trying to make a couple years back, with which you disagreed so virulently. Rather than repeat my explanation of why high input C is bad, just re-read [3].

[ I agree that if the cap is right at the receiver in a point-point connection, all it will see is the filtered edge on the initial transition; but ignoring the aftereffects of that massive reflection is foolhardy. ]

The last time you said that, I asked [4]:

Also from that thread, I suggested some other measurements to make on your "A vs. X" test platform:

When might we see some published data on those, particularly items C & D?

Brian

[1]
formatting link
[2]
formatting link
[3]
formatting link
[4]
formatting link
Reply to
Brian Davis

Hmmm, so why do they say in Table 1. "Virtex-4 IBIS Models do Not Have Package Information"? How can they simulate the V4 package parasitics without this? Are you saying they're up to no good? It'd be interesting to see the Xilinx simulation from V4 LVDS output to V4 LVDS input.

I disagree. The Cpin of course limits the rise time at the pin. But also, and maybe worse, the capacitor at the input reflects a whole bunch of energy back down the T-line. The bigger the cap, the more energy is reflected. Some of this energy comes back again to the receiver after hitting the Cpin at the Tx end of the T-line. This causes inter-symbol interference. (Were you running your sim with a perfectly source terminated transmitter?)

Stop changing the subject! You should be a politician! ;-) I did say your Rocket I/Os were a solution! And I bet they don't have 12.5pF of capacitance.

I'm pretty sure you're agreed IBIS simulations are a good idea. Works in simulation, should work in real life, right?

Yep, Xilinx make great parts. They'd be even better with less Cpin though... Bloody customers want it all! ;-) Cheers, Syms.

Reply to
Symon

Brian,

Get the ML450 board, or ask for the documentation.

formatting link

Lots of scope shots are available (ask your FAE).

or,

formatting link
(page 2)

Or, go to one of our RocketLabs and measure it for yourself.

As for the reflection, the LVDS transmitter is also a 100 ohm termination, so reflections are absorbed at the transmitter (when the LVDS is properly done and meets the specifications, which ours do).

Anyone with an IBIS simulator can see all of the above happening, so I really don't want to take this any further - demanding to see scope shots of things is pretty pointless when the simulations are perfectly good (when they are done correctly).

But, I am sure our Marketing Folks will be rolling our scope shots as part of pitch-packs, etc. for those who are unable or unwilling to do the SI engineering that their job requires of them.

Austin

Reply to
Austin Lesea

No you didn't bum steer... you were right initially. CE nets can be put onto a global clock network. Look at the CLB switch box in FPGA Editor again... each CE pin can be driven by a bounce pip (4 stubs in the middle right edge of the switch box), and these 4 bounces can all be driven by the GLK pips on the lower left edge of the switch box. There's your path.

Cheers, Ajay Roopchansingh Xilinx Inc

Reply to
Ajay Roopchansingh

No. Not if this transmitter is a Xilinx FPGA with 12.5pF of parasitic capacitance. The high frequencies see a lower impedance, and so stuff relects back out of the transmitter, exactly the same as at the receiver. This is the point I'm trying to get you to understand. I tell you what, why don't you call that nice Dr. Howard Johnson and ask him?

Here's a quote from National's LVDS manual. "In a good design the connector contributes 2 pF to 3 pF, the trace contributes 2 pF to 3 pF, and the device contributes 4 pF to 5 pF.The total load in such a design is around 10 pF. The flexibility of programmable devices comes at the cost of capacitance. National Bus LVDS products have an I/O capacitance of 5 pF. The I/O capacitance of a programmable device is approximately double or 10 pF. This increase in capacitance will lower the loaded bus impedance, thereby reducing the available noise margin and lowering the reliability of operation in the design."

formatting link

I don't want to see scope shots, I agree I want to see a simulation 'done correctly'. I think I already have on Altera's website. Best regards, Syms.

Reply to
Symon

Make up your mind Austin. On numerous occasions you have recommended that people run simulation of I/O systems to see what should happen, and you have recommened the IBIS models. To suggest that Altera does not know how to run simulations is insulting. Enough!

Philip Freidin

=================== Philip Freidin snipped-for-privacy@fpga-faq.org Host for

formatting link

Reply to
Philip Freidin

Doh, Thanks Ajay. I see it now. Sneaky! Cheers, Syms.

Reply to
Symon

Symon,

What is 12.5pF in series with 12.5pF?

Yes, that is right, 6.25pF differential load, not 12.5pF.

Falling for the A FUD is especially embarrassing when you just repeat things which are factually incorrect.

All these things are taken into account from the simulation.

Austin

Reply to
Austin Lesea

Philip,

  1. They ignored the top comment lines of the IBIS model which instructs them how to model the package (since package modeling is incorrect and wrong in IBIS 3.2).

  1. They used an external resistor instead of the internal termination.

Run it right, or not at all.

Austin

Reply to
Austin Lesea

ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here. All logos and trade names are the property of their respective owners.