GSA Intellectual Property Blog

A simple model for first order IP make/buy decisions

bill_martin@mentor.com (Bill Martin) — Mon, 13 Apr 2009 14:17:00 +0000

Jack Harding and Bill Martin

Option Theory contains many different, complex models concerning financial option pricing (stocks, derivatives, etc) between a seller and a buyer. Initial research was performed in the early 1900’s but did not accelerate until the 1960/70’s and is based upon complex math (differential equations, stochastic calculus, Monte Carlo, etc). Several Nobel Prizes have been awarded on work performed in this area. As stated, the work tries to evaluate pricing based upon an asset’s value, inherent market risks and realistic returns.

Do we need complex analysis to help us determine whether to purchase an IP asset or to internally develop IP? We believe that much of the complexity can be eliminated by analyzing two key attributes. This brief discussion might help resolve your IP purchasing decisions.

A “Make” or “Buy” IP decision can be aided by looking at two attributes and creating a map for all combinations. For two variables, this would be a 2x2 scenario matrix. The attributes to consider would be a differentiated feature and your company’s capabilities.

A differentiated feature allows your product or service to be beneficially unique from other competitors. An example might be a very high speed SERDES design with NO jitter. Another might be ‘universal’ digital controller for PCI Express, USB, Ethernet and SATA all wrapped into one RTL code with ‘on the fly’ configurability by user. To our knowledge, neither product exists. Each company determines how differentiation allows them to compete.

Your company’s capabilities help you determine how to best use your resources. Your company might have specific skills or experiences that can set you apart from your competition. Perhaps it is outstanding marketing, brand recognition, customer service, product development, engineering or operations. Few companies have outstanding logistic management. FedEx built their business on next-day delivery and this capability was used to differentiate FedEx’s service. FedEx can easily apply these capabilities to open new business lines such as Fleet Management, Outsourcing Shipping functions at large catalog companies, etc. It would not make sense for FedEx to expand into non-adjacent services. A simple example might be business process outsourcing. FedEx does not have the skills or experience to be successful in this area. If they wanted to enter this market, they would need to acquire an existing company.

How can this be applied to IP purchases?
To fill in the scenario matrix, let’s use easy questions to help guide us.

Will the IP help differentiate your product in the market? Is there a unique capability or performance that distinguishes you from other products?

If you look at common standards-based IP, the value is that it works on a worldwide defined standard. Connecting to this network (i.e. USB) ensures that your product can communicate with any USB enabled device. A USB connector alone does not differentiate your product in the market.

If however, you did have the “universal” digital controller enabled device mentioned above, your product can easily configure for any available network choosing the highest bandwidth available.

If the answer to the above questions are, “no, this IP would not differentiate my product,” you should immediately purchase IP if it is available. In Figure 1, this would be the bottom row filled with “Buy” recommendations. With a “no” answer, we have eliminated two of the four potential scenarios.

If the IP in question does differentiate your product, then you need to examine your staff’s capabilities. This will determine how to best acquire this IP. Let’s add another question to help resolve another scenario.

Does your staff have the right skills and experience to enable successful development?

If you do not have the right experiences, you would minimize your risks by finding an IP vendor with a successful track record. You might pay a premium for this but the insurance lowers your risks. In the diagram, this is the upper right-hand corner denoted “Carefully Buy”. This purchase is slightly different than the preceding recommendations. In this case, this is a differentiated capability for your product and you might consider methods to ensure exclusivity. If your competitors are able to purchase the same IP, your advantage has a low barrier.

So after two questions, we have resolved three of the four scenarios. For the above three scenarios, a user could use the GSA’s IP ROI Calculator but focus on licensing, royalty, and maintenance costs in regards to overall product costs. A user can look at different purchasing models to determine an appropriate model and price.

The most difficult scenario is when the IP does differentiate your product AND your staff has the skills/experience to develop the IP block. In Figure 1, this is the upper left-hand corner denoted with “Make?”.

To answer this, you will need to examine the opportunity or trade-off costs in how your staff is used. Which activity will provide the highest return to your company? This is complex and has many variables to trade-off. The entire IP ROI calculator can be used to help review which action will have the best return.

What other techniques do you use to analyze available options?

IP Quality: What are you paying for?

bill_martin@mentor.com (Bill Martin) — Mon, 02 Mar 2009 18:20:00 +0000

Bill Martin, Mentor Graphics

Quality is an old concept with various definitions and diagnostic tools to help improve quality. During the 1960s, few purchased Japanese cars. Today, most prefer Japanese cars due to their reliability and lower total cost of ownership. If you want to explore quality in depth, look for material written by Deming, Juran, Crosby, etc.

The Basic Definition of Quality
The basic definition of quality is simply meeting your customer’s expectations. Note: this does NOT imply the BEST product. One example to show various levels of quality would be different hotel chains. If you stay at Hilton vs. La Quinta hotel, you have different expectations on price and overall service. Both are great hotels and I have stayed at each. But I have different quality expectations for each hotel. If you pay more money, you expect more amenities. If you receive amenities meeting or exceeding your expectations, you are happy. If you do not, you may complain to the hotel management.

What about IP quality?
Several years ago at an IP industry panel, we discussed ‘standards.’ I created a diagram of five circles surrounding the customer. I labeled these: Specification Compliance, Integration, Quality, Business and Legal. Here are brief descriptions for each.

Specification Compliance:
Does the design or IP block meet the standard’s specification (USB, SATA, Ethernet) and can it pass their SIG testing and plug fest events? Without working in this environment, your product cannot ‘touch’ the network and will provide little value to your end customer. These compliance events are regularly held around the world and final reports are created for each vendor’s tests. IP products that pass these tests should not have functional defects.

Integration:
Can the purchased IP easily fit into the design/tool flow that I use? This is different than Specification Compliance. Are standard formats, languages and scripts used for fast adoption? How much energy will it take my team to be able to use and integrate this into my design? As one software vendor states: how much drag is this IP placing on my development?

Quality:
This is quality of the IP’s bill of materials (BOM). Each IP product contains many different subcomponents to help the customer understand how to use the IP. This might include scripts, application notes, reference manuals, verification tests, etc. Quality needs to be viewed in two dimensions: Are all the pieces available? Is each piece complete and easy to understand?

Business:
These are the pricing terms – up-front licensing, royalty or a hybrid model.

Legal:
Legal issues include indemnities, warranties and other terms specifying what happens in various circumstances between the customer and supplier.

In retrospect, I should have merged the above Integration and Quality definition into Integration. Integration would concern integration with tools, other IP and with your product development team. Quality would be the summation of: Specification Compliance, Integration, Business and Legal aspects. The ‘whole enchilada’ needs to meet customers’ expectations to be successful.

When purchasing IP, make sure that you ask questions for each of these areas. GSA has some tools to help you perform due diligence. Ensure that you have the right expectations before you sign a contract otherwise: Caveat emptor.

Post your comments on your definition of quality.

A Probability Formula for IP Integration

bill_martin@mentor.com (Bill Martin) — Mon, 23 Feb 2009 17:55:00 +0000

Bill Martin, Mentor Graphics

Years ago, I worked for Bob Payne CTO at VLSI Technology. Bob was great to work for and had many bright ideas concerning ASIC design. One of Bob’s ideas concerned the probability of individual components to the overall project’s probability. You can think of this as ICs being soldered to a PCB or pieces of IP integrated into an IC (SoC, ASSP, FPGA, etc.).

We are not talking about complex Statistics and Probability formulas, but a simple math concept used by many to help calculate overall product costs as well as managing piece part inventories.

How does it work?
To make it work, take the probabilities of each component in your design and multiple them together to determine the end product’s probability of working. This will be the maximum probability since it assumes that top-level integration of these components is perfect in the final product.

Simple example: A product consists of 5 individual components that have probabilities of 80%, 92%, 98%, 99% and 100%. These probabilities were derived from previous usage and estimated for blocks that were modified or never used.

In this case, the overall probability of the end product working is:

71.4% = 80% X 92% X 98% X 99% X 100%

You might ask: how can I apply this to my own situation?

First, by understanding the risk of each component, you can put additional focus on the riskier blocks. In the above case, the block with 80% should be the highest priority of focus. Maybe additional people, different skills, more verification, more/other EDA tools or a different IP supplier might be worthwhile investments. If the 80% block were raised to 90%, the probability of product success would be raised to 80.3%, nearly ~9% higher.

Second, once you have successfully used blocks, you have gained better insight into these blocks. The blocks might be developed internally or purchased, it does not matter. What matters is the probability of each block’s success. Should you reuse these IP, invest more time/energy on them to raise their probabilities or find other alternatives? There are times when any of these actions are appropriate.

Third, some areas of the design might not be well established. The market itself may not have clearly defined a standard. For these situations, if you cannot improve the probabilities of each component, you might as well start planning for several respins OR design your solution so that high-risk elements have minimal impact on your solution.

Some ideas to investigate include: can the high-risk portions be in a separate, self-contained design/chip? Can you enable easy changes to high-risk blocks after silicon (i.e. either software programmable OR placing spare gates near this logic)? Software is the easiest and cheapest for retrofits. Spare gates can help minimize changes to a few mask layers that are used late in the fabrication cycle, allowing you to quickly change logic and ramp up volume production. Either method can help reduce the cost of a respin and minimize your product’s delayed market entry. In most consumer markets, any delay can be very costly regarding sales revenue: possibly a company killer.

Fourth, for any purchased IP, have you considered how you alter the risk profile by modifying that IP block? Is it better to perform modifications external to the purchased IP or should you contact the IP supplier for their assessment?

Fifth, it also shows that reducing the number of components in your design does impact the probability of success as well as the cost. Rather than purchasing independent IP and integrating them, you might consider purchasing a subsystem that has already been integrated and fully tested.

Ron Collett has presented various data points regarding how teams have reduced risk. Figure 1 shows that increasing reuse can help reduce risks in your development.

Figure 1

What other suggestions do you have on reducing development risk?

IP Tools: Do any exist to help us?

bill_martin@mentor.com (Bill Martin) — Thu, 12 Feb 2009 20:27:00 +0000

Bill Martin, Mentor Graphics

If you would have asked me a year ago, few tools or companies were focused on IP quality, reuse and integration. Many managers and engineers complain in the press and at various conferences that problems do exist. If you worked in the IP arena (for example, a supplier or consumer), you had first-hand knowledge of quality and integration issues. There are existing tools from Mentor Graphics (HDL Designer Series), Synopsys (CoreBuilder?), Cadence (ChipEstimate) and Design & Reuse (IP Reuse Station).

In the last six to nine months, I have seen more ‘point’ tools in the press that attack specific issues related to IP. These are not ‘Ron Popeil/Veg-O-Matic-like’ tools (that “does everything to the low cost of $19.95 with lots of extras given away for free”), but at least some point tools are being developed. You might explore the following companies for additional point tool solutions:

Atrenta http://www.atrenta.com/
Fenix Design Automation http://www.fenix-da.com/
NXP/IP Extreme QCore http://www.ip-extreme.com/
Satin IP http://www.satin-ip.com/

I am sure that other companies exist or will be started. Clever people are listening to the IP issues and they are determining how to provide a solution that creates value for all concerned.

If your company has other IP-related tools, please post your company’s name and product below. I am sure many potential customers would like to see what is available.

Altered States: To Change or Not to Change?

bill_martin@mentor.com (Bill Martin) — Wed, 04 Feb 2009 19:47:00 +0000

Bill Martin, Mentor Graphics

Most people purchase a product and never think about modifying their recent purchase to perform additional functions. If we have issues with these products, we go to the manufacturer or a skilled service provider to fix or replace them, because we know the price of product ‘tinkering’ equals voided warranties and support.

Motive: when it comes to purchased IP, engineers feel they can always improve “off-the-shelf” purchases. The logic says the original designer did not fully understand my specific need, so by adding ‘minor’ tweaks it will enhance the product’s usability. Or will it and at what cost?

Then why do we have different expectations with purchased IP?
Opportunity and Means: Engineers have the opportunity, and means are available to them. Soft IP (RTL) is provided via source code which offers up the opportunity to reconfigure IP. Many engineers can write and understand Verilog or VHDL, providing the means.

So what’s the problem?
Once a modification, however trivial, is implemented on the IP, the original value and purpose created by the IP vendor has been negated. For years, Numetrics has collected various data concerning IC design and the impact of reuse. Figure 1 shows a block that was altered by 25% and the impact on its value. In this case, 25% change reduced the effort saved by 50%. Are the alterations worth the cost?

Figure 1

The verification, validation and compliance work must be re-done to maintain the original value; very similar to restoring an old car back to its original condition. Few people consider restoration due to the amount of money and work required. The same thoughts should be applied when contemplating IP changes. For IP, the industry does not understand how the IP design team constructed their product or the standard (i.e. USB) specification. At least when re-storing or re-tuning cars, you can buy a complete manual with hundreds/thousands of pages on how the car was constructed with complete BOM and specified parts. Over time, this documentation should become a standard offering available for each IP.

How to avoid domino effects?
In my career, I have had teams that quickly implemented a bug workaround believing that they had complete knowledge of the IP’s interactions. While this might have fixed a specific customer’s issue, it created other issues for other customers’ applications. And this is from the original design team. If they could not understand all the interactions, how could a designer with little history with this IP be able to perform surgery?

I have also had teams that quickly thought of a solution but wanted to run full regression tests to ensure that a small change in one area of the design did not cause issues in other areas. These teams understood that given the IP’s complexity and Murphy’s Law, they were human and could easily introduce bugs.

With the growing complexity of IP, I prefer the latter team’s approach. Determine a solution and re-test it with your regression and silicon validation suites to ensure no unexpected bugs are introduced. The latter approach helps improve IP quality.

Each of us wants to add our own value to a project, but maybe the value we add is by NOT touching an IP block that was purchased. If changes are required, go to the original design team and get a quote from them. In the long run, this will be cheaper and faster.

What are your thoughts on altering IP?

IP Futures: Predictions for IP Evolution

bill_martin@mentor.com (Bill Martin) — Wed, 04 Feb 2009 19:40:00 +0000

Bill Martin, Mentor Graphics

IP Past
Engineers have always found ways to help reduce the labor-intensive work in chip design. Long before ASIC and IP businesses were created, engineering teams invented standardized building components to reduce labor costs, minimize variability in critical areas and/or help reduce risks in labor pools with too few qualified personnel.

A perfect example would be an I/O pad design. IC designs will contain many I/O pads that require the same functionality, performance and adherence to latch-up, ESD and process specifications. This requires a skilled physical design expert to layout the pad’s geometries to meet these goals. Rather than developing unique instances for each pad, a common schematic and layout were created to accelerate design and reduce risk. IP Memory blocks and compilers were other key building blocks during this time period and used similar principles.

This was years before the ASIC evolution led by VLSI Technology and LSI Logic. Both companies realized that standard libraries (either gate array or standard cell) would remove much of the complexity and resources required to perform design work. Standard libraries used many similar tools but raised the level of abstraction from transistor to gate level. Another tool, RTL synthesis, allowed designers to write RTL code rather than entering schematics composed of gates. Rather than design 10s of gates per day, now engineers could design 1,000s of gates per day. Block-level IP started to be formed in the early ASIC period and 82xx macros enabled many board level designs to be implemented in single chip ASICs.

IP Present
The level of integration continues as subsystems enter the customer domain, allowing customers to purchase subsystems that incorporate digital, analog (PHY) and small embedded driver SW that were designed and tested as a unit. Subsystems reduce the amount of integration, support and functional issues that customers had when purchasing each piece individually. Subsystems REDUCE risks. It won’t be long before subsystems around specific functionality (i.e. USB, PCI Express, Video, Audio, etc.) emerge. At this point, many of these subsystems are still comprised of individual components, but like Lego Blocks, they are much easier to put together.

IP Future
The above subsystems will eventually be integrated into one block, combining the digital and analog logic into a pre-routed physical file. Reasons for this integration include:

The level of integration at 45nm and below will provide ‘free gates’ and the wasted area consumed by this integration will be small. Rather than have the RTL configured and then synthesized and routed into optimized gates, the configuration will be built into the silicon and users will tie or drive signals to specific values for specific configurations. The configurations would be restricted to ‘non x-Lane’ options, allowing IP consumers to define products that could have on the fly configurability. Inactive gates used in one application might be driven active by control signals within the chip. A simple example would be to use a common SERDES with different, “switchable” Digital Front-Ends for PCI Express or SATA or other applications.
The higher frequencies required by the standard interfaces will require tighter control on the placement of the digital and analog blocks. This will remove one variable that otherwise might prevent subsystems form working. The block will be tuned for a specific process and allow test chips to be supplied to potential IP customers for their evaluation.
There will be fewer foundries/processes for which to create physical blocks. In the past, for each foundry and each process, new physical designs were required. This quickly increased the number of physical blocks required to suit each foundry/process combination. With the Common Platform approach, a process and mask set will work across many foundries significantly reducing the number of variations.

Both IP providers and consumers will benefit from this solution. IP providers will create larger integrated blocks that will not require customer tweaking, thus reducing the amount of support requested. IP consumers will get pre-defined blocks that have built in configurability, have proven silicon and reduce risk. Integration of these subsystems will be much easier than integrating the subcomponents.

What happens to IP from the past? All of these will continue to be migrated to future process nodes. Many changes in process, design and market requirements (decreasing supply voltages, rapidly increasing bit-counts and clock-speeds, noise, radiation, temperature, etc.) pose new challenges that require these IP to be updated.

Tell us your vision of how you think IP will morph in the next 5 years?