SoC Design Management with Git

Linux creator Linus Torvalds lives in Oregon not too far from me and he also created the popular Git system for Design Management (DM) in 2004 that is now used by many software developers. So what makes Git so attractive as a DM tool?

• Feature-branch workflow
• Easy to switch context between features
• New features can be created orderly and be traceable
• Low overhead for making releases
• Speedy performance
• Distributed DM system
• Active user community

Would an SoC design team use Git as their only DM tool? Probably not, for several good reasons like:

• Git is designed to control text files, not binary files
• All versions of all files are kept by each team member
• Incremental changes to binary files are not exploited

As an example, consider making 10 versions of a text file and also a binary file, then look at how many MB of data storage are required for each in a DM system:

You really don’t want to use Git for versioning binary files that are part of your SoC designs because Github has a recommendation that repository size stay under 1Gb, while each file size is limited to 100MB in order to keep performance levels acceptable. Sure, you could use multiple repositories in Git to get around these limitations, and even use some Git add-ons to work with larger binary files.

Another direction to consider for versioning binary files is with Perforce, because that tool allows you to have a workspace with single versions of each file, plus just the required portions of the repository.

The Percipient Approach

Thankfully, we have a vendor like Methodics that has figured out how to enable DM for SoCs that have both text and binary files, and their tool is called Percipient. The main features of Percipient include:

• A single source of truth
• Designs decomposed into units and subunits, or IPs
• Each IP can be saved in a variety of DM systems (Git, Perforce, Subversion)
• Each user can have a workspace with the entire design or just pieces of the design

Here’s a diagram to show how all of your SoC data can be managed, organized and versioned with Percipient and other DM tools:

So with this flow you have all of these IPs and they can be released, creating new versions. Your IP becomes qualified to some level, and all of that is published automatically to the Percipient platform. Users just query Percipient to find the new versions of any IP that they need. Each qualification level along with meta data are kept in the system.

As a bug is discovered in a version of an IP then you just file a ticket about it using your favorite bug-tracking system, while users of Percipient can view all bug reports for that IP. All the info needed about any IP is visible to all team members, across the globe, in real time.

Because Percipient uses a single source of truth approach it becomes the one place to go to when asking a question about design readiness. Users can even add simulation and test results to any IP, and you can find out if each IP has met specification compliance using IP properties. There’s even an integration with Jama, so that users can track IP requirements throughout the design lifecycle.

Percipient, Perforce and Git all work together because Percipient supports the Git-P4 type IP, which is using the Perforce Helix4Git feature. Perforce is quite efficient as it host the native Git data, giving users the ability to clone any portion of data from any branch. So Git-based developers continue working in their favorite tool, then others can populate the same data, so you’re not having to populate an entire Git repository.

Summary

Methodics has learned how to best manage complex SoC design projects by integrating with other popular tools like Git and Perforce. Every team member with Percipient can get the right IP version into their design and be alerted of any changes or bugs filed against that IP.

Read the complete White Paper from Methodics here.

Related Blogs

• Hierarchy Applied to Semiconductor Reuse
• Rethinking IP Lifecycle Management