# How propagation delay of synchronous counter is less than asynchronous counter?

My question is very basic one, but thought of asking here to clarify. In asynchronous counter the output of Flip Flop is given as input to other Flip Flop as clock, where as in synchronous counter the output of Flip Flop is given as direct input to other Flip Flop. So in both cases the next Flip Flop has to wait until previous output of Flip Flop is available. Can someone explain how synchronous counter has less propagation delay than asynchronous?

• It’s also called a ripple counter which means each /2 delay adds up Mar 30, 2018 at 4:20
• The critical path is the clock-to-output (Tco) delay of a flip-flop. For an asynchronous counters, all Tco are summed. For a synchronous counter, there is only one Tco in the equation. Note, as the asynchronous counter output signals are asynchronous to the clock, the counter values needs to be synchronized to clock, which takes several clock cycles. Apr 1, 2018 at 19:39

In every Flip-Flop there is the clock-to-Q delay.

In a synchronous counter all the outputs are updated with a single clock to Q delay.

In an a-synchronous counter the first FF updates after one clock to Q delay. The second one can only change after the first one has changed so it updated in two clock to Q delays. The third one needs three clock to Q delays etc.

If you analyze only for two FFs you won't see the difference. But as the counter is built by more and more FFs, the difference becomes apparent.

If you have 'n' FFs, for an asynchronous counter, the 'n' FF has to wait until the clock signal has traversed the previous 'n-1' FFs. For a synchronous counter the latency is constant, since all the FFs receive the clock simultaneously. The latency is a single clock cycle.

• Yes, but the inputs to other flip flops will be given from previous flip flop outputs. So the inputs will be available after the outputs are generated in previous flip flops. So these flip flops also should wait for output of previous flip flops even clock is present?
– gvs
Mar 30, 2018 at 4:38
• @gvs the FFs must 'wait' that other FFs (and logic) update their inputs, that is right. But if you design the counter in such a way that there is enough time for all the inputs to settle so to fulfill setup time, you know you will ALWAYS have a new datum at each rising edge of a clock. Imagine connecting the output of each counter to a synchronous register. Draw them and see for yourself that the output from the asynchronous counter 'steals' setup time for each stage you add to it, for the register connected to its output. Mar 30, 2018 at 5:12