Why does quartus think my signal is a clock?

In the second process you write:

out_register <= out_register

out_register behaves like a latch, so you need a latch enable. May be Quartus takes "enable" as a clock because the register refresh it's output when enables goes high. I think Quartus inferred a latch.

--- Quote Start ---

In the second process you write:

out_register <= out_register

out_register behaves like a latch, so you need a latch enable. May be Quartus takes "enable" as a clock because the register refresh it's output when enables goes high. I think Quartus inferred a latch.

--- Quote End ---

I might just remove it since it's useless (this is legacy code) and test it.

I forgot to say what i get in timequest.

It says i have 1 unconstrained clock and that

Node: shuffler:shuffler_0|enable was determined to be a clock but was found without an associated clock assignment.

To solve it i used a false path to it but i don't think it's the right thing.

I changed the code to this but the problem persists

process (clk,reset_n)
  begin  -- process    
	if reset_n = '0' then
	out_settings <= x"FEDCBA9876543210";
    elsif rising_edge(clk) then 
	 enable <= '0';
      if (write_register = '1') then
        case address is
          when '0' =>
            out_settings(31 downto 0) <= writedata;
          when '1' =>
            out_settings(63 downto 32) <= writedata;
				enable <= '1';
				  when others =>
				    enable <= '0';
        end case;
      end if;
    end if;
  end process;
  process (enable,out_settings) is
  begin 
	 if enable = '1' then
    for i in 0 to (N_CHANNELS_ANA - 1) loop
        for j in 0 to 3 loop
          out_register(i)(j) <= out_settings(i*4 + j);
        end loop;
    end loop;
	 end if;
  end process;
  process (ana_bits_in, out_register)
    variable index : integer range 0 to (N_CHANNELS_ANA - 1);
  begin
    for i in 0 to (N_CHANNELS_ANA - 1) loop
	 index         := conv_integer(out_register (i)(3 downto 0));
      ana_bits_out(i) <=  ana_bits_in(index);
    end loop;
  end process;

clearly enable is not a clock in the usual meaning of edge triggering signal. I assume quartus is not saying it is clock but timequest.

The signal out_register(i)(j) will become all latches enabled on your enable and I believe timequest just regards it as clock.

You delete the line:

out_register <= out_register

but the inferred latch problem persists. You don't make any assigment when enable = '0'. If you need a combinational output try:

if enable = '1' then

for i in 0 to (N_CHANNELS_ANA - 1) loop

for j in 0 to 3 loop

out_register(i)(j) <= out_settings(i*4 + j);

end loop;

end loop;

else

for i in 0 to (N_CHANNELS_ANA - 1) loop

for j in 0 to 3 loop

out_register(i)(j) <= '0'; -- Dafault value. May be different.

end loop;

end loop;

end if;

If you want a registered output use the clock:

if(clk'event and clk = '1' ) then

if( enable = '1' ) then

for i in 0 to (N_CHANNELS_ANA - 1) loop

for j in 0 to 3 loop

out_register(i)(j) <= out_settings(i*4 + j);

end loop;

end loop;

end if;

end if;

Last code I used enable as a clock enable signal.

One thing I see in the code is not a clear use of synchronization in your VHDL processes.

As a matter of code style, it might be appropriate to trigger the processes on the clk signal alone, unless you are purposely wanting an asynchronous design style. As others have said, Quartus infers latches, and your design will operate where values appear on the output of the latch, likely, within the current clock cycle. This may have unintended timing effects, and can set up unwanted feedback paths--even with the inserted latches.

Better, more robust style is to have the clk and reset signal in the sensitivity list of the 2nd process, and have the other signals references in conditional statements in the logic. This means all operations would be synchronous with the clock.

Then, you can use the clk'event attribute to control execution of statements in the process, like this:

if (clk'event and clk = '1') then

-- insert all the other process code inside this condition.

end if;

Hope this helps.

regds,

jim

Looking at this further, I'd also synchronize the 3rd process using clk and reset signals.

You're executing loops and updating internal signals and variables as a result, but there is no explicit state machine. I wonder why. I don't write code, nor do I teach students to write it this way, as it is much more evident what is going on if the state machine is explicitly defined in its own process (states as enumerated values of a state variable, and a process with a Case construct to execute next state transitions based on present state and any inputs that affect next state decisions). Then your data path operations would be in one or more separate processes. Any non-clocked, asynchronous data path operations would be in their own processes, with input signals and not the clk in their sensitivity list.

Just a thought.

regds,

jim