Why does quartus think my signal is a clock?

[Altera_Forum]

Here is the code snipped 

begin write_register <= '1' when ((chipselect = '1') and (write = '1') and (byteenable = "1111") ) else '0'; process (clk,reset_n) begin -- process if reset_n = '0' then out_settings <= x"FEDCBA9876543210"; elsif rising_edge(clk) then out_settings <= out_settings; 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,reset_n, out_settings, out_register) is begin out_register <= out_register; 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;  Why does quartus think that my enable on the second process is a clock? It makes no sense to me and how can i solve it?

[Altera_Forum]

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.

[Altera_Forum]

--- 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.

[Altera_Forum]

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;

[Altera_Forum]

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.

[Altera_Forum]

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.

[Altera_Forum]

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

[Altera_Forum]

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