State Machine Viewer - missing transition

[Altera_Forum]

Hello every one, 

can you explain me why I get different state transition diagram from relatively the same VHDL?  Here is the code: 1)  if rx_bit_index < 7 then  rx_bit_index <= rx_bit_index + 1;  rx_state <= s_rx_data_bits;  else  rx_bit_index <= 0;  rx_state <= s_rx_stop_bit;  end if; 2)  if rx_bit_index = 7 then  rx_bit_index <= 0;  rx_state <= s_rx_stop_bit;  else  rx_bit_index <= rx_bit_index + 1;  rx_state <= s_rx_data_bits;  end if; and here the state transition: https://www.alteraforum.com/forum/attachment.php?attachmentid=15347  https://www.alteraforum.com/forum/attachment.php?attachmentid=15348   Regards, Emil

[Altera_Forum]

Hi Emil, 

  --- Quote Start ---  can you explain me why I get different state transition diagram from relatively the same VHDL?  --- Quote End ---   Here VHDL codes aren`t same, It leads the different state transition diagram, 1) rx_bit_index <= 0; In all cases except when rx_bit_index has value ranges from 0 to 6; 2) rx_bit_index <= 0; only when if rx_bit_index = 7  Let me know if this has helped resolve the issue you are facing or if you need any further assistance.  Best Regards Vikas Jathar  Intel Customer Support – Engineering (Under Contract to Intel)

[Altera_Forum]

Hi Vikas, 

thank you for the quick answer.  May be I didn't explain enough what I am doing  the two IFs are within a CASE within a PROCESS  So:  p_UART_RX : process(CLOCK) begin if rising_edge(CLOCK) then  case rx_state is when...........................  --FIRST VARIANT when s_rx_data_bits => if rx_clk_count < g_CLKS_PER_BIT-1 then rx_clk_count <= rx_clk_count + 1; rx_state <= s_rx_data_bits; rx_smp_tick <= '0';  else rx_clk_count <= 0; rx_data <= rx_stable & rx_data(7 downto 1); -- LSB first --rx_data(rx_bit_index) <= rx_stable; -- Wait g_CLKS_PEBIT-1 clock cycles to sample serial data rx_smp_tick <= '1';  if rx_bit_index = 7 then -- !!! rx_bit_index <= 0; rx_state <= s_rx_stop_bit; else rx_bit_index <= rx_bit_index + 1; rx_state <= s_rx_data_bits; end if; [/INDENT] end if;[/INDENT]  --SECOND VARIANT when s_rx_data_bits => if rx_clk_count < g_CLKS_PER_BIT-1 then rx_clk_count <= rx_clk_count + 1; rx_state <= s_rx_data_bits; rx_smp_tick <= '0';  else rx_clk_count <= 0; rx_data <= rx_stable & rx_data(7 downto 1); -- LSB first --rx_data(rx_bit_index) <= rx_stable; -- Wait g_CLKS_PEBIT-1 clock cycles to sample serial data rx_smp_tick <= '1';  if rx_bit_index < 7 then --THE DIFFERENCE IS HERE rx_bit_index <= rx_bit_index + 1; rx_state <= s_rx_data_bits; else rx_bit_index <= 0; rx_state <= s_rx_stop_bit;  end if; [/INDENT] end if;[/INDENT] when........................... when others => rx_state <= s_rx_idle; [/INDENT]   end case;[/INDENT]   end if;  end process p_UART_RX;  THE both variant have the same behavior but in the state machine viewer the transition stroke are missing for the second, and I do not understand why? Else the both code work correctly and a signal tab show correct transitions  Regards, Emil

[Altera_Forum]

Hi Vikas, 

not realy. may be I didn't explained correctly the case.  The both IFs are with in a clocked process within a case. The IFs are just the transition condition to the next state, and they are equivalent: when 7 -> transition else count. I can describe as count if < 7 else transition or count and if = 7 transition.  In the simulation it is corect in real test too but the state machine viewer do not like the "<" sign :)  Regards, Emil

[Altera_Forum]

The main question is does this code work as you expected, for both variants? Have you got a testbench? have you simulated and got the correct result? have you tested it on FPGA and both cases work? 

 The code IS different. While this snippet does look functionally similar, they are actually logically different. For example - the first one has logic to only change state when rx_bit_index is a single value - 7. The second code can change state when rx_bit_index is any value greater than 6 (depending on the declaration of rx_bit_index, this will be a minimum of 9 values, 7-15) Because of this, Quartus has decided there are optimisations that can be made. But because you only show a small snippet of code, not all of it in context, and you dont say if it works, its impossible to say why Quartus has changed the state diagram. If the code doesnt work, then this will be the reason for the state difference.

[Altera_Forum]

Yes, you are right saying that in the second variant the state change at any value greater than 7. But the first value at which there is a transition is 7, and Quartus do not show this. Why? 

Else the declaration of rx_bit_index is   signal rx_bit_index : integer range 0 to 7 := 0; And the index is set to 0 after reaching 7.  I mentioned that "In the simulation it is corect in real test too" It work (the both codes) on MAX II device and is correctly behaving in ModelSim  Regards, Emil

[Altera_Forum]

I believe both variants are functionally equivalent. I don't see any ambiguity (at least in the posted code snippet). I presume there are neither state overrides below the case construct.  

 The fact that the state machine viewer misses the state transition to s_rx_stop_bit, which apparently occurs both in simulation and synthesized code, seems to indicate a bug.

[Altera_Forum]

--- Quote Start ---  ..... seems to indicate a bug.  --- Quote End ---   That is what I supposed. And it is only in the visualization in the viewer. Thank you for the answers. Regards, Emil

[Altera_Forum]

Hi Emil, 

  --- Quote Start ---  The both IFs are with in a clocked process within a case. The IFs are just the transition condition to the next state, and they are equivalent: when 7 -> transition else count. I can describe as count if < 7 else transition or count and if = 7 transition.  In the simulation it is corect in real test too but the state machine viewer do not like the "<" sign :)  --- Quote End ---   Can you check with either if rx_bit_index <= 6 then --the difference is here OR signal rx_bit_index : integer range 0 to 8 := 0; if rx_bit_index < 7 then --the difference is here  I am able to see the state transition to s_rx_stop_bit in the state machine viewer. Check Screenshot.  Let me know if this has helped resolve the issue you are facing or if you need any further assistance.  Best Regards Vikas Jathar  Intel Customer Support – Engineering (Under Contract to Intel)