Why do we need to synchronise asynchronous inputs in FSM?
As you already understand, your traffic light controller state machine is a synchronous machine. That is, it is driven by some clock in such a way that all combinatorial logic changes happen and settle out to stable values long enough before the next clock edge to meet the required set-up times.







simulate this circuit &ndash; Schematic created using CircuitLab



If the data changes within that setup time the final output will not only be unpredictable, but due to meta-stability, can actually float or dance around some intermediate value for a while before it picks a final value. It can even oscillate between logic one and logic zero at a high frequency causing considerable current flow and heating.



As such, any asynchronous input to a state machine needs to be synchronized at some point in order for the system to work as you expect it to. However, that does not necessarily mean you ALWAYS need to add another latch to the system.

If the input is only proceeding to a single "next gate" AND the state of the input is independent of all other inputs, then it really does not matter if the signal arrives late to the party. Basically, you need to ask... "If we miss the input for a clock cycle, does it matter?"

If however, the input feeds multiple gates that is different. The next gates may see different logic levels and propagate an erroneous state to the next latch.  Basically a variety of bad things can happen.

This can be illustrated with your simple example. Note if the metastability at REG1 has not settled before the next clock, it could cause both the WALK and Traffic light to turn on at the same time, or neither could turn on.







simulate this circuit

Further, if an asynchronous input has a relationship with another asynchronous input that you expect to happen at the same time, the second input may be recognized but the first one not.

In both cases you need to add a synchronizing latch to the input to bring the signal timing into line with the state machines clock. Notice, this adds one clock cycle delay, or a half clock cycle delay if you use the other edge of the clock signal.

However, you may be asking, "but doesn't THAT latch suffer from the same problem?" and of course, the answer would be yes it does. But the trick here is to allow that potential meta-stability to happen at a point in the circuit where it does not matter as I highlighted above.

Finding that point can be problematic with dependant inputs. Normally, extra logic needs to be added to qualify those inputs.

However, be aware metastability is a probability thing. Although, because of differences in manufacturing tolerances, most latches will pick-a-side very quickly, there is the possibility that it will remain unstable for quite some time. The longer the gap between clock pulses the higher the probability that it will have settled. As such, if your system clock is at a high frequency it is prudent to divide it down to do the pre-latch to allow for more settling time. However, even then there are no guarantees. 

A final thought. I mentioned that there is the possibility of meta-stability induced high currents and heating when synchronizing a random external input. Unfortunately, there is very little you can do to correct that and long metastability issues other than removing asynchronous input circuits.