IP Verification : Building systems at the silicon level: time, cost, design constraints

Users of programmable logic devices (PLDs) are ahead of ASIC designers in this area because PLD reprogrammability makes fast, low-cost IP verification in silicon a reality. The first component of this head start is that IP developers can assume a common design environment for much of the PLD-using community and it is possible to restrict verification to a popular but limited set of design flows they use. Also, PLD vendors offer tools and design flows specifically targeted at easing the integration and use of IP.

PLD IP should be prepared or "packaged" so that it can be used in multiple designs. The IP developer's first step is to develop HDL and a test bench of the product. If appropriate, the HDL should be parameterizable so the user can customize the IP. Using architecture-specific features such as DSP blocks and memory will produce the best performance results. Any IP with timing requirements should include a set of standard constraints. Support for the Synopsys design contraints (SDC) scripting style is also valuable. It allows users to pass timing constraints from commonly used synthesis tools directly to some FPGA place-and-route engines. p>

PLD vendors offer tools for packaging IP that automatically generate graphic user interfaces (GUIs) that can be used across many operating systems, improving the adoption rate of these cores.

Many IP cores include an on-chip bus (OCB) interface. When targeting an ASIC with such IP, an IP developer must verify that their core can interface with other cores via the OCB. To accomplish this, they must often gain access to these other cores to check interoperability, which adds logistic delay to the already lengthy simulation process. In comparison, verifying an IP core's OCB interface in PLD hardware takes much less time than it takes to completely simulate the same ASIC-based system. Any incompatibilities or problems can be addressed with quick revisions to actual hardware, which is impossible in ASIC-based designs.

PLD vendors offer tools that speed the assembly of designs using OCBs. This is possible because the PLD vendor can define a standard in which IP vendors can specify IP ports and their connections, allowing process automation. For example, Altera's SOPC Builder relies on a text file called a class parameter template file (PTF) to declare the parameters, port definitions and GUI display of a given IP core. After an IP developer creates a PTF file for their core, it can be easily integrated into a PLD design and verified with one of Altera's development kits along with the rest of the system and software to verify proper functionality.

With PLDs, it is possible to make placement, pin and timing constraints to an IP core that are portable across devices in a family. These constraints define the placement of the design within the device. This is advantageous compared to ASIC flows for IP development because it takes less time to develop PLD constraints that are optimized all the way through place-and-route.

The final step before making an IP core available is encryption. PLD vendors offer tools that enable the encryption of IP cores without hindering their evaluation by users.

Verifying systems with IP cores from different vendors may require scrutinizing their internal operation; major PLD vendors provide this capability. It is possible to use the embedded memory of a PLD to capture internal signal behavior before routing it to external pins for analysis.

Another challenge that has impaired SOC designs in the ASIC domain is the inability to analyze a complete system, including software, in a silicon environment at full speed before purchasing the IP (and perhaps a mask set). While some simulation and emulation systems provide a silicon environment, they do not provide the ability to analyze the entire system including the software at speed. In contrast, PLDs allow users to achieve this rigorous and complete evaluation of their entire system at the actual operating speed of the end product.

System-level tools should be able to automatically generate much of the logic and interconnect necessary to integrate components, as well as create correspo nding VHDL or Verilog output files. In the case of multiple masters (such as two processors, or a processor and a DMA), the tool should automatically generate the arbitration logic. For example, SOPC Builder from Altera uses a technology called slave-side arbitration to optimize the performance of a multi-master system.

Software designers require a complete development environment to match this custom-built hardware. Some of the new tools automatically produce such an environment. For instance, when SOPC Builder generates a hardware system, it also creates corresponding software components to ease software development. These software components can include some or all of the following: header files, generic peripheral drivers, custom software libraries and OS/RTOS kernels.

Such a development environment promotes better design coherency between hardware and software engineers. Changes to the hardware are immediately reflected in the software development environment. As long as the software tea m has access to the latest header files, libraries, and drivers, both teams can work to the same goal.

See related chart