I have seen similar behaviour with Altera Quartus. It was the same problem: asynchronous inputs changed the state machine and sometimes it hangs. I think it is possible that the state machine is internally implemented with some more bits and it is possible that it hangs, if there are some timing violations or meta stability conditions, because then there is an invalid state encoded and everything can happen with optimized gates. The fix was easy: Creating an input latch (or even two, if you are paranoid) for each asynchronous signal to make it synchronous. -- Frank Buss, http://www.**--****.com/ piano and more: http://www.**--****.com/
On Sep 20, 10:52m, Darol Klawetter < XXXX@XXXXX.COM > <snip> I only skimmed the code, but this bit jumped out at me: if (pipeFill == 1'b1) // 'pipeFill' is asynchronous to 'clk' If pipeFill is really asynchronous to the clock that is running your state machine, using it without synchronizing it first is going to cause you problems. Probably not because of metastability, but because of coherency problems. If pipeFill is changing near the clock edge, some FFs will see the new value, and some the old. This can cause weird and flaky behaviour. Regards, John McCaskill www.FasterTechnology.com
I thought the same thing, especially because XST often uses one-hot encoding internally, and that introduces more state bits. Even though I exhaustively defined all states, this may not be the case in the post-synthesis result.
> asynchr>no>s to 'clk' > > If pipeFill is really asynchronous to the clock that i> running your > state machine, sing it without synchronizing it fir>t is going to > cause you problems. robably not because of meta>tability, but > because of coherency problems. If pipeFill is changing >ear the clock > edge, some FFs will see the new value, and some the >ld. his can > cause weird and fl>ky>behaviour. >> >> Regards, > > John McCaskillwww.FasterTechnology.com Agreed, but the state machine should recover, right? All states are defined.
On Mon, 20 Sep 2010 08:52:16 -0700 (PDT), Darol Klawetter Try adding a (* safe_implementation = "yes" *) to your state register and see if that gets rid of the problem. -- Muzaffer Kal DSPIA INC. ASIC/FPGA Design Services http://www.**--****.com/
> asynchr>no>s to 'clk' > > If pipeFill is really asynchronous to the clock that i> running your > state machine, sing it without synchronizing it fir>t is going to > cause you problems. robably not because of meta>tability, but > because of coherency problems. If pipeFill is changing >ear the clock > edge, some FFs will see the new value, and some the >ld. his can > cause weird and fl>ky>behaviour. >> >> Regards, > > John McCaskillwww.FasterTechnology.com I think I just found the source of the problem, and it's not a bug in XST. In state S1, if 'state' is updated while 'phaseRamWE' is not, then it would produce the symptoms I saw. Early on, I had considered synchronizing pipeFill to the 'clk" domain, but I thought I would just handle it in the robustness of the state machine - my mistake.
On Sep 20, 11:12m, Darol Klawetter < XXXX@XXXXX.COM > > > asynchr>no>s>to 'clk' > > > If pipeFill is really asynchronous to the clock that i> >unning your > > state machine, sing it without synchronizing it fir>t>is going to > > cause you problems. robably not because of meta>t>bility, but > > because of coherency problems. If pipeFill is changing >e>r the clock > > edge, some FFs will see the new value, and some the >l>. his can > > cause weird and fl>ky>b>haviour. >> >>>>Regards, > > > John McCaskillwww.Faster>ec>nology.com > > Agreed, but the state machine should recover, right? >ll states are > defined. Hello Darol, While you may have specified all the possible states for the width of state variable that you used, unless you tell XST otherwise, it will choose which ever encoding style that it feels is optimal. That is usually a one hot encoding for a state machine the size of yours. By default, XST will assume that states that you do not explicitly have a transition to are truly unreachable and will not worry about them, and will ignore default or when others cases of your case statement. You can change the default behavior. You can force the tools to use an encoding of your choice, and you can use the safe state machine constraint to cause the tools to be more conservative in their assumptions about unreachable states. Doing that will come at a cost that the tools will choose a different encoding that will probably be slower and bigger. I think that you are much better off to always synchronize an asynchronous signal at the boundary of your design. Regards, John McCaskill www.FasterTechnology.com
On Sep 20, 2:02m, Darol Klawetter < XXXX@XXXXX.COM > The rule is that any time there is a logic path from an asynchronous input to more than one device that samples the signal(s), you must first synchronize the signal before feeding it into any logic path. This condition occurs for any state machine with more than one state. KJ
> The rule is that any time there is a logic path from an asynchronous input to more than one device that samples the signal(s), you must first synchronize the signal before feeding it into any logic path. This condition occurs for any state machine with more than flip flop used to implement the state. KJ
I agree that this is a rule that should be generally followed, but there are exceptions. For example, a gray-coded state machine is sometimes used to tolerate an asynchronous control input. If timing is violated on any of the flops, the machine will stay at the current state or transition to the next state.
On Sep 20, 5:01m, Darol Klawetter < XXXX@XXXXX.COM > In practice, Gray code is not very useful for state machines that have many branch possibilities. Remember that you need to make sure that any possible transition only changes one state bit. This is easy for any linear or loop state logic like a counter, but most control logic state machines will have multiple-way branching from many of the states. So unless you add intermediate states to prevent more than two-way branching from any node you can still run into problems with asynchronous inputs to the Gray coded machine. The added states would give the same delay as a synchronizer flop on the input signal.
On Sep 20, 2:01m, Darol Klawetter < XXXX@XXXXX.COM > This is not a rule that "should be generally followed". It is rule that must ALWAYS be followed! If a signal from a "foreign" clock domain is used in a conditional inside a state machine, the state machine will fail (eventually). This is NOT a metastability problem. It is because the time to decode the D inputs of the state bits is different for each D input, and if the "foreign clock" signal is used in a conditional it will go to more than one D input. There is no way to ensure that the D inputs are all valid at the same time, and when the clock happens while one is valid and the other is not state machine gets corrupted. This syndrome is independent of the coding method of the state variable. Synchronizing all inputs to a state machine to the state machines clock will prevent that. Not optional. Sorry. RK
In comp.arch.fpga, Did that many years ago for a CPLD design! Draw a big Karnaugh map, try put in your states with the minimum possible dummy states and only single bit changes. Great fun, better than cross-words. :-) But agreed, wouldn't do that now (although, I might ...), and back then it only worked if the machine was not too complex. -- Stef (remove caps, dashes and .invalid from e-mail address to reply by mail) Most public domain software is free, at least at first glance.
Return to Computer architecture
Users browsing this forum: No registered users and 40 guest