Blocking Assignments on SIGNALS in VHDL

Question

I am making an FSM with VHDL. The simplest possible when valid = 1 change from stateA to stateB.

The confusing part is the rising edge selected by the blue rectangular. When valid = '1'. At the first rising edge, the state will be calculated to be B but it won't take effect until the next rising edge BUT what happened that it took effect at the FIRST rising edge.

Because the change in the state from A to B should affect other parts ( parallel process ) in the design in the NEXT cycle. From the waveform, If valid = '1' just before CLK_1.

At, CLK_1 all other processes should see state = A | waveform correct output

state = A
enteredlastcycle = 0

At, CLK_2 all processes start seeing state = B. another parallel process checks if state = B then it drives ENTERED_STATEB_LASTCYCLE to be 1 waveform correct output

state = B
enteredlastcycle = 0

Then at CLK_3, waveform correct output

state = B
enteredlastcycle = 1

Do I misunderstand something?

Library IEEE;
use IEEE.std_logic_1164.all;
use IEEE.numeric_std.all;
use work.KDlib.all;

entity nearestPoint is
generic ( ARRAY_WIDTH : integer := 8);
    port (
        clk: in std_logic;
        reset: in std_logic;
        inpoint: in kdvector;
        valid: in std_logic;
        finished: buffer std_logic
        );

end nearestPoint;

architecture behave of nearestPoint is
signal state: two_state_type;
signal stateB_entered_lastCycle: std_logic;
begin

process ( clk )
begin
if ( reset = '1' ) then
elsif ( rising_edge(clk) ) then
    case state is
        when stateA =>
            if ( valid = '1' ) then
                state <= stateB;
            end if;
        when stateB =>
        when others =>
    end case;
end if;
end process;


process(clk)
begin
if ( reset = '1' ) then
elsif ( clk = '1' ) then
    case state is
        when stateA =>
        when stateB =>
            stateB_entered_lastCycle <= '1';
        when others =>
    end case;
end if;
end process;

end behave;

You may find this useful. https://stackoverflow.com/questions/13954193/is-process-in-vhdl-reentrant/13956532#13956532 I think what you're missing is that the second process doesn't see the new "state" value even though clk = '1', because it isn't woken up until the next clk event. For fun, what would happen if you added "state" to its sensitivity list? Answer this to yourself, then try it... — , Aug 10 '19 at 11:56

score 2 · Answer 1 · edited Feb 21 '21 at 10:25

2

VHDL has no concept of blocking/non-blocking assignments. There are signals and variables and they are assigned differently.

In your case, you need to remember that simulation runs on a series of delta cycles. 1 delta is an infinitely small space of time, but they happen sequentially. A signal assignment doesn't take effect until the end of the delta, so state = B in the delta cycle after the rising edge of the clock. The 2nd process is sensitive only the clock, so it cannot update stateB_entered_lastcycle until the clock rises again.

edited Feb 21 '21 at 10:25

halfer

19,824
17
99
186

answered Aug 02 '19 at 12:44

Tricky

3,791
3
10
23

Yes, exactly using SIGNALS should always be a non-blocking assignment so the change in a state from A to B in one cycle should affect other processes in the NEXT cycle. – Alaa Salman Aug 02 '19 at 15:21
What happened here that it affected the other process in the same cycle of the transaction as a BLOCKing assignment – Alaa Salman Aug 02 '19 at 15:22
No it didn't. State changes then the other process changes the signal in the next cycle. The waveform shows exact behaviour if your code. – Tricky Aug 02 '19 at 17:51

score 2 · Accepted Answer · answered Aug 02 '19 at 12:58

I will give you an explanation through a digital circuit prism. It is a way of thinking that you have to keep in mind when you develop VHDL.

Your valid is at 1 before the clock edge. You are in simulation so you can imagine that all your computations are instant. At the input of your flipflop the new value of your state is already calculated.

I am used to code with only one sequential process and one or more combinational process. Maybe you will understand better with this code with same functionnality than yours (a bit simplified) :

SEQ : process(clk, rst)
begin

  if rst = '1' then
    current_state <= '0';
  elsif rising_edge(clk) then
    current_state <= next_state;
  end if;

end process SEQ;

Circuit corresponding to this code :

COMB : process(current_state, valid)
begin

  next_state <= current_state; -- Default value to ensure that next_state will always be affected

  if current_state = '0' and valid = '1' then
    next_state <= '1';
  end if;

end process COMB;

Circuit correspondint to this code :

If we consider that when valid changes next_state is refreshed instant, current_state (state in your code) goes high on the very next clock rising edge.

Hope you will understand, if you need more precision, don't hesitate to ask, I can edit my post or answer in comments.

Important note : If you have an asynchronous reset in your sequential process, it has to be in sensitivity list.

Just to add more confusion, the reset in the original post works as a clock enable (signal cant change when reset = '1'). — Tricky, Aug 02 '19 at 13:16
Indeed but I think the author removes some code to simplify before posting his code so I suppose there had something in this *if reset = '1'*. He will tell us :) — Gautitho, Aug 02 '19 at 13:26
Yes, the state should equal B at the first clk but that should not affect the other parallel process in the same cycle If you look at the waveform you can see that the transaction for A to B happened in the first CYCLE but it also affected the other process and this should not happen ( I don't need to care about setup/hold time in the simulation ) — Alaa Salman, Aug 02 '19 at 15:20
I have thoughts that the glitch is because the Async valid signal that I used in the test bench. When I used a sync valid signal it worked as expected. Also, your code works fine. Thank you very much. can you suggest a reference/text book fto learn making much more complex designs? — Alaa Salman, Aug 02 '19 at 15:40

Blocking Assignments on SIGNALS in VHDL

Do I misunderstand something?

2 Answers2