Common Counter FSM Reset
Guest
#4740547
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. 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. 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...
Guest
#4740573
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:
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.
Guest
#4740639
never mind, my own twisted logic, fsm is not clocked... thx 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... ;-) ReplyPlease log in before posting. |