I use Quicken to manage my business and personal finances because it saves me so much time by downloading all of my transactions from Chase for credit card, Amazon for credit card, Wells Fargo for banking and Schwab for IRA. Likewise, for IP management in SoC design you want an app like Quicken that plays well with other tools that you are already familiar with. Such is the case with IP management as many engineers have used Git before to manage their software source code projects they can also use Git to manage their RTL code because they are related text files.
The challenge comes in SoC design when you want to start managing IC design files that are binary like IC layout, AMS designs or even SPICE waveform files. Perforce is a popular version management system that can handle these binary files quite well, so how would you connect Perforce and Git together cohesively?
At Methodics they have created an IP Lifecycle Management platform called Percipient that does tie together Perforce and Git so that each component of your design can be managed as an IP, then each IP use the data management system of choice: Git, Perforce, Subversion or others. With the Percipient tool you build workspaces for your project that have any combination of IPs that use different data management tools. Now thats giving you choice and flexibility, instead of being locked in to a single vendor approach.
Let’s walk through the details and setup of using Git IP. In Percipient create an IP with a ‘repo-path’ field that holds the repository URL used by Git. When you do a commit in Git it creates a 40 character revision identifier using a SHA-1 hash. Percipient will load the Git IP by doing:
- git clone (to retrieve the repository)
- git reset –hard (puts the repository at the defined commit that matches the IPV release)
If you just load a Git repository in a workspace at some commit, then that repository is in something called a “detached HEAD” state which has a limitation where any user changes and commits do not belong to any branch. This is overcome in Percipient because it does a git reset –hard when loading a Git IP at a known version. Here’s a diagram to help explain what Percipient is doing:
- Previous commits become dangling
- Updates the currently checked-out branch
No need to worry about the dangling commits because Git does garbage collection to remove them.
Git Branches in Percipient
Git has a branch and merge flow, while Percipient will map its TRUNK and lines to Git by:
- TRUNK is the “master” Git branch
- Other lines are a Git branch.
You don’t have to match each Git branch into a Percipient line, just match Git branches that are important or used to share with others.
Updating a Git IP
Your IPs in a particular workspace can easily be updated to a different release or a version by using Percipient. If you’re doing a pi update command then Percipient first checks the Git IP status, for clean status then Percipient can apply update modes to this action, but they will only by at the IP level.
Releasing a Git IP
To release your Git IP run the command pi release. Some of the checks when releasing an IP are:
- Is workspace status clean?
- IPV line and Git branch match?
- Commit has been pushed?
Each Git IP needs to reside in its own repository, so your IP can’t be just a portion or a sub-directory inside of a repository. Your Git repository needs to be mapped to one IP.
No Submodules or Subtrees
A Git repository cannot reference submodules to work with Percipient.Use Percipient to manage your hierarchies.
Mixing DM tools is desirable and possible, so now you can enjoy using both Git and Methodics on the same SoC project. Git can handle text files quite well, and Percipient understands binary files, a perfect fit for modern chip design projects that need to track both file types.
Read the complete white paper here online.
- Combining IP and Product Lifecycle Tools
- SoC Design Management with Git
- Rethinking IP Lifecycle Management
There are no comments yet.
You must register or log in to view/post comments.