4 ms·
The quote from Ken Stevens, whose opinion I respect, makes a compelling argument, and certainly Intel has a lot of expertise on asynchronous design, but I'm won
by gradschool 10y ago
The quote from Ken Stevens, whose opinion I respect, makes a
compelling argument, and certainly Intel has a lot of expertise on
asynchronous design, but I'm wondering if its position is similar to
that of Kodak inventing digital imaging in the 1980s. That is, there
would be less money for Intel to make in a future where asynchronous
design prevails, so there's no incentive for them to develop it. With a
properly executed tool chain, asynchronous design would be a
comparable skill to software development (that is, less of an elitist
activity than it is now) and the circuits would be more likely to work
on the first try because a whole class of hardware bugs wouldn't be a
thing anymore. Any comments or am I just a plonker for believing this?
- pjc50 10y ago> circuits would be more likely to work on the first try because a whole class of hardware bugs wouldn't be a thing anymore 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.
- kruhft 10y ago> 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. 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.
- pg_is_a_butt 10y agouh... kodak did invent digital imaging even though it was detrimental to them, and they did it in the 1970s. yes, you are a plonker. you're all idiots.
- Bartweiss 10y agoThere's probably truth to that - we talk like companies just miss potential breakthroughs, but they frequently make a conscious decision to abandon a new domain because they have no special expertise there. 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.