10 Challenges in IP Design Collaboration

Enterprise design management can be summed up in one word: collaboration. Intellectual property (IP) reuse and the success of distributed system-on-chip (SoC) design efforts depend strongly on how well designers can collaborate. As time-to-market windows have shortened, the challenges around design collaboration have become more critical.

With escalating design costs for each SoC start, shouldn’t there be more emphasis on an underlying design management engine to maximize designer productivity and team efficiency? During my visit to #53DAC, I saw a sneak preview of just such a new collaboration platform in development at ClioSoft – and we shared our views on this Top 10 list of challenges ClioSoft is targeting.

Trivial designs and very small teams aside, most IP/SoC design efforts run into many, or all, of these challenges. Improving IP/SoC design collaboration has many of the same characteristics as any major change initiative, and has some IP-specific issues.

10) Multi-site teams can’t keep data in sync real time: With large teams collaborating across multiple remote sites, often worldwide, keeping the design data in sync securely and in real time is key to improving design productivity. Some remote sites do not have the requisite network bandwidth available, making it more important to ensure optimal use of bandwidth.

9) Revision control and release management must be managed: With different teams working on the same design, it becomes important to manage the different design versions as well as to identify the differences between the versions for both text and binary files. Integration with EDA tools to check in or check out different versions of a design is a definite plus.

8) Information is trapped in silos: As with many business processes, organizational structure is sometimes a barrier to sharing. It’s not even the overt “warring tribes” mentality; it can be as simple as business units not regularly interfacing with each other in open conversation. Any knowledge or IP developed within a business unit does not necessarily get shared with other design groups.

7) Physical boundaries are in the way: Distance, time, and language are the traditional barriers to collaboration. Time zones, different work tools, different expertise domains (digital versus analog, timing versus power, IP block versus system integration, and so on), different patterns of responsiveness, and different preferred mediums of exchange can also be barriers.

6) Multiple unconnected sources of information can lead to mistakes: Design information is typically captured in different tools and formats; for example, in meeting notes, emails, Word documents, Excel spreadsheets, bug tracking systems, or design management systems. To avoid costly mistakes, everything relating to a project should be stored in one place for all to see and use the correct versions.

5) No clear guidelines on what should be shared: Most designers are still not sure what data can be shared with others within a company or with vendors or externally. Who has access to what design data should be determined by built-in and customizable access restrictions and by ensuring that all design data is stored in one place.

4) Unclear information on third-party IP: In-house built IP, borrowed IP, and bought IP may have three different sets of artifacts and metadata. Bought IP may be the hardest one to obtain data for. Vendors may be unwilling to share, or may charge for the privilege, or may just not have some elements of data. In addition, while accessing third-party IPs, most designers do not pay attention to the license agreements to see if they are authorized to use the IP, which can lead to liability problems.

3) Limited feedback between IP authors and users: IP artifacts tend to flow downhill, from creation of individual blocks to integration of subsystems and finally the full-up SoC. Creators often do not find out what happened from users of their IP, but that information can be critical to future reuse. IP users, on the other hand, do not know how to fix IP-related problems and often end up creating a kluge to resolve issues. If users know the IP authors, they can communicate with them for any needs.

2) Tracking IP quality is difficult: What should be tracked regarding IP quality? A database is only as good as the items captured; reporting depends on metadata describing variables and relationships. Thinking through quality metrics can help decide what to track.

1) No infrastructure for sharing and reusing IP: Replacing “sneakernet” with an “intranet” moves documents, but not real information. Design data and IP need an enterprise tool designed for collaboration optimized on an infrastructure that delivers cost-effective performance.

Do the items on this list sound familiar? What else is holding back more IP reuse, or driving up SoC design costs in terms of productivity, in your organization?

Also Read

Enterprise design management engineered for SoCs

Managing and reusing IP in a build-borrow-buy era

Reinventing Power Management ICs for Mobile