Forum Discussion

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

Diagnosing "signal was determined to be a clock .." message.

After incorporating a number of files produced by colleagues, I now get a warning from TimeQuest saying a signal "was determined to be a clock but was found without an associated clock assignment." The signal in question is the master asynchronous reset for one clock domain and is not intended to be used as a clock. It is asserted and acts asynchronously but is removed synchronously (as is standard practice).

Rather than backing out various updated files to find the cause, is there a way to get TimeQuest to say why it has determined the signal to be a clock. I'm thinking along the lines of reporting all paths from the source in question to pins which Quartus thinks are clocking something. Having a mix of VHDL and graphical entry (Mentor), I suspect there is no common name I can use.

Thanks,

George

5 Replies

  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Have you tried "not a clk" option in assignment editor.

    the only connection with clk is that master reset will be global to avoid delay and clock slip at release unless somebody connected it by mistake.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    --- Quote Start ---

    Have you tried "not a clk" option in assignment editor.

    --- Quote End ---

    That's a useful hint, thanks, although in this case setting "not a clock" would only have covered up the problem.

    --- Quote Start ---

    the only connection with clk is that master reset will be lobal to avoid delay and clock slip at release unless somebody connected it by mistake.

    --- Quote End ---

    A few minutes ago I found the cause while looking into another fault. It was a mistake, the author had set a register to the value of another signal during reset rather than to a fixed value so it was inferring a latch, passing the value through while reset was active, even though the preceding source was itself reset. 

    
 proc_a : process(rst,clk)
 begin
  if (rst='1') then
   sig_a <= '0' ;
  elsif rising_edge(clk) then
   if (enable_a = '1') then
    sig_a <= sig_in ;
   end if;
  end if;
 end process proc_a ;
 
 proc_b : process(rst,clk)
 begin
  if (rst='1') then
   sig_b <= sig_a ;
  elsif rising_edge(clk) then
   if (enable_b = '1') then
    sig_b <= sig_a ;
   end if;
  end if;
 end process proc_b ;

    Changing the second process to the following corrected the error without changing the behaviour: 

    
  if (rst='1') then
    sig_b <= '0' ;
  elsif rising_edge(clk) then

    Although I have now resolved this particular instance, it would still be useful to know if there is a way to get TimeQuest or Quartus to identify the process which was causing the warning message.
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    If it pointed back to the code, it would just point to the signal that it mentions. What you wanted to know is where that is used as a clock. Of course, that's more difficult since it could be thousands of locations(for cases where someone forgot to assign something that really isn't a clock), and in those cases it still might not be clear. Some quick ideas:

    1) Put a clock assignment on it. Something simple like "create_clock -name bad_clk -period 10.0 <nodename>". So now it has a clock on it(and all clocks are related by TimeQuest). Rerun timing analysis and report_timing -to bad_clk, as well as do a report_timing -from bad_clk. Your going to see the exact nodes that use that as a clock.

    2) Go to the Fitter Report and look at the Control Signals section. Sort on usage and scroll down to where all the clocks are. Note that this list has nothing to do with your TimeQuest constraint, but is a list of every physical node that directly drives the .clk port of a regsiter. Most of them should be PLLs or input ports and make sense. If something doesn't make sense, go look at it. Even if it's not this reset issue, this isn't a bad thing to do anyway...
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    Thanks Rysc, that's the sort of hints I hoped for. I did try defining it as a clock but reporting "-from" gave about 20000 destinations, hence the problem. Using the fitter report in conjunction with the dummy clock is an something I will try.

    Thanks,

    George
  • Altera_Forum's avatar
    Altera_Forum
    Icon for Honored Contributor rankHonored Contributor
    16 years ago

    If your reporting from that clock, then look at any of the source registers and see what clocks it. Basically whatever that is should be directly from the reset in question. Make sure to do report_timing -detail full_path to get the clock tree path broken out.