In ESNUG 396, users responded to an engineer who asked for opinions on a teammate's suggestion to use synchronous reset flip-flops instead of asynchronous. "Do your readers have any suggestions on this?" he asked.

They sure did. One argued that you "definitely" need asynchronous resets, never synchronous. For synchronous resets, he noted, you must make sure that you always have a clock during reset.

Another said he prefers asynchronous reset, but acknowledged two "schools of thought" that have emerged. The argument for synchronous, he said, is that asynchronous controls on registers create paths a designer may be unaware of, and asynchronous designs can't be proven to work in timing analysis or simulation.

"Each has its pros and cons. This is another religious issue," wrote another respondent, who said he prefers asynchronous resets even though synchronous ones are no longer a big problem for Design Compiler.

Striving for the best of both worlds, one engineer described a technique for asynchronous activation of resets with synchronous release.

In ESNUG 398, the debate shifted to another question: If a net has 40 or more loads, should Design Compiler buffer the net, or should it be done during physical layout? Several respondents said the Design Compiler tool won't do a good job of buffering nets and that the problem should be left to PhysOpt (Physical Compiler) or placement and routing tools. But one engineer insisted that Design Compiler can indeed handle high-fanout nets, depending on how you set fanout load constraints.

Another advised giving the job to Design Compiler if loads are in the same hierarchical block. If they're in a control signal that goes across the die, bring in the place and route tools.

Meanwhile, we recently struck a nerve at EEdesign by asking the following poll question: "Should Accellera bring OpenVera assertions into System Verilog?" Last I looked, there were more than 5,200 responses, with 55 percent saying "yes" and 42 percent saying "no." It appears to be an argument over potentially useful technology vs. letting a standard get too complex.