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?

The second level, which builds on the first, is the application level. Here the focus is on verifying complete paths that represent application use cases for the SoC. Verification engineers ascertain whether the SoC can perform the necessary functions, whether multiple paths can be exercised concurrently, and whether there performance bottlenecks.

The third level is the functionality that only exists at the system level, such as power and clock management. While pieces of the functionality are distributed among the blocks, the main controllers reside at the full-SoC level.

Collectively, these three verification levels make up the integration engineer's responsibility, and information necessary to perform each task is somewhat different. The verification approaches are also different from those of block-level verification.

Defining SoC verification tasks
While there is variability in the way that companies approach SoC integration verification, they probably include many of the tasks in the following list, each designed to answer a particular set of questions. These tasks represent a refinement of the previous three levels of integration verification:

???Connectivity. Can each processor access all of the memories and other peripherals within the system? Does everything get reset to the right state? Are the fields within register words mapped correctly? Is the memory map correct? This is part of driver-level verification.
???IP integration. Can a processor read and write to all of the registers of an IP block? Can DMA move data in and out of each block and are the correct interrupts generated on completion? If there are any GPIO pins on the chip, are they multiplexed correctly? This is also part of driver-level verification.
???Use cases. Can data move through the system correctly to perform defined tasks? This may start with single tasks and extend to multiple concurrent tasks. This is part of application-level verification.
???Performance testing. Under worst-case conditions, does the system perform with no loss of fidelity, dropped data, or other conditions that may cause unexpected degradation of system functions? This is another part of application-level verification.
???Stress testing. When multiple random tasks are initiated, can the system handle concurrency, maintain data coherence, deal with multiple interrupts, and retain data integrity? This is the closest verification category to techniques used at the block level. This type of verification may also be used for power and thermal analysis of the chip. This is a further part of application-level verification.
???System management. Do system-level features such as clock and power management function as intended? Do changes of configuration at this level affect the results of any of the other verification tasks? Typical scenarios trigger transitions in the system power states and execute IP operations to verify that blocks are behaving correctly under these conditions. This is system-level verification.

While this list represents some of the tasks expected during integration verification, most verification teams do not move beyond connectivity and basic integration verification. As shown in figure 1, such teams address only the tip of the iceberg, leaving the more advanced SoC verification tasks underwater and unexecuted.

Figure 1: Many SoC verification tasks remain underwater.

Lack of specialized tools
SoC integration verification is usually performed with the same techniques used for block-level verification. Historically, verification was performed using a suite of directed tests, each specifically hand-written to verify a particular feature or aspect of the block.

Over the past decade, many companies have adopted constrained-random verification using languages such as SystemVerilog or e. This allows multiple tests to be created from a set of verification models and enables aspects of the block to be tested that may not have been explicitly considered. Only when constrained-random stimulus fails to verify specific or required cases are directed tests written.

However, as size and complexity of designs grow and as engineers attempt to use constrained-random techniques for SoC integration verification, they are finding it to be less successful. Simply put, constrained-random is not effective at exercising a specific function.

In addition, constrained-random stimulus is a "shotgun" approach where it is difficult to get focus on any particular aspect of a design. Verifying the complete functional space requires redundancy, which translates to an inefficient process.

?First Page?Previous Page 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