Don’t Forget To Consider Productivity In Semiconductor IP Evaluations

When companies consider purchasing Semiconductor IP (SIP), they often have a strict procedure for evaluating third-party vendors and their products. If they don’t have a set way of evaluating IP, the Global Semiconductor Alliance (GSA) has developed a Hard IP Licensing Risk Assessment Tool to aid in assessing the value of IP (there is also a quality assessment tool). This aid is part of the GSA IPecosystem Tool Suite and is complementary to the entire industry – regardless of member status within GSA. It is a great tool suite and many companies have similar methodologies they use when considering the purchase of SIP.

But notice the focus: “Risk.” I strongly encourage prospective SIP customers to consider risk, including the risks related to the legal status of the IP being purchased, as well as the availability and expertise of SIP vendor technical support resources.

While risk factors may be top of mind in SIP evaluations, there are several other key factors to consider. For example, what’s at stake when benchmarking SIP performance and features is how well the product functions, and whether it meets the requirements for the design in which it is intended to be used. Of course, this is critical to those customers who need the absolute highest performance available, while others may only need to meet a minimum performance goal or requirement.

Engineers (I started my career as one) can be obsessed with performance because this part of the evaluation process is based on “objective” mathematics. That is, the results are simply numbers, so a ranking is easy. And numbers don’t lie, right? Unfortunately, the way that performance benchmarks are structured can be very political and bias the results for or against the project goals. For example, constraints defined for a similar SIP used in prior designs may unnecessarily limit what can be done with a newer SIP. This can lead to the wrong conclusions.

Because it requires conducting an actual project or set of projects from start to finish, productivity is a key factor that is rarely measured in evaluating SIP. Sometimes an engineering manager will simply ask if someone in their group knows how to implement a needed block – if they do, and their time is available – the block is built internally with little concern for core competency. Just because an engineering resource is available to do the work shouldn’t preclude consideration of third-party SIP. The risk is that time is wasted creating an inferior, less-feature-rich block compared to simply selecting a more robust, commercially available SIP version. Furthermore, internal development should be focused on the places that provide the real value-add and product differentiation.

Productivity is a hidden value that every engineering team should consider in the evaluation of SIP. In order to weigh the true effort involved in a SIP “make-versus-buy” decision, productivity benchmarks must include more than just design time. They should also include:

1) Effort to set up and run verification of the SIP.
2) Effort to document the block. Consider making the SIP reusable.
3) Effort to parametrize the SIP (if you are really serious about reuse).
4) Who will support this block in other designs? What if the original author leaves?
5) EDA tool costs. Internally developed blocks may require tool licenses that would not be consumed with the purchase of SIP.
6) Patent protection. Will your internal design violate any patents in creating this SIP?

This is not an exhaustive list of productivity considerations. By their very nature, SIP vendors are creating products that perform either a fixed function or that are highly parameterized, so that they can be easily used in any customers’ design. In fact, the SIP deliverables list often includes documentation, test benches, training classes, and indemnification against patent infringement—all factors that impact productivity.

To demonstrate its tremendous hidden value, Sonics actually tracked the productivity of one of our network-on-chip (NoC) customers. What our study showed was that not only did the customer gain productivity in their first design, but their productivity also continued to increase the more familiar they became with the NoC SIP.

Over time and derivative design projects, the customer saw increasing output and productivity from using SIP that was easy to configure to their needs, was of high quality, and met their performance and feature requirements. The lesson of this study is that when deciding whether to buy third-party SIP or make it yourself, be sure to consider all of the factors—including the important productivity benefits that engineers so frequently overlook.