As IC designers how many times have we heard “Why can’t the design be right the first time?”. Having answered this question many times over the years most responses tend to identify some uniqueness to the design in question that will greatly diminish the odds of its initial success. Right out of the box we have justified in our minds that it will need a spin or two. Typically we end up succumbing to schedule pressure and we loose our “extra” spin in the plan. The reasoning is that design needs a higher bar to achieve the preferred level of design execution. Increased pressure will breed success being the rationale that drives this line of thinking.

While it is OK to have a carrot to drag us to a higher level of productivity a crucial question we must ask ourselves is what will be done differently to achieve a new level of success? Is it burning more midnight oil? Although that has provided limited success in the past it tends to negatively impact quality. Genuine, permanent positive results will come out of changing “how” things are done. And by change, I do not mean only in the framework of tools and design flows. The vision of the design landscape to be managed must be broadened to encompass tasks where ownership is typically vague.

Take a look at the above visual depicting the scene to be managed by design. With respect to your own design team, can you genuinely say that everything item has been managed to the crisp level that leaves nothing to chance? Bringing clarity to the tasks where ownership has been vague will enable a higher level of quality and productivity. Any assumptions about who is on the hook for ensuring closure of required decisions and activities will always undermine a team’s optimal execution to plan.

Ambiguity around ownership of a task will ensure a lack the proper attention to detail and eventually disrupt your plan. Take another look at that visual. Is there anything there that should not be owned and managed by design? Build your design plan around ownership and closure on all of these items and enjoy a new level of predictability and quality. Ignore them, or assume someone outside of design is addressing them and your 2nd spin will be preparing its assault on your plan.

There were four main items I identified in the article as having impact on first time success of a design.

High complexity reduces chances of success.

System design methodologies improve success.

Attention to functional verification will improve success.

Standardization on IP deliverables will improve success.

All four of these items share a common thread, the lack or abundance of information. Clarity and quality of information is an area that I strongly believe will always enable a design teams predictable nature. To clarify this point I will discuss each one of these items and identify how quality information has been the true deliverable out of each.

High Complexity
I will not argue that complexity adds risk to first time success although in our world we frequently need a differentiator to secure market share. That comes in the form of products that must be revolutionary, hence adding complexity. In the face of essential complexity how does one reduce risk exposure? An abundance of high quality, necessary information will reduce the risk in the face of a complex architecture. That information comes in the form of architecture trade-off analysis, communication of down stream requirements, clarity of plans for review and feature vs. market requirements. Dial up the complexity and you must dial up the planning and review of those plans to mitigate risk.

System Design
My view of system design is that it provides a top down development effort where the chip level trade-offs are done early in the cycle. I regard this is another form of planning to ensure the end product will meet the requirements before wasting time on lower level design details. It also brings clarity to the expectations of the lower level deliverables. The main benefit of system design is the early product validation and partitioning plus the crisp requirements information derived for lower level design activities. The diagram below represents how the system information flows down to lower levels of abstraction through the use of hierarchical design guides.

Functional Requirements
How will the part be expected to behave in the system and how will that behavior translate to block level behaviors? Information again. It must be complete and crisp to ensure the design will act as expected, under all conditions. Any functional verification will only be as good as the understanding you have of the end customers system. Spend the time to gather the information about the customers system, develop a functional verification plan around that system and you have increased your odds of 1st time success.

Standardize on IP Deliverables
You want your IP to come together without a hiccup during chip integration. How do you do that? Make sure every piece of IP meets the same set of requirements by mapping out a consistent set of expectations for all IP. Those expectations are the information that is necessary for successful, hassle free chip integration. What regression tests, simulations, reviews, functional verification etc. that must be done for each block. What specific IP deliverables must be provided for each IP block? Standardizing on IP deliverables is the role of our block level design guides.

Design is about moving information from one person to the next. If the information is incomplete, nonexistent or does not meet the input requirements of the receiver, a step is running on autopilot. Bring on the information and you will enable a higher level of silicon success. Cut corners on information and you will elevate the risk to first time success.