embedded hardware design
July 22, 2021

Hardware Design Best Practices

Design
IP Lifecycle Management

By

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 

Table of Contents

  1. What Is Hardware Design?
  2. Challenges of Hardware Design
  3. Branch/Merge Issues for Hardware Design
  4. Recommended Workflow For Hardware Design Teams
  5. Learn More About Hardware Design
Back to top

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 top

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:

  1. Mixed assets: projects consist of a mix of binary and ASCII files, especially in mixed signal designs.
  2. Large team sizes: each sub-team within the project team has 10+ members, and the entire project might have 50–100+ members.
  3. Large file count: a typical hardware workspace consists of 10,000+ or even 100,000+ small and large files.
  4. Long, involved flows: each flow, from verification through synthesis and P&R to cleaning LVS to regression runs take hours, days, and sometimes weeks.
  5. 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 top

Branch/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.

Make Hardware Design Faster and Easier

Accelerate chip design delivery with tools used by top semiconductor companies. Our Semiconductor Starter Pack includes 10 licenses of Helix IPLM, Helix Core, and Helix Plan (formerly Hansoft) at a lower, introductory price.

UNLOCK YOUR DISCOUNT

Back to top

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.
Back to top

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. 

TALK TO AN EXPERT

Back to top
Michael Munsey

Michael Munsey

Vice President Marketing, Corporate Strategy and Business Development, Methodics IPLM by Perforce

Michael Munsey has over 25 years experience in engineering design automation and semiconductor companies. Prior to joining Perforce, Michael was Senior Director of Strategy and Product Marketing for semiconductors, software lifecycle management, and IoT at Dassault Systemes. Along with strategic initiatives, he was responsible for business development, partnerships, and cross-industry initiatives such as automotive electronics and M&A. Michael began his career with IBM as an ASIC designer before making the move over to EDA where he has held various senior and executive-level positions in marketing, sales, and business development. He was a member of the founding teams for Sente and Silicon Dimensions, and also worked for established companies including Cadence, VIEWLogic, and Tanner EDA. Michael received his BSEE from Tufts University.