I have too often read how made Asynchronous signals e.g clear, set e.t.c are but than

[Altera_Forum]

... why is it that Altera primitives even have asynchronous clear and set signals on them. If latches are so bad, why does Altera even have them in the first place in Quartus? 

Also if ripple counters are so bad, than are there megafunctions to do the same thing? I always read how bad asynchronous design techniques are e.g gated clocks, clocks with inverters. What substitute does Altera Quartus II have for these things than???

[Altera_Forum]

The asynchronous set/reset is not bad if used correctly. Note that TimeQuest analyzes them as if they were synchronous, so they should not have any timing violations. (The user can always false path these paths though...). Note that some systems require an asynchronous reset, so that the system can be reset even if the clock disappears. For example, think of a medical device that is putting out radiation, and the clock driver goes bad. With an asynchronous reset the system can clear it's state and go to a non-radiating state without the clock. The circuit used for this is an asynchronous assert, synchronous de-assert circuit. Go to alterawiki.com, pull up my TimeQuest User Guide, and go to the section on Recovery and Removal.  

As for ripple clocks, that generally are not good, so I'm surprised you see them, but occasionally they can be useful. I also see some designs with tons of gated clocks, not because they want to, but because they have to(large clock muxes are the best example). These are things that should be avoided when possible, but carefully designed for when it is an absolute requirement.

[Altera_Forum]

Why does mankind not resort to Muxes instead of gated clocks? 

 I heard from a lecture on youtube (I think its that Australian University) that Asynchronous design techniques are becoming important recently. At present there are circuits that consist of different clock domains (like the uP made by ARM) and these domains can turn on their clock when activated and then turn it off when they have done their job. Since a huge proportion of power in a digital circuit is spent on the clock, and a circuit component may spend a huge amount of time idle, it makes sense to turn the clock off when the circuit is not needed.  The point I wish to get to is that, the tools we have in the industry are not inclined towards this, they abhor asynchronous behavior. Why?

[Altera_Forum]

I'm not sure what you mean on the first statement. Clock muxing is usually done to switch between different clock sources, while clock gating can be done for power. The example you provide can be done with the enable on the altclkctrl block, which can be timed in a synchronous manner, so that turning the clock on/off is a completely synchronous process and there is no "asynchronous" behavior. The key is to design synchronously when you can, and to be careful and know what you're doing when designing asynchronously. Is there a specific circuit/scenario you're trying to analyze?

[Altera_Forum]

--- Quote Start ---  The point I wish to get to is that, the tools we have in the industry are not inclined towards this, they abhor asynchronous behavior. Why?  --- Quote End ---   It's not primarly a limitation of the tools. It's the present FPGA hardware that's constructed to achieve best performance in synchronous designs and that demands for tools supporting it.   Presuming that the claimed advantage of asynchronous circuits in terms of power consumption holds, it would need different hardware and tools to implement it in the FPGA worlds.

[Altera_Forum]

Mankind resorted to clocked synchronous approach because they could not control logic hazards of non-clocked design(asynch). Asynch design can be very fast as it has no registers to worry about their timing violation. It is only but seriously limited by variable delays at various levels of logic. 

The drawback of clocked design is the register timing bottleneck which mankind is converging towards with clock speeds as high as 500MHz in fabric and much more in ASICs. The other drawback is forgetting that in FPGAs and designing everything combinatorial. If you google "Achronix" you will see they want to build an hyperfast fpga based on no clocks but appear to the fpga designer as any clocked design i.e. you design as usual but the tool will convert it to asynchronous and you don't worry about setup/hold timing(sorry Rysc).

[Altera_Forum]

No problem. I do think we're using "asynchronous logic" in too broad of a sense, as it encompasses everything from an asynch clear(found in most designs) to a completely asynchronous Achronix design, along with many cases in between. (Another case I've seen is the "asynchronous bus/fabric", whereby the individual processing blocks are synchronous, but they send data to other blocks asynchronously, so there's no real logic being done, just data being transferred). I've always been curious how truly asynchronous logic works. The best I've found is that a feedback loop is generated, so data goes out and is processed, and when it's done being processed, the feedback signal states that new data can enter the loop. Because of this, there is no clock, just all these loops. One really nice thing is that they run as fast as the silicon runs, where synchronous designs have a clock that has been throttled to the slowest path under the slowest PVT conditions. But if you need a guaranteed throughput, I'm not sure how asynchronous design gets around that. Anyway, if there's someone out there who has a good grasp of it, I'd be interested in hearing more...

[Altera_Forum]

I am quite happy to receive response from the elite that hold the keys to the esoteric knowledge of the Altera Digital design world. Thank you for your responses :D

[Altera_Forum]

Just to ad to what Rysc pointed at. Async design is a completely different digital methodology (I believe it preceded synchronous design historically). 

The FPGA design is meant to be synchronous i.e. clouds of combinatorial logic inserted between registers (RTL chain) though some signals entering the chain may be stray (asynchronous) coming off chip or internally from different clock domain. One can view these stray signals as the unwanted inevitable headache left over from asynch methodology. The fpag designer must make efforts to tackle these troublesome signals. Going back to asynch method for FPGAs is a dream so far and will make good money if you find a trick.

[Altera_Forum]

I was hearing about the "amazing" and "cancer curing" ways of analogue circuits about 10 years ago. Seems we're still not there yet.......

[Altera_Forum]

Talking about the Analogue people, they sure appear rather arrogant at times claiming there is no such as digital - there is just 1 and its analogue. Sure digital is subset of analogue but to make claims like the one I mentioned makes them appear quite arrogant I must say.