Verification issues for reconfigurable IP (Actel)

IP vendors have found a variety of ways to configure IP blocks to improve reusability, such as RTL parameters, automated netlist generation via a Web interface and netlist generation via a software graphical user interface (GUI). The most flexible approach is to deliver register-transfer-level code with a testbench, which offers the most freedom for use and reuse, but is also the most difficult to change without breaking the code. A more conservative approach is to deliver the RTL with scripts or top-level parameters that configure the RTL based on the user's input to a GUI. The user never actually needs to touch the RTL, but instead selects the features and configuration of the IP block with a GUI that outputs the scripts to set up the RTL for synthesis. This limits the configurability to the range verified by the IP designer while giving users the flexibility to tailor a core to their application.

There are many ways to deliver IP from highly configurable RTL code. These methods can require extensive verification to netlists, thereby limiting configurability and reducing the amount of verification required after a change. Each approach provides the user with some degree of configurability, but with varying degrees of direct interaction with the RTL. Reducing interaction with RTL is desirable because it limits the potential for the code to be broken and thereby reduces the need for verification.

Whatever the IP delivery method, verification is an issue that needs to be addressed by the IP creator and system integrator. There are clever ways to deliver verified IP, but as flexibility increases, so does the user's effort for verification. As a rule, the more configurable an IP block is, the more verification will be required on the part of the user.

Shades of verification
There are several levels of verification that users should consider before they use an IP block. In some applications users are required to certify their final application no matter what IP they use. In these cases, users may be more inclined to modify the IP and customize it further for their application because they will have to extensively verify

their final product anyway. In other applications the user's desire for customization should be balanced with the accompanying need for verification.

One can imagine at least four levels of verification: simulation, hardware, hardware against a standard tester and third-party verified hardware (validation or certification).

Simulation with a testbench is the simplest, but provides less assurance than other levels, which more thoroughly verify the IP with hardware.

The validation in level four is the toughest because the verification is completed or overseen by a third party.

Beyond verification, the trend is toward more complex IP blocks performing a larger portion of the SoC system functions. As a result, there is increasing emphasis on reference designs and turnkey SoC solutions that are preverified at the block and system level.

Preverified reference designs and systems with a standard bus allow a configurable preverified block and the RTL to remain untouched. This multiple-block SoC IP is configured similarly to the range of methods used to deliver IP from highly configurable RTL code, but the parameters specify a bigger function, such as I2C or an Ethernet media-access controller. The system integrator can then add blocks to differentiate a product and achieve quick time-to-market.

Ian Land (ian.land@actel.com) is senior IP product manager at Actel Corp. (Mountain View, Calif.).

IP vendors have found a variety of ways to configure IP blocks to improve reusability. The most flexible approach is to deliver RTL code with a test bench, which offers the most freedom for use and reuse, but is also the most difficult to change without breaking the code. Source: Actel Corp.