A Probability Formula for IP Integration

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 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 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 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:

1. 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.
   
2. 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.
3. 
   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?