Semico’s list of 10 reasons why it’s taken so long for SoC design teams to adopt IP. How many apply to your team?

For those of us who formerly purchased IP in the form of 40-pin DIPs, the idea of using IP to design SoCs isn’t so foreign. However, for people accustomed to designing everything under the hood of their latest ASIC, the idea has seen surprisingly slow adoption. Semico’s new IP report, “IP Subsystems: The New IP Market Paradigm,” lists 10 reasons for the slow uptake. With author Rich Wawrzyniak’s kind permission, I have decided to list them here.

  1. The need for 3rd Party SIP was just starting as the SoC market was beginning to take its first small steps
  2. Most silicon designers did not feel comfortable in allowing ‘outsiders’ access to parts of their design
  3. The level of complexity found on parts in the early 1990’s was very low compared to today and it was possible for ASIC design teams to complete designs within acceptable time frames without the need to use IP from outside the company
  4. Many companies had their own ‘IP’ they had been using for years that was adequate for their design needs. Several embedded memory types such as MROM, 8T and 6T SRAM, various analog blocks and several proprietary CPU cores are good examples of this
  5. The quality of many IP blocks was not up to the internal standards most companies employed for their designs
  6. The expertise needed to utilize 3rd Party SIP was lacking at most companies and it was easier to design their own IP rather than use non-company IP
  7. The pressure to integrate discrete semiconductor functions into ever smaller footprints, while present, was not overwhelming at the time
  8. Power issues were not as critical as they are now for SoC designers
  9. The markets for mobile devices that require high functionality and performance, small footprints, ultra low power consumption and low price points were just starting to gain momentum
  10. There were many IP vendors at the time, but few who were ‘serious’ and capable of starting, cultivating and maintaining a relationship with large corporate entities

Which leads to one question.

How many of these issues plague your ASIC/SoC design team?


About sleibson2

EDA360 Evangelist and Marketing Director at Cadence Design Systems (blog at
This entry was posted in EDA360, SoC Realization. Bookmark the permalink.

2 Responses to Semico’s list of 10 reasons why it’s taken so long for SoC design teams to adopt IP. How many apply to your team?

  1. Eric Yan says:

    If the SOC Design Flow become easier and easier, and the manufacture fee is acceptable for small company, The sip market will be more and more booming.

  2. George Storm says:

    All. But for us there are two far more potent issues.
    However, before embarking on this, a note on the glory days of packaged functions: there was little choice – you physically checked the suitability of the packaged IC for your application and used those that actually worked in context (unspecified parameters often being important). So it was horses for courses then – and remains that now.
    One problem for imported analog(ue) IP is its effect on system configuration: matching the architecture to the (currently relatively limited) range of available parts can be as expensive as designing your own parts around a natural architecture. This is of course a bit chicken-and-egg: if we don’t buy sufficient IP there won’t be the incentive to support more.
    A further issue is that we have to make exactly the same checks on the IP as we used to make on the packaged function; only it has to be done in simulation, which is slower and may only answer the questions you already know need asking. When (as often) the purchased IP is more general-purpose (and complex) than is needed in the particular application, it is often more economical in design time to put together the simplest component arrangement that will actually do the job.
    As a result, the habit is to only use IP for functions where all the parameters are common to many applications. For us this includes all digital applications including NV memory and standard interfaces, but not always (for example) for Voltage regulators as the trades-off between noise, rejection, input and output impedance and ground current may sometimes best be met on a case-by-case basis.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s