Tracking Re-Use Of Design IPs

Design teams have a great incentive to create design blocks or IPs that can be reused: Each time an IP is successfully reused, precious time is saved from project schedule. Of course, as easy as it sounds, achieving this goal in real life is not simple. In reality, the observation is that design libraries cannot be used as-is by multiple projects.

Consider this scenario: A smart new graduate design engineer came up with a good design for an I2C IP. An I2C IP is a basic building block required by a number of AMS chips and SOCs alike. The application of this IP typically includes interfacing with DACs and ADCs, volume control for intelligent speakers and accessing real time clocks and NVRAM. There is a good chance that projects using this reusable IP would end up speeding up the design cycle. This seems like a great return on investment for hiring a new graduate!

As the IP gains popularity in the organization, the IP creator often gets feedback from the consumer of his IP. Some of the modifications suggested may be great ideas to be incorporated in the design and implementation of the next release of the IP.

While contemplating the modifications to the IP based on feedback from one of the consumers, the creator must consider its impact on other consumers. It is important for the ongoing reuse of the IP that it does not adversely impact the other consumers of the IP. A practical case is being made in the organization for reuse of IP, in more generic term – an IP reuse methodology. A design management system’s ability to track the consumers of its IPs is a critical function.

SOS7 has a referencing feature that allows the IP owners to track the usage of their IPs. The design management system is capable of generating detailed reports that includes who is using what release of the IP. From an organization standpoint, tracking this information is critical. Figure 1 shows two projects – the microcontroller project and LED driver project both using the IP reuse methodology. While both projects use the SPI IPs in their design, the microcontroller uses release R3 of SPI while LED driver uses release R2. This is a critical piece of information for the SPI IP owner to have tracked. In cases where a critical bug was discovered in a release of an IP, the IP authors can find the consumers who are using the IP and alert them. This could potentially save the consumer project from disaster. SOS7’s referencing feature also tracks if and when the consumers upgraded their release. This is even more critical if you are developing products for specific industries such as the ISO 26262 compliance for the automotive industry.

Figure 1: IP reuse – Different projects use different versions of the underlying IP

The IP reuse methodology poses another problem that needs to be addressed upfront: Collision of IP releases. Say you have a design project – the microcontroller. It uses an on-chip I2C and SPI IPs. In turn, these IPs use other IPs, such as the autobaud IP. However, the designers of the I2C and SPI IPs may be using different releases of the autobaud IP. This is an issue that may be difficult to track down. This could be an expensive problem to solve if the microcontroller gets taped out with the autobaud IPs behaving differently for SPI and I2C communications. SOS7 allows the microcontroller team lead to generate a detailed bill of material that would flag any such collisions in the IP releases. This is a valuable tool in any design manager’s toolbox.

Figure 2: Collision on IPs modules

Reusing IP is potentially a great methodology for increasing the productivity of the design team. However, it needs to be implemented with practical scenarios covered and considered. Using tools to catch potential pitfalls is a much-needed approach to making design reuse successful. It is also important to be able to trace the hierarchical usage of an IP so all users can be alerted of critical issues and new releases.