How will the "next state" handle the signal...

Status
Not open for further replies.
S

shaiko

Advanced Member level 5
Joined
Aug 20, 2011
Messages
2,644
Helped
303
Reputation
608
Reaction score
297
Trophy points
1,363
Activity points
18,302
In the following code - signal alert will NEVER become high. right ?


Code: 
process ( clock , reset ) is 
begin
	if reset = '1' then 
		state <= state_1 ;
		x <= '0'
		alert <= '0' ;
	elsif rising_edge ( clock ) then
		
		case state is
	
			when state_1 =>
				x <= '1' ;
				if trigger = '1' then
					x <= '0' ;					
					state <= state_2 ;
				end if ;
				
			when state_2 =>
				if x = '1' then 
					alert <= '1' ;
				end if ;
	
		end case ;
   end if ;
end process ;
 

the probability of it turning high is low

but we can never say that it will not turn high at any time
 
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Now this :

Code: 
first_process : process ( clock ) is
begin
	if rising_edge ( clock ) then
		x_registered <= x ;
	end if ;
end process ;

rise_of_x <= x and ( not x_registered ) ;

second_process : process ( clock ) is
begin
	if rising_edge ( clock ) then
		if rise_of_x = '1' then
			[COLOR="#FF0000"]alert[/COLOR] <= '1' ;
		end if ;
	end if ;
end process ;

We can say with a high level of certainty that the second process will detect the rise_of_x signal (just before it falls to zero) and assert the alert signal high!

Please explain how and why this differs from the situation in my first post.
Why does the logic in the first post fails to capture while the second one is almost certain to work.
 

I don't understand your point here. The second code example is a clocked rising edge detector for the input signal "x".

The first code example doesn't make sense. The input signal "trigger" makes the state machine go to state_2 but sets x to '0' at the same time,
so alert can not go high since the state machine is stuck in state_2 and x is not assigned a value there so it will keep the value '0'.

When a process is executed all signals you read reflect the state they had before th execution started.
The assignments take effect when the process execution halts, so they will be available at the next execution.
When you second code example goes to state_2, x was set to zero in the previous execution, so it will read as '0' until another value is assigned,
and that will never happen.
 
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
you're saying that the combinatorial logic inside each state "comes to life" a single clock pulse after the state has been entered ?
 

No, I say that state_2 is entered one clock cycle after the assignment "state <= state_2;".
x is assigned '0' at the same time, so it will be '0' when the state is entered.
 

in the first post -- alert will be 0. The only ways for it to be something else is if you give alert, x, and state initial values that would allow simulation to retain a '1'. eg,
Code: 
signal state : state_type := state_2;
signal x : std_logic := '1';
signal alert : std_logic := '1'; -- optional, the above two are enough if the reset is never given


in post #3, during reset, x = '0'. the cycle after reset, x = '1'. Because alert in this example is not limited to specific states, alert will be asserted directly after reset. The lack of a reset condition may also upset the synthesizer. This is likely not what you were asking about though.

Also for post #3, your premise is false. Assuming for the moment that x had been reset to '1' to avoid the reset to state_1 transition, when trigger is high and the clock rises, the system will transition to state_2, x will transition to '0', and x_registered will transition to '1' (remain '1'). on the next cycle, x_registered will transition to '0'. at this point, there is no way for x to change to a '1' (except with a reset from the assumptions of this post).


This may be helpful -- you have three pieces of code in post #3. you can re-order these in any of the six different permutations that are possible. This will not affect the design at all. The code is not executed sequentially. The next values are all determined, but not assigned. Only after all of the "next states" are determined is anything actually changed. after everything is changed, it is possible that "events" have occured, and require processes to be evaluated.
 
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Ignore the resets please - there're not the point here.

I'll try to explain again what's unclear to me...
In both cases (post #1 and post #3) the condition is evaluated when it's already '0' (from viewing the simulation waveforms - that's how it seems to mee at least).

1. in post #1 the triggering condition (if x='1') is evaluated when 'x' is already '0' so nothing happens.
2. in post #3 the triggering condition (if rise_of_x = '1') is also evaluated when "rise_of_x" is already '0' however, in this case the logic still sees this signal high and asserts alert <= '1'

Why does this happen?
 

In post #3, when x goes high, rise_of_x will be '1' until the next rising clock edge, and there the condition to set alert will be detected.
rise_of_x will go to '0' when alert goes to '1'. Remember that the clocked process will see the values that existed just before the clock edge.

I should mention that the edge detector in post #3 is not the proper way to do it if 'x' is unrelated to the clock.
To avoid metastability problems, 'x' should be clocked through at least 2 registers. To do the edge detection you add one extra register.

A rewritten version of post #3, not tested:

Code VHDL - [expand]
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19

signal x_registered: std_logic_vector(2 downto 0);
...
first_process : process (clock) is
begin
  if rising_edge(clock) then
    x_registered <= x_registered(1 downto 0) & x ; -- shift in the next sample of 'x'
  end if ;
end process ;
 
rise_of_x <= x_registered(1) and (not x_registered(2)) ; -- only use signals that have been clocked through at least 2 registers
 
second_process : process ( clock ) is
begin
  if rising_edge (clock) then
    if rise_of_x = '1' then
      alert <= '1' ;
    end if ;
  end if ;
end process ;
 
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
suggest drawing the circuits by hand if its not clear.

code one checks the output of a register, the 2nd checks some combinatorial logic. as has been posted, the first sm sets the x value, in the 2nd, x is just an input to the system.
 

Remember that the clocked process will see the values that existed just before the clock edge.
Click to expand...
My point exactly!

According to this statement:
state_2 should see "the values that existed just before the clock edge" - hence , state_2 should see 'x' at logic '1' (because x -
drops to '0' after that clock edge !

Just to make clear. I'm not arguing with the facts - I know what happens. I just don't understand why...
 

x is set to '0' at one clock edge, but it is evaluated at the next clock edge, when state_2 is entered.

"state" is a signal, so when you set it to "state_2" on one clock edge, that value will be used in the case statement at the next clock edge.
 
Reactions: shaiko

    S

    shaiko

    Points: 2
    Helpful Answer Positive Rating
Thanks std_match !
Post #12 makes it crystal clear.
 

Status
Not open for further replies.

Similar threads

Menu
Log in
Register
Cookies are required to use this site. You must accept them to continue using the site. Learn more…