Parallel development is an essential technique for boosting the productivity of big software development teams that must make numerous changes to a large source-code base. To employ that technique, software engineers use sophisticated tools and procedures to manage parallel development tracks. These tools help developers manage multiple versions of their code, facilitate ports to different platforms, and manage the stream of bug fixes.
Now hardware designers face similar problems, in addition to some new troubles unique to system-level hardware development. The solutions to these problems will derive from the lessons learned by their software brethren. In the course of creating a complex hardware design, a team may create hundreds of thousands of files, but send only a small portion of them to the fab for tape-out. Without an effective revision control system geared for parallel hardware development, grave mishaps occur with an unfortunate regularity in the industry. (Consider, for instance, the loss of an entire mask set worth a half-million dollars, and three months of additional development time simply because someone grabbed the wrong file.)
By taking advantage of parallel development techniques, hardware designers can effectively address complex development-supply-chain (DSC) management issues. These DSC issues include employing and managing virtual design-team members spread across numerous geographic locations; creating multiple variants of the same design; using externally sourced semiconductor intellectual property (SIP); porting designs to multiple foundry processes and libraries; and the need to start on the next design before the current one is finished.
Most hardware developers force-fit generic software-oriented shareware tools, such as Revision Control System (RCS) or Concurrent Versions System (CVS), into their hardware development environment.
RCS manages multiple revisions of text or binary files. It automates storing, retrieving, logging, identifying, and merging revisions. Useful for files requiring frequent revisions, such as programs, documentation, graphics, papers, and form letters, RCS is widely used on Unix operating systems.
CVS is an open-source network-transparent version control system. It's useful for both individual software developers and large, distributed software teams. Based on a collection of shell scripts written by Dick Grune in 1986, the present version was designed and coded in 1989 by Brian Berliner and Jeff Polk.
These tools don't address the numerous problems specific to hardware design environments, though, or provide any type of multisite access solution. Moreover, managing and maintaining a custom version of shareware requires spending extensive time and resources—an effort that doesn't reside in the company's core business.
EDA tool vendors' attempts to supply parallel development capabilities for their tools have also fallen short. These programs work only with the particular vendor's tools and data. This poses a significant problem, because the typical design flow may incorporate 50 or more tools from a dozen vendors. Cadence's Team Design Manager (TDM) is one such case. Although reasonably effective for the company's files, TDM is less successful in a multivendor tool flow. (Ultimately, Cadence contracted with Synchronicity to develop a solution for tools that support parallel development.)
In lieu of ad hoc internal solutions, a suite of tools from Synchronicity lets hardware developers manage the parallel development of hardware, firmware, and software across geographic and corporate boundaries. The suite comprises three complementary elements: DesignSync, ProjectSync, and IPGear.
DesignSync provides revision control, workspace management, and process management through a client-server architecture built upon Internet standards and protocols. The branching and merging capability lets design teams create development branches for new, old, purchased, or unproven intellectual property (IP). Then when it's ready, the hardware description language (HDL) is easily remerged back into the mainstream product or derivative product, as necessary.
ProjectSync supplies the features needed for managing all tracking and communications of a system-level hardware design project. These features include configurable panels, triggers, access controls, and a built-in e-mail notification engine. ProjectSync is tightly linked with DesignSync's revision control features too.
One feature, IPGear, offers a comprehensive enterprise-design-reuse infrastructure and supply-chain management facility. A virtual corporate IP repository, IPGear delivers the benefits of design reuse across the enterprise, including business-to-business collaboration in the electronic-development supply chain.
Revision control, branching, and merging: The hardware design community has traditionally employed a serial design methodology that requires each designer to obtain a unique lock on a file before making changes to it. Although this serial development style lets other users fetch reference copies of the data, they can't change the data until the first designer releases the file. In contrast, parallel development techniques permit creating and managing so-called revision branches. This approach lets numerous designers work on the same data simultaneously, and then merge the desired revisions back into a single file (Fig. 1).
One of the greatest obstacles with respect to deploying parallel development techniques in the hardware arena is the variety of data formats produced by hardware design tools. Many of these data types can't be merged using typical merge algorithms, making parallel development impractical. This is especially true of the binary files created by many back-end design tools. The trends toward using high-level HDLs such as Verilog and VHDL, and implementing C code for hardware modeling and test benches, have paved the way for effective parallel hardware development.
In its simplest form, DesignSync's parallel revision control re-quires each user to log onto the server with an appropriate password and "check out" the particular file on which they plan to work. DesignSync can automatically create a "branch" for that file, noting the origin or "parent" for that branch, and keep track of all changes that the designer makes. Other designers can check out the same file too, if the system is set to create a separate branch for each designer. After a designer has finished working, he checks his file back into the server.
If, at some point, two designers or more decide to merge their changes into a single branch, DesignSync identifies the "contributors" to the merge: the parent, or common source for the branches, and each new branch. DesignSync next employs a merge algorithm to calculate the deltas from the parent to each branch, and adds them back into the parent. The software includes graphical tools that help resolve potential conflicts during merge operations (Fig. 2).
This branching and merging ability offers numerous benefits to the hardware development process. The first and most obvious advantage is the increased productivity from multiple designers simultaneously working on the same files without conflict. The tool suite makes this particular benefit more accessible by employing an Internet-based client/server architecture.
One of the most powerful applications of branching for designers might be performing "what if" analyses on specific parts of a design, without interrupting the primary development effort. The designer can experiment and simply merge the best new design changes into the main design. Or, possibly a designer has created a new feature on a separate branch, but the company decides not to incorporate the feature in the present release. By saving the branch with its entire history and all changes, the company can incorporate the feature into a future release.
Another scenario where branching offers substantial benefits arises when a company must support an already released design that's now in use by another design team or customer. Invariably, the company will discover bugs in the original design, while development continues on the new design for the next release. Instead of making fixes into the branch with the new release, where changes to the design may not have stabilized, the designer can apply fixes directly to the released version of the design and verify the changes in a known environment. By creating a separate branch for the released version, the designer can first verify the fixes on the released version, then merge the now-proven fixes back to the development branch to prevent their loss in the next new design release.
At a higher level, branching and merging can provide the basis for more-efficient design strategies in complex hardware design projects (Fig. 3). Branching flows naturally when the design manager partitions the design into specific blocks and features. Each block can form its own branch. These branches are merged into the main design of the chip upon their completion. This way, the manager can track the design and verification progress for each branch, determine where the development is lagging, and decide where and when to assign additional resources to keep the project flowing smoothly.
Security: Customers can use the tool suite within the corporate firewall over local- or wide-area networks, as well as over the open Internet. To ensure security when venturing outside the boundaries of the corporate firewall, there's full user authentication and Secure Sockets Layer (SSL) encryption for transactions that take place over the open Internet. Users stay securely connected to all relevant design data management issues and project team communications, even when traveling or accessing the Synchronicity server(s) remotely. Additionally, the tools compress data as it travels between client and server. Using compression and encryption together ensures each transaction's security and efficiency.
A Design Example
Perhaps the best way to view the full value and impact that parallel development can have on hardware design is to construct a virtual scenario of complex design management issues—a sort of design manager's nightmare. For our design example, we'll create a system-on-a-chip (SoC) development team tasked with building an extremely large, state-of-the-art, system-level ASIC.
As usual, the end-system delivery schedule is very tight, placing enormous pressure on the company to assign as much resource as necessary to finish the ASIC on time. Therefore, the design team is quite large, with over 100 team members dispersed across four geographic locations in Asia, North America, Europe, and the Middle East (Fig. 4). Each site requires collaboration with its coworkers in the other locations. The project also requires using consultants for specific design expertise lacking within the in-house design teams. These consultants reside in completely different geographies and may never work at any of the corporate sites.
Portions of the ASIC must incorporate third-party SIP and internal legacy SIP from a previous design. Typically, the SIP won't be usable "out of the box," but its use is absolutely essential from both a functional and time-to-market standpoint. The ability to reuse the SIP, while at the same time modifying it for improvements in power or speed, is essential for this design.
The marketing department, which has done extensive research on the size and facets of the market for this system, has convinced management to embark on a multitiered price/performance strategy. This means that the design team will eventually have to create and maintain multiple variants of this ASIC design. The team must be prepared to add new features to the design, create faster versions, and even spinout some low-power variants. Thus, the design environment must support the management of all variants of the design at the same time.
Implementing a parallel development infrastructure: Creating such an infrastructure requires installing a design data-management system that provides each team member with secure, controlled access to the design data—regardless of where they're physically located. This design management system is ideally based on Internet or Web-based architectures. Clearly the Internet is the most efficient way to bring up, support, and reconfigure a multisite environment quickly and easily worldwide. The design-data management system must supply the productivity and flexibility benefits inherent in parallel development too. The designers need to work on many facets of the design concurrently without affecting the work of others.
Finally, this collaborative infrastructure must provide a project-tracking capability, including defect and issue tracking. This part of the infrastructure should be Web-based and integrated into the design management system, so the system can be completely browser-based and available to any authenticated user on the Internet.
Creating a parallel hardware development strategy: As usual, this SoC will be composed of a multitude of individual function blocks and subsystem multifunction or multiblock modules, integrated to perform the specified system-level functionality.
Each block or module is decomposed into subpieces (blocks, modules, subsystems, and so on), and ownership of each subpiece is assigned to the teams. Next, the hierarchy from the top level of the chip to each subblock (and sub-subblock, etc.) is constructed via the tool that will manage all of the data. This defines the hierarchical partitioning of the design data, which must be known to the data-management system.
At first, all blocks making up the design will be developed on the same branch as all other blocks. Let's call it the "main" branch. Once a working skeleton or top level of the design is defined via the specification, then branches come into play. Most, if not all, blocks won't be functional at this time. But they will have their interfaces defined, so the hierarchical composition of the design and how the blocks fit together are well understood.
A key block, such as the top level of the chip, may have all changes developed on the main branch, because all teams need to work with the latest version of the top level. For subblocks in the design, the various teams and members would start developing independently on a separate branch (call it "development") so their changes wouldn't be picked up by, for example, the team responsible for the top chip level. The top-level team periodically (maybe as frequently as every day) picks up newer versions of each subblock that have been checked into the main branch for use.
Once the subblock team has a working version of the block that they want others to see, they merge that subblock from their development branch to the main branch. At some point, the sub-block might become frozen for use by another design team. A separate "release" branch would be created for the subblock so necessary fixes to the frozen version of the block can be made in parallel to further work on the development branch or the main branch.
Due to all of this block-level interaction and interdependency, problems will inevitably arise with one or more blocks on the design. This requires multiple-team support and careful documentation of the problems encountered. ProjectSync tracks issues that occur during development.
Benefiting from ProjectSync's Web technology and integration with the design-management database, the team manager links the actual design files (and branches of design files) associated with an issue directly to the issue itself. In addition, ProjectSync saves the threaded discussion involving the affected engineers in a relational database for future reference. This is very valuable to the company for the long term because teams usually conduct these discussions through e-mail, which is essentially lost when an employee leaves the company or a consultant's contract ends.
Furthermore, by using keywords and multiple databases within ProjectSync, the team can manage bugs and defects, design issues, EDA tool issues, vendor issues, and so forth. This is all accomplished using the same tool with multiple databases—all easily accessible from the ProjectSync interface—from all locations over the Internet in a secure manner.
Managing the SIP supply chain: As mentioned earlier, design reuse is a fundamental requirement for this project. The team needs a seamless way to assemble and maintain a corporate IP repository. That repository provides enterprise-wide access to up-to-date revisions of internally developed IP. The team manager also needs to keep track of which engineers worked on each revision and manage the identification, evaluation, procurement, and implementation of externally sourced IP. The team chooses IPGear.
The IPGear Catalog is a convenient mechanism for finding and inspecting IP components from one's Web browser. A designer uses the IPGear Catalog to identify a new version of a particular IP block. The block's specs more effectively match the project's requirements than one of the company's legacy IP blocks. Comparing the performance of this block to others found and displayed in tabular form by the IPGear Catalog, the team decides to download and evaluate the block directly over the Web from the IP vendor's site.
This team downloads the IP on a new branch using a vault-to-vault transfer from the IP vendor's DesignSync vault to the company's own vault using IPGear. Because DesignSync implements Web technology, the transfer is fully secure and encrypted. The evaluation looks good. The team verifies that appropriate functionality is present, and the available regression test suites determine that the new features work as advertised in simulation. The team assigned to that block merges the new IP onto its branch and continues working. If for some reason the IP hadn't passed evaluation, the team would have notified the IP vendor via a problem ticket on the help-desk site and left the IP idle on the branch.
Two weeks from tape-out, the third-party IP vendor discovers a bug in the particular version of the netlist and test vectors that team scheduled to tape-out. The design manager and the designer working this branch automatically receive notification of this problem through IPGear e-mail.
Because both the IP vendor and the design team are employing DesignSync, in one command they download only the (correct version of) files that need updating into the appropriate project branch. They don't waste time sorting through an entirely new distribution tar (tape archive) file of the vendor's IP. The team manager creates a new branch and runs his verification suite. Now having successfully passed the IP block-level verification and timing tests, the design manager integrates the new release onto the mainline, the final regression is run, and the tape-out can happen on time.
Complex HDL-based SoC IC development can benefit tremendously from software-style parallel development techniques. This level of hardware complexity demands Web-based multisite support to facilitate parallel development activities across geographic and corporate boundaries. In addition to meeting these requirements, powerful, yet easy to use HDL design management, project management, and IP management tools are necessary. Thus, Web-based tools that perform these functions are a powerful addition to a company's EDA toolbox.