Addressing the What, Where and How

For any task, the who and when are generally clear and well known to the entire team; it's in the project plan and visited frequently during project meetings. Whereas the more procedural information that describes the specific what, where and how for tasks is often lacking clarity and left open to interpretation. This gap in clarity often leaves a project open to reworking of deliverables. The following sections provide some considerations for addressing procedural clarity - the what, where and how for task objectives in design.

What
This covers both the deliverer and receiver of any project deliverables. The primary consideration is that everyone has the same expectations.

• Test mode handling expectations.
• Specific model requirements.
• Specific process and any process options.
• Area requirements.
• Power saving expectations.
• Pinout, pin type and loading expectations.
• Module level deliverable requirements for the chip.
• Layout abstract requirements.
• Specific documentation requirements.
• Critical node descriptions.
• Block diagram expectations.
• Documentation requirements.
• Routing blockage assumptions.

Where
You never want anyone guessing about where "current and released" project information resides. The worst-case sharing scenario is when email is used to send items around - very dangerous. Define locations for any shared information, identify release mechanisms to those locations and then legislate these repositories as the only way to share project information.

• Location(s) of current requirements and specifications.
• Location(s) for deliverables.
• Location(s) of any non standard reference libraries, custom component models etc.

How

• Valid reference libraries, components and tools/versions to use.
• Design collateral validation requirements to minimize chip integration surprises.
• Validation requirements to guarantee design quality.
• Risk mitigation strategies and configuration options in support of them.
• Review requirements - specifically what must be completed and what must be presented.
• Simulation expectations - analysis types, stimulus, supplies, test benches etc.
• Standards for RTL, naming conventions, ECO conventions, etc.
• Schematic standards.
• Procedure for version control of documents and design libraries.

Addressing the what, where and how completely and concisely will permit your organizations to experience a new level of predictability.