Semiconductor IP News and Trends Blog

Top Ten Reasons Why Semiconductor IP Fails

Companies fail to reuse their internal IP for reasons well-known to the software and systems engineering domains.

A few months ago, IP- Extreme’s CEO Warren Savage shared his list of the top ten reasons for failures of EDA and semiconductor companies to reuse their internal intellectual property (IP). Savage compiled the list from his own lengthy experience in the creation and management of IP and the experience of his many customers.

At the time of Savage’s presentation at the Semico Research “Impact” conference, I was struck by the similarities between his list and similar ones from the worlds of basic software design and hardware-software systems engineering. (Some members of the EDA community have most recently called the later “system enablement”).

What follows is my first attempt to map these three different domain lists of best practices. I start with Savages’s list on the causes of IP disasters, which is followed by a chapter reference to Frederick P. Brooks’s seminal work in large scale software development, and finally my own notes from the world of systems engineering.  (I’ll leave it to my PSU graduate students to refine this list in the near future.) Naturally, I look forward to any inputs offered by the readers. – JB

As Savage notes, complex systems are prone to failure.

#1: Throw People At It

Savage: To the inexperienced, this appears as an easy solution as long as you have the budget. A better approach would be to leverage your best designers with a solid supporting cast.

Brooks: The Mythical Man-Month; “Example: 50 developers give 50 · (50 – 1) / 2 = 1225 channels of communication.”

Systems Engineering: More people require even greater levels of communication and interface management.

#2: Lost IP

Savage: It’s not uncommon for a design company to purchase third-party IP, e.g., a UART interface, only to find that they have their own internal UART IP. These lost assets happen because few organizations assign anyone to the management of IP. One solution is to create a centralized place to inventory reusable designs.

Brooks: Formal Documents; Communication

Systems Engineering: This is a configuration issue, a problem with the organizational structure and a communication break-down issues between management and engineers.

#3: Excessive Optimization

Savage: The problem is one of attitude, i.e., that of a craftsman vs. an engineer. It’s best to focus on the minimum requirements for usefulness and improve from there.

Brooks: Code Freeze and System Versioning

Systems Engineering: The designer’s sandbox effect – i.e., endlessly optimizing his/her portion of the design – requires a “good enough” management approach to the total design.

#4: Revision Control

Savage: A lack of discipline and communication causes this problem. It is mitigated by having a product-oriented focus on IP development with design reviews and release tags.

Brooks: System Versioning

Systems Engineering: Configuration Item process, commonly known as red-lines verses CI version control.

#5: No Documentation

Savage: This disaster results from a focus on coding instead of reuse. “Designers are seduced by the keyboard, meaning that they would rather code than text.” Best practices require a minimum amount of documents that can help future designers modify and reuse IP.

Brooks: The (architectural) Manual; Formal (programmatic and technical) Documents.

Systems Engineering: Useful documentation is the second major end product of the SE process. The first is a successful system or product.

#6: Not Invented Here (NIH)

Savage: Egos, distrust and a lack of alternatives are the cause of this myopic perspective. The solution is to understand what is available before wasting time on another design.

Brooks: Conceptual Integrity and The Surgical Team; Lowering Software Development costs; Project Estimation

Systems Engineering: Poor trade-off analysis between technical-market-cost objectives.

#7: Hiding IP

Savage: With no one responsible for IP (see #1), is it any wonder that no one supports their IP with other groups within the company? Technology companies need to establish a culture of reuse and systems that encourage sharing.

Brooks: Communication

System Engineering: This is often traced back to the problem of embedded implementation, where a designer wants to use his favorite implementation solution. Hiding IP should not be confused with information hiding, a technique to reveal only that level of information that is needed

#8: Overly Ambitious Expectations

Savage: All engineering endeavors suffer from this problem, which happens from the complicated and restrictive nature of most designs. The solution is to keep it simple and to continuously reassess expectations.

Brooks: Communication; Code Freezes; The Second-System Effect

Systems Engineering: This result happens when marketing department run the engineering groups. It really relates back to poor configuration management of the design and requirements.

#9: No Quality Metrics

Savage: Commonly cited reasons for this problem are “not enough time,” and “not sure how to do it.” Addressing this problem requires using tools and feedback from prior projects and storing that information in a repository for future reference.

Brooks: Progress Tracking; Formal Documentation; Project Estimation

Systems Engineering: System architects and managers assign budgets (power, bandwidth, memory, etc) to each subsystem. These metrics must be traceable up and down the system hierarchy – and documented.

#10: Too Busy

Savage: A short-term focus results in a “fire-fighting” mentality.  Best solution is to use agile practices to focus on the short-term problem while remembering medium-term objectives.

Brooks: Plan to Through One Away – “… reluctance to document designs is not due to laziness or time pressure,. Instead it comes from the designer’s reluctance to commit himself (herself) to the defense of decisions which he knows to be tentative.”

Systems Engineering: Time not spent up-front in architecting a good design will results in greater delays later on.

References:

• Frederick P. Brooks, Jr., The Mythical Man-Month – Essays on Software Engineering
• Blyler: Interface Management, IEEE I&M
• Normal Accidents: Living with High-Risk Technologies
• [Video] Wally Rhines on the dis-incentives of systems engineering. “Mentor’s Wally Rhines – Learning Curve; Golden 28nm, IoT Innovation and Systems Engineering”