PRODUCT

Breker, the SoC Verification Company, has set the bar for SoC verification.Breker's TrekSoC product is the first commercially available tool that automates the creation of portable self-checking C test cases for multi-threaded, multi-processor System on Chip (SoC) devices. TrekSoC verifies system integration and connectivity, plus it can generate aggressive and sophisticated test cases for the verification of concurrent, coherent multi-threaded capabilities. In production use at top semiconductor companies, TrekSoC integrates easily into existing verification environments.

TrekSoC

TrekSoC supports a natural thought process about SoC verification, helping you "mind map" how the SoC should work and what the test flow should be. It helps you create scenario models that define your verification space in a textual or an intuitive graphical form, allowing you to deliver a modular, extensible and scalable solution for the functional verification of complex SoCs.

The tool generates self-checking C test cases that target all aspects of system level verification and are portable amongst execution platforms.

Figure 1: TrekSoC in Verification Flow

Benefits

Key benefits of TrekSoC include:

• Modular, Extensible and Scalable solution for SoC Verification


• Flexible, Incremental Deployment with high ROI


• Visualization and Coverage Analysis of Verification Scenarios


• Reusable Verification Modules

Modular, Extensible and Scalable

Figure 2: SoC Scenario Models

In Figure 2 above, the modules in purple are provided as part of TrekSoC and the modules in green are provided by the user. The various levels of scenario models are discussed further below in the section titled Underlying Technology.

TrekSoC takes as input a hierarchy of scenario models. Lower level models provide randomized services to higher level models, and higher level models may apply constraints on lower level models to control randomization of the provided services.

TrekSoC provides a number of generic system services. These services are extensible to use SoC specific information about memory maps, testbench BFMs and system management operations.

These system services are used by driver scenario model that focus on individual IP level operations. Application scenario models constrain and combine driver scenarios to define use cases. Performance scenario models constrain and combine application scenarios to define performance benchmarks.

This hierarchy of scenario models is used for constrained random generation of SoC tests. Each test, written out as C code for each of the processors within the SoC, takes the form of a randomized micro-kernel running randomized applications. Applications call randomized drivers for each IP component to test possible system interactions. Applications and drivers can request randomized services that are provided by the micro-kernel.

Easy Learning Curve

Scenario models are developed in C using a simple paradigm of graphs and graph constraints. There are only a small number of constructs to learn.

The TrekSoC hierarchy of scenario models has been designed to mimic the hierarchy of services provided by a Linux kernel. This allows for a simple software metaphor that unifies all scenario models.

At test generation time, as opposed to test run time, TrekSoC makes constrained random decisions about services in order to stress system interactions. This strategy yields individual test cases that are light weight, repeatable and simple to debug while allowing sophisticated constrained random decisions to be made for each of the services.

Flexible, Incremental Deployment

Figure 3: ROI on Effort

The modular and extensible nature of scenario models allows verification components to be incrementally constructed and enhanced as project priorities dictate. As verification modules are added or enhanced, the verification search space grows allowing the generation of additional randomized tests.This makes it attractive to start with a limited deployment of TrekSoC and incrementally expand the verification scope and coverage as resource and project priorities allow.

Visualization and Coverage Analysis

Figure 4: Visualizing Scenario Models

The modular graph-based structure of scenario models makes it possible to visualize the possible search paths and the constraints applied to those paths. TrekSoC provides reachability analysis on the scenario model that highlights unreachable test cases. These visualization capabilities make it convenient to review the SoC verification model for completeness.

TrekSoC tracks the paths through the model that have been exercised. The achieved coverage can be visualized as a hot-spot graph and analyzed to ensure that cross coverage cases of interest have been exercised. .

Reusable Verification Modules

The modular organization of scenario models enables reuse across projects, derivatives, and new SoC platforms. For example, an IP driver scenario model contains no system specific information and can be used with any SoC that incorporates that IP.

Environment Integration

This section discusses integration of TrekSoC into various types of SoC verification environments.

Fullchip RTL Bench

Figure 5: Fullchip Environment Integration

We define a fullchip environment to be one that contains the processor models and runs C test code.TrekSoC generates C test cases that are compiled and run as normal on the embedded processors.

TrekBox is a System Verilog module, provided by Breker, which is instantiated at the top level and active when running TrekSoC test cases. The TrekBox module is provided with a hierarchical RTL path to an address in system memory that will be used as a mailbox.

When TrekSoC generates a C test case, it also generates an events file for consumption by TrekBox. This events file contains the testbench operations, such as the manipulation of an external signal,which are required for running the C test. Each required event is given a unique event id. When threads in the C test case reach predetermined execution points an event id is sent to TrekBox to trigger the required testbench operation. These actions are performed through the DPI interface. Events only flow from the C test to TrekBox.

In simulation, TrekBox is used to manage debug tracing, driving and checking testbench BFMs and using backdoor memory accesses for offloading results data, saving simulated processor cycles. Debug messages and expected results are stored in the events file to reduce consumption of system memory.

Transaction / IP Unit RTL Bench

Figure 6: Transaction and IP Environment Integration

This is a verification environment where the processors are replaced by Bus Functional Models (BFM), or the IP blocks are directly driven by transactions. This may be done to improve simulation speed or to provide additional test control or observability.

In this configuration TrekSoC dynamically creates transactions for the processor and other BFMs. This provides better debug observability since the dynamic state of the system is known at the time of a failure. In this mode test generation may be reactive to system state.

The same scenario models are shared between the fullchip and these transaction environments.

The dynamic flow can also be used to reproduce failing test cases in an IP unit bench.

Target Aware Test Generation

TrekSoC provides several options to control test generation depending on which platform the test will execute on. Processor sequences can be generated as a C test or transactions driven througha BFM.

In the case of C tests, testbench operations are performed by TrekBox using the event id mechanism. The event id mechanism itself may be customized for each platform.

Data checking can be offloaded to the testbench via backdoor memory accesses if appropriate or processor cycles can be used to compute checksums (while continuing to service IP completions) on actual data when necessary.