Hardware Design Best Practices
Hardware design typically entails teams of many designers with a wide range of disciplines. Each of these designers manage a different aspect of the project, maybe with different workflows, and generate a large amount of diverse data.
Data management tools like Helix Core manage a substantial portion of this data. In this blog, find out how these tools are best used with an IP lifecycle management platform like Methodics IPLM to solve the unique challenges for hardware design projects.
Challenges of Hardware Design
With all of the different roles and flows involved in hardware design, there are unique challenges that come with these development projects:
- Mixed assets: projects consist of a mix of binary and ASCII files, especially in mixed signal designs.
- Large team sizes: each sub-team within the project team has 10+ members, and the entire project might have 50–100+ members.
- Large file count: a typical hardware workspace consists of 10,000+ or even 100,000+ small and large files.
- Long, involved flows: each flow, from verification through synthesis and P&R to cleaning LVS to regression runs take hours, days, and sometimes weeks.
- Massive workspace sizes: 10–100 GB workspaces are common.
When working with a data management system like Helix Core, all of these characteristics of hardware design require special consideration.
Branch/Merge Issues in Hardware Design
Branching and merging is a common paradigm in software development. In this type of workflow, each project member creates a branch from the trunk codebase and modifies files on that branch without impacting other changes. When the changes are ready to share with the rest of the team, they are merged back to the trunk.
While this sounds great at face value, hardware design has unique characteristics that differ from typical software development, making it difficult for teams to leverage branch/merge workflows.
Large Team Sizes
It is not uncommon to see team sizes of 20-50 designers, if not more, in the hardware space. This requires the flow to manage many branches, and their merges back onto trunk. All this branching and merging rapidly becomes logistically untenable.
Getting clean merge points becomes harder and harder, requiring negotiations and artificial constraints onto the merge process. Merge logistics can dominate the development process.
Mixed Signal Development – Cannot Merge Binary Files
Merging binary files doesn’t work. Users have to select one version or another in case of conflicts. This implies that resolving conflict would either result in lost work, or it would require manual rework to incorporate even the non-conflicting subsets of changes back into the file.
Shared Work Files
In mixed signal designs, different individuals have to work on the same physical files to get their job done (layout engineers, for example). They count on Helix Core file locks to achieve this. However, if users are off on their own branches, there is no way to know that the same file has been modified in conflicting ways by multiple users — leading to merging headaches and lost work.
Long Workflows
Many hardware design workflows take a long time to complete. Regressions can run for days. Feature additions and bug fixes can take days or weeks.
If users are off on their own branches for extended periods of time, their branches soon get hopelessly out of sync with other changes and merges on the trunk. The effort involved in bringing these branches back in sync causes users to postpone the sync, causing more changes to accumulate on branches — causing more and more diversion from the trunk. When the sync is attempted it becomes a multi-day effort, causing frustration and loss of productivity.
Large File Counts and Massive Workspace Sizes
With the massive number of files in a typical hardware workspace, it can be difficult (and cumbersome) to create all the branches needed for the project. In addition, with the massive workspace size, the creation of more branches causes the repository size to inflate to unmanageable proportions.
Accelerate Your Hardware Design
Plan, manage, and accelerate delivery of your chip design today with the tools used by the top semiconductor companies. Our Semiconductor Starter Pack includes 10 licenses of each Methodics IPLM, Helix Core, and Hansoft for a special introductory price.
Recommended Workflow For Hardware Design Teams
As detailed above, productivity in a hardware design environment can be hindered by branch/merge flows. Teams adopt this flow with the best intentions, but find that their time is now dominated by merge conflicts and logistics, rather than getting important work done. Using Methodics IPLM with Helix Core can solve these challenges.
The recommended flow that works best in a scenario like this is one that limits the number of branches, allowing multiple users to collaborate on trunk or a small set of long-living functional branches instead.
These functional branches are not meant to be merged back onto trunk, but they are used to make some custom changes that make sense in the context of that functional branch. Most of the development will still be on trunk.
Users should consider adopting a release-based flow along with actively and programmatically managing the Helix Command-Line Client ViewSpec to overcome the specific challenges of hardware design.
- The release-based flow addresses issues around branch/merge overhead, binary file merging and shared work files.
- Actively managing the Helix Command-Line Client ViewSpec addresses issues related to massive workspaces and large file counts.
Learn More About Hardware Design
Get more detail on how to adopt a release-based flow in our white paper, Best Practices for Perforce Helix Core-Based Hardware Design, including best practices for:
- Releases on trunk
- Managing massive workspaces
- Managing IP versions dynamically
Talk with one of our IP experts to learn more about how Methodics IPLM can help your hardware and software teams collaborate more easily and accelerate delivery. Click below to get in touch today!
