Apparently the asynchronous design uses 70% less power compared to its synchronous counterpart.
What do you think they mean by an asynchronous processor? I find it hard to believe the majority of the circuitry (pipeline, etc) is asynchronous.
Will asynch design ever be feasible in FPGAs? I suppose it would require a new tool chain and new ways of thinking, but having never done it, I have no idea.
It's also got to be the world's largest 8 bit uC :)
The beauty of Async logic is it self adjusts to Vcc/Temp/Process, so for what Epson are trying to target, it is quite a good choice. They can avoid any regulation, and the hot spot that would create.
The 70% claim is a 'best case' one, and relates to Async vs Vanilla Sync design. [See an earlier thread here on Async ].
Std Sync Cmos has to have margins for Vcc, Temp, and Process so it is not uncomon to find you can 'clock on the bench' much faster than the design speed. If you remove the older 'square box' design, and start to vary Vcc, Clock, and measure chip core Temp to determine where the two need to be, you can get closer to the Async powers. This is what Intel/AMD routinely do now, on their Mobile processors. Typical SMPS chips have
4/5/6 bit DAC inputs, allowing the CPU to request it's own Vcc level. PLLs and clock generators are now routine.
- ie you now have std devices to vary CLK, Vcc, and measure Temp.
In a FPGA, if you wanted to add a process track capability, you could use std Sync tools, and make deliberate test cell(s), that fail first. You then vary Vcc/Clk until those cells just fail, knowing that the margin in the rest of the design keeps the system operating. Sailing close to the wind, of course, but it would maximise battery life.
A modern processor is'n synchronous at all! It would be very hard to get a global clock all over the system (IMHO)
As far as I know is asynchronous design very well suitable for cryptographic processors, as it is very tough to use DPA or other methods to analyze it.
Nevertheless it is as far as I know in an experimental phase in workgroups at universities and large companies (e.g. INfineon).
I am not an expert in such things. Just mentioned what I heard.
Your second comment is very true; but it doesn't support your first statement. You should check some of Intel's clock distribution papers in ISSCC and JSSCC. You would be amazed the lenghts they go to keep their systems synchronous. It turns out designing a OO, 20 stage pipeline 4GHz x86 processor is more difficult with an asynchronous design methodology.
Great, thanks for the link. They're results are that the sync and async versions of the same processor have the same area, speed, and power consumption except that the async version apparently has less EMI. I was hoping the async design would have advantages in other areas, but I guess not.
This was done using FPGA tool flows, designed for Sync use, and also speed files done the same way - So I would not read too much into the area and speed comparisons. I'm impressed they got it to go thru the tools at all :)
Keeping the async handshakes safe is likely to consume area, but you could expect to save on less beefy global glock trees and drivers.
The benefits I expect Epson see from Async, are more in deployment than area or speed - if they can save hot spots, eliminate regulators, and spread the EMI, as well as extend battery life, those are all important gains to make in portable consumer equipment.
As Jim says, for embedded apps, lower EMI, less heat are good things to do but for high perf Async design is IMHO a wasted effort.
This issue comes up every so often, some think async will cure the ills of digital design, to show for its results there is very little. There is one little company in San Diego IIRC that does async asics, even a couple of pretty die shots on site, and there was the Amulet and a book or two.
SInce as Peter/Xilinx keep saying the asic is dead and long live the FPGA, we have to stick with global clocking, even more so for FPGA than Asics for obvious reasons. Atleast with Asics you could hand craft everything so you could justify any clocking, power management scheme to get the job done
Also look at the EDA world, name a single async tool vendor out there.
Also consider that par busses are dying and getting replaced by the fastest possible serial busses, its one thing to do async sub clock busses, can't see how you could do PCIe, Sata, FW, USB2/3 in a async world.
I f that damn Moore guy hadn't had that "double every 18months" comment we might still be exploring 1ucmos design space and then async design actually would have a place to shine but we're are in a geometry rat race and async lost its chance to make any real show.
My memory of it is slightly hazy (I didn't design it, I only used it.)
It used 1024 bit dynamic shift registers, which had a multi-phase clock. The clock had a swing of something like 16 or 20 volts, and had quite strict (fast) risetime requirements into a rather large input capacitance.
We never measured the current, but doing the calculations with voltage, risetime, and typical input capacitance gave a peak clock current of 60 Amps. The r.m.s. was clearly much less.
I just did a quick google,and found a paper on it:
formatting link
If I understand it correctly I was off by a factor of eight; the current was closer to 500 Amps peak.
ElectronDepot website is not affiliated with any of the manufacturers or service providers discussed here.
All logos and trade names are the property of their respective owners.