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 Helix IPLM (formerly Methodics IPLM) solve hardware design challenges.
GET HELIX IPLM + helix core demo
What Is Hardware Design?
Hardware design is a growing field and relevant to a wide variety of industries. The definition of hardware design is the building and testing of an electronic device's physical elements.
Hardware design is the creation of computer hardware, like microchips, circuits, processors, sensors, and storage devices.
Hardware Design vs. Software Design
Hardware design and software design are often parts of the same workflow, and each depend on the other. Hardware design is tangible and visible – like a motherboard, monitor, or speaker – while software is the script that enables these objects actions and performance.
Due to its tangible nature, hardware is designed and must be modified physically in the event of any bugs. Meanwhile, software is developed and can be more quickly repaired.
Back to topChallenges 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.
Back to topBranch/Merge Issues for Hardware Design
Branching and merging is a common development flow paradigm for 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.
Back to topRecommended 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 Helix 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
dOWNLOAD OUR HARDWARE DESIGN GUIDE
Connect with Perforce to learn how Helix IPLM reduces workflow pain points and empowers collaboration.