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.
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:
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.
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 ...
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.
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
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.
