Hacker News new | ask | show | jobs
by xodjmk 1493 days ago
I think I see where you are coming from. There certainly could be some power reduction if you limit the amount of switching. It's just combinatorial logic, so there shouldn't be any tool issues. The real challenge would be in verification. Usually, there are timing constraints that analyze your design and attempt to guarantee that everything will work across worst case temperature and process variations. Without timing verification there would be a lot of uncertainty in the actual path delays. So just because it might work on one device that was tested, this wouldn't guarantee that the design would work consistently. There would be a ton of glitches and phantom pulses to contend with, and every time you change something the routing delays will change! But maybe you have a method to deal with this.
1 comments

The combinational part of async design is built to be self-synchronous. You derive a clock signal to write computed value from the computed signal itself.

The combinational part also synthesized as monotone function without ringing - voltages there never go down after they went up during compute, and they never go down and then up and then down again when computation is reset.

This means that timing guarantees can be local, related only to parts next to concrete registers.

Usually, asynchronously designed chips work in the first batch. They also often work being underpowered, when power voltage is slightly lower than switching voltage - because switching voltage is set for typical transistor to work at the speed needed. Asynch designs usually are much less speed-dependent and can work being "officially underpowered".

Yes, makes sense. I can see how that could be beneficial in some situations.