IC Design Management Best Practices

Roger March, IC Manage

Designing large-scale integrated circuits today can require design teams composed of hundreds of hardware designers and hundreds of software developers spread across multiple locations worldwide—all working on the same products or derivative products.

It is becoming increasingly vital to deploy a strong design data management policy to guarantee that the most updated information and intellectual property will be available synchronously and on-demand at the various locations.

Repository-Based Approach:  Designers Focus On Design, Not Version Tracking

In the “repository centric” approach, chip designers have ready access to exactly the data they need to do their jobs. The data is packaged in “views” that make sense for their particular job function. This is because the organization of the data on the server is distinct from that presented to the designer’s space. Different engineers may see the same data presented to the design space in different structures.

When implementers carry forward practices from previous jobs or tools that focus on file trees as a way of organizing data, designers are faced with the  following drawbacks:

  • Designers are burdened with worrying about where things are stored or are forced to deal with cumbersome file trees, searching endlessly for files and proper versions.
  • The data management system is extremely inflexible, with data locations hard-coded. Designers must traverse the tree to find what they need.
  • Excessive copies of specific data are stored in multiple locations.
  • File trees require a fixed name space and structure that can become unwieldy. Designers working with a remote design center that only needs a subset of the server data may have to move the entire file tree.
  • Tools that operate on top of the file tree structure may have problems with collisions and incompatibilities.

In contrast, by focusing on the repository, designers can write simple mapping rules that allow them to map their repository into any data structure based on  the function they are performing. Designers can specify a namespace in the repository that is different from the names in their file system. They can  assemble multiple combinations of names to create data sets in the file system.

The example shown below (Figure 1) shows how data from a single depot, or top level partitioning of the repository namespace, can be altered into different configurations in the engineer’s space.


Figure 1 – Design data from a single source can be modified for multiple designers

Sources of data can come from several depots from anywhere in the world. The elements used to construct modules, chips or systems can be freely  intermingled from different depots.

Using a repository-based approach to IC design data management frees designers to organize and think in a way that fits their workflow and the way their design is organized. A repository-based approach is a fundamental starting point that makes it easier to reuse intellectual property, manage changes and derivative designs, plus manage individual workspaces and facilitate updates.

IC Design Data Management Best Practices

Below is a set of IC design management best practices that help obtain better IC design productivity through a repository-centric approach.

1. Understand the design’s organizational structure

It is important to understand the types of logical and functional data that the company operates upon. Creating the distinction between logical and functional data is key to effective reuse. Without it, a design is rigidly locked to the structure of the tree implementing it; reuse of leaf data may be possible, but that of intermediate units will be hard to access.

  • Logical “buckets” are aspects of the design—the project, the module or a particular revision of a project. Examples are PDKs, third-party IP, and internal IP, and producer-consumer relationships are dealt with at the functional level.
  • Functional “buckets” show how the data is organized to support the logical buckets, such as Analog, Digital, Test, or Simulation. Issues like library organization, separation of different data types,

Below are four levels of hierarchical composition: projects, variants, data types and libraries.

  • Projects are nothing more than the designer’s definition of a design. A project could be a chip, system or program.
  • Variants are specific revisions that represent different states of the design.
  • Data types define the elements making up the design, like RTL,  schematic or layout data.
  • Libraries are the lowest divisible level for data. Separating things any further would destroy the fundamental nature of the  object that it represents—like separating a gate into collections of P and NMOS transistors.

Libraries may be generic directories or specific EDA tool data structures. The granularity of a library should be as fine as possible.

Logical and functional data is difficult to organize in a file tree-based system, as there is little structure or logical partitioning. Additionally, establishing design coherency is hard because this type of design data management does not support fine-grained libraries because they could be spread all over the file  system. The result is a trend towards large, flat libraries that contain everything needed for a particular project, including many redundant copies.

2. Partition for reuse

Proper partitioning is essential for design reuse. Designers cannot reuse what they cannot find, and they cannot find data easily in a large file tree. Copying the entire tree is very inefficient. Creating a large number of logical and functional buckets will make it easier to locate objects for reuse.

One reason to make libraries fine-grained is to facilitate their reuse. Fine-grained libraries are like Legos that can be broken apart and reformed as appropriate to deal with problems that crop up in design. For example, if the  library contains a shifter or comparator rather than just  an “adder,” the  sub-component can be reused in an adder that implements a  different algorithm but reuses some of the same physical components. It is better to place the  shifter and comparator in their own libraries so they can be more easily reused.

Partitioning enables a divide-and-conquer strategy. Once the partitioning is created, it easily allows design teams to operate at maximum efficiency. For example:

  • A part of the design might be cut out and given to new team members to optimize.
  • An architectural issue might be found that requires the high-level structure of the design to be reworked.

3. Organize according to designer workflow

In  most cases, an individual will be assigned to a particular stage of the  design, such as schematic, RTL or layout. The design management system should be flexible enough to only present them with the data they need. Forcing engineers and tools to deal with the entire file tree is not only cumbersome, but  dangerous; they may accidentally modify data outside their scope.

Most humans work serially. Therefore, it is best to create a  structured representation of  the data for a given design task  rather than have a large sprawling tree of data and links. This brings clarity to the process, allowing the designer to better focus on the task at hand.

It is also preferable to use higher-level constructs such as projects, variants, types and libraries to  create this structured representation, instead of relying on traditional release label  schemes. The device to be taped out can be  structured into several projects that are  presented as  repository mappings, rather than  as file system objects or paths. Each project can be made up of several variants.

A type is another level of organization that distinguishes between the different uses of  the data and determines how the  design management  system deals with it. For  instance, Cadence cell view  data must be managed as an  atomic group of  files;  failure to do so can put the design tree into an unusable state. Typing the data also allows the system to better match the designer’s wishes. RTL and software files are typically text based, where more than one  engineer may edit the same file simultaneously and conflicts are resolved by merging. Other forms of data may be stored in binary files where exclusive locks are desired.

The concept of “view” is also critical to good organization. In many earlier generation design management systems, there is only a 1:1 mapping of files to the  repository files on the disk. A repository-based system allows workspaces to be constructed out of views that can have any path in the repository. In essence, the repository is structured to match the organizational structure, while the actual data files are filled in later from the file system.

A view provides a mapping from the  repository namespace to the design namespace. The repository may have two objects— “/fast/adder/” and “small/adder”—which can be selected by a view called “/adder/… object” that maps to the design space. With views, engineers can embed more information  in the name than they have in the tree—a practice that facilitates reuse.

A traditional data management practice is to organize files by reusable release labels; however, this is a flawed approach for IC design. One reason is that when designers reuse a label, the old state is lost. Unless all workspaces are resynchronized to a label simultaneously it creates confusion because designers do   not know what state they are in, for example, whether it was yesterday’s “A” or today’s “A”. Another reason is that workspace management needs to be straightforward. Designers should not be burdened with having to remember complex sets of label names.

4. Use branching with history to make changes

In file-based data management approaches, people make changes by copying them. This causes several problems: Engineers don’t know where they copied the change from; they lose the ability for incremental updates; and they don’t know where the objects will be used.

Suppose the engineer finds that a chip is failing in the lab because an inverter is having an electromigration problem. Copying will make it difficult to find out  other places the inverter is located in the product family.

Two additional problems with copying are the creation of redundant data, and the loss of ancestor-descendant (parent/child) relationships. The first issue costs disk space and performance. The second makes it exceedingly difficult to take advantage of the lifecycle benefits of  reuse. A problem discovered in a  reused component would have to be identified outside the design management system.

Branching is a more efficient approach that lets the repository do the copying. Branching is nothing more than metadata copying in the repository namespace. No design data is actually replicated; it is merely linked. Better still, this linkage explicitly defines the ancestor-descendant relationship so that the design management system knows what belongs to whom.

Branching should support integration history. This allows a bidirectional representation of the parent/child relationships, making incremental upgrades possible without having to “diff” files.

Branching with history is the cornerstone of repository-centric operations. The biggest issue with a lack of history is that it can quickly make design reuse infeasible. Historical information is natural and should be incorporated into the design system.

The design management system should be able to maintain the explicit state of all managed files in the designer’s file space. When an update is requested, the system just has to look up what the designer space state is, and compare that with the  destination state. If they differ, it just delivers the new files. For potentially huge design files this is an enormous speed advantage over systems that need to scan for state in the repository, and then compare that byte by  byte with the design files.

Figure 2  shows an example of a change made to a processor project comprised of the following components:


From this we wish to create a dual core version like:


Figure 2 – Creating a design variant

The PLL between the two chips is identical, but is in a different place in the cell hierarchy. This can cause much grief for file-based systems and approaches. The Processor Core1 is a derivative of  the Processor Core, but shares much of its internals with its parent. Only the cells which have been modified actually create new data, and the new data represents only the changed cells plus some metadata. File-based systems can only accomplish this by copying the data.

5. Do release management through branching

Reusable labels are a poor method of release management. Even if engineers create new labels every time, the data management system can become inefficient and complex very quickly, since they must write code to manage their label sets. This will cause a continual support and maintenance issue for the  designers and system managers.

Branching  provides a much better approach to release management. Releases are immutable snapshots of a design. Each release is just a recorded change number to which the design state can be rewound. Should a fix need to be made to the release, it should be branched from its release state so that the  contents can be modified. All these operations maintain the ancestor-descendant relations.

6. Establish change propagation policies

Change propagation is traditionally tracked through spreadsheets, with designers opening the design and manually making changes every place it is needed in  the design. This manual approach is slow and error prone. Some meaningful cases may be overlooked, or some part of the data set might get left out.

Here’s an example of how change propagation can be facilitated through branching. Say we have a project with several product releases like:


We notice field failures from r1, so we branch from the release to diagnose and fix the problem:


A number of issues are fixed and a release is created to address them. The data management system is then queried to see if any of the changed items are in subsequent releases. We find that the cell in r3 needs the new changes. A branch is made and only the fixed cell is included in the change list that we propagate to the r3 branch:


Figure 3 – Change propagation through branching

The blue line shows the change propagation path. A release is made of the fix.

Identifying the extent of a change involves querying the data management system to find the ancestors and descendants of  the changed files. The following branching diagram shows the relationships between projects in the repository namespace:


Figure 4 – The extent of a change

If scope of the change is small (the red circle), a few commands can be used to find the affected trees. If the scope is large, a script is a better answer. The  affected trees are integrated once they are found. This can be directed so that only specific files are brought over, and any necessary data pruning is done after  the differences are resolved.

7. Make workspace management effective

The workspace is the place where engineers edit, test and debug designs for which they are responsible, including top-level integration. Changes to a managed repository begin as changes to files in a workspace.

A repository-centric approach opens new possibilities for workspace management. Some best practices are as follows:

Don’share workspaces. A workspace should have a single purpose, such as an edit/debug area for a single engineer. Sharing workspaces confuses people and can compromise the data management system’s ability to track  activity by engineer or task. Workspaces and the disk space they consume are cheap, so trying to conserve them is a waste  of time. Most workspaces do not need to be on expensive shared network storage; by using local disk space, design teams can reduce network utilization, increase I/O  performance, reduce cost and increase application performance. Since the data is present in the repository and can be restored on demand, arguments about the difficulty of performing local file system backups become moot.

Don’t  work outside of  managed workspaces. A company’s design management system can only track work in progress that takes place in managed workspaces. Engineers working outside of workspaces are not part of the information flow.  Most design management system use workspaces to facilitate communication between engineers, where engineers have visibility into each other’s workspaces.

Don’t  use “jello” views. A jello view is a work space where file changes are caused by external events beyond your control. A typical example is a workspace built upon a tree of symbolic links to files in another workspace. When the underlying files are updated, the workspace files change and can cause  chaos, wasting time and money. Keep workspaces firm and stable by setting them up so that designers have control over when their files change.

8. Facilitate frequent updates

Most design teams currently use a shared repository space model for development. This means they see the most recent updates that any member of the   team commits. This is a way of communicating design progress to the  group and is central to the efficiency of the model. In a robust design management system, the ability to rewind and recover the design state to any point makes the penalty of making a bad update commit very low, so frequent updates are a big win. The following practices will help facilitate updates:

Stay in sync with other people’s designs. The quality of an individual’s work depends upon how well it meshes with other people’s work.  As changes  are checked in, each engineer should update their workspace to integrate changes. To facilitate this, update operations need to be fast and easy for design engineers, without tricky or time-consuming procedures.

Check in often. Integrating development work with other people’s work requires checking in changes as soon as they are ready. Changed files should be checked in as soon as a design task is finished, so the work is readily available to others.

Don’t set up barriers to change.  Arduous validation procedures should not be implemented. Short freezes are okay, but long freezes compromise productivity. Barriers to checking in changes will prevent regular check-ins and create a logjam at the end.


IC design data management best practices enable companies to implement a highly effective and scalable hardware design management process to reliably manage single and multi-site development IC design efforts. Companies adopting a repository-centric approach will be able to provide their hardware designers with quick access to their design data in a form that matches how they think  about their design, freeing them from searching through unwieldy and confusing file trees for the information they need

Roger March is Chief  Technology Officer for IC Manage, Inc., where he created their current design data management solution and continues to improve its performance and scalability for global multi-site use. Prior to IC Manage, Roger worked at Matrix Semiconductor, designing and  implementing the majority of their CAD software. Roger was the first CAD engineer at MIPS, building the infrastructure used to build their MIPS microprocessors and several system designs. After Silicon Graphics acquired MIPS, he worked in SGI’s microprocessor division, delving more deeply into design databases and writing several tools to analyze and manipulate physical, logical and parasitic extraction data sets. Roger began his career as a circuit and logic designer for Data General and Zilog, creating in-house circuit, logic and  fault  simulators to build and verify early microprocessors and  dynamic RAMs. He has a BSEE from San Jose State University.