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?
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?
posted by Bill Martin at
9:55 AM
RSS Feed 
1 Comments:
Test
Post a Comment
<< Home