Managing and Reusing IP in a Build-Borrow-Buy Era

Make-versus-buy inadequately describes what we do now in electronic systems design. We are on a continuum of design IP acquisition and use decisions, often with a portfolio of active projects and future projects depending on the outcome. Properly managing IP means adopting a build-borrow-buy mindset and tools capable of handling all aspects of the process.

In a binary make-versus-buy decision, teams either bought a complete subsystem (say a single board computer or real-time operating system) or made it from scratch. The potential for the buy option to disenfranchise designers often led to resistance. Overcoming that objection meant enabling design teams to add their value while still buying a base platform – such as expansion connectors for daughter boards and libraries and APIs for operating system extensions.

Subsystems became more modular and reusable, if properly defined with some kind of structure. Abstraction of IP eased integration and fostered reuse. Tradeoffs became much more granular. Rather than managing a design as a whole, functional blocks of software code or hardware descriptions could be brought into play quickly and managed as individual pieces integrated into a greater scheme.

Build-borrow-buy is a better term for two reasons. First, it represents what we really do. Second, it recognizes that reuse is manifested in several ways. Build is straightforward, with an IP block made in its entirety by internal or contracted design teams. Borrow suggests use of a block that was built or bought and proven in a previous design, or one that was lifted from an open source community for this design (and presumably proven in some use there). Buy delivers a block either to our exact specifications or commercial source files that can be tuned quickly to meet the needs.

Objectives in managing software and hardware IP are quite similar. Typical needs begin with version control and bug tracking. Once those are under control other uses appear, such as collaboration and access control, royalty tracking, licensing pass-through, artifacts for patent applications and compliance audits, and M&A due diligence. Automation of IP management provides huge benefits as the complexity of individual projects grows and a portfolio develops.

However, dissimilarities between software and hardware quickly emerge when the acquired IP is to be synthesized and integrated into a working product. A software configuration management tool such as Subversion handles source code and metadata needed for compilation in a high-level language such as C or Java. What these tools lack is any knowledge of a hardware design flow or the ability to handle multiple file formats (likely with different EDA tools) and relationships involved when working with hardware IP. Extending these software-centric tools to integrate with typical EDA tools would be a massive undertaking.

Just as it makes sense to evaluate IP on a build-borrow-buy scale, it also makes sense to consider EDA tools in that same context. While borrowing an open source tool like Subversion sounds attractive, buying tools appropriately designed for hardware IP management can rapidly pay for itself in complex environments. The number of IP blocks in designs has swollen, with larger designs now containing 100 or more. A typical large design team is now distributed, drawing on expertise from around the globe.

ClioSoft has built a robust, extensible hardware IP design management system in SOS7. Its focus on collaboration and integration with multiple design flows – including digital, mixed-signal, and RF – means that design teams can start managing IP quickly with a minimum learning curve. Instead of stepping outside a familiar design environment to perform additional steps (such as checking files in and out of Subversion), the SOS platform leverages existing EDA workspaces and optimized network storage. SOS handles the nuances of file and metadata organization without burdening the designer with the need to understand where information resides before attempting to use it. The fault-tolerant architecture handles synchronization, backup, and security of the repository.

The bottom line here is hardware teams should be managing the IP and the design, and not spending a lot of effort on improvising with tools not designed for the job. Knowing where IP has been, where it is and what state it is in right now, and where it is going is a competitive advantage that frees design teams from otherwise manual tracking methods. Selection of IP in a build-borrow-buy approach, including how internal teams have modified IP after obtaining it, is a fundamental element of efficient IP reuse.

We’ll be exploring ClioSoft SOS7 capabilities, how it facilitates IP reuse and collaboration, and how IP management fits in the bigger build-borrow-buy picture in future posts.

Also Read

Reinventing Power Management ICs for Mobile

Evaluating the performance of design data management software

The Case for Data Management Amid the Rise of IP in SoCs