Global Clocks in Xilinx Virtex-4

Cheng,

I am in the middle of a Virtex4 design myself and have gone back and forth with Xilinx about clock routing. The documentation is very poor, particularly with respect to the regional clock boundaries.

As I understand it, yes you can drive a BUFG from anywhere in the FPGA fabric if you want, however the routing is not ideal. So, while you still have no skew problems within the FPGA, because everything is on the global clock net, you could have skew problems with any other system synchronous devices in the design. (i.e. sync. srams, etc... ddr sdrams will be source syncronous, so there is no problem here)...

To confirm this though... I would run ISE with your design and follow the routing in FPGA Editor just to be POSITIVE that everything routed as you wanted. This is just what I recall.

uvbaz wrote:

You should instantiate a bufg on your clock net to make sure it gets onto the global routing. Not all synthesis tools automatically insert that buffer, and without it, you won't get on the global clock net. Assuming you do have that buffer, the clock that is distributed in the FPGA will have low skew, but there will be a sizable offset from the external clock. That may cause problems with communicating with devices external to the FPGA.

Also, the sizable offset will probably change every time you recompile the project.

Alan Nishioka

messagenews:V7J3h.10344$ snipped-for-privacy@newsfe20.lga...

This is not entirely true. The DCM will phase match the internal signal to the clock presented to it, but that does not compensate for the clock delay introduced by routing from a general purpose input. You need a feed back mechanism for that delay in order to automatically compensate.

That said, the Virtex4 DCM does allow the user to program a fixed phase offset, or for the FPGA design to diddle the offset in a variable mode. A user could add an offset to compensate for the 'typical' delay, or tweak that offset till it "works", however this gets into dangerous territory since that offset compensation does not track the actual delays encountered on that route. A sophisticated user might be able to use the DCM variable offset to train on the clock signal to get something that would autocalibrate, but it isn't something I'd generally recommend for the V4 because there are better ways to handle it. The V4 offers you the idelay elements on each pin that you can use for training for data alignment based on either a training sequence or a forwarded clock. In that case, a training circuit adjusts the delay on the data path inputs to center them on the active clock edges. It is primarily intended for high data rate clock-forwarded interfaces. The other option might be to use a clock capable I/0 and the regional or local clocking, which gives a way to get in a clock for clocking a relatively small amount of local logic, and then resynchronizing the data to your global clock domain inside the FPGA.

Peter,

Why not? I've done this before. Perhaps we are talking about different things. If data and clock arrive at the FPGA concurrently, and I want the input flop on the data to be clocked by a global clock generated by a PLL, not the clock coming into the device, compensation (phase angle) has to be adjusted to account for clock network delays. These delays are known and can be easily compensated for by the hardware, so nothing is done mystically.

Thank you, Rob

Ray,

Some FPGA's do have a feed back pin to do what you are describing. My original post was not meant to reference the Virtex4. My intent was to add to the general discussion of clock delay and skew.

The training you mention is something that my company had done to automatically compensate for data / clock skew--pretty neat.

Sorry for any confusion.

Rob

messagenews:mfS3h.11272$ snipped-for-privacy@newsfe22.lga...

Virtex4, as well as the other Xilinx FPGAs do have a feedback pin, which can be connected to an external net in order to deskew at the package level. In order to work properly, that feedback should come in on a global clock input, otherwise the compensation is destroyed by the internal route delays. The OP started out by saying he couldn't use the global clock pin for whatever reason, and therefore I was also assuming that using it for external feedback was also off the table.

If you haven't done it already, the training is made much easier in V4 relative to earlier families.