- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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, GeorgeLink Copied
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
--- 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.
- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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...- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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- Mark as New
- Bookmark
- Subscribe
- Mute
- Subscribe to RSS Feed
- Permalink
- Report Inappropriate Content
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.
- Subscribe to RSS Feed
- Mark Topic as New
- Mark Topic as Read
- Float this Topic for Current User
- Bookmark
- Subscribe
- Printer Friendly Page