Frequency Divider Timing Req. Never Met

[Altera_Forum]

I am trying to make a freq. divider and tried many VHDL solutions on the web. Most of them worked but TimeQuest always tells timing requirements did not met. Here is one code that worked with a worst case setup slack of -5.547: 

 library ieee; use ieee.std_logic_1164.all; use ieee.numeric_std.all; -- entity freq_div is port( clkin : in std_logic; reset : in std_logic; clkout: out std_logic); end entity; -- architecture main of freq_div is -- -- signal cnt0 : unsigned(4 downto 0); -- begin -- process(clkin,reset) -- begin if reset='0' then cnt0 <= "00000"; elsif clkin'event and clkin='1' then if cnt0 = "10000" then cnt0 <= "00000"; else cnt0 <= cnt0 + 1; end if; end if; end process; -- -- -- clkout <= cnt0(4); -- end architecture;Could you tell me what am I missing? By the way clkin is output of a PLL with ratio of 1/5000. I need this extra divider to reach lower frequencies PLL doesn't allow.

[Altera_Forum]

Forgot to mention setup slack of -5.547 belongs to cnt0(4).

[Altera_Forum]

Why doesn't it fail? When you launch TimeQuest and right click on the failing domain and do report_timing with detail set to full_path, what does it look like? What's the setup relationship?  

You're clock rate is probably already really slow. This circuit should run really fast. So it should work, but something in the constraints, layout, etc. is not correct. You need to debug the timing report since it gives all of that information.

[Altera_Forum]

Do you see the timing violation inside the clock divider? I would rather expect it in domain crossing assignment from clkin to clkout.  

 If so, it won't show a problem of the clock divider itself rather than of how to use divided clocks in a design.

[Altera_Forum]

--- Quote Start ---  Why doesn't it fail? When you launch TimeQuest and right click on the failing domain and do report_timing with detail set to full_path, what does it look like? What's the setup relationship?  You're clock rate is probably already really slow. This circuit should run really fast. So it should work, but something in the constraints, layout, etc. is not correct. You need to debug the timing report since it gives all of that information.  --- Quote End ---    When I do that all of the paths connected to cnt0(5) fails. Those paths have negative setup slacks with minimum pulse width violations.

[Altera_Forum]

--- Quote Start ---  Do you see the timing violation inside the clock divider? I would rather expect it in domain crossing assignment from clkin to clkout.   If so, it won't show a problem of the clock divider itself rather than of how to use divided clocks in a design.  --- Quote End ---    Actually the design works as expected but I get lots of annoying warnings related to timing requirements and negative slacks.

[Altera_Forum]

You didn't tell about the purpose of the divided clock in your design. Isn't it possible to use clkout as a clock enable instead of an actual clock? If I understand right, it's already active for one clkin cycle, as required for a clock enable in the clkin domain.

[Altera_Forum]

--- Quote Start ---  You didn't tell about the purpose of the divided clock in your design. Isn't it possible to use clkout as a clock enable instead of an actual clock? If I understand right, it's already active for one clkin cycle, as required for a clock enable in the clkin domain.  --- Quote End ---    I am using this divided clock to obtain low frequencies (such as 0.5 Hz) that I need in my design. This low frequency clock signal must drive a subcircuit that changes its output according to this divided clock. If I use this divided clock as clock enable then this subcircuit's output will change not in the frequency of divided clock but its actual clock during enable cycle.   My concern is about my VHDL code especially the cnt0 signal (where timing errors focused). Is it a wrong way to obtain this divided clock? Is there any other way to obtain a divided clock without timing errors?

[Altera_Forum]

As said, I don't see a problem with the clock divider itself. clkout is a copy of a registered signal and in so far keeping the requirements for a clock divider. 

 I assume the problem with clock enable is, that you don't want to change the subcircuit code. Otherwise there should be no problem to implement it.  Normally, Quartus will be able to adjust the clock path for the delay caused by a frequency divider, if a domain crossing is involved.

[Altera_Forum]

--- Quote Start ---  As said, I don't see a problem with the clock divider itself. clkout is a copy of a registered signal and in so far keeping the requirements for a clock divider.  I assume the problem with clock enable is, that you don't want to change the subcircuit code. Otherwise there should be no problem to implement it.  Normally, Quartus will be able to adjust the clock path for the delay caused by a frequency divider, if a domain crossing is involved.  --- Quote End ---    I see thank you for your opinions. But I have one more thing that tamper my mind. I have another clock that I use for other parts of my design. Is it possible for Timequest to fail analyzing them simultaneously? Because design works in practice.

[Altera_Forum]

To analyze timing of domain crossing data, TimeQuest must be able to determine their exact relation of both clocks. This is easy in the usual case of both clocks derived from the same input clock. Otherwise both are treated as unrelated. 

 The other point is that "design works in practice" doesn't guarantee that there are no timing violations and possibly infrequent random errors.

[Altera_Forum]

--- Quote Start ---  To analyze timing of domain crossing data, TimeQuest must be able to determine their exact relation of both clocks. This is easy in the usual case of both clocks derived from the same input clock. Otherwise both are treated as unrelated.  The other point is that "design works in practice" doesn't guarantee that there are no timing violations and possibly infrequent random errors.  --- Quote End ---    So far I haven't met any error but if I have in the future I will change the whole design. Than you very much for your replies.

[Altera_Forum]

--- Quote Start ---  To analyze timing of domain crossing data, TimeQuest must be able to determine their exact relation of both clocks. This is easy in the usual case of both clocks derived from the same input clock. Otherwise both are treated as unrelated.   --- Quote End ---   Oops? IMHO if not explicitly told by using set_clock_groups -asynchronous -group { clk1 clk2_derived_from_clk1 } -group {clk3_unrelated} ... TQ treats all clocks as being related and may thus flag timing errors between certain clocks, even if you have added anti-metastabiity provisions.

[Altera_Forum]

--- Quote Start ---  Oops? IMHO if not explicitly told by using set_clock_groups -asynchronous -group { clk1 clk2_derived_from_clk1 } -group {clk3_unrelated} ... TQ treats all clocks as being related and may thus flag timing errors between certain clocks, even if you have added anti-metastabiity provisions.  --- Quote End ---    Those kind of clocks should be considered as asynchronous group like this then. Thank you very much.