Why do instructions need to be processed at set time intervals (i.e. with the use of a clock)? Can't they be executed sequentially - immediately after the previous instruction has completed?

An analogy for the necessity of clocks in microcontrollers would prove particularly useful.

  • 7
    \$\begingroup\$ There are asynchronous processors. \$\endgroup\$ Jun 20, 2015 at 18:18
  • 9
    \$\begingroup\$ How would you determine "when the previous instruction has completed"? If you think about it, you'd need to know when the "Has the previous instruction completed?" computation had completed, and when the "Has the "Has the previous instruction completed?" computation" computation has completed, and........ It's much easier to just say "It takes 0.4 nanoseconds to complete an instruction". \$\endgroup\$
    – user253751
    Jun 21, 2015 at 1:01
  • 5
    \$\begingroup\$ Logic gates do not say when they are done. The signal is simply indeterminate for some period of time before settling on a stable value. In essence the clock allows the design to know when the logic has settled on a correct value. Advanced strategies like microinstructions help by breaking machine instructions into smaller pieces, so an ADD can take 4 clock ticks, while memory access might take hundreds of ticks. \$\endgroup\$
    – user52386
    Jun 21, 2015 at 11:04

8 Answers 8


An illustrative example or two may help here. Take a look at the following hypothetical circuit:


simulate this circuit – Schematic created using CircuitLab

Suppose to start both A and B are high (1). The output of the AND is therefore 1, and since both inputs to the XOR are 1, the output is 0.

Logic elements don't change their state instantly - there's a small but significant propagation delay as the change in input is handled. Suppose B goes low (0). The XOR sees the new state on its second input instantly, but the first input still sees the 'stale' 1 from the AND gate. As a result, the output briefly goes high - but only until the signal propagates through the AND gate, making both inputs to the XOR low, and causing the output to go low again.

The glitch is not a desired part of the operation of the circuit, but glitches like that will happen any time there's a difference in propagation speed through different parts of the circuit, due to the amount of logic, or even just the length of the wires.

One really easy way to handle that is to put an edge-triggered flipflop on the output of your combinatorial logic, like this:


simulate this circuit

Now, any glitches that happen are hidden from the rest of the circuit by the flipflop, which only updates its state when the clock goes from 0 to 1. As long as the interval between rising clock edges is long enough for signals to propagate all the way through the combinatorial logic chains, the results will be reliably deterministic, and glitch-free.

  • 9
    \$\begingroup\$ Thank you for actually mentioning propagation delay almost immediately, that is probably 99% of the answer. \$\endgroup\$
    – user52386
    Jun 21, 2015 at 11:07
  • 1
    \$\begingroup\$ A working example of this in action can be observed on Microchip (and other) microcontrollers' digital I/O peripherals. If you use the PORT registers to update outputs (rather than the LATCH) using consecutive Read-Modify-Write instructions, it is possible to read the state of the pin whilst it is changing state. See section 10.2.2 of the dsPIC33E/24E documentation for more detail. \$\endgroup\$ Jun 22, 2015 at 8:25
  • \$\begingroup\$ Do I understand it right that sequential circuits critically need clocking not only because they'll get glitches, but also because, due of this glitch, some flip-flop may end up storing the wrong value? \$\endgroup\$ Dec 25, 2017 at 14:21

I feel a lot of these answers are not exactly hitting on the core question. The micro-controller has a clock simply because it executes (and is driven by) sequential logic.

In digital circuit theory, sequential logic is a type of logic circuit whose output depends not only on the present value of its input signals but on the sequence of past inputs, the input history. This is in contrast to combinational logic, whose output is a function of only the present input. That is, sequential logic has state (memory) while combinational logic does not. Or, in other words, sequential logic is combinational logic with memory.

As well:

The main advantage of synchronous logic is its simplicity. The logic gates which perform the operations on the data require a finite amount of time to respond to changes to their inputs. This is called propagation delay. The interval between clock pulses must be long enough so that all the logic gates have time to respond to the changes and their outputs "settle" to stable logic values, before the next clock pulse occurs. As long as this condition is met (ignoring certain other details) the circuit is guaranteed to be stable and reliable. This determines the maximum operating speed of a synchronous circuit.


Short answer: managers want a simple, testable, PROOF of function before committing to millions (or more) dollars to a design. Current tools, just do not give asynchronous designs those answers.

Microcomputers and microcontrollers typically utilize a clocking scheme to insure timing control. All process corners have to maintain timing across all voltage, temperature, process, etc effects on signal propagation speeds. There are no current logic gates change instantly: each gate switches depending on the voltage it is supplied, the drive it gets, the load it drives, and the size of the devices that are used to make it, (and of course the process node (device size) it is made in, and how fast THAT process is actually performing --- THIS pass through the fab). In order to get to "instant" switching, you'd have to use quantum logic, and that assumes that quantum devices can switch instantly; (I am not sure).

Clocked logic makes PROVING that the timing across the entire processor, works across the expected voltage, temperature and processing variables. There are many software tools available that help measure this timing, and the net process is called "timing closure". Clocking can (and, in my experience, does) take somewhere between 1/3 to 1/2 of the power used in a microprocessor.

So, why not asynchronous design? There are few, if any, timing closure tools to support this design style. There are few, if any, automated place and route tools that can deal with, and manage, a large asynchronous design. If nothing else, managers do NOT approve anything that does not have a straightforward, computer generated, PROOF of functionality.

The comment that asynchronous design requires "a ton of" synchronizing signals, which required a "lot more transistors", ignores the costs of routing and synchronizing a global clock, and the cost of all of the flip-flops that clocking system requires. Asynchronous designs are, (or should be), smaller and faster than their clocked counterparts. (One simply takes the ONE slowest signal path, and uses that to feed back a "ready" signal to the preceding logic).

Asynchronous logic is faster, because it never has to wait for a clock that had to be extended for another block somewhere else. This is especially true in register-to-logic-to-register functions. Asynchronous logic does not have multiple "set up" and "hold" issues, as only the ending sink structures (registers) have those issues, as opposed to a pipelined set of logic with flip-flops interspersed to space the logic propagation delays to clocking boundaries.

Can it be done? Certainly, even on a billion transistor design. Is it harder? Yes, but only because PROVING that it works across an entire chip (or system even), is much more involved. Getting the timing on paper is reasonably direct for any one block or sub-system. Getting that timing controlled in an automated place and route system, is much harder, because the tooling is NOT set up to handle the much larger potential set of timing constraints.

Microcontrollers also have a potentially large set of other blocks that interface to (relatively) slow external signals, added to all the complexity of a microprocessor. That makes timing a little more involved, but not much.

Achieving a "first-to-arrive" "lock-out" signal mechanism is a circuit design issue, and there are known ways of dealing with that. Race conditions are a sign of 1). poor design practice; or 2). externals signals coming into the processor. Clocking actually introduces a signal-vs-clock race condition which is related "set-up" and "hold" violations.

I, personally, do not understand how an asynchronous design could get into a stalled, or any other race condition. That might well be my limitation, but unless it happens at data entering into the processor, it should NEVER be possible in a well designed logic system, and even then, since it can happen as the signals enter, you design to deal with it.

(I hope this helps).

All that said, if you have the money ...

  • \$\begingroup\$ Of course, it depends on the chip you're building - for example, neural networking hardware tends to be asynchronous, because that's actually the easiest thing - the thing they're emulating is asynchronous. We're mostly building synchronous sequential hardware, because the software /firmware is also mostly synchronous and sequential (especially on the "sequential" part - asynchronous code is used more and more commonly). In fact, it's a lot easier to wrap your head around a sequential, synchronous system, especially when most programming is done in languages that encourage sequential code. \$\endgroup\$
    – Luaan
    Jun 22, 2015 at 12:31
  • \$\begingroup\$ Events in the real-world happen at unpredictable times. If a device has a button, and is supposed to execute one code path if it's pushed "soon enough" and execute another code path if it isn't, then in the absence of quantum-mechanical limitations, between a moment when pushing the button where a button push would happen soon enough to trigger the alternate code path, and a moment where a button push would be "too late", there would be some precise moment where a button push would cause some behavior "between" the two (e.g. causing some bits of the program counter to get changed... \$\endgroup\$
    – supercat
    Jun 22, 2015 at 16:47
  • \$\begingroup\$ ...but not others). In the absence of quantum-mechanical limitations, the time between the last moment when the push would cause the branch, and the first moment when a push would cleanly fail to do so, could be made arbitrarily small but not reduced to zero. Quantum-mechanical limits may make it likely that any button push would happen either earlier enough to register or late enough to fail cleanly, but proving that there will never be a quantum state that would allow a button push in the deadly intermediate time would generally be infeasible. \$\endgroup\$
    – supercat
    Jun 22, 2015 at 16:50
  • \$\begingroup\$ Using synchronous logic greatly simplifies the analysis of situations where the system will need to respond to a truly-asynchronous event by ensuring that race conditions will have a very low probability of escaping a very small portion of the overall device. Analyzing that small portion of the device to ensure that race conditions are unlikely to escape is apt to be a much more tractable problem than allowing race conditions to occur almost anywhere and trying to analyze their effects to prove they're acceptably unlikely to cause trouble. \$\endgroup\$
    – supercat
    Jun 22, 2015 at 16:55

Microcontrollers need to use a clock because they need to be able to respond to events that may occur at any time, including nearly simultaneously with either other external events or events generated by the controllers themselves, and will often have multiple circuits that need to know whether one event X precedes another event Y. It may not matter whether all such circuits decide that X preceded Y, or all such circuits decide that X did not precede Y, but it will often be critical that if any of the circuits decides that X preceded Y, then all must do so. Unfortunately, it's difficult to ensure that circuits will within a bounded time reach a guaranteed consensus as to whether X precedes Y, or even reach a consensus on whether or not they have reached a consensus. Synchronous logic can help enormously with that.

Adding a clock to a circuit makes it possible to guarantee that a subsystem will not experience any race conditions unless an input to the system changes in a very small window relative to the clock, and also guarantee if the output of one device is fed into another, the first device's output will not change in the second device's critical window unless the input to the first device changes within an even smaller critical window. Adding another device before that first device will ensure that the input to the first device won't change in that small window unless the input to the new device changes within a really really tiny window. From a practical perspective, unless one is deliberately trying to cause a consensus failure, the probability of a signal changing within that really really tiny window can be reduced to be smaller than the probability of the device suffering some other uncontrollable failure such as a meteor strike.

It's certainly possible to design fully-asynchronous systems that run "as fast as possible", but unless a system is extremely simple it will be hard to avoid having a design get tripped up by a race condition. While there are ways of resolving race conditions without requiring clocks, race conditions can often be solved much more quickly and easily by using clocks than would be the case without them. Although asynchronous logic would often be able to resolve race conditions faster than clocked logic, the occasions where it can't do so pose a major problem, especially given the difficulty of having parts of a system reach consensus on whether or not they have reached consensus. A system which can consistently run one million instructions per section will generally be more useful than one which may sometimes run four million instructions per second, but could potentially stall for milleconds (or longer) at a time because of race conditions.

  • \$\begingroup\$ It's worth noting that the states being decided on can equally be internal ones - such as the result of an arithmetic operation. Delays due to line length can result in one part of the MCU seeing the result - and, without a clock, acting on it - before other parts. \$\endgroup\$ Jun 20, 2015 at 22:41
  • \$\begingroup\$ @NickJohnson: If the sequence in which operations are performed is never dependent upon things that aren't computed yet, those issues can be resolved without difficulty if each section like an ALU has "valid" inputs and a "valid" output, and things can be arranged so as to happen in deterministic sequence. Where the wheels fall off is when the order in which operations occur should depend upon the timing (e.g. if one has a number of parallel operations which need to use a shared memory bus and two of them issue near-simultaneous requests, arbitration of which one should go first... \$\endgroup\$
    – supercat
    Jun 20, 2015 at 23:16
  • \$\begingroup\$ ...and which one should wait may be intractable. If one decides beforehand which one is going to go first, such problems can be avoided, but if it turns out that the unit which was designated to go first isn't ready until long after the other one, performance may severely suffer as a result. \$\endgroup\$
    – supercat
    Jun 20, 2015 at 23:18
  • \$\begingroup\$ This is why going to space is so hard, the probabilities change unfavourably. \$\endgroup\$ Jun 21, 2015 at 9:11

MCUs are only one very complex example of a synchronous sequential logic circuit. The simplest form is probably the clocked D-flip-flop (D-FF), i.e. a synchronous 1 bit memory element.

There are memory elements that are asynchronous, for example the D-latch, which is (in a sense) the asynchronous equivalent of the D-FF. An MCU is nothing more than a bunch of millions of such basic memory elements (D-FF) glued together with tons of logic gates (I'm oversimplifying).

Now let's get to the point: why do MCUs use D-FFs instead of D-latches as memory elements internally? It's essentially for reliability and ease of design: D-latches react as soon as their inputs change and their outputs are updated as fast as possible. This allows for nasty unwanted interactions between different parts of a logic circuit (unintended feedback loops and races). Designing a complex sequential circuit using asynchronous building blocks is inherently more difficult and error prone. Synchronous circuits avoid such traps by restricting the operation of the building blocks to the time instants when the clock edges are detected. When the edge arrive a synchronous logic circuit acquires the data at its inputs, but doesn't update its outputs yet. As soon as the inputs are acquired, the outputs are updated. This avoids the risk that an output signal is fed back to an input which hasn't been completely acquired and mess things up (said simply).

This strategy of "decoupling" input data acquisition from outputs updating allows simpler design techniques, which translates in more complex systems for a given design effort.


What you're describing is called asynchronous logic. It can work, and when it does it's often faster and uses less power than synchronous (clocked) logic. Unfortunately, asynchronous logic has some problems that prevent it from being widely used. The main one I see is that it takes a lot more transistors to implement, since you need a ton of independent synchronization signals. (Microcontrollers do a lot of work in parallel, as do CPUs.) That's going to drive up cost. The lack of good design tools is a big up-front obstacle.

Microcontrollers will probably always need clocks since their peripherals usually need to measure time. Timers and PWMs work at fixed time intervals, ADC sampling rates affect their bandwidth, and asynchronous communication protocols like CAN and USB need reference clocks for clock recovery. We usually want CPUs to run as fast as possible, but that's not always the case for other digital systems.


Actually You are seeing the MCU as a complete unit,but the truth is it itself is made of different gates and TTL and RTL logic's, often FF array,the all need the clock signal individually,

To be more specific think about simply accessing a address from the memory,this simple task may itself involve multiple operation like making the BUS available for the data lines and the address-lines.
The best way to say is ,the instruction themselves occur in small units of operation that require clock cycles,these combined for machine cycles ,which account for various MCU properties like speed(FLOPS** in complicated MCU's),pipe lining etc.

Response to OP's comment

To be very precise,I give you an example there is a chip called ALE(Address latch enable) usually for the purpose of multiplexing the lower address bus for transmitting both address and data on same pins,we use a oscillators(the intel 8051 uses 11.059MHz local oscillator as clock) to fetch the address and then data.

As you may know that basic parts of MCU are CPU,ALU and internal register and so on,the CPU(controlling s/g) sends the address to all the address pins 16 in case of 8051,this occurs at timing instant T1 and after the address is the corresponding matrix of capacitor storing (charge as a signal )(*memory mapping *) is activated and selected.

After selection the ALE signal is activated ie ALE pin is made high at the next clock say T2(usually a High signal but change as per processing unit design),after this the lower address buses act like data lines,and data is written or read (depending upon the output at the RD/WR pin-of the MCU).
You can clearly see that all events are timely sequential

What would happen if we wont use clock Then we will have to use asynchronous clocking method ASQC this would then make each gate dependent on the other and may result in hardware failures,Also this kills the Pipe-lining of instruction impossible,Long Dependent and irregular time to complete task.
So it is something undesirable

  • \$\begingroup\$ That kind of makes sense. But why do these various compartments of the MCU need the clock signal to operate? What theoretically would occur if they didn't use a clock? \$\endgroup\$
    – M-R
    Jun 20, 2015 at 18:34
  • 1
    \$\begingroup\$ @Martin, logic gates change state immediately when their input changes. Clocked, sequential logic only evaluates it's inputs during a clock event. This is the basic principle that drives digital memory circuits. It gives us the ability to selectively move data from one place to another with absolute control, allowing the creation of general purpose hardware that can be programmed via softaware to do - well, anything. \$\endgroup\$
    – user39962
    Jun 20, 2015 at 18:50
  • 3
    \$\begingroup\$ @SeanBoddy: Logic gates do not chance state immediately, there is a short lag which is viewable on an oscilloscope. If we didn't use a clock, the differences in these timings between components could cause race-conditions producing the wrong results. \$\endgroup\$ Jun 20, 2015 at 23:03
  • \$\begingroup\$ @BlueRaja - well good golly gumdrops, how about that. Maybe I'll go back through 4 years of power electronics notes and 8 years of navy training to find out where I missed that one thing. \$\endgroup\$
    – user39962
    Jun 20, 2015 at 23:10

The fundamental problem that a clock solves is that transistors are not really digital devices: they use analogue voltage levels on the inputs to determine the output and take a finite length of time to change state. Unless, as has been mentioned in another answer, you get into quantum devices, there will be a period of time in which the input transitions from one state to another. The time this takes is affected by capacitive loading, which will be different from one device to the next. This means that the different tranisistors that make up each logic gate will respond at slightly different times. The clock is used to 'latch' the outputs of the component devices once they have all stabilised.

As an analogy, consider the SPI (Serial Peripheral Interface) communications transport layer. A typical implementation of this will use three lines: Data In, Data Out and Clock. To send a byte over this transport layer the master will set its Data Out line and assert the Clock line to indicate that the Data Out line has a valid value. The slave device will sample its Data In line only when instructed to do so by the Clock signal. If there were no clock signal, how would the slave know when to sample the Data In line? It could sample it before the line was set by the master or during the transition between states. Asynchronous protocols, such as CAN, RS485, RS422, RS232, etc. solve this by using a pre-defined sampling time, fixed bit rate and (overhead) framing bits.

In other words, there is some kind of Common Knowledge required to determine when all the transistors in a set of gates have reached their final state and the instruction is complete. In the (100 blue eyes) puzzle stated in the link above, and explained in some detail in this question on Maths Stack Exchange, the 'oracle' acts as the clock for the people on the island.


Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.