A true push-button flow is incredibly (and unrealistically) optimistic. By combining tools and processes to minimize every aspect of the engineering function, incredible gains in productivity are to be realized. Chief among these, and the most attractive to management, are reduced time and knowledge requirements. What manager wouldn't relish the idea of cutting three months and one engineer out of a schedule?

But there is no true push-button flow in the real world, only highly skilled engineers who utilize established tools, processes and procedures to achieve the desired end results. The degree to which these means are automated indeed constitutes a flow, but it is usually worlds removed from push-button.

Proponents of a push-button flow are usually those not directly involved in doing the work at hand. Examples include software vendors with canned demos that complete a project in one hour flat. In such a case, no one ever considers what happens when the push button breaks. The important thing is that it's there to begin with, along with all the promises it brings.

Perhaps the single greatest downfall of a true push-button flow is the simple fact that no two engineering programs are exactly alike. For example, the field of ASIC engineering represents an incredible range of decisions to be made to get from specification to silicon. In many instances, the initial decisions surrounding design architecture and verification methodology can become grossly over-complicated by EDA tool selection. Everything from tool compatibility to licensing issues, as well as server size to storage requirements, can prove to be major stumbling blocks.

Even if one were to isolate a specific subsection of the overall ASIC process, a single push-button flow typically represents a compromise. The tradeoff between the most appropriate engineering solutions versus the requirements of the flow must be made. This is not to say that the flow is inherently wrong, only that it proposes a single (or limited) engineering solution. This solution may very well possess other advantages such as uniformity in approach. If this is an acceptable compromise to all involved, so be it.

There are other reasons why a true push-button flow is simply not viable. Tools and technology are changing quicker than the flows can be developed and documented. When the flow breaks, an engineer must be capable of working outside of the flow to solve the problem. Remember, nothing is as simple as it looks.

Flows can be developed that considerably streamline the engineering effort, and engineers will happily use them as appropriate. If anyone believes an engineer can simply push a button, I have a bridge in Brooklyn for sale.

Paul Yohannes is ASIC DFT engineer at Mint Technology (Fairport, N.Y.).