Are we Ready for Hosted Solutions for Chip Design?

Software as a service (Saas), hosted solutions or cloud computing all have a similar meaning; and that is running an external software application on external hardware over the internet. No software to install or maintain and no hardware to buy or maintain. The positives are availability of the application from a web browser anywhere on the planet, simple deployment and a potential wealth of hardware at your fingertips. The negatives tend to be long term costs and the necessity of an internet connection.

This hosted approach for software is widely in use for project management, customer relationship management, brainstorming, collaboration, workflow management, desktop sharing plus many others. I am personally using many of the hosted approaches for my business and have found it a great way to have my data available to me with only a web browser and an Internet connection. I have grown to thoroughly appreciate this approach for the applications I need, although I was reluctant in the beginning. I am now a staunch advocate of this next generation of software delivery.

Now, how about hosted solutions for the chip business? Cadence announced their SaaS chip design offering back in September of 2008. There are also a few others out there with Saas offerings for design work. I am not sure how the adoption of this is going but I personally believe this is the future, once we get beyond the 1st order concern of having our IP “outside” the firewall.

Here’s a few links on the subject to get you thinking:
Cadence blog
Harry the ASIC Guy blog
xuropa

I would really like to hear comments from anyone who has given the hosted solution a try for any IC design activities, good or bad. Has it been a good experience or were there unknown potholes that made it unpleasant experiment?

Eliminating the Systemic Barriers to Meeting NPD Commitments

What comes to mind if you were asked “What are the systemic barriers to meeting New Product commitments?” These barriers are ingrained in the very fabric of an organization and typically subtle in visibility, yet pervasive in impact; often providing a veiled resistance to improvements in an organizations project execution. Their presence is often characterized by unexpected diversions in a projects course – surprises often believed as something that could have been avoided. Are you and your team tired of being surprised and dealing with the aftermath, project after project?

Understanding and removing these systemic barriers takes an attitude that change is possible and WILL happen. It takes an attitude of ownership to find and remove the roadblocks that are creating project surprises; the issues are right here, right now – not somewhere else in the organization or someone else’s responsibility. It takes an attitude that you will be successful in eliminating execution barriers. It takes an attitude that grasps the value in a proactive and never ending focus on being better.

What have you done in the last year to drive improvements and eliminate the systemic project barriers? How about the last quarter, last month, last week or yesterday? A never ending and relentless attitude on always being better will make you and your teams stand out from the pack by always delivering to the business objectives. Talk about being indispensable – do this well and the wow factor is off the scale!

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.

Closing the Individual Objective Clarity Gap

Are you confident that everyone has had all the information required to perform his or her tasks for projects? If any task deliverable or activity has needed to be reworked or massaged in any way, they definitely did not. Clarity of individual objectives is one of the top three contributors to unexpected diversions and delays in projects. This deficiency is often misunderstood, ignored and "assumed" to be under control. As an example of this misplaced assumption - the existence of ISO 9001 should not imply that the clarity of individual objectives is being addressed to the degree necessary.

Most project teams have a solid grasp of the timing expectations and responsible person for each task - the who and when aspects of the project activities. The primary reason for success here is that the information can be easily conveyed and interpretations of intent are rarely necessary. The expectations can be simply transmitted, captured and tracked in a project plan. It's "easy" information.

Where I see limitations in clarity is the what, where and how aspects of each of the tasks. This is the procedural information that does not easily fit into a single line description. Consider that for any project there are many "right" ways to do a specific task, the challenge is aligning everyone to the same "right" way. Failure to align expectations will lead to rework due to missed expectations between the deliverer and receiver of a task output.

The what, where and how objectives are procedural in nature and can't be easily integrated into a project plan. Detailed procedure descriptions, diagrams and flow charts are necessary to properly convey this type of information; this can't be done in a checklist or a project plan. There is another medium necessary to convey this type of information, one that is easily accessible and available to everyone. The chosen method must integrate into the workflow, not stand outside the workflow as a reference. Suitable communication of this information requires the addition of design guides and/or web workflow management systems.

Frequently there is an assumption that project plans, specifications and checklists cover the needs for communication of individual expectations. This is just plain wrong and will leave your project open to needless rework. Where both a predictable and streamlined path to new product revenue is required, it is essential to make sure each team member is clear on exactly what, where and how everyone is contributing to each project task. How far away is your organization from this ideal objective?