Solutions for Managing Complex SoC Design

Designers have been using this top-down method for a decade, but the way design tools manage the files that those designers work with is still largely flat. Thousands of files are linked, but there is often no way to handle them hierarchically. This flat approach creates a problem when all the files are not under the control of one design team in one place — when all those files were on one server, managing them was a headache, but still possible.

Now there are often 100,000 files in a design; that alone is a nightmare to manage. Part of the problem is that only a small subset of these, maybe only 20, are needed when the design is taped out and sent to the fab — the rest are iterations, variations of the files created as functional blocks were improved. Worse, these files are usually not in one location — sometimes not even the same continent or company.

Deep submicron projects are increasingly integrating blocks from teams around the world, including intellectual property (IP) from external suppliers. All these blocks are regularly updated, so there is a major problem in handling them. How does the designer know if he or she is using the correct version of a block (especially when the correct version is usually not the most recent version) or if anyone has found any bugs in that block and if anyone has fixed them? Worst of all, it is almost impossible to determine what effect all this has on the final design.

Some of the files can be updates from external IP providers who improve the blocks over time, but these changes can potentially have an effect on other blocks or the top-level design. These can change parameters, such as timing criteria or even the size or layout of the block; though sometimes this is not a problem, at other times other blocks need to be updated. Either way, the changes must be assessed.

As the supply chain of chips assembled at the board level is replaced by a design chain of blocks integrated into an SoC, so large organizations are increasingly looking at design chain optimization. This means more design reuse and buying in IP blocks, so tracking and managing these blocks is even more important.

Companies such as STMicroelectronics, Philips and Fairchild are now looking to a new generation of design management and collaboration solutions as an increasingly important part of the design chain. Being able to create complex configurations and stable subsets of all their files; monitor and control versions of files; communicate bugs, updates and status; and manage all this across multiple internal and external sites has become a competitive differentiator.

The average design team now consists of 50 engineers scattered around the world, not counting those working at partners, subcontractors and external IP suppliers. While engineers want to create the best device they can, changes can introduce delays that cause the company ends up losing the market window for the final product.

Most important is to be able to use the files the same way designers design the chip. There are many file-management tools, many from the world of software development, but they tend to use a flat approach.

The key change is adding data to the files to keep track of the position and status of all of them in the design hierarchy. This allows designers and project managers to navigate through all the layers of the design and have an immediate, up-to-date and reliable view of the design. Outstanding problems can be viewed on the block level or throughout the hierarchy, giving the project manager the information to decide which are critical and which are not.

IP vendors will update their contributions, increasing the quality and sometimes even the functionality of their blocks. This can change the interfaces, so the file-handling system must understand the difference between significant changes — such as those to the interface, timing or size — and the insignificant general improvements to a block.

These changes also have to be visible throughout the design so that the project manager can see the exact status of the design. It is this hierarchical configuration management (HCM) that is becoming increasingly important in managing the design files correctly and ensuring there are no mistakes caused by human error in the management of the design files.

This is not just relevant to the data files. All the associated data has to be included, from the scripts, synthesis files, schematics, architectural definitions, test vectors and many other parts of the design process. As these files change the changes must ripple through the design, to be accepted or declined as the designer sees fit.

These dynamic links are maintained throughout the design, crosslinking all the files wherever they are in the world and however they change. This also allows the automatic determination of who must be notified when a change has occurred. For example, a change deep in the hierarchy of one of the sub-blocks would be e- mailed only to the responsible developer, but the team leader would be able to define the rules that identified the changes that they would see. These criteria can be set and changed by the project manager as the project progresses to allow the team to focus on the important matters, particularly changes to block interfaces and bugs that effect corner cases. The file-management system also has to be able to roll back the design to a previous "gold" version, changing that dynamic linkage to a static one.

Maintaining that ability with files changing all the time is no mean feat. If, for instance, there is a change in the standard cell library, that change will ripple all the way up the hierarchy, creating new versions of each of the blocks above it. This allows new what-if versions of the design to be created, with the designer safe in the knowledge that if an impenetrable or time-consuming problem appears the design can roll back to a known good state.

All this file management has to be done in real time across design sites around the world. For example, Philips Semiconductor has teams working in Sophia Antipolis, France; Nuremberg, Germany; and Zurich, Switzerland. They use Synchronicity's Hierarchical Configuration Manager tool. This allows the project manager to see the whole design from the top level and push down into each functional block with all the options and versions available, but with a single control version that will end up in production.

There are severe infrastructure considerations associated with the global nature of design, as it is impractical to have thousands of large design files moving over global intranets and extranets. One alternative, having local copies of the design for every engineer at each site, requires many redundant gigabytes of storage and can delay changes trickling through to all of the sites. This creates large problems with version control and wasted work.

Instead, the Hierarchical Configuration Manager extension to the Synchronicity Developer Suite allows the files describing key regularly referenced blocks, or modules, to be cached in secure locations so they are local to the users. This approach, called Mcache (for module cache), uses a shared workspace containing all the files for particular versions of a design block or module and this is where the designers work. Accessing other modules or switching between modules is effectively instantaneous as all the files are rapidly accessible locally.

An Mcache can also be set up in an IP supplier's system so that changes to an IP block they are developing can be seen throughout the rest of the design and all the relevant people can be notified of the changes. With 13 out of 15 of the world's top semiconductor makers already using Synchronicity tools, this allows an IP provider to link to many of its clients seamlessly.

The HCM environment also allows other design management tools to have a greater effect on the efficiency of the design process. The hierarchical view from HCM allows users of Synchronicity's product, ProjectSync, to request a report on either the outstanding bugs or the design lifecycle status on the entire chip. Information from all the sub-blocks is automatically rolled up rather than just from the local hierarchy, even if the block is referenced from a Synchronicity Publisher Suite design reuse system.

HCM has a fundamental part in many semiconductor developers' design processes. With designs becoming ever more complex to manage, costs and time-to-market can be reduced by being able to handle all the files in the same hierarchical way that the designer thinks cuts down development times and improves the quality of the chip.

Patrick Romich is chief executive officer of Synchronicity Inc. (Marlboro, Mass.).