Intel® Quartus® Prime Software
Intel® Quartus® Prime Design Software, Design Entry, Synthesis, Simulation, Verification, Timing Analysis, System Design (Platform Designer, formerly Qsys)
16556 Discussions

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

Altera_Forum
Honored Contributor II
6,028 Views

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
0 Kudos
5 Replies
Altera_Forum
Honored Contributor II
2,944 Views

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.
0 Kudos
Altera_Forum
Honored Contributor II
2,944 Views

 

--- 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.
0 Kudos
Altera_Forum
Honored Contributor II
2,944 Views

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...
0 Kudos
Altera_Forum
Honored Contributor II
2,944 Views

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
0 Kudos
Altera_Forum
Honored Contributor II
2,944 Views

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.

0 Kudos
Reply