When we discuss an IC design teams capabilities to execute on a given project how quickly does the conversation evolve into an EDA discussion? Everywhere we read about design bandwidth and quality the emphasis is on tools and flows. There is little doubt that EDA capabilities are a significant contributor to a team’s productivity. The risk I see is that an unrealistic dependence on EDA can allow it to be considered as a design projects fundamental reason for failure, masking the need to find root cause and implement process changes.

Where does management, or more precisely the detailed planning of design team execution fall in today’s product development organizations? The planning I am referring to is not only the technology type activities and decisions; it must include the organizational interfaces and deliverable expectations beyond that of pure engineering. The “what”, “where” and “how” details. An unsettling trend in organizations today is that non-architectural planning aspects of a design project fall upon canned EDA flows and program management, primarily driven by the need to maximize design bandwidth for engineering activities.

The danger in this tendency is that the EDA scope does not encompass the entire design process that must be addressed and program management does not typically have the knowledge for in depth detailed design planning. A planning gap results, opening the project up to potential surprises during design execution; further leading to a diversion from the plan. Organizations are far less hesitant to send a design engineer off to training related to a specific tool than they are to a class dealing with design planning strategies, thus perpetuating the disparity in planning expertise for design projects.

If a design project fails to meet its objectives the blame can’t blindly be tossed on EDA or program management. We must face the stark reality that a failed design project was not planned and managed for success. If we want design project execution to be predictable and meet the mark we must invest in the teams abilities and skills for planning and managing their projects. Every member of design must possess abilities to enable him or her to properly scope, track and deliver their contribution to the project.

There are many “right” ways for a designer to execute design of their particular function. The key to minimizing integration headaches and maximizing design execution predictability is to ensure that all the designers choose the same “right” way. The design tools and flows themselves do not necessarily legislate that designers are on the same page in designing and delivering their IP back to the project. There must be another level of guidance in place, the design process. Please note the diagram to the left to refresh your understanding of the scope of design process activities that must be managed.

One mechanism for managing this process has been previously described as the Design Guide concept. This has traditionally been an electronic document such as Word or FrameMaker and is meant to be completed real time, thus guiding and documenting the design from concept to production release. Essentially, the guide is a container for designs “business process”. The design guide is best described is the merging of the design specification, the design checklist, the design flow and the design process. It is a superset of a typical design specification. Now if we took this document concept to a higher level of automation, how would that impact design execution?

Many of the business process tools used in an organization today are web based, however they do not typically delve into the details of the design process. Focus of these web systems tends to be on deliverables into and out of design, not necessarily on managing the execution of the deliverables themselves. This leaves a gap in the online automation and tracking of the design process. Filling of this gap could be easily covered with an online implementation of the design guide concept and I have begun to explore the feasibility of doing so.

There are many commercially available online workflow development tools available today. They can provide the basis of a platform upon which development of an online design guide could be accomplished. I have begun exploring these possibilities and would like to solicit input from the design community to guide me in identifying the key features of an online design guide. If an online design workflow system is of interest to you for guiding your design process, I would like your inputs on the main features. Please review the proposed feature document at Web Design Guide and let me know what you think via email comments or a phone call. All comments would be greatly appreciated and will remain confidential.

I would appreciate your inputs

Do you need a system such as this?

Do you already have this covered via a different approach?

What features would you want that you don’t see?

What features do not bring value to you?

Anyone who supplies inputs to me will receive the finalized version of this document. Email me here.

New Section
This section is available to readers that have something to say about what I have written or general comments on IC design process management. Email me your brief letter and include your name(or anonymous), title and company for possible publication in a future newsletter.