# Forum: FPGA, VHDL & Verilog Common Counter FSM Reset

Rate this post
 0 ▲ useful ▼ not useful
Hello,

I want to use a common counter for several states within a FSM. As long
as there is a state inbetween which does not use the counter it can be
reset in time, but if the following state uses the counter, the
comparision logic in this state samples the counter value from the
previous state before it is reset.

Is there some other kind of design pattern to deal with this problem?

Thank you in advance.

: Moved by Moderator

Rate this post
 0 ▲ useful ▼ not useful
bumo wrote:
> Is there some other kind of design pattern to deal with this problem?
And it can simply be solved: just manipulate the counter value in a
manner that it gets a useful value when leaving the previous state.

BTW:
I moved your English question from the German to the English forum.
If you want to post in the German forum pls. write German...

Rate this post
 0 ▲ useful ▼ not useful
Lothar M. wrote:
> bumo wrote:
>> Is there some other kind of design pattern to deal with this problem?
> Your problem is namend "latency".
> And it can simply be solved: just manipulate the counter value in a
> manner that it gets a useful value when leaving the previous state.

Maybe i don't get it, but "manipulating the counter" for the next state
cannot work when it is clocked. Let's consider the following example:
 -- register process (clk, rst) is begin if rst = '0' then ... elsif rising_edge(clk) then state <= next_state; cnt <= next_cnt; ... end if; end process; -- fsm process (..., cnt) is begin case state is when current => if cnt > limit then next_state <= next; next_cnt <= (others => '0'); else next_cnt <= cnt + 1; end if; when next => if cnt > smaller_limit then ... ... 

When the condition cnt > limit is reached, next_cnt will be reset, but
since the next state will be set also, the condition cnt > smaller_limit
is true for the first clk cycle...

> BTW:
> I moved your English question from the German to the English forum.
> If you want to post in the German forum pls. write German...

sorry for that.

: Edited by Moderator

Rate this post
 0 ▲ useful ▼ not useful
never mind, my own twisted logic, fsm is not clocked...

thx

Rate this post
 0 ▲ useful ▼ not useful
bumo wrote:
> When the condition cnt > limit is reached, next_cnt will be reset, but
> since the next state will be set also, the condition cnt > smaller_limit
> is true for the first clk cycle...
How did you figure that out? By simulation?

Indeed both of them cn and state result in  a similar hardware: more
or less a simple counter consisting of flipflops. And if state gets
the new value, then at the very same time cnt gets its new value also.

> the condition cnt > smaller_limit is true for the first clk cycle...
It may only be "true" for a few picoseconds after the next clock edge:
after the clock edge the flipflops in the FPGA get new output values and
the whole FPGA is busy and "glitchy" until the logic has reached its
next stable values and has calculated the next counter value. And this
stable values results are the next values for cnt and the next values
for state.
A short while later the following clock edge transferres this values to
the flipflops output and the show starts again.

With the two-process style you have spilt off the flipflops and the
combinatorial logic explicitly. Now think about the whole thing again,
but simply assume, the clock comes ony each minute or hour. Then there
plenty of time for the logic to stabilize.

The whole thing is called "synchronous design".

EDIT:
bumo wrote:
> never mind, my own twisted logic
So, I was a little bit too late... ;-)

: Edited by Moderator

• $formula (LaTeX syntax)$