↓ Archives ↓

IP Reuse – There’s an Elephant in the Room

Is IP reuse the great business fantasy of the past decade? It’s pretty clear that there is both an ample supply and a business demand that should propel a working IP reuse strategy. Can reuse really be successful, particularly in the analog area? If you ask a designer, one who is responsible for the technical success of a chip, the answer will be entirely different than an answer from business leadership or IP suppliers.

The truth is that designers have never been highly energized about reuse, from either internal or external sources. There is an elephant in the room that has never been dealt with and that is the fear of reuse. This long term anxiety has been erroneously packaged up and buried by leadership as a stubborn attitude or the NIH factor at play, keeping the reality just out of sight.

For true reuse enablement this fear package must be dug up, unwrapped and a full inventory of the contents must be completed. The essence of what is found will highlight the fact that the end designer’s needs are not being met. Proper actions to genuinely mitigate what is found will be the only path to a successful reuse strategy. The foundation of successful IP reuse begins with addressing the end users needs, providing IP deliverables that will mitigate reuse fear and truly make reuse the simplest path for the designer.

#1 – Deliverables
The deliverable package for IP is by far the most important aspect of winning end user support for reuse. It must inspire a sense of confidence that both the architecture approach and the verification activities are top notch. A schematic, RTL, layout and spec will NOT alone foster this essential trust. The end user must have access to information that captures the architecture trade-offs, risk analysis approaches, decision processes and verification concepts of the design originator.
#2 – Address User Concerns
Ensure there is a path for concerns about reuse to be aired and addressed. If the end users have no voice, IP reuse will absolutely be like pushing a rope. Without addressing these concerns a potential IP user will pushback. Forced reuse will typically cultivate a requisite verification phase that could take longer than an original design approach. Integrators of reusable IP fully embrace the fact that they are still on the hook for a chips success, even though a portion came from elsewhere. Never lose sight of that fact!

#3 – Marketing Strategy
Always remember that successful IP reuse is a pull from the end user, not a push towards the end user. If end users are not being drawn towards the IP the marketing approach has left out the most important customer, then end user. Any winning IP marketing tactic must minimally address items one and two above!

#4 – Repository
Having addressed all the IP content requirements, the repository can now be implemented. A word of warning – don’t put anything in the repository that does not meet the first two rules. Any perception of garbage in the repository will ruin your efforts for a very long time. Repository content that draws users towards it will always seal the deal on reuse. Remember – Quality content rules!

Reusable IP that is in Demand – A few Closing Thoughts

  • If a designer digs through a wonderfully crafted repository, downloads the deliverables and finds a deficiency in IP content, you have lost them for a very long time.
  • Keep in mind that IP reuse enablement is not a software or EDA task; it is a deliverable content development task.
  • The end user will make or break your reuse strategy. It is paramount to understand what will “make it work” for them.
  • The repository leaves a short-term impression, what the designers receive from it leaves a long-term impression.
  • Reuse content will need to be kept current based on silicon usage and tool updates. Don’t ignore or underestimate effort here.
  • Reuse enablement requires the matching of re-user needs with cataloged content.

5 Comments

  • Nov 17th 201004:11
    by John Eaton

    Can you show us an example of a well constructed IP repository?

    You are right in that what you put in or omit from the repository can make a huge difference in the reuse of the IP but nowhere in the industry has anyone bothered
    to specify what such a repository should look like.

    The IP is important because that goes into the customers product. The repository
    is simply the box that you use to ship the ip to the customer. It is thrown away after
    the design is released.

    But every high volume manufacturer from Henry Ford to the present day has specified the box for each part is shipped to the production line. If you leave it up to all the different suppliers then you will have a real mess at incoming and will never make your volumes.

    Our industry is still hand crafting designs which requires the end user to hand craft the importation of those designs. The “A” in EDA stands for Automation and you can’t do that unless you can write a spec for all the deliverables.

    Where is the spec for a IP repository?

    John Eaton

  • Nov 17th 201012:11
    by Jeff Jorvig

    John,
    Thanks for your comment. My point is that we need that spec and it will only come from understanding the needs of the end users. From my discussions with designers on reuse it comes down to a better understanding of the original designers thought processes, risk analysis, architectural decisions and design trade-offs; getting into the originators head. Essentially how the original designer went from spec to verified design, the “how” being the most critical aspect. That must be captured in a suitable form and be part of the repository documentation set. It is currently an unfulfilled need, a barrier to reuse adoption. This is the spec you are looking for.

    Jeff

  • Nov 17th 201018:11
    by John Eaton

    Hi Jeff,

    The model that I use is that there are three jobs needed for IC design.

    1) Component designer: Designs a module that performs one function

    2) Architect: Selects components, configures and interconnects them to form a larger component that is then handed off to another architect. This repeats until you have one component that contains the entire design

    3) Si Makers: Take that component, synthesise what they can and instantiate lib modules for the rest, make it testable, place_and_route to close timing before making a real part.

    The key is to understand the deliverables that flow between each of these groups. The rules do not change as we dive deeper into nanospace chips but the design sizes are pushing us to use more design automation. We don’t have time for a skilled designer to review all the rtl so we must use tools. That means we need a specification that can be used by a tool to find problems in a deliverable.

    I see that you are on linked-in, I’ll send you a connect

    John Eaton

  • Dec 8th 201016:12
    by Francis

    Hi Jeff,
    This is very good article , Do you have any public paper that can give me more understating in IP-reuse. I am doing my Master on “The development and analysis of a design methodology for IP re-use” . I want to know more about why nowadays designer fear of reuse their IP ?

  • Dec 11th 201023:12
    by Jeff Jorvig

    Hi Francis,
    The only other document I have is this paper titled “Key Components of a successful Internal IP Sharing Program

    Jeff

  • Leave a Reply