Enable Predictable Design Execution by Looking Beyond Tools and Flows

To manage the complexity of today's embedded designs, one should develop and follow a predictable design process.

By Jeff Jorvig

In many design teams, predictable design execution to the plan is a desired goal. Yet frequently, it remains unachieved. This trend tends to be more prevalent in larger mixed-signal or analog designs than those designs that are mostly digital. If a predictable nature is an unattained goal for your team, it may be time to look at activities beyond the typical design-flow items. There is likely a lack of clarity around assorted support, non-design-type activities, which the design team must complete in order to ensure crisp design execution. Design teams that manage beyond the basics of schematics, simulations, and layout will display predictable progress toward the agreed-upon milestones.

Broadening the Design Landscape
The IC design landscape must be viewed from a broader perspective than typical CAD- or CAE-type tasks. This view must encompass all of the essential support activities. Examples of the broader activities to be managed would include those associated with scope change, test capabilities/ features, and scheduling tradeoff decisions. Other instances include tasks associated with managing closure of the product specification, best practices (what, where, why, and how), design-flow development, simulation plans, and design- review strategies. These examples are only a sampling of the typical supporting activities that must be considered as components of a thorough design plan. Figure 1 provides a detailed view of the total landscape to be considered. The identity of supporting activities beyond typical CAD/CAE-type tasks is unique to each organization. It must be recognized and managed from within design, thereby allowing the chip to come together without a hitch as the fracture date nears. Leaving any of the support activities off the management list or failing to identify all of the supporting activities will cause a surprise for the project. The result will be an unplanned diversion of activities and a slip in the schedule.

The discovery of all of the actual supporting activities doesn't come without homework. By assuming that all of the supporting activities are already well known, one will surely lose the battle before it has begun. The mission must be to find the supporting tasks that aren't widely known to the team. If I were to go into any product design organization and ask what activities must be completed prior to fracture, they would have a lengthy list of items to share. A larger concern should exist about items that aren't on the list. Their lack of identity is quietly stealing precious development time. Instead, look for subtle disconnects that prevent the smooth flow of information through design from concept to production. Consider the deliverables that are necessary to feed into later activities. In addition, look for activities that are needed to support the success of product engineering, test, systems, program management, and marketing in their role on the project. Figure 2 provides the scope that must be considered in the quest of uncovering unknown or unmanaged activities.

Recognition of all of the hazy, unfamiliar supporting activities to be managed is best handled through a formalized discovery process with the product-development team. Components of discovery include one-on-one interviews and group brainstorming sessions targeted at uncovering gaps in activities that prevent crisp design execution. Figure 3 indicates the expected growth of the number of known design activities to be planned as one progresses through a formal discovery process. The designer begins with a known set of tasks. As he or she journeys through the process of identifying all of the supporting tasks, the list of items to be planned increases. The completion of this exercise results in a list of all activities that design must own and successfully manage to closure, thereby enabling a predictable workflow.

When embarking on a discovery process, it's essential to keep the focus broad and cover multiple areas and multiple engineering disciplines. As noted in Figure 2, uncovering the unknown supporting tasks requires visualization beyond the designer's domain. The process must probe around in test, product engineering, marketing, applications, and beyond. Many unknown activities are based on a lack of required information, as information isn't shared between individuals on the product-development team.

Considerations for Activities to Be Managed by Design
This section will review several functional areas in the design landscape that should be considered as the designer works to discover the unknown or unmanaged design activities. These examples are meant to rouse the thought process as one considers the scope of tasks to be managed on the next project.

Product Spec Closure
If it isn't managed well, closure of the product requirements can drag on for as long as it takes to actually complete the design activity. Specification closure must be an integral part of the design plan. It's best to break the requirement closure activities down into bite-sized tasks and manage them. With a well-managed process, the clarity of product expectations will quickly result from this typically gray, hazy portion of the project. Realization of a reduced product-development cycle will require the crisp, efficient closure of the product requirements for a project.

Design Assumptions
Design assumptions are the design group's outlook of the deliverable's what, how, and when back to the business. Without assumptions from design in place, the business is likely to make its own assumptions about what the design will produce. A disconnect in expectations is the likely result. Items for consideration as part of the design assumptions include the baseline process, number of metal/poly layers, die size (make clear scribe or no scribe), package type and characteristics, and resource assumptions and schedule. The activities associated with closure on the design assumptions should be part of the project plan.

Design Reviews
Compared to what is planned for, design reviews tend to have more activity. Frequently, this activity is rolled up into a task that's a day or so long. Review preparation activity will easily extend beyond a day, assuming the review is to be a working session. To reap the benefits of this important quality check, manage the expectations of what goes into the review as well as the actions of what comes out of the reviews. Be sure to understand the review needs of test and product engineering and address any activities related to completing them. Multiple tasks will be part of a good review. If they aren't clearly identified, the review content will be inconsistent across all of the design work. Gaps will then be left in quality control for design.

Change Management (Feature Creep)
Feature creep is a sneaky consumer of precious engineering resources. Not having a formal change management process in place enables the team to be quietly diverted to non-planned activities. Planned activities then begin losing ground. And there's no paper trail left behind to defend why things are running late. Non-sanctioned what-if scenarios may be stealing time from a project. Even worse, a potential change could become a must-have in the design team's mind. As a result, the team will begin work on tasks that aren't in the plan. The business must drive the change process while design management must act as a gatekeeper to change. Without steps in place to manage feature creep, design will be faced with unexplainable delays due to the lack of clarity in feature expectations.

Design Documentation
Design documentation goes beyond the engineering specification to cover process-related activities, such as change management, best practices, simulation plans, design-review requirements, etc. Personally, I feel that completion of documentation goes a long way toward aligning the team--even if it is never read. Documentation development will foster team alignment when and if there�s large group participation. If there's work to be completed for any project documentation, there must be tasks associated with their completion.

Design Best Practices
Defining how design work is completed within the team should be covered under the best-practices umbrella. Coverage of the "how-to" areas outside of the standard CAD/CAE design environment also should be captured in this type of document. To remove the possibility of rework as design integration later commences, the information must be defined for any design deliverable. If there's a procedural decision to be made, capture it here to ensure alignment across the entire team.

For schematics, valid view types, page symbol generation requirements, and valid reference library components should be defined to capture process options like single or double poly caps. The PDK version to be used should be identified in addition to the specific tools that will be supported for the project. Don't leave out simulation expectations. Include sim corners and temperatures to be run for both digital and analog designs in the project.

Designers tend to fight with tool-related issues quietly and by themselves. As a result, design activities take longer than expected. If each designer deals independently with a tool issue, the total impact to the schedule will be amplified. To ensure that the project plan includes completion of any CAD/CAE work before it is required on a real design, any expectations of the design tools and/or design flow should be defined and then validated. Making any assumptions about what will be available to the team in terms of the technology and methodology that it will be using will leave the team open for unforeseen problems with the tools. Instead, identify any CAD/CAE work required for the project. Make it part of the project plan and then track the activity to closure.

Design Ownership of Supporting Activities
Absolute clarity in the ownership of any of the supporting design activities is essential. If there are any assumptions made about the ownership of supporting tasks, the project opens the door to an unpredictability that will be certain to disrupt the plan. Organizations that assume that design-support activities are owned outside of design are opening themselves up for missed expectations. Ensuring the proper clarity and depth of supporting activities will only be accomplished if design identifies, defines, and manages them as part of the design execution flow.

Managing the support tasks within a design organization falls within the scope of what I consider as the "design process." All of the activities, decisions, and deliverables from a design team are part of an organization's design process. For example, the design flow is considered one of many sub-processes that make up that process. A predictable design team will have a thorough set of supporting tasks that will be identified, defined, planned, and tracked for each one of the sub-processes outlined in the landscape. They are indicated in Figure 1.

To find what is not known about roadblocks to ideal design execution, it's best to formalize the identification of missing or unmanaged activities. Make sure that all design activities are part of the design plan and manage them all to closure within design. Teams that strive to manage all of the activities related to support of the design steps as well as the actual design steps themselves will reap the benefits of predictable design execution.

Jeff Jorvig is President of Jorvig Consulting Inc.