Help on Virtex-II Pro global clocks.

The simple rule is "use a BUFG." If you have a [very] small fanout, you may be able to get away without it, but you may need to place all your FFs appropriately; otherwise, you have a high probably of lousy clock skew and lousy routing.

Ideally, pre-pin-selection planning lets you assign all your potential clocks to appropriate pins; a select number of pins have 'favored' connections to the BUFGs.

If you don't have such luxury (and I would guess you don't), you need to carefully control the routing of your input clock to control its phase relative to the input/output data at the IOBs. If you can control the routing (i.e., make the delay predictable), then you can use a DCM to produce a phase-corrected clock (2x, /N, ...), and use normal clock routing resources. (And face the Primary/Secondary restrictions in each quadrant, which gets to be quite a pain when you exceed 8 clocks and want matched BUFGs... but that is another story.)

There are lots of good app notes on Xilnx' web site. Enjoy reading.

JTW

Ok, the existing IP uses a lot of clocks and my logic must be very simple. Anyway I'd like to ask what is the difference between IBUFG and BUFG. If the input to the DCM is:

bufg_syncclk: bufg port map ( i=>sync_clk, o=>sync_clk_dcm);

I get the error, but if the input is:

bufg_syncclk: ibufg port map ( i=>sync_clk, o=>sync_clk_dcm);

I don't.

Why happens that?. Should I LOC the clock buffers?. Thanks, Daniel.

I'm using a virtex2p VP40 (xc2vp40-5ff1152). The pin is AH17, according to the datasheet, it's in bank =EF=BB=BF4 and the inputs are IO_L74N_4/GCLK3S. What I want, is to know the right way to use the DCM. According to the users guide, both ways (IBUFG and BUFG) are OK. I want to know which one should I use. If I use IBUFG I should look for the corresponding DCM and LOC it?.

I guess using BUFG and DCM I run out of BUFG's but using IBUFG I don't.

I'm sorry I'm very confused with this and that's because I'm newer.

Thanks, Daniel.

There are not actual different devices on the chip for ibufg and bufg, so whether you specify ibufgs or bufgs, you will run out at the same time. I don't ever LOC DCMs in the virtex2p devices I use, and I have not specified ibufgs; I always just use bufgs, and specify only the clock pin location. So I don't really know what the problem is in your case, and why specifying an ibufg fixes it.

You say that you have a lot of clocks (something you might want to rethink ;). Are all the other clocks locked to pins, and is one locked to AJ17?

Yes, I have a clock on that pin too. Why do you ask? This IP interacts with many components: rocketIO, SDRAM, ZBTRam, PCI bus and DACs; and that is why, I think, it uses so many clocks. I thougth I was runing out of clocks resources so that using IBUFG I was saving some. The problem is that as the logic grows, even using IBUFG, P&R is unable to route the hole design and I get the ERROR:Place:249.

Because my part of the logic on the FPGA generates the signals to enable DACs which move with an external clock, I generated them with system clock and put 3 synchronizers runing at external clock to sync them with it. I mean, reduce as much as possible the part that should use the external clock.

So, I'll see how it works. Thanks!, Daniel.

Once you have clock buffer assignments that work, be sure to LOC them all in your ucf. I have a Virtex 2 Pro design where I had to figure out the clock placement manually. ISE could not figure it out, and if I didn't LOC every clock buffer, I'd always get an automatic placement error.

Because these are primary and secondary clocks of a pair, and therefore they share resources. And that is what this message is trying to tell you: "The main restriction on clock placement is that only one clock output signal for any Primary / Secondary pair of clocks may enter any region".

If you spread your clocks out so that you are only using one of each primary / secondary pair, and you have 8 clocks or less, then you would not have a problem.

Nope, ibufgs won't save resources, because it is actually using a bufgmux, just like a bufg. Different routings can result in failure/ non failure dependent upon the how PAR places components, because physical routing resources are divided into 4 quadrants. Yes, I think you are running out of resources, but it may only be because you are using both the primary / secondary clock of a pair.

I think you are going to find that in this application, using 3 synchronizers instead of 1 does not buy you anything. With 1 synchronizer, you don't need to bother with a global buffer for the external clock input. Just place timing specifications that insure that the external clock pin input to registered output pin to the DAC is small enough to meet the setup time the DAC requires. For even a modestly fast DAC, this should be easy to meet.