quartus II timing analyzer ignoring neg edge clk?

[Altera_Forum]

Tool is complaining about path from falling edge clock to rising edge, 25mhz, MAXII cpld. i would rather not ignore warning, how do i help timing analyzer understand, or me understand why it isn't happy: 

the divided down clk, clk2048, only changes on rising edge clk_cpld, so there really is a clk low time for this path.    Minimum Slack From To From Clock To Clock Required Hold Relationship Required Shortest P2P Time Actual Shortest P2P Time  -1.674 ns clk_8192000_countNEG[7] i_dac_csn CLK_CPLD CLK_CPLD 0.000 ns 2.604 ns 0.930 ns ------------------------------------------- process (clk_cpld)  begin  if (falling_edge (clk_cpld)) then  clk_8192000_countNEG <= clk_8192000_count;  end if;  end process;   -----------------------------------------------------  DAC_CSn_gen : process (clk_2048, RESET_F)  begin  if (RESET_F = '0') then   i_dac_csn <= '1';  elsif (clk_2048'event and clk_2048 = '0') then -- fall clk  if ( (clk_8192000_countNEG >19) and (clk_8192000_countNEG <115)) then  i_dac_csn <= '0';  else   i_dac_csn <= '1';  end if;  end if;  end process DAC_CSn_gen; -------------------------------------------------------  clk_2048 <= clk_div_counter(1); -- 2.048 MHz ------------------------------------------------------  CLK_DIV : process (CLK_CPLD, RESET_F)  begin -- process CLK_DIV  if RESET_F = '0' then -- asynchronous reset (active low)  clk_div_counter <= (others => '0');  elsif CLK_CPLD'event and CLK_CPLD = '1' then -- rising clock edge  clk_div_counter <= clk_div_counter + "00000001";  end if;  end process CLK_DIV;

[Altera_Forum]

Hi,  

 1. I don't think your divider is producing a 2.048 MHz. In fact, since 25 isn't a multiple of 2.048 you can't divide a 25 MHz into exactly 2.048 MHz. You can divide it by 12 to get a 2.083 MHz clock though.  2. You need to use a "create_generated_clock" command to tell TimeQuest about clk_2048. create_generated_clock -source clk -name clk_2048 -divide_by X [get_nets clk_2048] The "get_nets" part may need some changes..  3. Using clock dividers often creates problems with skew and hold times. Most likely, even after adding the generated clock statement, you'll still have the problem.  Best solution is to replace the clk_2048 clock with a clock enable.  process (clk, reset) if reset = '1' then elsif clk'event and clk = '1' then if enable = '1' then -- Logic goes here end if; end if; end process

[Altera_Forum]

Thank you for taking the time to reply. 

I understand your comments. The real system clock is 8.192Mhz, i just told the timing analyzer 25mhz for extra margin. I am currently using classic timing analyzer, but can see the need to move to timeQuest. After posting the question, if found the default setting under classic timing Analyzer does is not set to fix hold time for all paths. Once I changed it to all paths, all the warnings went away.  So even though i think the paths were false, i don't see any harm in letting tool fix them as it sees fit, a couple of ns change in the data or clock to i_dac_csn destination register won't matter since it has a half clock cycle.   Do you agree?

[Altera_Forum]

Letting the tool fix is a good option, at least in this case. 

As long as you have realistic timing constraints and they are met, it's fine.  However, there warning you were getting were not false paths and they were important. Ie, your circuit would not have worked correctly.  This is what you have a) clk_8192000_countNEG is launched on the rising edge of clk_cpld. b) there's some combinatory logic for the comparators c) the result of b) is latched on the falling edge of clk_2048  However, both the rising edge and falling edge of clk_2048 are aligned with clk_cpld! But, because it's generate by logic, there's a relatively large skew between the clocks. This is causing that at c), the hold time is being violated. And thus, the design would not behave correctly.

[Altera_Forum]

thanks again for reply, 

I do think it was a false path, clk_819000_countNEG bus is from falling edge clk_cpld, and clk_819000_countNEG is feeding logic using ultimately captured on derived clk that is rising edge clk_cpld based.  thanks  process (clk_cpld) begin if (falling_edge (clk_cpld)) then clk_8192000_countNEG <= clk_8192000_count; end if; end process;

[Altera_Forum]

Ah. You are correct. I was convinced clk_8192000_countNEG was on the rising edge. 

Thus, there should be a considerable margin there.  Maybe the classic timing analyzer got it wrong. I'm not terribly familiar with it, I only use when I have to deal with devices not supported in TimeQuest (which is rare).