Effectively Managing Maintenance Cost For Low-Touch IPs

Semiconductor design houses are in a race to differentiate themselves by integrating and delivering more functionality in their SoCs while addressing the common concerns of power, performance and cost.

This global race has led to a steep rise in the number of design IPs integrated in any given SoC. As generations of SoCs are churned out, some of the design IPs repeatedly used in them reach a state of nirvana. They are still useful and required for current SoCs, but from a development point of view they have transitioned to a mature state, as their specifications have stabilized and aren’t changing much. These class of design IPs are now commonly being referred to as low touch IPs.

The low touch design IPs are typically integrated into the generation of SoCs with very few changes. Changes are in the form of updating few configurable parameters, editing of control/status registers, address space allocations or number of instances changes to meet the requirements of the target SoC. Some examples of low touch IPs are timers, legacy interrupt controllers, general purpose IOs (GPIO) and real time clocks (RTC) etc.

SoC manager’s challenge: Engineering resource allocation
Ideally, SoC managers would wish to invest a minimum number of engineering resources on low touch IPs. That’s because of two reasons. First, low touch IPs do not have sufficient work to warrant dedicated engineering resources and, second, those valuable engineering resources could be doing differentiating work for the active design IP developments.

Low touch design IPs based on their design complexity and configurability take varied time for sanitization and integration. Due to a lack of data on accurate effort required, and the necessary design documentation, owing to the fact that they have been used for a number of SoCs, almost all low touch design IPs gets classified as simple and easy to close. A number of designers will vouch that making this assumption can be risky.

Assigning a bare minimum of a single design and verification engineer to these low touch design IPs quickly adds up to a sizable number. Consequently, it becomes painful for an SoC manager to justify these numbers to the upper management who are looking at design complexity and the rigors of IP integration and verification from ten thousand feet above the ground.

Engineer’s challenge: Trapped in the “simple and easy” bias
On the other hand, in order to optimize engineering resources, engineers are convinced to own and support multiple low touch design IPs by saying there are not many changes required. They are told, “All that is required is few very easy changes, do quick integration and run a few sanity tests to show that design IP is healthy. That’s all!” But unfortunately, that is never the case.

In reality, engineers end up facing the following challenges:

• Low touch design IPs are generally older design IPs. There isn’t much documentation available. Even when it’s available, it’s scattered all over the places. Different teams follow different ways of providing documentation. Some prefer to put it on an internal wiki, some prefer to put it on SharePoint, and so on. Adding to the confusion, there will be multiple copies of the same document as well as multiple revisions with no one sure which version of the specification was used for which version of the IP.
• The real nightmare unfolds when multiple branches of the same design IPs are found. It’s not clear which bugs were fixed in which branch. Engineers will have to manually scan and diff through the code of each branch to figure out which was so-called “latest” branch. Then they have to manually integrate the required and missing bug fixes from the different branches into the selected latest branch.
• Once you get all the required pieces of code in one place, the code just wouldn’t build and compile. Why? It’s not clear which version of scripts and tools were required for this design IP to build, compile and simulate.
• Migrating any analog IPs used to a different process node can often be a challenge as it is unclear which verification test bench was used for which version of the IP.
• Engineers have to trace back through code check-in history to figure out the previous developers to talk to. Previous developers, if still present in the company, will also have partial information about it, as it was all done a long time ago. Everyone is busy with his or her own work. With the limited help, engineers take several weeks to get it to state of the building, compiling and running regressions.
• Then comes the next surprise. Regressions will have failures and coverage reports show a score nowhere near 100%. How can it fail? We have been using this design IP for ages. But there isn’t clear information about the history of regressions and coverage reports from the last SoC where it was used. Without any such references to compare, the situation generally goes out of control.
• After painful work of getting control on regressions and coverage, there are no clear instructions on how to go about making changes to the design IP for meeting the requirements of SoC integration. After engineers figure out the changes required by several weeks of trial and error, the regressions tank once again. This time the test bench wasn’t parameterized and it took additional work to make it all work.

Finally, when engineers make it all work after several months of hard work, they would still be busy justifying why “simple and easy” design IP took so long. All we had to do was just change few configuration parameters. Why did it take so long? Additional engineering resources pulled in to maintain the schedule causes heartache to the SoC manager.

At the end, engineers are just afraid to touch the “low touch design IPs.”

How to address this lack of context challenge?
We cannot arbitrarily call a design IP a low touch design IP. We need to define the process to qualify a design IP as a low touch IP. This process has to be:

• Enforceable in executable format consistently across all the design teams spread out across multiple design sites.
• We need a single central portal to be able to find all the necessary information about the design IPs and all the developers who have worked on it in the past.
• With constant movement of design engineers across different companies, it becomes necessary to capture the knowledgebase for each IP so that designers can go back and look at why a certain decision was made, issues and resolutions, etc.
• We need the metadata and metrics about the design IP to be available as trends on a single dashboard.

The context of low touch design IPs should be able to provide the following documentation, metadata and metrics.

What do I gain by investing in process to qualify and maintain context?
Sounds like extra work?

Yes, there is some work but it has high ROI. How?

First of all, it makes sense to perfect the process of sanitization and integration for key low touch design IPs because the future churn in these IPs is limited. So your uncertainties with these design IPs should be minimized. The last thing you want is SoC schedules slipping due to these low touch IPs.

The SoC design manager can then optimize engineering resources for the low touch design IPs by creating a shared pool of engineers for a group of low touch design IPs instead of allocating dedicated engineers. Engineers from the pool can quickly jump into any of the low touch design IPs, load the context about it, get it integrated in an SoC, sanitize it and move on to the next action. This can directly translate into cost savings on the engineering resources.

Also, it does not tie down engineers to specific low touch design IPs. It creates flexibility to rotate engineers across design IPs allowing redundancy for companies and excitation of something new to learn for engineers.

How to go about it?
Either you can reinvent the wheel to solve this problem in sub-optimal way or look at the designHUB from ClioSoft.

designHUB supports defining the custom workflows needed to qualify low touch design IPs by matching criteria and benchmarks of your organizations and teams. It provides an “IP Reuse ecosystem” which enable designers within an enterprise to share all the metadata and collaterals about the design IP making it easy to discover. Design data can be stored in different places – SOS, Git, Perforce, SVN or NAS. Since designHUB is agnostic to where the design data is stored, it serves as the single portal within the company to access all design information for any IP or SoC.

designHub’s “Unified dashboard” allows easy and central location to track both the design and verification metrics. Metrics provides the clean baseline status at the start of design IP reuse.

Not only you will be able to enhance the IP reuse productivity, save costs on engineering resources, and improve the quality of IPs, but also sustain it throughout the life cycle of the design IP.

—Anand Shirahatti wrote this blog on behalf of ClioSoft.