USER COMMENTS 19 comment(s)
|Wait to come (2:23pm EST Thu Nov 04 2004)
Just think Atomic - by Luke Kaufman
|No race conditions (3:00pm EST Thu Nov 04 2004)
If it is done right, clockless designs avoid race conditions and timing design is, in fact, much simpler than a typical ASIC where much of the effort is in trying to balance clock trees.
I heard about a clockless processor done at CalTech where a major manufacturing mistake was made which caused about 1/2 the transistors to run about 100 times slower. Because all logic states were passed by 'handshaking' (this is probably where Handshake Solutions gets it name), the chip still worked! - by grapevine
|timing? (3:16pm EST Thu Nov 04 2004)
so what happens to my (wait 10ms) command? how does it know time? - by k2h
|re: grapevine (3:56pm EST Thu Nov 04 2004)
“If it is done right, clockless designs avoid race conditions and timing design is, in fact, much simpler than a typical ASIC where much of the effort is in trying to balance clock trees.”
The ignorance in your statement is nothing short of amazing. How many clock domains have you tried to manage?
From the asynch designs I have seen, there is substancial overhead for latch control. This results is more timing paths and more standard cell area.
I personally use a balanced approach… synchronous design with per-block clock gating. I also hold the inputs of long combinational paths to make sure that they don't unintentially toggle.
These are easy to do and can allow a synchronous design to consume much less power. I'll never be as efficient as asynch, but I don't need to be.
I get the nice synchronous benefits of scan testing 99% of all my cells in under 3 seconds of test time. Even with process variation, my die per wafer yield in high 90s (percent). All my timing paths have enough slack to yield well… I checked them all, so I'm not just getting lucky.
Power, area, and complexity all need to be balanced for the optimal design. - by chipace
|Wasn't sun micro making an async cpu (4:08pm EST Thu Nov 04 2004)
I heard from way way back on I think technology review or something that sun micro was developing an async cpu. Then again this type of thing must be in development by almost everyone for things like mobile cpus and servers. Wonder when this technology will be seriuosly considered by these companies. - by Caliber FX
|Gotta agree (4:31pm EST Thu Nov 04 2004)
Grapevine, I haven't seen asynchronous design with a simpler timing scheme than a typical clock based scheme. If you have one that can be produced reliably even in circular logic loops which state store structures in between, sounds like something you should publish and patent fast.
Regarding chipace's balanced approach, that appears to be the popular compromise. Even the Pentium 4 incorporated a number of “decoupled” logic blocks. Sort of a pseudo-asynchronous nature between the execution and decode units. And I think there are a few altogether independent clockless components in there. But the industry appears to be accepting the GALS approach (globally asynchronous, locally synchronous) as an alternative, or perhaps transitional methodology what I believe chipace simply refers to as “a balanced approach”. - by Ronnie Lindsay
|why an ARM processor? (4:43pm EST Thu Nov 04 2004)
I'm thinking that existing ARM customers might pay double or triple for a die that consumes half the dynamic power (even if that savings was on the order of milliwatts).
I underclock (and undervoltage) my AMD chips to run power efficiently… and crank them up when I have video to crunch.
I have no desire for any async chips… unless they are much cheaper than the synchronous equivalent. - by Si_man
|Does this really all 'fit'? (4:53pm EST Thu Nov 04 2004)
What I would really like to hear is GIVEN THE IDENTICAL PROCESS, the difference in power consumption between a 100 MHz “thing” designed for conventional heavy-latching and clocking, and the same “thing” designed to an almost wholly asynchronous metric. Would it really consume so much less power? Would it require nearly non-deterministic external clocking as well?
Although being decades 'out of the loop' on chip design [I defer humbly to Lindsay & ChipAce], it seems to me that there should be some additional gate-complexity associated with accurately predicting logic-settle time for any given cell. (Assuming that each functional unit will pass an 'all-clear' signal downstream to the next-in-line dependent subsystems.) Or, if not, then is it merely through exhaustive 'worst case modeling' that propagation delay is figured, and allowed for in that GALS model?
I continue to think that the power consumption of all those latches that act as noise-stoppers are also preventing down-wind circuits from uselessly toggling between indeterminate states while upwind functions are settling down. Maybe that makes me a fuddy-duddy, but as a betting man, I'd place money on the side that says (in answer to my question), “Well, its true — for a given process, the actual power savings of asynchronous logic are overruled by the additional time-to-market complexity of testing the things, making sure they really work right.”
- by GoatGuy
|Food for thought (5:23pm EST Thu Nov 04 2004)
GG, I have a few apples to apples comparisons for you…When Intel made the asynchronous Pentium in 1997, a report was published stating the chip ran 3x as fast with 1/2 power consumption. While I have no quantitive data, I would imagine it took much longer to design, and was not feasible for manufacturing in volume, compared with its synchonous counterpart. Also, Phillips currently has a pager on the market using asynchronous IC, for which they had to design the entire tool flow from scratch. In fact, Phillips now has a Philips' EDA tools arm of their corporation to sell those tools to accelerate the adoption of this design practice (not to mention to recoup some of that heavy investment). The good news is: that pager lasts 2X the battery life of its competition. Not too shabby, especially if they can use that core for multiple devices. One of the big debates of synchronous vs. asynchronous has always been the overhead logic required by asynchronous to help timing and other classic design issues usually solved by clocks. This has usually translated into greater area required by asynchronous ICs. This was however when clocks represented 5-20% of the routing. Now with 100-300million gate ICs being common and clocks consuming 20-40% of the power and routing, and multiple entire metal layers dedicated for ground and power alone, suddenly the pro-asynchronous side of the overhead debate is armed with some decent reasoning. - by Ronnie Lindsay
|Caltech examples (8:24pm EST Thu Nov 04 2004)
I found a paper describing the asynchronous processors designed at Caltech:
It mentions that it is possible to use a design process where by “that the correctness of the design is unaffected by a change in the slack (amount
Unfortunately they didn't use this property throughout the processor, which complicated the design. But it at least suggests that there are asynchronous techniques that can make the design simpler than today's clocked designs. - by grapevine
|re: Ronnie (10:01pm EST Thu Nov 04 2004)
“Now with 100-300million gate ICs being common and clocks consuming 20-40% of the power and routing, and multiple entire metal layers dedicated for ground and power alone”…
I think you mean 100-300million TRANSISTOR ICs… an inverter is two transistors, 2input nand/nor is four, flipflop is 16+
Your pager example is certainly on-the-money… the last wireless transceiver design that I worked on gated the clock until a valid receive/transmit event was detected. The asynch circuitry was 1% of the total design… 99% was synchronous. Gated clock routes consume less area that the asynch path overhead (and still retains all the synchronous benefits).
Could ARM just be claiming an asynch design and internally gating the clock until interrupts are detected (and goes back to gated clock after servicing the interrupt). This would akin to the PCs S3 suspend state… I use that feature everyday and save a-ton-o-power. - by chipace
|eek (10:23pm EST Thu Nov 04 2004)
I'd really hate to resolve race issues actually…I'd think the overhead would just be huge…
So what is actually holding this area back? is it just the lack of money that has been put into it? I mean, I guess there isn't really that big of a bariar or anything. - by hybob
|Semantics… (2:16am EST Fri Nov 05 2004)
I hate to barge in with such a horribly nitpicky point, but the term “asynchronous” in my education on the subject refered to any number of circuits that did not all synchronize their operation to a common signal (clock).
So an asynchronous device doesn't necessarily have no clock signal. It may have no clock signal, or multiple clock signals, or it may have sub-circuits that operate off of the clock signal. For example the “pseudo-asynchronous” operation Lindsay referred to is really actual asynchronous operation. And turning the clock off and essentially halting CPU activity until an interrupt signal is triggered involves a circuit that is not synched with the clock, and therefore it can be called “asynchronous”. On the other hand, I agree that it would be a stretch of the definition to refer to the entire device as asynchronous if only such a small portion really was, but my point is that it's difficult to tell exactly what ARM means because of the apparent vagueness of the term.
- by DrSengir
|transistors, not gates (11:16am EST Fri Nov 05 2004)
100-300 million transistors being common.
thanks for the correction. - by Ronnie Lindsay
|why lower yields (12:34pm EST Fri Nov 05 2004)
I hate to ask you guys to simplify the conversation, but can you tell me why a different design like this would effect yield? I thought yield was largly based on the manufactoring process. That is the physical nature of the components being used, not how they where placed on the chip. Obviously I am missing something.
- by et
|re: et (3:11pm EST Fri Nov 05 2004)
manufacturing process allows for different transistors on the same die to become faster/slower (capacitance and gain are physically determined).
It is possible to have a die that has no timing problems at 1GHz/1.7V, but one or more at 1.1GHz/1.7V. If you make sure that all your die are tested at 900MHz/1.8V, you could yield extremely well… and if you tested at 1.2GHz/1.6V you might yield hardly anything at all.
Higher voltages wear the oxide (longevity) and consume more power, but are somewhat needed to keep switch speed fast.
Design is just trading-off different properties… if you unrealiastic expectations or mistakes, your design won't yield well. - by chipace
|re: et (3:41pm EST Fri Nov 05 2004)
I didn't really answer your specific question of why an asynch design would yield worse than a synch design…
Synchronous designs have many timing paths, but few unique clocks… you can do an analysis per clock group and be confidant that you have analyzed all the timing paths. Asynch designs have many timing paths, and many unique “clocks” (could be as high as one per individual latch). You could have a method to check all those individual paths. This could be somewhat complex.
The nail in the coffin for large asynch designs (in my opinion) is test time and effort. My synchronous designs test in seconds using minimal test resources, and I can guarantee a specific standard of performance for any die I pass. The same can't be said for asynch design testing… loading each path can become very difficult and time consuming. It becomes a functional test (not a structural one like synch scan testing).
- by chipace
|Asynchronous is hard to market (4:59am EST Sun Nov 07 2004)
That's why it is hard to sell in high volume – no GHz figure of merit. - by blah
|Thanks (2:04am EST Sat Jan 01 2005)
It's a pleasure to read people who KNOW the matter.
- by cozak