Electrical – Should we use asynchronous inputs in Moore blocks and synchronous in Mealy blocks

Wow, your question isn't terribly focused, and it's not obvious what you are really asking for. But let me give this one a try. Sorry if I didn't get it quite right.

Ripple counter vs. normal synchronous counter: Who says that people don't use ripple counters? People use whatever they have available that works best. In FPGAs, nobody uses a ripple counter because the logic blocks do a sync counter so much better than a ripple. But if you're designing a custom chip then a ripple counter can be more advantageous when it comes to power consumption and logic size. It would not surprise me at all of some people use ripple counters in their ASICs. Sync counters would still be better for speed and simplicity of timing.

Gray Counter vs. Binary Counter: People do use gray counters in ASICs and custom chips. In FPGAs, where binary counters are faster, people still use Gray counters when the count value has to go across clock domains, such as in FIFOs.

Multi-phase clocks: These are certainly used in the design. There are reasons why the PLLs in FPGAs can often output 0, 90, 180, and 270 deg phase-shifted versions of the original clocks. But as the clock frequencies go up, using multiple clocks gets harder due to clock skew and clock distribution issues. It's not impossible at high frequencies but it just isn't done as much.

Sync vs. Async: Sync circuits are not just easier to simulate but easier to design and easier to guarantee that they work correctly. Verification and timing analysis tools are difficult-to-impossible to use with async circuits.

MCU Counter Circuit: Do you KNOW that there are no MCUs that do it that way? If it did, how could you tell? Maybe the prescalers on the timer are ripple counters. Maybe the timer itself is a Gray-coded counter and reading/writing the registers automatically converts it to/from binary. My point is this: the guys who design super-low power MCUs (like the MSP430) do every trick in the book to reduce power consumption. Many of those tricks, like using ripple counters and Gray code where appropriate, are completely invisible to people like you and I. They can, and probably are, using those tricks plus a couple of hundred other tricks that you haven't thought of yet.

One thing that you haven't mentioned is the use of completely async circuits. This is where all of your talk about clocks eventually goes when taken to it's logical conclusion. There have been companies that have tried to build large-scale CPUs that are completely async, including one group that tried to bring an async ARM to market. The benefits are amazing: super-low power, faster processing, and less EMI among them. But the disadvantages are more amazing yet. The main one is that the complexity of designing this chip is huge and is not economically viable today. A secondary problem is that the number of transistors about doubles when compared to an equivalent sync chip.

Even so, there are CPUs on the market today that use async logic in some of its blocks, like the FPU, but nobody uses it on a large scale.

This answer is valid for ASICs.

After reading few references on the net I discovered that the question "sync or async" is a kind of "iOS or Android" question. All the below is my opinion on the subject which is biased.

Async resets are pain in the neck because:

1. They are glitch sensitive
2. They must be deasserted synchronously
3. They must be deasserted synchronously, to all flops, at the same clock cycle
4. They can cause metastability problems if there are flops which are not reset

While section 1 and 2 are easy to handle, the rest are major issues which require thorough understanding and a whole lot of tools for validation.

And now the painful truth: async resets are still preferable for large systems. The advantages of async resets are:

1. Async resets have priority over any other signal
2. Async resets do not share combinational paths with other signals
3. Async resets do not require clocks

The fact that all the flops are reset, and that all the flops are out of reset at the same clock cycle is a major advantage (and if it does not happen on the same cycle, then this is indicated by tools and awaits for designer's decision). In complex designs (containing many clock domains where each clock is gated tens or hundred of times) it is very difficult to ensure that there are no corner cases when sync resets are used. Async resets are agnostic to these issues (there is still one place where async resets meet clocks - in the deassertion logic, which must be distinct for each clock domain).

The warning you see suggests that all your flops should be reset asynchronously. However, it is a matter of micro-architectural decision which kind of reset to use, and this should be consistent across some defined boundary. Still, if you're sure that non-standard reset is more appropriate in some place - use it and waive the warning.

EDIT:

During scan insertion all the flops in a scan chain are required to function properly. If you're using an externally fed async reset then the above condition is very simple to satisfy - just tie the external net to a non-reset value.

In a sync reset designs the above condition must also be satisfied. This is achieved in the same manner, but since sync resets may share combinational paths with other logic, the tools may erroneously detect flops which can get reset during scan (or not erroneously).

In light of the additional information provided in comments (no async resets at all and this warning is reported for all flops), I believe that you can disable this rule completely. On the other hand, you might want to ensure that your Lint DFT supports sync resets (i.e. it has parallel rules for sync resets, and these rules are enabled)

EDIT2:

I found this great article on the Web. I've never been to SNUG myself, but it seems like there are many designers who favor sync reset schemes. You can find pretty deep analysis of sync and async schemes in the above article, along with many practical advices.