Continue to Site

Welcome to EDAboard.com

Welcome to our site! EDAboard.com is an international Electronics Discussion Forum focused on EDA software, circuits, schematics, books, theory, papers, asic, pld, 8051, DSP, Network, RF, Analog Design, PCB, Service Manuals... and a whole lot more! To participate you need to register. Registration is free. Click here to register now.

Register Log in

State Machines - please help me spot the error

Status
Not open for further replies.
Z

Zhane

Member level 5
Joined
Feb 2, 2008
Messages
89
Helped
1
Reputation
2
Reaction score
1
Trophy points
1,288
Activity points
1,876
State Machines

Code: 
signal output: std_logic_vector(3 downto 0);
signal LED : std_logic_vector;
signal count : integer:=0;

process(clk)
begin

  if(clk'event = true and clk='1') then
     state <= nextState;
  end if;
end process;


process(state,rst,in1,in2,in3)
begin
          LED <= '0';
  case state is
      when state 1 =>
           output <= "0010";
           if(in1 = '1') then
                count <= count +10;
           elsif (in2 ='1') then
                count <= count +5;
           elsif (in3 ='1') then
                 count <= count +20;
            end if;
          
            if(count >90) then
                LED <='1';
                count <= 0;
            end if;
      when state 2=>
            output<= "0001";
end case;

end if;


I have the above code implemented on a virtex 4 fpga, with in1,in2 and in3 as dip switches. state1 is the default state for 'state'.

I wanted something like this....
eg. when i set any of the dip switch (in1,in2 or in3) to high and then low, it increments the count once... until the next time i switch it to high-and-low again.
when the count hits >=90, the led is lit.

however when i tested it out on the fpga, without any clock and just the 2nd process alone... the LED blinks when i set in1/in2/in3 to high and held it there.

it seems that the increment is done many times while the in1/in2/in3 is being held when it should have been done once.


can anyone help me spot the error?
 

Re: State Machines

Several things I noticed:

1) You should add a reset condition for your state flip-flop so the hardware comes up in a known state. If you assign a value to a signal when you declare it, it will work in simulation but the hardware may not match.

2) You never set the nextState variable in your state machine process.

3) You need to add the count signal to your sensitivity list in your state machine process.

4) You probably want to add a "when others" case to your state machine.

5) This one is a minor nit. You can write rising_edge(clk) as a short-hand way of
checking for the rising edge of clk.

Radix
 

Re: State Machines

radix said:
Several things I noticed:

1) You should add a reset condition for your state flip-flop so the hardware comes up in a known state. If you assign a value to a signal when you declare it, it will work in simulation but the hardware may not match.
Click to expand...

something like a asynchronous reset that resets my count to 0 and state to state1?

2) You never set the nextState variable in your state machine process.
Click to expand...

in this example, i never intend to use the 1st process. just merely want to see how the 2nd process works out when in1/in2/in3 has something. but it happens that it keeps on retriggering despite in1/in2/in3 are being raised high and held there,... and rst and state remains unchanged.

3) You need to add the count signal to your sensitivity list in your state machine process.
Click to expand...

may i know why is there a need for this??
 

Re: State Machines

Zhane said:
radix said:
Several things I noticed:

1) You should add a reset condition for your state flip-flop so the hardware comes up in a known state. If you assign a value to a signal when you declare it, it will work in simulation but the hardware may not match.
Click to expand...

something like a asynchronous reset that resets my count to 0 and state to state1?
Click to expand...
Correct
2) You never set the nextState variable in your state machine process.
Click to expand...

in this example, i never intend to use the 1st process. just merely want to see how the 2nd process works out when in1/in2/in3 has something. but it happens that it keeps on retriggering despite in1/in2/in3 are being raised high and held there,... and rst and state remains unchanged.
Click to expand...
What do you mean the 2nd process is retriggering? How are you detecting this?

Are you seeing this in hardware or in a simulation?

Where is nextstate being declared? Where is it being set? Your 2nd process is a combinatorial process. If nextstate is changing, so is state, and so are your 2nd process outputs.
3) You need to add the count signal to your sensitivity list in your state machine process.
Click to expand...

may i know why is there a need for this??
Click to expand...
If your sensitivity list isn't complete the process won't alwarys update correctly in the simulation. This will lead to mismatches between the simulation and the actual hardware.

Radix
 

Re: State Machines

2) You never set the nextState variable in your state machine process.
Click to expand...

in this example, i never intend to use the 1st process. just merely want to see how the 2nd process works out when in1/in2/in3 has something. but it happens that it keeps on retriggering despite in1/in2/in3 are being raised high and held there,... and rst and state remains unchanged.
Click to expand...
What do you mean the 2nd process is retriggering? How are you detecting this?

Are you seeing this in hardware or in a simulation?

Where is nextstate being declared? Where is it being set? Your 2nd process is a combinatorial process. If nextstate is changing, so is state, and so are your 2nd process outputs.
Click to expand...
my count is actually a internal signal instead of a input signal. so what happens is this count is incrementing by itself when those inputs are being held high.

I see this in the hardware, but not in the software.

i've no clock, no changes made to nextstate, and so no changes done to state... that's y i nv expect the 2nd process to be triggered multiple times when the inputs are held high.

but the led juz blinks and blinks as a result of the count being incremented and reset.

3) You need to add the count signal to your sensitivity list in your state machine process.
Click to expand...

may i know why is there a need for this??
Click to expand...
If your sensitivity list isn't complete the process won't alwarys update correctly in the simulation. This will lead to mismatches between the simulation and the actual hardware.

Radix
Click to expand...

i should add it even when count is not an input signal but an internal signal??
 

Re: State Machines

You need to realize that unless you take care, simulations and hardware will not match. If you're doing digital design you're normally doing it synchronously, which means everything of relevance is changing in lock-step with a clock.

What you're currently implying in your code is strictly combinatorial logic (no clock). Everything you're doing with your count signal is combinatorial logic that is instantly feeding back on itself since you have no clocked elements. You should specify a range on your count signal and then make it part of a clocked process so that the value is stored in registers.

Something like this might work for you:

Code: 
signal count     : integer range 0 to 127;

-- FFs for count value
process(clk, rstn) 
begin 
  if (rstn = '0') then
    count <= (others => '0');
  elsif rising_edge(clk) then 
    -- The count will rollover to 0 when it exceeds 127
    if(in1 = '1') then 
      count <= count +10; 
    elsif (in2 ='1') then 
      count <= count +5; 
    elsif (in3 ='1') then 
      count <= count +20; 
    end if; 
  end if; 
end process; 

-- FF for LED value
process(clk, rstn) 
begin 
  if (rstn = '0') then
    LED <= '0';
  elsif rising_edge(clk) then 
    -- keep the LED signal high after count hits 91.  LED is set to 1 when
    -- count is between 91 and 127.
    if (count > 90) then
      LED <= '1';
    else
      LED <= '0';
    end if;
  end if; 
end process;

Radix
 

Re: State Machines

Zhane said:
in this example, i never intend to use the 1st process. just merely want to see how the 2nd process works out when in1/in2/in3 has something. but it happens that it keeps on retriggering despite in1/in2/in3 are being raised high and held there,... and rst and state remains unchanged.
Click to expand...
A process is effectively an eternal loop. When there is no feedback, the process appears to act like an "execute once" process. However, when you have feedback (a signal appears on both sides of the same assignment), the hardware will not "execute once" in the absence of clocking.

Clocked processes using event or rising_edge/falling_edge are the preferred means to create "execute once when triggered". The clock edge provides the trigger. The signal that is updated only once must appear in the code block selected by the clock condition.
 

Re: State Machines

tkbits said:
A process is effectively an eternal loop. When there is no feedback, the process appears to act like an "execute once" process. However, when you have feedback (a signal appears on both sides of the same assignment), the hardware will not "execute once" in the absence of clocking.
Click to expand...

I'm not quite sure what you mean by "a signal appears on both sides of the same assignment" (a <= a ????).

I just want to clarify the last line above. If you have a block that is just combinatorial logic (and gates, or gates, muxes, etc... and no FFs) and you have feedback from the output of that block back into the input you may do more than execute once. If the feedback path involves an odd number of inversions you may create an oscillation, i.e. that path is constantly switching.

Also, for a combinatorial block every input to that block provides the switching.

Radix
 

Re: State Machines

You have feedback with

count <= count + 5;

This is because an adder is not a sequential circuit - the adder is combinational, built with AND, OR, and NOT logic, and no registers.

This is the case with the original post, where the counter increment is in a process that does not have a clk'event or rising_edge/falling_edge condition.

Put the increment under a clock condition, as you have done, and that removes combinational feedback, because a register is inferred.
 

Status
Not open for further replies.

Similar threads

Part and Inventory Search

Welcome to EDABoard.com

Sponsor

Back
Top