Virtex4: On using a LC clock pin for global clock.

via a BUFG or IBUFG primitive?

pins, whereas GC pins are located near the center of the die...

Howdy Steve,

It is possible to take a generally routed signal and put it on a global clock. And as you suspected, it isn't recommended, although not for the reasons you list.

The main reason for having the global clock inputs come from certain pins (and local clock inputs too, for that matter) is so that there is known amount of delay between the input pin and the resources it will be driving. Having a known amount of delay allows you to control the timing between that clock and the other I/O pins in the device (or region). Here are the two main examples:

1. If the clock has a known (fixed) phase relationship with other signals on the board and is responsible for clocking those signals into the FPGA, you really want to use a dedicated clock input.

1. If there are bits being clocked out of the FPGA that need to have a fixed relationship with the *input* phase of the clock, you want to use a dedicated clock input.

2. Virtex-4 has introduced a third reason: global clocks are routed differentially, so if you want low jitter, use them.

You'll notice that the wording for each of those uses the word "want." That is the one thing that my coworkers and I have always loved about Xilinx - they don't keep you from doing most things you want to do, even if you want to do it in a way that isn't generally advisable.

So, going back to my very first sentence of this post, it is possible to use the local routing over to a global clock net. It is also possible to nail this routing down so that it doesn't change everytime you do a P&R - and when you nail it down, you now have a fixed (although large) delay. Figure out what that delay is (using FPGA editor to get a starting point) and feed the clock into a DCM, which you'll use to dial out all that large delay. Or with V4, you can dial the delay into the ISERDES, either for the "clock input", or for the data bits, and get the same result.

I'm not sure what you are asking here. Are you referring to using a DCM? Or simply that the signal on the global clock net is some sort of "resynthesized" version of the clock that came into the device originally? Regardless, the answer is that if you use global (or local) dedicated clock resources, you won't have skew. In the above paragraphs, I explained how you'll have extra delay before get on the clock net, but you shouldn't have skew.

Good luck,

Marc