Product How-To: Incorporating quality into reusable IP

Today's complex silicon-on-chip (SoC) designs contain multiple instances of silicon intellectual property including CPUs, DSPs, and large numbers of interface IP—SD, SDIO, USB, and MIPI—to store and route video, audio, and data within these designs. On some large SoCs, as much as 85 percent of silicon real estate is made up of third party IP. Given the time-to-market constraints, chips specially destined for consumer electronic devices, the standardization of individual interface IP blocks has made it very attractive to do a make versus buy decision. This has created a large and steady demand for interface IP from third party suppliers, however the expectations of quality for first time success are extremely high.

Beyond shortening time to market, the advantage third party IP provides SoC designers is reducing the design resources needed to build a large system on chip while mitigating risk. To deliver these benefits, IP blocks must be as close to plug-and-play as technically possible, considering the variability in complex SoC designs. The worst-case scenario for a customer purchasing an IP block with an error is having to divert resources from the larger SoC effort to help find the problem and even worse being delayed in getting the chip into silicon. Hence pre-silicon verification is extremely important to ensure against a costly respin of the SoC. Silicon proven Interface IP blocks are less likely to cause this problem than those with little or no history. Successive generations of a given interface IP block builds on existing, extensively debugged RTL code, hence maintaining the desired quality.

The key element of a successful IP block is being able to seamlessly integrate into a larger design, especially with the myriad of internal buses. Seamless integration demands that the interface IP deliverables come with support that understands the SoC's operation in the final consumer application. For example, the support team should have a comprehensive understanding of the USB, SD/SDIO, or MIPI specification as well as internal buses like AXI, AHB, APB, PCIe, PCI etc. and how the IP block will behave within many different SoC environments—cell phone, netbook, video game, digital camera, and the many other consumer electronic products being developed. In addition, the IP blocks must be customizable and verifiable to accommodate the unique requirements of individual customers.

Introduction

Arasan has been in the IP business for the last 15 years, striving to enable technology adoption by providing total solutions for standards-based peripheral IP. Its major advantage is its close participation with the standards bodies creating the peripheral specifications. The company has participated in the definition of the standard for every peripheral IP block it produces. In addition, one of the biggest value-add Arasan offers is providing customization services to integrate the IP into the customers SoC design. This service extends to ensuring certification and interoperability by participating in industry plugfests for PCI, PCIe, USB, Ethernet, MIPI, SD/eMMC; testing with key partners; and testing in commercially available products—PDAs, mobile phones, consumer products.

At Arasan building quality into an IP design from inception begins with a design methodology that targets the root cause of errors: poorly or incorrectly written RTL code, errors that creep into a design during synthesis, and errors in the design's corner cases. Eliminating these errors is essential to achieving a high level of quality. In addition, complex interface IP block deliverables include a large set of design components: requirements, specifications, HDL code, compiled code, embedded software, test plans, test scripts, test results, defect logs, etc. Because the hardware RTL and its associated software drivers are developed concurrently, effective collaboration and communication among these engineering teams, often separated by time and geography, is essential to parallel design and verification. To ensure that team members have easy access to the right versions of code and documentation, a common configuration and change management system is essential.

Ensuring the quality of reusable IP begins with a tool flow comprising a well-developed verification strategy, one that roots out errors that creep into a design during development. The strategy must accommodate customizations provided for individual customers after the IP block has been productized. The verification strategy also demands a well-defined process for tracking and documenting errors identified and fixed, both before and after an IP block is released for licensing. Finally, the nature of reusable IP blocks being modified leads to a proliferation of versions of every IP block developed—a version for each customer, thus leading to continually increasing number of SKU (stock-keeping units) that must be maintained and updated over time. Arasan has confronted these issues head-on to ensure the highest level of quality for the IP blocks it offers. This white paper will detail the process the company adopted to address all these issues.

Designing Quality in Reusable IP

Arasan has adopted a design flow with an aggressive verification regimen that includes conventional simulation, rules checkers, and formal verification tools to predict and eliminate problems that normally only show up much later in the design process. Arasan has adopted SpyGlass, a rules-based checker from Atrenta Inc. that allows design managers to capture design-and-reuse policies, thus correcting poorly or improperly written RTL code and finding errors that creep into a design during synthesis. Arasan adopts the Cadence Encounter Conformal Equivalence Checker to assure code changes or synthesis runs do not alter the logic function. To find difficult-to-isolate errors in corner cases that other tools are unable to locate Arasan uses the Incisive Formal Verification tool from Cadence and the Assertions facility in SystemVerilog to boost verification coverage over 90 percent.

In the simplistic approach to verification, the design team produces RTL code and writes a test bench that applies stimulus vectors to the code and checks the resulting responses against expected ones. The problem in this approach is that much of the design is left untested, on average less than half the code. To boost coverage, design teams run the code through register-transfer-level (RTL) rule checker, such as SpyGlass, which employ "rule decks" that can be written in C or Perl. These decks allow design managers to capture design-and-reuse policies by adding rules without modifying the rule checker. In operation, SpyGlass checks for style limitations, makes sure that the design is using the correct naming conventions, and that the design meets certain norms. For example, when moving a signal from one clock domain to another, does the design adhere to the best practices method? Other checks might include analyzing problems such as latch inference or combinational loops.