In the long run, designing for reuse helps bring products to market faster and with higher quality.
Due to its many advantages, IP reuse is an obvious choice for developers. However, to get the most out of IP reuse, the IP needs to be well defined and constructed for reuse. Some of the generic design considerations one should follow while creating reusable IP are as follows.
- Black box approach: The IP should be defined as a black box, so that the larger system where this IP fits is not impacted by implementation specifics. The methodology to achieve this in an IP is defining clear requirements.
- Interface design: The main aim of any IP is to be used in a larger system consisting of multiple IP blocks. To achieve the black box design approach, each IP block must define its interfaces clearly and use them consistently. In terms of code, this may be an application programming interface (API) or a function's declarations.
- Modular and not processor dependent: With the advent of multiple microprocessors, IP must be defined in a processor-agnostic way. Processor-specific calls and requirements should be identified in a low-level IP layer and clearly defined. It is a good practice to provide a guide for how to port this low-level IP layer to a new microprocessor.
- Testing of corner cases: Standalone IP can be tested in only limited scenarios. System-level test scenarios should be considered for the IP, and code coverage should be documented, including unit testing and system-level testing. Even though IP is often developed to run as a standalone block, system-level scenarios must be used during testing to validate the IP.
Reusing IP provides numerous advantages but comes with a few disadvantages. One of the biggest disadvantages is that the IP is designed for a particular architecture. If the organization has to move to a new architecture, there is a barrier to reuse, because of the significant effort required to learn the new architecture and port the IP to it. This is one of the common problems faced by silicon manufacturers while marketing their products. To gain marketshare and overcome this issue, silicon manufacturers are coming out with well-defined and tested IP for their device architectures. These IP blocks not only configure the hardware and control data, but they also provide APIs for data processing. The terminology varies from vendor to vendor -- some call them user modules (UMs), and some call them components or libraries.
To illustrate IP reuse, consider an example using Cypress PSoC Designer. IP blocks are referred to as UMs, and each configures an internal digital and analog block to work together and implement the required functionality. Though a lot of configurations are device dependent, these UMs are built so that the top-level software can be used across multiple devices, while only the low-level implementation changes according to the device being used. The CapSense CSD UM available in the CY8C21x34 device family generates a set of files whenever CSD UM is selected in the project, as illustrated below.
Workspace explorer -- CSD UM in Cypress PSoC Designer.
The CSD.asm file implements all the low-level APIs required for configuring and communicating with the hardware. For example:
- CSD_Start () is used to configure the hardware analog and digital blocks for capacitive sensing functionality.
- CSD_SetRefValue() changes the reference value of the comparator.
As can be seen from the description of these APIs, they interact with the hardware by modifying or configuring some of the parameters. The CSDhl.asm file implements all the high-level functions employed by the user when designing the application. These APIs primarily implement abstractions and ensure that developers do not have to worry about low-level implementation details. This allows the developers to focus on coding the main application. Here are some of the high-level APIs from CSDhl.asm.
- CSD_InitializeBaselines() initializes the baseline for all the sensors. This function internally calls the low-level function for scanning each of the sensors. Once the result is obtained, it initializes the baseline of the sensors with the current raw count.
- CSD_wGetCentroidPos() processes the raw counts obtained from the low-level functions and implements the software algorithm to calculate the centroid or to obtain the position of a finger on a slider.
The important thing is that these high-level functions do not change from one device to another, thereby allowing the developer to reuse the same code developed for one device on another device.
This column discussed the methodology to extend the IP concept to system design. The advantages to the IP reuse approach outweigh the initial investment required to create the IP. The first product where this IP is created might include some features not required immediately. In the long run, however, designing for reuse helps to bring products to market quicker and with higher quality. OEMs can also anticipate lower development costs with future products, hence justifying the initial investment.
Richa Dham is a product apps manager for the PSD division at Cypress Semiconductor. She has 13 years of experience with semiconductor companies and holds a master's degree in electronics and communication from the Indian Insititute of Technology (IIT), Delhi.
Pushek Madaan is working with Cypress Semiconductor India Pvt. Ltd. as a senior application engineer. His interests are in designing embedded system applications in C and assembly languages, working with analog and digital circuits, developing GUIs in C#, and (above all) enjoying adventure sports. He can be reached at firstname.lastname@example.org.