As chip design organizations grow and mature, they inevitably start to look at creating a global set of standard tools and methodologies. There are several benefits to this approach, but there are some major drawbacks that need to be taken into account when developing a corporate strategy for design and verification.
On paper at least, the benefits of creating a global methodology team are numerous:
- All engineers are trained in a common approach, allowing them to easily be retasked to work on other projects as needed.
- Centralizing development of scripts and libraries frees project teams to focus on the task at hand without having to "reinvent the wheel".
- Significant cost savings can be achieved by reducing the number of different tools being purchased to solve the same problem (i.e. standardize on all Cadence or Synopsys tools).
- Members of a global methodology organization have insight into a larger problem space and thus should be able to architect more robust and reusable solutions.
In practice, these benefits can be diluted (or worse) by the following:
- Global methodology engineers aren't working on any specific project (or are perhaps only working on one) and become disconnected from the real needs of individual project teams.
- Different types of projects require different approaches. What works for an ASIC might not work for a full custom solution. Analog interfaces likely need to be handled differently from digital ones. Ditto with CPUs vs. Networking Devices, Server processors vs. Mobile processors, etc. Then you have the differences between cross-site and single site teams.
- Enforcing global standards too severely can stifle innovation and degrade productivity as they can prevent smaller project teams from trying out more modern approaches.
- Not all projects are created equally. Anyone having issues with the global tools and methodologies that are part of low priority projects may be out of luck.
One of the first things that should be taken into account when attempting to create a centralized organization as described above is whether you want to be in the application development business. Creating a set of libraries for a project is one thing. Productizing those libraries and supporting their use among multiple organizations is something else entirely. There needs to be a commitment to providing adequate documentation and support.
There also needs to be a commitment to hiring the correct types of engineers for the job. For example, you may decide your organization needs a suite of web applications to handle things like bug tracking, simulation results analysis, etc. It's unlikely that a run-of-the-mill hardware engineer is going to have the experience necessary to build these applications in a robust fashion. Finding a diverse and talented group of individuals is key, but care needs to be taken that the team doesn't lose focus on its customers - the product teams. One way to help work around this issue is to rotate some percentage of the team in and out of the group every year or two to make sure there is always a stream of fresh ideas.
Speaking of fresh ideas, it is critical that any methodology organization be open to new ideas developed by members of the product teams. Each team should have the freedom to choose whether they want to use the global methodologies or not. They should be given incentives to use the common infrastructure, but if the situation warrants, they should be encouraged to go off and develop new methodologies which they can then feed back into the corporate organization. The key is to remember that the goal of the global methodology team is to enable the company to bring new products to market faster and with a higher level of quality.If an individual team has a set of skills that make it easier for for them to bring a product to market by doing things a little differently than the rest of the company, that's OK.
Standardized methodologies can truly improve an organization's ability to drive quality products to market in a shorter time. However, care should be taken to ensure the global team works seamlessly with the product teams, or the benefits may quickly be lost.