Hello,
I am having some troubles with my Moore state machine. Is it actually possible to use an internal signal or variable dependancy in a IF-statement during a process? Im using a the next-state logic. It uses a case statement with the state-reg signal as the selection expression. The next state is determined by the current state and external input. It consists of segments for the state register, next-state logic, Moore output logic. Actually i like to check my internal signal X or variable X which is initialized with zero during a specific case in my state machine. Once i reach this case statement, im checking with my If statement. When this condition is true the next state of my state machine is determined while I m incrementing my checked signal or variable X so that I will never go in this state again expect some hard resets because the specfic IF-statementcheck is not fulfilled. Im not able to get this behaviour. I can get it to work when i am exclusivly using defined inputs from my entity in order to change the next state in my combinatorical block. Here an example of my issue ------------------------------------------------------- process(...) variable cnt: integer:=0; begin case current_fsm_state is when State_A => if(cnt=1)then cnt=cnt+1; -- check only once and never again expect resets next_fsm_state<=B; elsif(input_a='1')then next_fsm_state<=State_C; else next_fsm_state<=State_A; end if; ...... ----------------------------------------------------------------- I am using that integrated student waveformbuilder in quartus to test my system on correctness ....especially this special case with that internal signal or variable( I ve tried both) is messing my state machine up. I mean i know that variables get instantly updated when I enter a process...but does that also count for an expression within nested if statements? I thought here is the equivalence to C-programming style. So far i ve only seen finite state machines with external inputs in literature. Does someone have advice how to face this issue?Link Copied
This code snippet has issues:
1. VHDL is NOT a programming language, it is a hardware description language. Treating VHDL like C or any other programming language is doomed to failure. You should be drawing your circuit before you write any VHDL. 2. It is not a synchronous process, so you cannot have a counter in it. A counter is a synchronous logic circuit. Having it in an asynchronous process will cause it to count up in infinitely small amount of time. 3. I highly recomend you do not use variables. They can have behaviour that may work like a programming language but then will make your circuit behave really badly. You should use signals for everything. 4. Where is the process that assigns the next state to the current state? Why are you using a wave builder? you would be much better served writing a testbench in VHDL as you have far more control.Hello Tricky , thanks for your reply. I am aware that I am describing hardware, but I am still a big novice. Im using that waveformgenerator because we used it on my university first time when I came in touch with vhdl/verilog to test easy circuits.
Currently I have a block diagram in my eye's mind how to implement it (reffering to literature). I just like to describe this behaviour I ve mentioned in my first post. Here s a small cutaway for the nextstate logic. --------------------------------------------- state : process(clk,rst) begin if(rst='1') then current_fsm_state<=RESETSTATE; --current_internal_cnt<="00"; elsif(rising_edge(clk)) then current_fsm_state<=next_fsm_state; --current_internal_cnt<=next_internal_cnt; -- -- i have also tried it with that signal assignment to check against it end if; end process; p_output: process(current_fsm_state) begin case current_fsm_state is when RESETSTATE => error_output<='0'; when State_A => -- -- dont wanna spam the complete code end case; end process; ------------------------------------------------------------------ Do u have some ideas how to implement or avoid this scenario?Im not quite sure what you want. Your first post implies that you assume the process is executed over some finite time. It's not. Its executed in 0 time. Your state transition occurs on a clock edge, so if the RESETSTATE has a next state assignment to state_B, then it will happen on the next clock edge.
For more complete information about compiler optimizations, see our Optimization Notice.