Development for Design Reuse is a critical challenge facing design houses and semiconductor vendors today. Designs are broadly classified into two categories: legacy designs and current designs. For the past decade, companies were focusing on creating a design and getting it to work for their immediate product. However, with a shift to the "system-on-chip" methodology, it has become crucial, for competitive reasons, that every design be done with an "IP paradigm" or "Design Reuse" in mind, so that it can be integrated quickly into a larger system-on-chip. However, this approach requires a completely different methodology and mindset.

This paper explores the details of a complete IP methodology that revolves around development standards, scripts, release mechanisms and shrink-wrapped packaging using "SOS", a software system for design data management.

1. Introduction
   1. What is the IP paradigm?
      Traditionally, chips have been designed with a goal to get them to work. Engineers pay lots of attention to aspects that are very specific to a particular project. However, often engineers do not look beyond the horizon of the current project. Due to faster chips, increased competition and shorter design cycles, companies have been forced to reevaluate this narrow vision. Therefore, it has become imperative that each company does the designs in such a way, that these designs can not only be used for the current project, but also for the future projects. This approach requires engineers to build every design as a synthesizable core. We call this the "IP paradigm".

      Companies need to design with the IP paradigm so that they can be competitive in the marketplace. Design cycles are becoming increasingly shorter and levels of integration are rising exponentially. If a company does not move to an IP paradigm, it will be left with costly products that are late to market. In addition, the structured approach will help designs to be done much quicker.

   2. How does it affect the design process?
      The first time the block is being developed, engineers need a very structured methodology that promotes design reuse. It takes a little longer to set up the methodology. However, once it is set up, the process of design creation is a lot more efficient and methodical. There is less confusion about how the design tasks are partitioned and engineers can work independently to get their blocks working before integrating them into the design.
   3. How is it applied to legacy designs?
      Legacy designs that have not been designed with an "IP Paradigm" will need to be converted over to an IP methodology so that these designs can be reused within the company or sold to other companies. We currently use a "cleaning room" methodology to clean and package existing IP.
      
      
   4. How will it be applied to new designs?
      New designs will have to be developed as synthesizable cores. They will then be converted to silicon for a specific project. The project thus becomes an internal customer of the synthesizable core. The core can also be sold to external customers.
      
      

       

2. Managing IP design data This section discusses how we handle IP design data.
   1. Handling Design Complexity
      Designs are increasing complex. Multiple engineers have to work together on the same design. It is not only important to keep track of the HDL files that make up the design but also all the test benches, make files, scripts, stimulus, and other data files necessary to verify and synthesize the design. So a design may be made up of hundreds or even thousands of files. The burden of managing this data is even more complicated for IP design. You also have to deal with making multiple releases to customers and making patches to old releases. Sometimes you may also have to do special enhancements for some customers. In order to effectively manage IP design data we need to:
      • Manage many hundreds of files spread over multiple directories.
      • Revision control all source files.
      • Have multiple engineers work collaboratively.
      • Make sure that only lint free HDL files are checked in.
      • Allow different engineers to work on different activities such as verification, synthesis, release, patch, etc. concurrently.
      • Make high quality releases and track the revisions of all the files and directories that make up a release.
      • Recreate any previous release exactly with the same directory structure and revision of files so customer problems can be replicated.
   2. What is SOS?
      SOS is a graphical design data management product from ClioSoft, Inc. (http://www.cliosoft.com), which we have used to effectively manage IP development and release over the past year. SOS has helped us enhanced the productivity of our design team and improved the quality of our product.

      The graphical nature of the tool and the simple usage paradigm makes it very easy for new engineers to get started on a project. It has a centralized and secure design repository and provides revision control, manages directory hierarchy and tracks releases. Each engineer works in her/his own work area or sandbox, which is created through SOS by specifying a rule to select revisions of files. This allows one engineer to work on the latest enhancements while a second engineer is creating a patch release and a third engineer is running a long synthesis job concurrently without affecting each other.
      

      
      

      In addition to the visual representation of the entire project SOS has a set of flags, which automatically improve collaboration and quality. Furthermore, the customizability of SOS allows us to automatically run Verilint before a verilog file is checked in. Due to these collaboration features our engineers never lose time struggling with common errors like tracking down who forgot to check a file in or added changes which are not lint free. When making a release we know exactly what we have and that all previous patch fixes have been incorporated into this new release. The following figure shows the data management of a complete AGP/PCI IP development system.

3. IP Development Methodology
   This section examines the various aspects of our development methodology for new IP cores.
   1. Design for reuse
      This step is the first part of our reuse methodology. In this step, there is a lot of planning before, we actually do any coding or implementation. We plan for each step of the following methodology.
      

1. Code review
   The next step is a code review. This is done mainly for the RTL code and the synthesis scripts. The project manager goes over all the code and scripts with the engineers to look for:
   • Coding errors
   • Design errors
   • Architecture and partitioning
   • Coding
2. Documentation standards
   Strict documentation checklists are maintained for the IP. Documentation for each IP block should contain:
   • A template for formatting the entire document. This makes all IP documents look uniform.
   • Block Diagrams
   • File Hierarchy
   • Description of Deliverables
   • Description of the user interface
   • Timing diagrams
   • Description of synthesis scripts
3. Versions and file management with SOS
   A design under development consists of many files spread over multiple directories. SOS manages this hierarchy of directories and lets you control the whole project. You work in your own sandbox or work area created through SOS. You select the directories you are interested in and SOS will create the directory hierarchy and place a read only version of each file in the appropriate directory. You specify which revision is to be placed in your work area by setting up a revision search rule in SOS.

   SOS uses the normal checkout-modify-checkin paradigm. When you have a file checked out, a write-able copy of the file in placed in your personal work area and a lock is placed to notify others that you are editing this file. You edit and debug your changes in your own work area. When you are satisfied with your changes you check the file back in and a new revision of the file is created. If you must edit a file that is locked by another user (usually a test bench) then SOS allows concurrent checkout with an automatic merge capability to allow both of you to make changes without overwriting each other’s changes.

   With SOS you not only revision control files but also revision control changes to directories like adding, deleting, or renaming files. This gives you the flexibility to rearrange your directory structure or rename the files while still being able to recreate previous releases with the old directory structure.

   SOS allows you to setup design processes through user define-able triggers. To improve the efficiency of our team and to maintain the quality of our design we have setup a trigger to automatically invoke Verilint on all verilog files. Check in is not allowed if Verilint reports any errors. This avoids unnecessary team down time, which may be caused if files with errors are accidentally checked in.

   We use symbolic labels or tags on revisions to communicate the status of a revision. A revision of a file ready for simulation is given the tag ‘simulates’. A revision of a file ready for synthesis is given the tag ‘synthesizes’. An engineer who wants to simulate can use a revision search rule to select revisions of files with the tag ‘simulates’ and an engineer trying to synthesize can ask SOS to search for the tag ‘synthesizes’. This eliminates ad-hoc means of communication like email which are very error prone.

   Your work area maintained by SOS provides a stable environment for you to work in. You control when changes made by others are brought into your work area. This allows you to run a long simulation or synthesis job without being affected by modifications being checked in by other team members. Similarly you can work on creating a patch for a previous release without affecting ongoing development. The alert icons in your SOS window are periodically updated to show you what changes have been made to the project without actually bringing those changes into your work area. If you now choose to update your work area your revision search rule is applied again to get the latest changes made to the project into your work area.

   A neat feature in SOS is the ability to rewind your work area to any given time. No matter how careful our engineers are someone is liable to check in a file that causes a failure. With the number of files and number of changes happening it is sometimes hard to guess what may have gone wrong. Using the rewind feature you can set the work area back in time until the problem no longer exists and you can continue your work. It also helps you isolate the problem. This further helps us reduce team downtime.

   When an IP is ready to be shipped we take a snapshot of the project in SOS and give the snapshot a meaningful name. This places a fixed tag on the current revisions of all the files and directories in the project. Development can continue to the IP. If a customer later reports a problem we can easily recreate the development environment used for the release by using the snapshot name as the revision search rule. Not only does SOS get all the right revisions of files for this release into your work area it exactly recreates the directory hierarchy. So all our old makefiles and scripts work and we can quickly reproduce the problem. We can then fix the problem and send out a patch fix while other team members continue with normal development. The figure below shows how a snapshot is taken in SOS.

   
4. Components of a release environment
   The release environment contains the code that will actually be shipped to the customer in the appropriate format. All the IP releases are sent directly from the release environment. A release environment should contain the following components for each IP block.
   • A script to copy from the development environment to the release environment.
   • A directory to hold the IP block. This block should contain subdirectories for RTL source code, synthesis scripts, simulation scripts, testbenches and documentation.
   • A directory to hold the verification environment for the IP in the release area. The scripts in this directory should simulate the IP package completely in the release area.
5. Partitioning between development and release environments
   The release environment and the development environment are totally separate. The development environment has a different directory structure that is good for development. Yet a completely different structure is required for a user release, because the IP is packaged differently from the point of view of a user.
   
   

   The advantage of this approach is two-fold:

   • The files do not get written to the release, until the developer is ready to freeze his development. Thus, a user gets code that is stable and completely verified in an area that does not assume any preset parameters in the development environment.
   • The developer does not have to worry about keeping files in the same way that the user will see it. The developer can create a structure that is most convenient for him.
6. Maintaining versions in a release environment
   Each version in the release environment is created only when the developer is ready to freeze the development of an IP block. Detailed reports for bugs and fixes from the previous version are created. We take a SOS snapshot of the development environment and name it so that we can relate it to a release version. A record of the changes in each release version is kept. The following figure explains how versions are kept in a release area.
   
7. Releasing code to a customer
   The code is released to the customer in form of a data tape or ftp-ed to their site. The release contains the following items:
   • Installation Scripts
   • Installation Manual
   • IP Release
• Conclusions
  Designing with an IP paradigm requires discipline and methodology. Once the methodology is set up, the IP can be transferred to either an internal project or an external customer with equal efficiency. A company that designs with the IP paradigm is more likely to proliferate its designs by integrating them with other IP blocks and creating cost efficient chips. SOS from ClioSoft, Inc. has helped us manage the entire IP methodology with efficiency.