Implementing a Design Reuse Methodology
Using a Design Data Management System
Samir Palnitkar, Chief Technical Officer
Integrated Intellectual Property Inc.
1765 Scott Blvd, Suite #208, Santa Clara, CA 95050
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.
- 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.
- 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.
- 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
- 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.
- Managing IP design data This section discusses
how we handle IP design data.
- 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.
- 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.
- IP Development Methodology
This section examines the various aspects of our development methodology for
new IP cores.
- 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.
- 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
- 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
- Block Diagrams
- File Hierarchy
- Description of Deliverables
- Description of the user interface
- Timing diagrams
- Description of synthesis scripts
- 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 others 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
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
- 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
- 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.
- 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.
- 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.
- 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
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.