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

Overcoming challenges for SoC verification team

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

Keywords:verification engineers? block-level? IP?

The inefficiency and ineffectiveness of the constrained-random approach is contributing to the SoC verification process growing out of control.

One problem is that sequential constraints or guidelines are difficult to describe in the existing testbench languages. The Universal Verification Methodology (UVM) standard provides guidelines for describing sequences and layering these into higher-level sequences. However, it is difficult to control dependencies between sequences, limiting the effectiveness of SoC-level testbenches. In addition, the UVM does not address embedded processors within the SoC; testbench languages were designed for transaction-based verification of hardware, and not the control of multiple pieces of concurrent software.

Further, it is difficult to fully exercise a large design by manipulating only its inputs, whether via hand-written directed tests or constrained-random stimulus. Software running on the embedded processors plays a critical part in the functionality of the SoC. This argues for a new method that encompasses both the code running on the SoC's embedded processors and the testbench connecting to its inputs and outputs. This method must be able to handle multithreaded processes running on multiple processors within the SoC and coordinate multiple concurrent activities within the chip and with the testbench.

Ideally, the new approach should be able to span all the SoC integration verification tasks shown in Figure 1, from the tip of the iceberg to its deepest point.

Approach to solving SoC verification problem
A new method for SoC integration verification considers verification goals and the design of tools that can find valid, but randomized, ways of achieving those goals. Solving this problem requires a focus on the goals and outcomes rather than the input stimulus. In order to solve this problem, the focus needs to shift from stimulus and to goals and outcomes.

Tools should be constructed that can find ways to meet the goals and provide a sample of the possible ways those goals can be achieved utilizing different parts or paths through the system.

The information necessary for a tool to do this can be divided into four main types:

???Register and Memory Map. In order to know how to talk to each IP block, it is necessary to know how they can be accessed by each processor in the system. Software needs to know how the bit fields or registers are laid out and any relationships or dependencies that may exist between them, often described in an IP-XACT description of the system. This information is necessary for driver-level verification.
???Driver Models. While it is necessary to have models for blocks in the system, these do not have to be complete functional models. Instead, sparse models may be used which only describe aspects of the block necessary for SoC integration and verification. Models should be reusable in both a vertical and horizontal manner. Vertical means that a model can be incorporated into a subsystem model and that, in turn, can be incorporated into a larger system model. Horizontal means that generic operations can be defined and quickly adapted for specific needs. This information is necessary for driver-level verification.
???Application Models. What is the system meant to do? A model such as this is ideally developed incrementally. Waiting until all the use cases have been defined to start performing the verification is not necessary. As new use cases are added, or exiting ones refined, new spaces in the device can be exercised. It should also be possible to measure verification coverage by looking at possible paths that have been exercised through this model.
???System Models. As previously discussed, today's SoCs include a significant amount of functionality at the system level and this is increasing in size and sophistication. Power and clock management can affect all aspects of device performance.

This level of information is sufficient to automate SoC integration verification. It is possible for a tool to automatically generate self-verifying C test cases that are compiled and run on the embedded processors. These test cases verify every aspect of the intended top-level SoC functionality while not repeating the UVM-based testbench verification typically performed at the block level. Multi-threaded test cases stress the SoC RTL design, especially resources such as bus fabrics and memories shared by multiple blocks. This exercise of parallel behavior is also effective at measuring system-level performance under stress conditions.

An example of this approach is the TrekSoC tool from Breker Verification Systems, shown in figure 2.

The user starts by defining outcomes and then configuration settings, conditions or stimulus that can produce or modify those outcomes. These are called scenario models, and they span the driver, application, and system levels described previously. These models can be built up in a hierarchical manner either through composition of lower level models or through refinement of existing models.

As more information becomes available, higher levels of verification scenarios can be generated. The tool takes these scenario models along with an IP-XACT register and memory map and, for each user-defined goal, finds ways to make that goal happen. It will then pick a random solution and generate the necessary self-verifying C code to turn that goal into a scenario running in simulation. In this way the test cases can orchestrate multiCPU and multithreaded verification scenarios.

Figure 2: An SoC verification tool can automatically generate self-verifying C test cases that are compiled and run on the embedded processors.

As shown in figure 2, the tool also generates the SystemVerilog TrekBox module to interface with existing UVM testbench components on the SoC's inputs and outputs. This is necessary since some scenarios will entail reading data into the chip or sending data back out.

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

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


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

Back to Top