Delay counters in three process state machines

[thecolororange]

state machine delay

I'm trying to change some existing code to improve timing and the quality of the code in general. One of the ways I'm trying to do this is switching from using a single process for a state machine to dividing it into 3 processes (state advance, output, state change).

I'm having trouble with one part of the code, though. In several states, there are delays generated by using a simple counter, like the following:

	when READ_2 =>
		if wait_ctr = 2 then
			wait_ctr <= 0;
			sram_clk <= '1';
			ram_action    <= READ_DATA;
			access_state <= READ_3;
		else
			wait_ctr <= wait_ctr + 1;
		end if;

These worked fine when there was only one process, since that process was the only place I used or modified wait_ctr. With three processes, only the state advancement (access_state <= next_state process gets a clock, so it has to increment the counter, but only the state change process or output process would know when to reset wait_ctr, and they all can't drive the same signal.

If wait_ctr was always reset at the same max value, I'd be fine, but it's used in several places with different max values. Do I need separate signals for each counter? Is generating delays like this bad practice? Is there a better way? I appreciate any input.

 

[pev]

state machines with counters

You need make signals (as needed) like:
load counter enable,
load counter value,
counter incerment enable,
etc...
These signals talk from your anysrnconouse process to your syncronouse (state advance) one.

You could also put the conter into it's own process.

Generating delayes using counters is good practice as the dealy values are then easy to chage (much better then shift regsiters or extra states for large dealys). I tend to have the counter in its own process and use the overflow/underflow flag to trigger the state change (this way you don't need a logic chain to compare the counter's value).

 

[thecolororange]

3-process statemachine

@pev: Thanks, that's what I was looking for.

I'm guessing it would be better to move each delay (there are about 3 different delays I need to generate) into separate processes, rather than putting all 3 into a single process?

 

[pev]

how to provide delay by using counters

My apolgies I don't realy understand the question.

However in my when it comes to state machins it's best to have at least two processes a a syncrnoise one and an ansyncronise one.

The ansyncronise process is dependent on (signals in the senstivitly list)
... Current state (the value in your case statment)
... Counter underflow
... Reset (syncronise reset - best for Xilinx)
This process drives:
... next state
... counter load value
... counter load enable / counter decrement enable

The syncronise process (clk is in the senstivitly list - and only clock:
... sets current state to next state
... loads or decrements the counter value (drives counter underflow)


This is how I would recormend making a state machine in VHDL. Can I recormend you look at the VHDL coding examples in section 2 (XST HDL Coding Techniques) in the following document:
... <http://www.xilinx.com/itp/xilinx10/books/docs/xst/xst.pdf>
Even if your not using Xilinx this should help. Look at how thay implement carry in / carry out with there adders you can do the same thing for counters.

There FSM is all done all in one process but I still recorment breaking it up. It'll help you understand (and probabily the synthesisor) how it's being implemented in hardware.

 

[mytechface]

working of counter in state machines

you could always choose to use 3 separate counters to do 3 separate delays. it will be cleaner but more expensive in terms of gates.

or you could share. one way is by doing a decrement instead of increment, this way all the end state is the same (which is 0). when the wait counter = 0, you change state. with this change of state, you can re-load your wait counter with the number of cycles you want to wait for this particular state.

something like

if(wait_ctr == 0)
case NEXT_STATE
when READ_3 => wait_ctr = 2;
when READ_2 => wait_ctr = 4;
:
:
else
wait_ctr = wait_ctr - 1;