Parallel Load operation:
Clock (CLK):
Reset:
Counter:
Flip Flops:
Answer:
Without the extra flip flop, the serial data might be valid only briefly, which would be make the receiving equipment very susceptible to errors due to tiny variations in timing.
This arrow convention can be used in both the table and the state diagram.
Incidentally, how does the counter reach unwanted states? Once it's in one of the desired states, it is designed to cycle through them, never reaching any of the unwanted ones. However, what happens when the power is first switched on? The counter could be in any state then. Another way this can happen is if the power flickers momentarily, as occasionally happens to both mains and batteries. A third possibility is that we might try to run the clock too fast: overclocking can cause hardware to enter unwanted states. On PCs, overclocking can cause spontaneous reboots and other unpleasant events.
--> yyyy
If the Next State is unstable, then follow it by a dashed arrow, then the state that it immediately changes into. For instance:
yyyy --> zzzz
| Current State | Next State |
| 000 | 001 |
| 001 | 010 |
| 010 | 011 |
| 011 | 100 |
| 100 | 101 --> 000 |
| 101 | --> 000 |
| 110 | 111 --> 000 |
| 111 | --> 000 |
In this example, the first five states (000 to 100) are stable, but the next active clock edge causes 100 to transition to an unstable state 101 which the gate logic quickly replaces by 000. States 101 to 111 are unwanted states, but on power-up the counter could start in any state. Normally we'd want the counter to be initialised as zero (here 000), but we haven't provided any initialisation circuitry. Of the three unwanted states, 110 is stable, but 101 and 111 are unstable because of the NAND gate.
Here's the state diagram for the mod 5 counter. Note which transitions are clocked (synchronous), and which are gated (asynchronous).