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: