'Pushbutton flow': Don't accept the myth as gospel

'Pushbutton flow': Don't accept the myth as gospel
By Paul Yohannes, EE Times
January 14, 2002 (10:13 a.m. EST)
URL: http://www.eetimes.com/story/OEG20020114S0040

The engineering community is continually asked to accomplish more work in less time. Motivational programs and phrases are a favorite means to help accomplish this daunting task. What engineer hasn't heard of "continual improvement," "change management" or "team building"? Then there's my favorite: the myth of "pushbutton flow."

A true pushbutton 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 those, 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 in the real world there is no true pushbutton flow, only highly skilled engineers who use established tools, processes and procedures to achieve the desired end results. The degree to which those means are automated indeed constitutes a flow, but it is usually worlds removed from pushbutton.

Proponents of pushbutton flow are usually 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 pushbutton breaks; the important thing is that it's there to begin with.

Perhaps the single greatest downfall of a true pushbutton flow is that no two engineering programs are exactly alike. For example, ASIC engineering represents an incredible range of decisions to be made. Often, the initial decisions surrounding design architecture and verification methodology can become grossly overcomplicated by EDA tool selection. Everything from tool compatibility to licensing issues, server size and storage requirements can prove a major stumbling block.

Even if one isolated a specific subsection of the overall ASIC process, a single pushbutton flow typically wo uld represent a compromise. A trade-off must be made between the most appropriate engineering solutions and the requirements of the flow. That is not to say that the flow is inherently wrong, only that it proposes a single (or limited) engineering solution. The solution may very well possess other advantages. If it is an acceptable compromise to all involved, so be it.

But there are other reasons that a true pushbutton flow is simply not viable. Tools and technology are changing more quickly than the flows can be developed and documented. When the flow breaks, an engineer must able to work outside the flow to solve the problem.

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 Design-for-Test Engineer at Mint Technology (Fairport, N.Y.).