Clock skew from using global and local routing

[Altera_Forum]

I'm chasing a number of hold and sometimes setup violations that stem from impractical amounts of clock skew. When I pull up a failing path in the technology viewer, I find that one of the flops is being driving by the global or regional clock buffer as it is suppossed to. The other flop is being driven by the pre-buffered clock via the normal routing. This is not a clock gating situation. In the RTL, both flops are driven by the same ungated clock, even in the same module for some cases. How do I stop this? If both flops were driven by the dedicated clock network, I am sure that the paths would pass.

[Altera_Forum]

The fitter should not be doing that. I would try to identify what is being put onto the global and what is not, and see if something jumps out, such as "All the registers in block A are put onto local while everything else is global". It shouldn't be random. The only things I can think of are: 

- Partitions might cause this, if some are post-fit. Maybe when they were compiled, the fanouts for the partition were put on local/global while the later compiles the other one was chosen. I've never seen that happen, but just a thought that's easy to determine(you would have had to manually create partitions) - Global buffers in the design. Doubtful, but maybe they exist, which can cause behavior if they don't cover all the fanouts. Also look for "Global" assignments in the Assignment Editor. - There is a case where it will demote a signal from a global, but that is when it is used as a clock elsewhere. For example, let's say you have a register clocked by the global clock, but that register feeds the clock port of other registers. This causes huge clock skew and all sorts of timing problems. I've seen Quartus demote the clock route to that first register to reduce the skew, but does add some issues for transfers to/from that register. That being said, it would only be a register or two. One thing to try is assign Global = On for the source. For whatever reason it's occuring, that may clean it up.

[Altera_Forum]

Adding an lcell seems to help for the pin driven clocks but I also have some clocks are gated that have the same problem and the lcell in not effective. To be clear, I'm referring to flops on the same side of the clock gate. For some flops, the clock path is gate -> regional or global buffer -> flop. Others are gate -> (data network) -> flop.  

 Auto global is turned on. There are no global buffers defined in the RTL for this clock.

[Altera_Forum]

Assign the pin to a global in the assignment editor. That should force everything onto the global, which is what I assume you want. (Or assign Global = Off, if you don't want it). The one case I mentioned where I know of demotion involves gated clocks, so this may be the cause. (If you can get rid of the gated clocks and use clock enables or something, that would be great, but naturally understand it's not always possible).

[Altera_Forum]

Explicitly assigned the clock as "Global" seems to make no difference. Running with partitions turned off doesn't help either.  

 Early on, I get this message: Warning: Can't implement Global Signal option for node "lanai_clk_reset:clk_reset|ungatedClkCore" that drives nodes that cannot change routing due to incremental compilation -- other nodes are not affected  But, in fact, it does assign the net to a global clock.  Later, it says: Info: Promoted node lanai_clk_reset:clk_reset|ungatedClkCore   Info: Promoted destinations to use location or clock signal Global Clock CLKCTRL_G10  Info: Following destination nodes may be non-global or may not use global or regional clocks  Info: Destination node lanai_top:lanai_top|sysc_top:sysc_top|sysc_reg_control:sysc_reg_control|video_output_ctrl_sg[24]  Info: Destination node lanai_top:lanai_top|sysc_top:sysc_top|sysc_reg_control:sysc_reg_control|video_output_ctrl_sg[23]  Info: Destination node lanai_top:lanai_top|sysc_top:sysc_top|sysc_reg_control:sysc_reg_control|video_output_ctrl_sg[20]  Info: Destination node lanai_top:lanai_top|sysc_top:sysc_top|sysc_reg_control:sysc_reg_control|video_output_ctrl_sg[18]  Info: Destination node lanai_top:lanai_top|sysc_top:sysc_top|sysc_reg_control:sysc_reg_control|video_input_ctrl_sg[7]  Info: Destination node lanai_top:lanai_top|sysc_top:sysc_top|sysc_reg_control:sysc_reg_control|video_output_ctrl_sg[22]  Info: Destination node lanai_top:lanai_top|sysc_top:sysc_top|sysc_reg_control:sysc_reg_control|video_output_ctrl_sg[21]  Info: Destination node lanai_top:lanai_top|sysc_top:sysc_top|sysc_reg_control:sysc_reg_control|video_output_ctrl_sg[19]  Info: Destination node lanai_top:lanai_top|sysc_top:sysc_top|sysc_reg_control:sysc_reg_control|video_output_ctrl_sg[17]  Info: Destination node lanai_top:lanai_top|sysc_top:sysc_top|sysc_reg_control:sysc_reg_control|video_output_ctrl_sg[16]  Info: Non-global destination nodes limited to 10 nodes

[Altera_Forum]

It's saying it can't promote to a global for certain destinations(and then lists 10 of them, although there are surely many more). There's something going on. Are you maybe reading in a .qxp file? Is there maybe an .rcf in the project(routing constraint file).

[Altera_Forum]

--- Quote Start ---  It's saying it can't promote to a global for certain destinations(and then lists 10 of them, although there are surely many more). There's something going on. Are you maybe reading in a .qxp file? Is there maybe an .rcf in the project(routing constraint file).  --- Quote End ---    No rcf. While there was a qxp because it was set to save the logiclock regions after each build, I turn the setting off, deleted the file and rebuilt with no real difference. The first message went away but the "non-global" message is still there and the same flops have their flops driven by data lines.