Most large electronics companies take a divide and conquer approach to projects, with clear division lines set between HW and SW engineers, so quite often the separate teams have distinct methodologies and ways to design, document, communicate and save a BoM. This division can lead to errors in the system development process, so what is a better approach?
To learn more, I attended a virtual event from Perforce, their Embedded Devops Summit 2021, which I blogged about last month. They had three concurrent tracks: Plan, Create, Verify. I chose the Create track, and listened to the presentation, Implementing a Unified HW/SW BoM to Reduce System Development. Vishal Moondhra was the presenter, and his company Methodics was acquired by Perforce in 2020.
IP is a term used for both HW and SW teams, and it’s the abstraction of data files that define an implementation, plus all of the meta-data that defines its state.
A SW IP example would be a USB device driver, and a HW IP example a SRAM block. The Bill of Materials (BoM) shows the versioned hierarchy of all IP used to define a system, both HW and SW.
The SW blocks are shown in Green, along with their version numbers, while IP2 and IP1 are HW blocks with their own version numbers and hierarchy. If you examine the hierarchy carefully there are two instances of IP13, one at version 8, and the other at version 9, so a version conflict has occurred and your BoM system needs to identify this so that consistency can be restored.
Your SW team may be using Git, while the HW team prefers to use Perforce, and a unified BoM allows this mix and match approach.
Meta-data is the dependencies, file permissions, design hierarchy, instance properties and usage for each IP, and the Perforce approach is that a single system is used for both traceability and reuse. Once again, any Data Management (DM) system can be used.
Being able to trace which SW driver applies to a specific HW block is fundamental to maintaining consistency during system design, and a unified BoM takes care of this compatibility requirement. Tracking patches and updates across HW and SW ensures that no mismatches creep into the system during design.
The Platform BoM knows all of the versions being used in both HW and SW BoMs, and it’s fully traceable so that you always know which SW component was delivered with each HW component.
If a SW driver is incompatible with a particular HW block, then you can quickly identify that occurrence with a unified Platform BoM. If your Platform was only a handful of HW and SW blocks, then a simple Excel spreadsheet would suffice to track dependencies, but modern SoC systems have thousands of HW IP blocks, and millions of lines of code, so having a unified BoM system with traceability is the better choice.
Sending out SW patches to your released Platform demands that proper testing has been validated, so keeping track of dependencies is paramount for success.
With IPLM a SW team can use the concept of private resources where all of the details are abstracted out, leaving behind instead just the results of a build process. It still provides consistency, traceability and dependencies. Here’s an example of using a private resource for an ARM SW stack:
Working as a team with a unified BoM breaks down the old silo approach that separated HW and SW designers from each other. Design metadata can be managed to ensure traceability, promote transparency across engineering teams, enable IP to be reused, all while separate DM systems continue to be used.
The Methodics IPLM implements this unified BoM approach, so that your engineering teams can focus on completing their system work, while knowing that their HW and SW IP is fully traceable with centralized management, and that their IP releases are not introducing bugs.
To watch the 25 minutes archived presentation online, visit here.
- A Brief History of Perforce
- Conference: Embedded DevOps
- Third Generation of IP Lifecycle Management Launched
- Perforce Software Acquires Methodics!