synchronisation question

[Binome]

Hi,
I've got a strange behaviour when simulating a design.
Here is a part of my design:

  out_process: process(rst_n, r_hash_done, s_hash, clk)
  begin
    if rst_n = '0' then
      n <= 1;
      tree_end <= '0';
      out_ok <= '0';
    elsif r_hash_done(0) = '1' then
      tree_end <= '1';
      out_ok <= '1';
    end if;
    
    if rising_edge(clk) and tree_end = '1' then
      if n < leaves_nbr-1 then
        n <= n+1;
      else
        out_ok <= '0';
      end if;
    end if;
    out_idx <= std_logic_vector(to_unsigned(n, out_idx'length));
    out_tree <= s_hash(n);
  end process;

and the simulation waveform is:

"s_out_idx" is changing the first 5 times on the rising clock edge but then on falling edges.
What happens?

 

[TrickyDicky]

None of the signals in the wave form (including s_clk) are in the code you posted. Please post the code that relates to the waveform.

But I do have several comments on the code you did post.
1. Your reset and clk branches are in separate ifs. That means that the clock if always has priority over the reset.
2. you have signals assigned outside of the clock and reset branches, and they are dependent of signals not in the sensitivity list
3. This code is unlikely to synthesise as it does not match the synchronous template
4. If it does synchronise, then the simulation is unlikely to match the hardware, due to above concerns.

Post the real code that has any relation to the waveform, and maybe we can explain the falling edge clock issue (but I bet its because of at least one of the reasons above).

 

[Binome]

None of the signals in the wave form (including s_clk) are in the code you posted. Please post the code that relates to the waveform.

But I do have several comments on the code you did post.
1. Your reset and clk branches are in separate ifs. That means that the clock if always has priority over the reset.
2. you have signals assigned outside of the clock and reset branches, and they are dependent of signals not in the sensitivity list
3. This code is unlikely to synthesise as it does not match the synchronous template
4. If it does synchronise, then the simulation is unlikely to match the hardware, due to above concerns.

Post the real code that has any relation to the waveform, and maybe we can explain the falling edge clock issue (but I bet its because of at least one of the reasons above).

Thank you.
I can't post all the code because of my company privacy policy but I rewrote the process (that was indeed badly written) trying to be careful. It's like that:

  out_process: process(rst_n, r_hash_done, s_hash, clk)
  begin
    if rst_n = '0' then
      n <= 1;
      tree_end <= '0';
      out_ok <= '0';
    elsif rising_edge(clk) then
      if tree_end = '1' then
        if n < leaves_nbr-1 then
          n <= n+1;
        else
          out_ok <= '0';
        end if;      
      elsif r_hash_done(0) = '1' then
        tree_end <= '1';
        out_ok <= '1';
      end if;
    end if;
    out_idx <= std_logic_vector(to_unsigned(n, out_idx'length));
    out_tree <= s_hash(n);
  end process;

and it's really better.

 

[ads-ee]

r_hash_done and s_hash should NOT be in the sensitivity list.

You need to read a better VHDL book or find a better VHDL tutorial.

- - - Updated - - -

I would put both out_idx and out_tree assignments outside the process.

 

[TrickyDicky]

Are you saying these mods fixed the issue? Or are you still asking for help with something?

I would move out_idx and out_tree out of the process - otherwise they will be taking incorrect values in simulation compared to the real hardware as the process is not sensitive to n. Either that or move them inside the clocked branch (and an appropriate reset value).

 

[Binome]

I had corrected everything with what you all thought about and it's working perfectly.
I thank you all for your advice.