Global Sources
EE Times-Asia
Stay in touch with EE Times Asia
?
EE Times-Asia > EDA/IP
?
?
EDA/IP??

Overcoming challenges for SoC verification team

Posted: 30 Aug 2012 ?? ?Print Version ?Bookmark and Share

Keywords:verification engineers? block-level? IP?

As system-on-chip (SoC) designs have become ever more complex, verification engineers have grown in importance to become an integral part of a product's success. With more SoCs being designed, there is a growing class of verification engineers who are woefully under-appreciated in terms of the complexity of the job they have to do and the lack of tools made available to them. These are the engineers given the responsibility for integration verification as well as system verification and validation.

This article defines the unique problems that SoC verification engineers face in their jobs and outlines an approach that provides a level of automation for them similar to that enjoyed by block-level verification teams. It also discusses longer-term implications of this approach within the overall SoC development flow and demonstrates that a higher level of abstraction is necessary for efficient and effective verification.

The unique SoC verification problem
High-end chips may contain 200 or more discrete IP blocks. Many of these blocks come about as part of the system design process, where functional needs are identified and those that do not offer product differentiation are fulfilled by an existing IP block wherever possible. This leaves the in-house design engineers to concentrate on the most differentiated functions: the high-value parts of the SoC.

What about the integration of these blocks? IP blocks can come from many sources, including internal design teams, development partners, EDA vendors and third-party IP providers. All these blocks need to be integrated with new blocks being designed for use within the particular SoC.

Some blocks may have been designed for reuse, which means that they likely will have several modes of operation or ways in which they can be used or configured, with only a few of these options actually used. Some are parameterizable and some may have been modified to fit the particular set of design requirements unique to the current design. Blocks may be at different levels of stability and quality. They may or may not come with testbenches designed to demonstrate that they function correctly in a standalone environment. Most testbenches are of little help when it comes to stitching blocks together and verifying that they can collectively perform a useful function.

This is the nightmare that the SoC integration verification team must face.

One of the reasons why SoC design is based on the divide-and-conquer approach is that it is too difficult for any one person to fully understand the total functionality. The same is true for verification because the task should be divided such that each aspect of verification can be performed by different people, possibly with different skill sets.

Redundancy between these verification tasks must be minimized. For example, there is no point in having integration engineers repeat verification that has already been performed at the block level. Each block has been verified in a standalone manner and thus, when integration verification is performed, the team should not attempt to do this task again.

Instead, the verification should focus on ascertaining that the blocks have been connected correctly and that collectively they can perform the necessary system-level functions. In addition, there are certain types of functionality that only become apparent and verifiable at the full-SoC level CC the ability to support concurrency, power and clock management, for example, and performance issues such as throughput and latency.

SoC integration engineers must perform three levels of verification, in addition to the block-level verification generally performed by different groups. Naturally this testing must be done at the "bare metal" hardware level, with no production operating software or drivers. However this article uses the metaphors of "drivers," "applications" and "performance" borrowed from operating systems.

The first level is the driver level where the integration verification team concentrates on the ability of blocks to effectively communicate with each other. This communication is most commonly between a processor and a peripheral, but could also involve DMA engines, memory subsystems or other infrastructure blocks. This level establishes that the necessary communication paths are functional.

1???2???3???4?Next Page?Last Page



Article Comments - Overcoming challenges for SoC verifi...
Comments:??
*? You can enter [0] more charecters.
*Verify code:
?
?
Webinars

Seminars

Visit Asia Webinars to learn about the latest in technology and get practical design tips.

?
?
Back to Top