Processor without a clock

Post Reply New Topic

I have a fairly limited knowledge in EE, however I have been wondering why we can't have a microprocessor that isn't operated by a clock. Obviously there are 2 problems that wind up being encountered, one of which is synchronization, and the other is heat. To take care of heat, it could simply be cooled by liquid nitrogen, liquid hydrogen, or liquid helium like quantum processors are. As far as synchronization goes, obviously an architect such as x86 wouldn't work naturally, since the instructions require synchronization for most of the instructions, but why couldn't you have a architect like this work:

movrex 8FA0 ; move 8FA0 into REX
movmem F00 ; move F00 into a special register called 'mem'
movram 32 ; move 32 into the memory address stored in 'mem'
addmr ; add value in mem with value in register 'DEST', store in register called DEST
movrexm ; move value from mem into REX

While this shows a limited amount of commands, and a limited amount of registers, it seems that this could be expanded into a larger command/register set (note, that was pseudo code, and not designed to be fully efficient, or completely working in a larger instruction set). For things that require a clock, it could be an actual instruction, and would be a separate part of the processor that would call an interrupt at a specified label point after a time has passed (the time would be contained in a certain register). To make sure the clock doesn't interrupt the processor while an instruction is being carried out, the clock could simply mark a flag in the processor. This flag would be checked at the beginning of each command cycle. If the flag is true, the processor checks to see what label it should jump to, then it jumps to it.

Then again, maybe I greatly misunderstand how processors currently work, and this is how they work...

Anyways, just 'thinking out loud', hoping for some insight : ).

The biggest problem I see is how cost prohibitive liquid cooling systems are.

True, however, lets assume that money is of no importance in this instance.

I think so. The quartz clock in a computer processor generates a square wave signal. The low portion of the wave is "off" and the high plateau is "on" giving the basic binary signal critical to modern computing.

There exists analogue computers however, but they are not practical for the uses we put our computers to. They are not precise, but rather specialize in physical calculations.

The one diferance between this methodology, and the methodlology of a processor using a quartz clock is, a processor with a quartz clock usually has multiple cycles per instruction, where as this methodology would have exactly one instruction per cycle.

I once did some work on asynchronous, potentially clock-free, computer hardware design. It involved the creation of Petri net circuitry, although everything I was involved in was simulated (and it was simulated by a clocked workstation, obviously). It seems to be one of those academic hobbies, like tri-state logic, that commercial companies occasionally decide will be ground-breaking.

Cooling and so on are not an issue, anymore than clocked hardware - the circuit simply runs whenever an event is enabled.

A synchronous processors have One Big Problem, the so called racing problem when signals can take more than one path through the circuitry. Some logic has to be placed to resolve races.

ruveyn

At a wild guess, that was why we were using Petri nets - or perhaps you did not read (understand?) my post.

Did the simulations show a speed increment of noticeable proportions when compared to a more traditional design?

Of course, so long as you choose the right test case! The proponents of Petri net design (still around, but more in software than hardware) would claim that we need to adapt our software designs to suit net methodology. Creating a usable, general purpose design that code can be compiled for almost inevitably produces clocked CPU designs like we use.

It is exciting to find a railway token (or "key" in some places) used in early rail systems to prevent deadlock and collision conditions, on display. The driver actually had to drive to the terminus and then walk the token back along the single-track line for the later fast train on the track that goes past my house. This predates Petri, but his methodology is applied in modern railway systems with virtual tokens.

http://intranet.cs.man.ac.uk/apt/async/

Have fun.

Vanilla_Slice

And more specifically: http://intranet.cs.man.ac.uk/apt/projects/processors/amulet/

The AMULET research is really neat, sort of a shame that it doesn't seem to have gone anywhere. It can be quite a mental leap to move from synchronous designs to asynchronous. They can actually be lower powered (in some instances) than synchronous designs, and the way they spread electromagnetic noise can also be super handy.

I seem to also remember something about the instruction decoder unit on the Pentium M being asynchronous, but I can't find any info on that at the moment...

without a clock, how would you be able to brag how fast your system was?..

The individual logic gates in a processor move their bits along on the clock - something like
movrex 8FA0 ; move 8FA0 into REX
actually shifts a lot of bits, and without some form of synchronisation you wouldn't get sensible results.

Then there's synchronisation with memory fetches and other I/O - without some kind of a clock the individual bits of a byte lose their coherence. Perhaps I'm missing the point?

If you move the bits in a linear form, couldn't you do it without the clock?

Yes, certainly, maths works just as well in serial as in parallel. But an asynchronous system can still run a set of operations in parallel when synchronised by a token instead of synchronised by a clock. Traffic lights can be synchronised together in a city-wide system without a clock. An adder within a processor can be triggered by a token without being clock-synchronised to the rest of the processor, and the result of addition will pass a token on to whatever uses the result.