Slashdot Mirror
Philips, ARM Collaborate On Asynchronous CPU
Sean D. Solle continues "Back in the early 1990's there was a lot of excitement (well, Acorn users got excited) about Prof. Steve Furber's asynchronous ARM research project, "Amulet". The idea is to let the CPU's component blocks run at their own rate, synchronising with each other only when needed. Like a normal RISC processor, one instruction typically takes one clock cycle; but in a clockless ARM, a cycle can take less time for different classes of instructions.
For example, a MOV instruction could finish before (and hence consume less power than) an ADD, even though they both execute in a single cycle. As well as energy-efficiency, running at effectively random frequencies reduces a chip's RFI emissions - handy if it's living in a cellphone or other wireless device."
See here. Developed by Steve Furber and his team at The University Of Manchester
Read the story.. there were ARM based asynchronous chips in the lab (AMULET) a long time before 97.
the very first drafts of microprocessors were clockless.
just with higher speed and hence, brute force, performance could be achieved easily.
The problems which could not be solved back then were the obvious synchronisation issues. Setting up a common clock seemed the only way to resolve them.
The idea behind clockless designs is less a "back-to-the-roots" idea, but more a step to gain the advantages of such a design, which are, amongst others:
Reduced Power Consumption
Higher Operation Speed
Moreover, highly sophisticated compilers could tune program code to match a given performance/power ratio.
Yet, I would not bet on clockless cores to become the new mainstream, by far not. Clockless cores will most likely be aimed at embedded design appliances, and low- and ultra-low-power applications.
Powerful is he who overpowers his temptations.
I think you are getting clock confused with ticker interrupt. A CPU clock is typically measured in nanoseconds. A ticker interrupt is typically measured in milliseconds. A clockless core will still need to field interrupts (for I/O) and very well can still field a ticker interrupt. -cdh
No they weren't. From TFA:
The AMULET1 microprocessor is the first large scale asynchronous circuit produced by the APT group. It is an implementation of the ARM processor architecture using the Micropipeline design style. Work was begun at the end of 1990 and the design despatched for fabrication in February 1993. The primary intent was to demonstrate that an asynchronous microprocessor can offer a reduction in electrical power consumption over a synchronous design in the same role.
You appear to be confusing the CPU's clock with a real-time clock interrupt. They are fundamentally not the same thing.
The clock being dispensed with is the one that causes the registers inside the CPU to latch the new values that have been computed for them. At 3GHz, this happens every 333ps. The reason this clock exists is basically because it makes everything in a digital system much, much easier to think about, design, simulate, manufacture, test and re-use. But, it's not an absolute requirement that it be present, if you're clever. (Too clever by half, in fact.)
The other clock, which you were referring to, fires off an interrupt with a period on the order of milliseconds, to facilitate time-slicing. If your application requires such a feature, you can have one, regardless of whether your CPU is synchronous or asynchronous internally. It's a completely separate issue.
These sigs are more interesting tha
As for the power problem, all parts of the CPU is powered, except that gates that aren't switching consume less power (mostly leakage, which seems to be quite significant now). In synchronous circuits, at least the gates connected directly to the clock signal switch all the time, while in asynchronous circuits unused parts of the CPU can avoid switching altogether, so some power may be saved, but I don't know how much it will be.
We're talking about two different types of clocks:
- a timing source needed to preempt a long-running task
- the heart-beat that dictates when the CPU is going to do the next instruction.
These two are completely different things. The former can have a pretty low resolution as well -- but is needed for other tasks as well. Any non-degenerate processor will need some kind of timing source, but there is no reason why it would be connected to the number of instructions executed.In a multitasking operating system, there are three reasons that can trigger a preemption:
Some outside even has happened. A new bit/byte came in from a serial source, an IO tranfer ended, etc, etc.
The process requires some resource that is either held by another process or will require an IO.
A timer interrupt is needed for this, but nothing bad will happen if the resolution is many orders of magnitude bigger than the CPU core clock would be. You don't preempt processes every a handful of CPU cycles, do you?
The creatures outside looked from Alt-Right to Antifa; but already it was impossible to say which was which.
Usually with these kind of asynchronous cpus the communication with the outside world is made synchronous again. Just the inside of the processor is asynchronous. This is relativly easy since you only have to make sure that the asynchronous path is travelled faster than a clock cycle.
The big advantage is that not every flipflop has to be active at every clock pulse and thus saves a lot of energy. Also the chip doesn't turn into a giant clock transmitter.
Jeroen
Secure messaging: http://quickmsg.vreeken.net/
These asyncronous computers are implementations of data flow computers.
The problem is that the first implementations were very slow.
The reason why a clock is commonly used in microprocessor circuits is to try to synchronise everything, because different logic elements take a different amount of time for the outputs to reach a stable state after the inputs change. This is known as "propagation delay" and is what ultimately limits the speed of a processor. With CMOS, you can actually reduce the propagation delay a little by increasing the supply voltage, but then your processor will be dissipating more power. {CMOS logic gates dissipate the most power when they are actually changing state, and almost no power at all while stable, whether they are sitting at 1 or 0. This is in contrast to TTL, which usually dissipates more power in a 0 state than in a 1 state, but there are some oddball devices that are the other way around}.
The clock is run at a speed that allows for the slowest propagation, with data being transferred in or out of the processor only on the rising or falling edges. This allows time for everything to get stable. It's also horrendously inefficient because propagation delays are actually variable, not fixed.
If you wire an odd number of NOT gates in series, you end up with an oscillator whose period is twice the sum of the propagation delays of all the gates. If you replace one of the NOT gates with a NAND or NOR gate, then you can stop or start the oscillator at will. Furthermore, by extra-cunning use of NAND/NOR and EOR gates, you can lengthen or shorten the delay in steps of a few gates. Obviously at least one of the gates should have a Schmitt trigger input to keep the edges nice and sharp; but that's just details.
My idea was to scatter a bunch of NOT gates throughout the core of a processor, so as to get a propagation delay through the chain that is just longer than the slowest bit of logic. Any thermal effects that slow down or speed up the propagation will affect these gates as much as the processing logic. Now you use these NOT gates as the clock oscillator. If you want to try being clever, you could even include the ability to shorten the delay if you were not using certain "slow" sections such as the adder. This information would be available on an instruction-by-instruction basis, from the order field of the instruction word. The net result of all this fancy gatey trickery is that if the processor slows down, the clock slows down with it. It never gets too fast for the rest of the processor to keep up with. Most I/O operations can be buffered, using latches as a sort of electronic Oldham coupling; one end presents the data as it comes, the other takes it when it's ready to deal with it, and as long as the misalignment is not too great, it will work. For seriously time-critical I/O operations that can't be buffered, you can just stop the clock momentarily.
The longer I think about this, the deeper I regret abandoning it.
Je fume. Tu fumes. Nous fûmes!
No it isn't, a corporation is a single person, at least in the US.
Which is exactly the point. A corporation is only considered a single entity in the United States of America because there is a legal basis for treating corporations as a real person. In the rest of the world a corporation is a distinct legal entity and thus is not treated as a single entity. A corporation is composed of many people, hence it is a collective noun.
Because that was for async bus operation, not async internal operation. The 68000 is fully synchroneous internally, as most/all other commercially successfull CPU's. Async buses is nothing new, and the ability to support it on the 68000 was in fact mostly to allow it to integrate with older hardware.
In 2001 they presented a paper on an asynch processor design called FLEETzero/FastSHIP. According to the patents list on this page, they're still doing work on it (see also here.)
Posted with Mozilla
Philips previously released an asynchronous processor - it was used in pagers and reportedly resulted in 75% longer battery life (I forget the processor number).
One of the problems with asynchronous circuits is that they are more likely to experience single event upsets (seu's) from glitches in the circuit. These can result in unpredictable behavior - not something you want in your processor. One of the benefits to a _synchronous_ design is that you only have to be concerned that your logic levels are correct during clock edges which is a very small percentage of the time. Your logic can be bouncing all over the place before and after a clock edge but as long as its stable when the clock rises, your circuit behaves as expected. Not so with asynchronous logic - any glitch on a line can start up an unintended computation with potentially disastrous effects.
One technique that designers use to combat this problem is triple modular redundancy (tmr) which is essentially a majority rules (2 out of 3) circuit. Naturally, this increases the amount of logic in the design which can counter some of the benefits of asynchronous design. Hopefully they've been able to solve some of the problems with asynchronous techniques.
Since you expressed a particular interest in register files, here is a recent publication:
David Fang and Rajit Manohar. Non-Uniform Access Asynchronous Register Files. Proceedings of the 10th International Symposium on Asynchronous Circuits and Systems, April 2004.
http://vlsi.cornell.edu/~rajit/ps/reg.pdf
The fastest/lowest energy asynchronous circuits do not use clocks for anything. Moreover, very few arbiters are used in practice. The "completion logic" of course is always the hard part, but about 10 years ago, something called "pipelined completion was developed" which alleviates that bottleneck.
For how arbiters are used and avoided:
Precise Exceptions and Interrupts in Asynchronous Processors. Rajit Manohar, Mika Nystrröm, and Alain J. Martin. Proc. 21th Conference on Advanced Research in VLSI, IEEE Computer Society Press, March 2001.
Crossing the Synchronous-Asynchronous Divide. Mika Nyström and Alain J. Martin. Workshop on Complexity-Effective Design, 2002