What happened to clockless computer chips?
stackoverflow.com
stackoverflow.com
I thought another advantage was that it modularized chip design to some degree - ie you can improve individual sections to run much faster, without having to make the entire chip run at that speed - http://www.cs.virginia.edu/~robins/Computing_Without_Clocks....
In any case in a similar vein is TTA (https://en.wikipedia.org/wiki/Transport_triggered_architectu...) which I think Ivan Sutherland was also involved in, but maybe I'm wrong about that.
This reminds me of 4GL hype.
I'd say it's the other way round. People have trouble learning synchronous logic design because everything happens in parallel, but it's a set of well-understood building blocks. Whereas asynchronous design is just entirely free of familiar reference points and there isn't quite the same set of standard idioms.
Yes, you get rid of setup/hold violations, but you're going to get a whole new class of problems with the addition that "timing closure" is now a moving target.
Async design in simulation is not some great hidden secret, it's just a trackless jungle. People are welcome to play with it; if you find a great way of teaching async design I'm sure we'd all like to hear about it.
Sounds like the argument about the problems and differences typed/untyped programming languages. One set of problems is solved with typing at the cost of linguistic expressiveness due to lacking and/or cumbersome type systems.
I'm thinking async hardware is the typeless of HW designs, but that also takes off the safety guards used from years of experience in synchronous design.
I don't think it's much of the story, though. Judging by the Stevens quote, the risk seems to be that async chips would have the same optimization patterns as sync chips - so unlike digital imaging, which started behind and leapfrogged ahead, async makers would be stuck in the past indefinitely.
Intel would be set back 20-30 years on retraining, retooling, and redoing old work, but that could still be worth it if they considered async the way of the future. Unlike Kodak and digital, they would still have enough of their skills and investments transfer to take a massive lead over any other player. So it seems to me that the concern is less "we won't profit", but we "we would never catch AMD's synchronous work".
I wonder if that'll stay true, though; as annual speedups decline, constant factor improvements in power and speed become increasingly appealing. I guess it's a question of whether we're stuck down around 10nm for a long time, or hit a breakthrough in some alternate basis for synchronous chips.
http://www.greenarraychips.com/home/documents/greg/PB003-110...
Normal D flip-flops require that, at the time of the clock edge arriving, the inputs are not changing. If you violate this you get "metastability" and data loss. Special structures are needed when you move data from a fast-clocked area to a slower. On processors, usually the core is at one (maybe variable!) speed while the peripherals and DRAM are at a lower speed (what used to be called "front side bus").
As to the application for async, maybe he's right and maybe he isn't. There would have to be synchronisation to fixed external bus speeds, but 20% seems very high as a proportion of power consumption.
http://electronics360.globalspec.com/article/4615/maxim-prep...
Asynchronous design is a huge sell; we scaled it back to just applying some async techniques to the clock tree of synchronous designs for moderate performance/power improvements.
There are three problems we found:
- the existing toolchain is synchronous-orientated, so you'd have to replace all of it and retrain your staff.
- the chip developers and their managers tend to be older and more conservative than the software world. They're also potentially large teams (Intel are obviously huge). So the retraining is going to be difficult and expensive.
- it's risky. New toolchain and newly trained staff? There's going to be bugs in the tools and errors in the design. Worse, there will be new types of bug that people aren't good at diagnosing. These will take weeks to resolve and a couple of wafer sets. That's a very expensive proposition!
If async is to get a foothold it would be, like ARM, starting at the low end. Low power consumption is an obvious pitch for microcontrollers, and the simpler designs will be less risky.
Given that the answer to that question for the AMULET was 'Errm...', they'd then just abandon it as a processor candidate as being conceptually too difficult to think about.
I wonder if the design could be reworked into Verilog or VHDL and used as an FPGA soft core?
I can't see anything about RISC-V (or any ISA!) that makes a difference to those four points.
Tool complexity isn't really to do with size or complexity of design, although size affects runtime. It's a question of how accurate the physical modelling is and how well manufacturers trust an OK from the tools. And whether the engineers trust the tools and can use them effectively.
There aren't all that many design tool companies, too. Remember I worked for one. The Cadence/Synopsys duopoly is quite strong for the usual reasons.
Fundamentally what you're asking is for someone to make a quarter-million-dollar+ bet on async. It's easy to say "sure it'll be great" when it's not your money.
(Maybe the easy way to do it is to build an app for sending "yo!" to your friends, raise the $1.5m VC, and spend it on silicon instead...)
(Less snarky edit: you know that async isn't a magic dust to apply to existing designs, and that someone would have to write an entirely new core targeting RISC-V in an async style?)
I have no doubt that will eventually happen. There are lots of RISC-V designs already and more underway. If async is really a win, someone wanting to prove that will do a RISC-V chip with it.
The cores themselves are asynchronous, with all of the benefits of lower power. The memories sitting outside of the cores are clocked, however.
I remember being a little bit disturbed by the temperature dependence of the chip on wall-clock execution time but it didn't affect our applications.
It was interesting to find this stuff as a product-ready platform.
A clock is a signal that is used as a valid signal for the data moving across a bus. That could be as short as between pipeline stages.
With async you have a different valid signal, which you will need to derive.
With aggressive dynamic frequency and voltage scaling, clock gating, power gating and having different power and clock islands you get a design that is very difficult to improve on. What AMD has done recently with circuits that lower voltage based on reading the environment on chip rather than sticking to a frequency: voltage mapping is a nice optimisation.
What async designs don't improve on are all the static power issues that are increasingly important.
It all adds up to being an interesting take on the problem of digital design, but not much more.
It already did. Sophie Wilson said [0] its 28nm for ever. Scaling further makes no economic sense (unless you really need the space, e.g. in Smartphones).
That's not quite what her slide said. It's that the transistors on 14nm are _currently_ more expensive than those at 28nm, although that may change.
And then she states that only some things will make sense to do at less than 28nm. But a lot of the really big players are already at 14nm or will be there very shortly. Apple, Intel, Samsung, AMD and Nvidia are at 14nm now, either for their newest products or ones to be introduced later this year.
there are ways of dealing with this. delay-insensitive circuitry, QDI circuitry, micropipelines...
if you're interested as to the "state of the art", as I learned it, look no further than Principles of Asynchronous Circuit Design[1], a fantastic book. a PDF[2] is also available. another fascinating piece of work are Micropipelines[3] by none other than Sutherland.
the main benefit for asynchronous architectures is their ability to be expressed in software. the primitives used (as you'll read) function very much like traditional software constructs based around control and dataflow. this is very easy when your entire architecture is based around pipelines, which can choose to hold and "re-transmit" data.
asynchronous design isn't dead or disadvantageous. we just forgot about it for some reason.
[1]: http://www.springer.com/us/book/9780792376132 [2]: http://www.orbit.dtu.dk/files/2775719/imm855.pdf [3]: https://pdfs.semanticscholar.org/b840/ae4b928964eff41206f89f...
not saying it can't be done or even that it's hard. just a different process.
Clockless architecture is also not about the general processor design.