Hold time violations in simple clock divider

[Altera_Forum]

I am using a register to divide a 100 MHz input clock and am getting hold time violations. 

 The actual code is a tad more complicated (it switches to a slower clock divider depending on an input), but the following verilog fails in the same way.  always @(posedge In_Clk, negedge Rst_) if (~Rst_) Out_Clk <= 1'b0; else Out_Clk <= ~Out_Clk;  The hold error is from node Out_Clk to node Out_Clk, with launch clock being Out_Clk and the latch clock being In_Clk. There are separate hold time failures for both the rising edge of the launch clock and the falling edge. From the falling edge, the hold time violation is about 0.08, for the rising edge it is about 0.05  I have confirmed in the Resource Property Editor that the only input to Out_Clk is itself, fed back from the register through LUT input C, so I am assuming this is a tools problem.  Specifically, it seems that the Launch clock should also be In_Clk, not Out_Clk. Is this problem caused because Out_Clk is routed to the global clock network?  Should I just set a false path between these nodes? If there is another way to re-write this portion of code that will help the tools automatically analyze this clock generator properly, I would prefer to do that.

[Altera_Forum]

@wcalkins, 

   --- Quote Start ---  I am using a register to divide a 100 MHz input clock and am getting hold time violations.  --- Quote End ---     making your own clock in this way is not considered good design practice. It is normal that your timing verifier runs into the problems you mention.   Do not use gated or derived clocks to control flip-flops, registers and memories in your design. In case you need a slower or faster clock, use a PLL to make this clock.

[Altera_Forum]

Or, in your case, as you are only dividing by 2, generate a clock enable that toggles, rather than an actual clock.

[Altera_Forum]

But according to what the OP is saying, he is getting hold violation at the clock generation itself, not on registers using the generated clock. This should not happen, let alone on a register feeding itself.

[Altera_Forum]

--- Quote Start ---  @wcalkins, making your own clock in this way is not considered good design practice. It is normal that your timing verifier runs into the problems you mention.   Do not use gated or derived clocks to control flip-flops, registers and memories in your design. In case you need a slower or faster clock, use a PLL to make this clock.  --- Quote End ---    Because this clock has to change frequencies while running, a PLL won't work. According to the Design Recommendations for Altera Devices and the Quartus II Design Assistant ( http://www.altera.com/literature/hb/qts/qts_qii51006.pdf ) on p. 5-8, generating a clock with custom logic is ok, as long as the clock is based on a synchronous source and is not gated. In this case, the Out_Clk signal is routed directly from the output of the register to a CLKCTRL block of the Cyclone III.  Tricky, I would consider this, but in the actual design I am using a counter, not just dividing by 2. This is just the simplest case I could find that shows the problem for diagnostic's sake.  And, as vjAlter mentioned, the registers that use this clock as a source are analyzed properly and meet timing by a wide margin.

[Altera_Forum]

I have fixed this by added an extra register stage to the clock generation output. While I don't believe this changes the functionality or timing of the clock generation at all, it does prevent Quartus from seeing a net that gets routed to a global clock tree as a data input to the Out_Clk flip-flop (even though the input is routed from inside the LE, not from the clock tree). I think this is what was confusing the timing analyzer. 

 always @(posedge In_Clk, negedge Rst_) if (~Rst_) Staged_Clk <= 1'b0; else Staged_Clk <= ~ Staged_Clk; always @(posedge In_Clk, negedge Rst_) if (~Rst_) Out_Clk <= 1'b0; else Out_Clk <= Staged_Clk;