Forum Discussion

Altera_Forum's avatar
Altera_Forum
Icon for Honored Contributor rankHonored Contributor
14 years ago

Frequency Divider Timing Req. Never Met

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.

13 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor

    --- 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.