Using IC Manage GDP for Collaborative Custom IC (Virtuoso) and Digital SOC Design

Roger March, IC Manage

To produce a functional SOC on time and at budget, it is critical to tighten and streamline the information flow between design layers and team members. Tools that assist the design process and team collaboration are as vital to completing the SOC as the individual tools used to build the design.

This white paper will explore the typical components, processes and flows used to create an SOC, as well as the intricacies of collaboration among interdependent design teams. It will also show how IC Manage’s Global Design Platform (GDP) can serve as a foundation for unifying the entire SOC design and verification process.

GDP uses shared workspaces and change-based design methods that efficiently deal with constant changes and propagating those changes as needed for both the initial design and all the derivatives.

The SOC Design Layers

As shown below, SOC design encompasses the traditional areas of IC design:


It contains the familiar levels of the silicon design and implementation (behavioral through layout) as well as a software layer. This new layer may provide firmware to complete the SOC’s functionality as well as device drivers needed for customer integration into their products.

Each layer represents a world view of the SOC at a different level of abstraction and utilizes a different set of tools to realize its function. For example, RTL and Logic levels may use logic synthesis and simulation tools while the Circuit level works with parameter extraction and circuit simulation tools.

The subsystems are implemented with internally generated IP, externally provided IP or some combination of both. Design goals such as power, area, and performance can span multiple layers. In many cases they represent constraints which must be met before the project is complete.

Verification must be addressed across all levels of the design stack. It must be developed and applied against a churning of project changes. Closure on verification is the final step in completing the design.

Moving between domains can be difficult. The design flow must be sufficiently robust to deal with changes occurring simultaneously on all levels as work progresses.

Beyond the SOC itself, other collateral is also needed for the product. This includes documentation, device models, manufacturing test suites, and so on. These must be delivered before the component can be manufactured or sold.

Global, Interdependent Teams

The organization of the tasks among the development teams can rival the intricacy of the design itself. Logic, circuit and layout designers are now joined by software and system designers.

Inclusion of external IP may also cause the IP vendor to be incorporated into the team to fix bugs or add features. These external dependencies create an extra level of headache for the integration team.

There are other stakeholders who are not directly involved in the design process.

  • Management is keenly interested in determining how the design is progressing so they can assign resources and manage risk accordingly.
  • Customers may need advance releases of software or device models for their own product development.

SOC design team members and stakeholders are frequently distributed worldwide. This puts an additional burden on inter-team communications in the form of time zones, information transfer, physical infrastructure and network costs

Globalizing the Collaborative Environment through Workspaces

A critical success factor of a team design is the ability to achieve efficient collaboration and communication between team members. The IC Manage Global Design Platform utilizes workspaces to provide the information sharing needed for collaboration. A workspace can present the particular state of a slice, a partitioning or the entirety of the project. At any point in time a user may have one or more active workspaces. The contents of each workspace are private to a user until committed. At this point the information then becomes public and is available to all other workspaces that need the same portion of the design space.

With GDP, workspaces can be configured so they only present those parts of the design relevant to each individual user. This keeps the contents of the workspace clear and directed to the user’s work at hand.

IC Manage’s Global Design Platform natively supports multi-site projects. The source of a workspace’s data is opaque to the user. The logical structure that the user works with is distinct from the physical structure used to populate the workspace.

Changes made to the underlying network or storage infrastructure are transparent to a project’s workspaces. In a world where a single project’s design teams are spread over the globe this level of independence eliminates disruptions due to infrastructure changes or resource reallocation.

Further, IC Manage proxy servers and read-only replicas address the real world effects of long latency network connections. Fail-over servers and back up replicas eliminate downtime and disaster recovery issues. These features contribute to the overall risk reduction that IC Manage brings to a project.

Before a collaborative environment of workspaces can be established, the content must be organized and structured.  IC Manage GDP provides flexibility in allowing choices in how to structure the design space.

Design Partitioning by Data Type

The design space can be partitioned according to the data’s functional category. The first step in this organizational approach is to identify the data types used and their relationships to the team. Frequently this determination is a natural and obvious choice. For example in the following:


  • A SystemC data type would likely consist of source code for system models being used by the system architecture group.
  • An RTL data type would likely consist of text files of Verilog or VHDL. Its primary users would come from the RTL and Logic
  • Schematic and Layout data might be binary data from a schematic capture tool from an EDA vendor like Cadence, Synopsys or Mentor. Again, a particular data type is applicable to specific functional groups: Schematic data for the Logic, Circuit and Layout

In some cases, separation into data types is not so natural. An IP library provided by a vendor may contain all its data in a single package. The IC Manage Global Design Platform is flexible enough to handle these packaged sets as well.

Partitioning Design Space by Design Unit

In many cases a single functional group does not take ownership for all the tasks at their associated subsystem. A common example of this is found in lower levels like Layout. Here the design space might be separated into physical regions, like a group working on a data path, another on bus interface and yet another dealing with the integration of the full chip.

Another example is a logic group where part of the group is responsible for the RTL model used for simulation and verification while another part of the group deals with the logic synthesis. Here there is not only segmentation within the RTL data space but the synthesis group must deal with data outside RTL altogether such as timing or space constraints.

The SOC may be covered by a mosaic of groups working on their assigned sections. For example:


Three logic groups are assigned functional units: Arithmetic, Bus and Memory. The Synthesis group needs to work across all the units on the Control subsystems.

GDP supports this kind of partitioning by allowing data sets to be organized into libraries. The libraries are derived from a data type, like a Cadence layout data or RTL source. The library contents library can be an arbitrary set of directory trees.  Collections of libraries may be mixed and matched when constructing workspaces.

Change-Driven SOC Design

One of the most powerful aspects of a project under GDP is that the data management system is aware of all changes as they occur during the project. It provides a framework for triggers based on changes that can be used to generate notifications or actions to respond to the changes.

For example, if a section of a design has been declared ‘done’ it is critical that any changes that could affect that section be evaluated. This early notification mechanism allows the issue to be resolved with much less effort than waiting for detection by verification at a later stage.

IC Manage provides command line, GUI and tool based utilities for working with design changes. Each workspace is a private copy of a shared design space. At the lowest level, operations like add, delete, move, sync and submit can be applied to the workspace contents. Queries can be made to find out things like which objects are opened, are out of date or their history.

Using GDP for Custom IC Design:
Cadence Virtuoso Illustration

An example of how IC Manage GDP is deeply integrated into a custom IC design flow is shown on the screen-shot below of GDP’s integration with Cadence Virtuoso. It retains the same look and feel as the original component but adds design data management information in a concise and intuitive form.

The following set of screen-shots shows the GDP’s Cadence library manager in action. Here the schematic opamp_adc is shown having two committed versions.


After checking out the symbol, it becomes editable (the little red in the cell view icon):


Submitting the change can be applied to the individual cell view or through a check in dialog. The dialog displays all currently editable or added objects. Any and all subsets of the objects can be selected for submission as a group. After check-in the window shows that the new current state of the cell view is version 3 of 3 and the check mark has vanished from the icon:


Right clicking on a cell view entry brings up a pop-up with various options, one being to query the symbol history. As show below, both versions and their change numbers are displayed:


Any history item can be selected and the symbol can be restored to that state within the workspace. In fact, the workspace or any part of it can be changed to any committed state within its entire lifetime. This capability can be useful for team members to investigate and communicate about the effects of a change.

The True Variant Info pane shows our opamp_adc in the library opamp_int originally came from the library opamp.

Managing Digital Designs with GDP

Many digital design tasks require multiple iterations over various design stages. For example, several runs with logic synthesis are needed to investigate how RTL or timing changes may affect the results.

Each logic synthesis run is the result of a variety of file types comprising an input state. GDP’s flexible directory structure easily allows the entire set to be associated as a group used to produce a particular solution.

GDP makes it trivial to save promising candidates while continuing the design exploration. Designers can then restore the best solution of the set as the basis for their next iteration towards the final design.

Managing Verification Changes with GDP:
JIRA Illustration

All stages of verification suffer from two major problems.

  • Identifying changes (e.g. bugs) that trigger a new round of verification and communicating the results back.
  • Creating a verification environment while its input design state is constantly changing.

A typical verification environment consists of a set of validation models and a regression farm of servers to run tests against the models. A subset of verification runs may happen nightly while a full set is done weekly. The contents of the run sets are statically allocated. This means that when a particular model state is not appropriate for a run at that time, the verification run can generate false errors which must then be evaluated.

IC Manage can improve this process by enhancing bug traceability. For example, in the following:


The change Ci in the design initiates a trigger which then identifies the regressions applicable to the change. It then updates a set of workspaces, W1 and W2, in the regression farm and initiates their runs. Only meaningful runs are performed, providing better utilization of regression farm resources and minimizing the number of false errors to investigate.

An IC Manage supported bug tracker such as JIRA allows the design state to be bound to identified bugs. In the case where the test itself was initiated by a change this process can be completely automated. The designer can then view the bug and trivially move their workspace to the design state when a specific bug occurred to confirm and fix the issue. Committing the fix will then cause the verification cycle to repeat – verifying the fix and allowing the bug to be closed.

Below shows a defect being resolved:


Here an integration build had failed due to a bug in a vendor library. The defect was fixed locally and tested to confirm the fix. This allowed work to progress pending an official response from the vendor. The defect was ultimately closed with a vendor update recorded in change 16124. The defect-to-change binding permits workspace synchronization based on defect state for improved test and verification productivity.

The problem of obtaining a verifiable design while design groups continually submit changes local to their own section can be very challenging. With the Global Design Platform this is solved by allowing the teams to have their own shadowed versions of the design. These shadows are derived from the real design but let other groups pull in selected changes to create islands of stability for large scale testing, parameter extraction or other time consuming operations.

Monitoring Project Progress

The change driven nature of the design provides ample opportunities for defining metrics to monitor progress. Some examples of what you can do with filtered change scripts with GDP are:

  • Creating a script to plot defect numbers over time by filtering a design change stream for defects.
  • Producing defect histories over specific subsystems via additional filtering.
  • Producing metrics about the activity in particular sections. You can use such information to help determine when work in a section is winding down, potentially allowing team resources to be deployed elsewhere.
  • Gathering statistics to determine the correlation between changes in one block with respect to other blocks to better determine where a fix should be implemented.

Handling Design Releases

Following design completion, the chip will be sent to manufacturing, and often there will be issues to be dealt with. An SOC is also likely to have a continued existence as a shrink or bundled into an IP block of its own, in whole or in part.

To create a release with IC Manage GDP you simply create a read-only snapshot of the design state.

Managing IP and Derivative Designs

You can continue with further development on the original design. If you then find a bug in the release, you can open an editable copy to fix it. You can also choose to propagate the fix back into the evolving original design, if so desired.

Producing a literal derivative is nearly as simple as creating a release, the primary difference being that the derivative is an editable copy. You can also pull bits and pieces out of a design for use in a completely new project:


In all cases the derivative still retains the knowledge of its ancestor so that fixes and changes can be moved freely between them

Managing Third Party IP

External IP is traditionally delivered as an opaque bundle; the design teams get a snapshot of a vendor library. If present, any information about changes in the IP from one version to another is contained in form of release notes. This makes it difficult to understand and deal with changes between vendor releases.

The 3rd party vendor’s IP can be brought into GDP and a new release can be associated with a prior release. This makes explicit which items have been added, deleted or changed between different versions. It also makes it easy to switch between items in differing releases to diagnose problems between versions.


The technical and business goals of today’s SOC design projects requite tight collaboration across diverse teams, often across multiple geographies. IC Manage’s Global Design Platform provides the foundation for hardware-software co-designed SOC projects by streamlining the information flow and hand-offs between design layers and team members.

A project is no longer and entity unto itself. Its release and derivatives must be intimately bound with their sources for true derivative management through the product life cycle. GDP maintains knowledge of the design object relationships, carrying attributes as the objects evolve so that derivatives can be managed and tracked.

Function-specific workspaces are an excellent method of allowing team members to localize their own work on the project while enabling their ability to view and interact with others in a controlled fashion. The incorporation of design data management and change-based design techniques  can produce great efficiencies by automating many design tasks and only performing them as a consequence of a change.

GDP can be used for digital and custom IC design with tools such as Cadence Virtuoso to improve designer efficiency with  regards to reliable release, configuration, IP and derivative management. It is also well suited to producing project metrics and evaluating progress.

About IC Manage

IC Manage, Inc. provides a high performance, scalable, reliable design management system for IC design data across global design teams. IC Manage Global Design Platform (GDP) is a comprehensive set of tools and configurable work flows to improve product quality, designer productivity, team collaboration, bug tracking, and IP reuse and management of derivative designs. GDP also include built-in IT capabilities such as hot backup, high availability, and disaster recovery for 24×7 enterprise availability. For more information, please go to:

Roger March is Chief Technology Officer for IC Manage, Inc., where he was a key architect of their current design data management solution and continues to improve its performance and scalability for global multi-site use.