Global/Regional Clock Assignment

[Altera_Forum]

I am getting many setup/hold time violations on one large clock fanning out to approximately 10,000 nodes. So, I decided to put this large-fanout clock on the fast regional clock line in the Assignment Editor. In addition, I am also setting the max fanout of this large-fanout clock to 2000. However, both settings in the assignment editor seem to get ignored by the Quartus fitter. 

 Then, I tried turning off the "Auto Global Clock" switch in the Fitter settings, and manual specified all my global and regional clock signals, including the large-fanout clock that is causing timing violations. However, as I checked the report after fitting, the Fitter still would not put the problematic large-fanout clock onto the regional clock line (while the other global/regional clocks in my design are placed correctly by the fitter).   Does anyone have any idea why the fitter would not put this large-fanout clock onto the regional clock line? This large-fanout clock is driving the clock inputs of thousands of registers, so it is definitely functioning as a clock. And, I had also put a "create_generated_clock" constraint on it.   Any suggestion is welcomed. Thanks!

[Altera_Forum]

Is it coming from a PLL? PLL outputs always drive globals(which includes regionals) so Auto Global Clock has no affect, and I would be surprised if they obeyed max fanout constraints, since one of the benefits of globals and regionals is that you don't care about fanout. You said there were setup and hold failures, but I don't think moving it from a global to a regional will help either, at least on any path where this clock feeds both the source and destination registers. For setup and hold, the only part of the clocck tree that comes into play is the clock skew, and globals and regionals both have extremely low clock skews. In fact, both are guaranteed not to have hold violations. The main reason to use regionals(besides the fact that there are more of them), is that the actual delay to the registers is shorter, so they can get faster Tcos or things like that. So in your case moving to a regional will probably not help(it might take a few ps of the setup, but that's it), and splitting the fan-out onto multiple globals would only hurt. 

If you analyze some of your failing paths, is the source clock and destination clock the same? What's the clock skew? What's the requirement?

[Altera_Forum]

Thanks for the informative reply!! 

 The large-fanout clock comes from an output (regular I/O) pin.   For all of the failing paths, the source and the destination clocks are different clocks. Actually, the large-fanout clock is on the launch path of all setup time violations, and it is also on the latch path of hold time violations. That's why I am thinking if I can cut into the delay time on that large-fanout clock, I might be able to solve all timing problems. Currently, delay from the large fan-out clock driving a register is about 4ns, whereas the clock period is only 8ns (it is a PCIe clock signal, so the clock period is fixed and cannot be slowed). The worst setup time slack is about -1.2ns and the worst hold-time slack is -0.4ns.   In terms of clock skew, I cant recall the exact numbers, but I dont think there is a big difference between the skew on the launch and and the skew on receiving paths.   So, it seems that moving the clock signal to regional clock line wont help me much. Does that mean I should try modifying the RTL design (which might be a lot of work). Or, are there anything else easy and obvious in Quartus that I can do to solve the timing issues. I have tried a lot of setting already like increasing the routing effort, optimize speed during synthesis, etc (basically most of the suggestions in the timing optimization advisor).

[Altera_Forum]

Now that you've described it, I stand corrected. Putting it on a regional just might help. It sounds like you've already done it, but go to the assignment editor, put the input pin name in the To column, Global as the Assignment, and Regional(or dual-regional) as the Value. That should work. 

Putting a PLL on the clock should work too, if it's available. (Are you coming in on a dedicated clock pin? That could be a problem too, since it if's a regular I/O it would have to route over to the global drivers. If the board's laid out there's not much you can do about that, but something to be aware of.) Finally, where do the "other clocks" originate from? Are you sure they're synchronous to this clock? If a clock comes in a pin, doesn't feed a PLL(which can generate multiple clocks), then usually that domain is asynchronous to other domains in the device. Just something to be careful of.

[Altera_Forum]

I also have been trying change some clock assignments, and I have also found that the fitter ignores some of the assignments. Some were honored. More disappointingly, there were no messages to explain how/why it is doing that. 

 I'm ending up taking a different tack - I suspect that part of my problem is a difficult clock crossing in the high perf DDR2 controller at full rate, and I suspect that if I use the controller at half rate, like the majority of people, that crossing probably is different, and an easier timing relationship.  Rule# 17 for using IP should be - are you using the IP in ways that are different from how most other people are using it? If so, you better have a good reason - actually, a reason that you absolutely can't use it the way most people do, because there are good chances you'll have trouble.