Hierarchy Spells Order For SoC Data-Management Tool

Increasingly, system-on-a-chip (SoC) design is a discipline that requires its practitioners to look, at least during some parts of the design process, at the big picture. Certainly, at times, it's necessary to drill down into small segments of the overall design to examine them in detail. But the whole point of system-level design is efficiency, which is borne on the wings of design reuse.

Design reuse is a great concept that should make the creation of complex SoCs much easier. It also depends on that "big picture" view of the design process and asks the designer to think in terms of blocks. This is a natural view of designs that best enables engineers to handle a very complex SoC.

Thinking about a design at the block level is one thing, but managing the mountains of data comprising the design in that fashion is another. When one considers that today's design teams are global and multi-organizational in nature, the problem takes on another dimension of complexity. SoCs are created using a mixture of newly developed IP blocks, reused internal blocks, IP licensed from other vendors, and blocks designed by other organizations under contracts (Fig. 1). All of this information quickly mushrooms into a management nightmare without the proper tools.

Design data-management tools aren't a new idea, but to date, no tools have organized SoC design data at the block or hierarchical level. Existing tools manage data at the file level without maintaining the connections between files that constitute a given block within the overall design. But Synchronicity Inc., Marlboro, Mass., has come up with the missing link that ties its own file-based data-management tools together in a suite that takes design data management up to the hierarchical level.

The Hierarchical Configuration Manager (HCM), when used in concert with Synchronicity's existing DesignSync, ProjectSync, and IP Gear tools, manages all data associated with an SoC design project from a hierarchical perspective. Beyond this, it tracks the communications between far-flung team members, and solves the problem of accurately recreating design hierarchies at any point in the past. It also manages the versions and customizations of the design tools used to create the design.

Management of the files associated with a given SoC block is itself a daunting task. The end product is the physical design files, of course, but thousands of files can be associated with the creation of one IP block. These can include synthesis files, schematic captures, architecture documents, and much more. But a change to given files within this entire mass of information can cause a ripple effect that propagates upward throughout the design hierarchy. The HCM keeps that information up to date and correct for all users.

The tool doesn't simply keep track of all current versions of the files related to an IP block. Most of what the tool does applies to an entire hierarchy of linked blocks. This includes retrieving data from a central repository, committing changes to share with others, or creating a snapshot of a design that can be worked on at any point in the future.

All of the files comprising each block are revision-controlled automatically, or can be worked on individually with DesignSync, Synchronicity's file-based data-management tool. With HCM placed atop DesignSync, and by making use of DesignSync's built-in Web-enabled multisite capabilities, any block in the hierarchy can be defined and managed by any design team, whether it's intracompany or intercompany.

Also through the HCM, the concept of design hierarchy is brought to bear in Synchronicity's ProjectSync tool. A collaboration tool, ProjectSync enhances design-team productivity by allowing the sharing of up-to-date ideas, issues, bug reports, engineering-change information, and much more via a standard Web browser. The HCM and ProjectSync combination lets a project manager determine, for example, the number of open issues related to an entire design hierarchy. Managers can also be notified when any block in the design changes.

Embodied within the HCM is the important ability to create dynamic references to sub-blocks within a block, which greatly helps to reduce administrative updates. The referenced sub-block can change without the upper-level block having to change the reference. For example, you might have a top-level block for a CPU subsystem that references version 1.0 of the CPU sub-block itself. Rather than having to change the reference to that sub-block when version 1.1 comes along, HCM allows the design teams to define a "golden" configuration (or whatever terminology they prefer). Then, the top-level block can refer to the "golden" version of the CPU sub-block and always pick up the appropriate version.

HCM would also alert users when their local "golden" version of a given sub-block is out of date as the owner of the overall block creates a new version of the sub-block. With this capability, complex design hierarchies can be created while HCM continually and automatically tracks the ever-evolving configuration of blocks that make up the hierarchy. In the process, project managers and their teams avoid incurring the overhead of changing references between a block and its sub-blocks as changes occur in the sub-blocks.

References may be made between any blocks, libraries, tools, and scripts that are under configuration management by the HCM. References can be made to blocks stored at other sites inside or outside the designer's company. This flexibility permits the management of a complete design hierarchy, along with the blocks in the design. In fact, even if a block is under management by other Synchronicity tools, such as DesignSync or IP Gear, users can create references to them. These references could be made to data from these tools even when using an older version of DesignSync or IP Gear without HCM installed.

Another critical function performed by the HCM is the creation of immutable snapshots of the design, which can be returned to or recreated. A snapshot may represent a major breakpoint in the design, or be created at a tapeout version or final production release. When a design is released hierarchically, any dynamic references to sub-blocks are resolved such that they're made static. A static reference always resolves to the same configuration of a block. Once a design hierarchy contains only static references, the hierarchy is considered immutable.

Releasing a snapshot doesn't stop changes to the design originating from the released hierarchy. But the designer or project manager can always be assured of getting back to that snapshot that defines the released hierarchy.

This capability gives designers a great deal of flexibility in their decision-making process. "Say a team is working on the standard-cell library and they make a change," says Ken Jones, HCM product manager. "When that low-level change gets picked up, its use at a higher level in the hierarchy creates a new instance of this hierarchy at the top level."

Armed with the confidence that they can restore all design aspects to a known-good reference point, designers have much more freedom to explore options that they might not otherwise. If they hit a wall or find themselves going astray, they'll know that the HCM can bring them back to a fresh start. Returning to a known-good design plateau can also be useful for starting a design variant off of some known-good core implementation that's the basis for all sorts of variants to be created.

It's important to note, however, that exercising the option of returning to a given point in a design doesn't mean that other work done beyond that point is lost. That work can still be accessed.

Another point to consider about a snapshot is that in addition to the design files that make up the blocks in the hierarchy, it contains information regarding the tools used to create the files. "When you want to go back and recreate the tapeout of a specific design, the design data is no good without the tools that were used to create it," explains Jones. "You want to bundle together a snapshot of all the tools and all the scripts you had, including the parameter files for these tools, along with the entire design hierarchy."

For all of its inherent power, the HCM's real utility lies in its use with Synchronicity's existing tools. The HCM is being launched as part of an SoC Developer's Suite with updated versions of both DesignSync and ProjectSync.

DesignSync has within it a mechanism for defining collections of files, which could, for example, comprise the design data for an IP block. By tagging a set of related files at some revision level, DesignSync creates what's referred to as a "configuration." The process, though, is somewhat laborious and requires substantial insight into DesignSync's workings to achieve anything near a hierarchical level of data organization. HCM provides a set of commands that bring DesignSync's capabilities to fruition in the hierarchical sense, while hiding the file-level details from users.

Similarly, the HCM ties in with ProjectSync by bringing a hierarchical format to the management of collaboration-related data. ProjectSync tracks notes and other documents related to a design project, especially those related to bugs and their status. On its own, ProjectSync would only let users see one level of the hierarchy at a given time. When used with the HCM, it makes the hierarchical aspect possible (Fig. 2).

The HCM also has a role in conjunction with Synchronicity's IP Gear product. IP Gear is a repository for IP that provides a foundation for a complete IP reuse infrastructure. The HCM is a system for works in progress that facilitates the creation of new IP and its integration with other blocks. Eventually, HCM will let users export pieces of IP or even entire new designs and capture them in an IP-Gear-based repository. For now, users can leverage existing IP in an IP-Gear repository for use in a current design project.

Synchronicity Inc., 201 Forest St., Marlboro, MA 01752; (508) 485-4122; fax (508) 485-7514; www.synchronicity.com.