TrekSoC automatically generates self-verifying C test cases to run on the embedded processors in SoCs. This verifies your chips more quickly and more thoroughly than an external testbench, hand-written C tests, or running only production code on the processors. TrekSoC’s generated test cases target all aspects of full-SoC verification and work in a variety of different environments.
- TrekSoC Flow
- TrekSoC Scenario Models
- TrekSoC Services
- TrekSoC Incremental Deployment
- Integration into Full-Chip RTL Testbench
- Integration into Transaction-Level/IP Component RTL Testbench
- TrekSoC Visual Coverage
- TrekSoC Test Case Visualization
TrekSoC supports a natural thought process about SoC verification, helping you “mind map” how the SoC should work and what the verification 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 SoCs.
From your scenario models, TrekSoC generates the embedded C test cases and connects to the input and outputs of your SoC without requiring a complete testbench. This provides completely automated controllability and monitoring of your SoC.
The benefits of TrekSoC include:
- Modular, extensible and scalable solution for SoC verification
- Flexible, incremental deployment with high return on investment (ROI)
- Visualization and coverage analysis of verification scenarios
- Reusable verification modules
TrekSoC Scenario Models
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, bus functional models (BFMs) and system management operations.
These system services are used by driver scenario models 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 generation of SoC tests. Each test, written out as C code for each of the processors within the SoC, takes the form of a constrained-random micro-kernel running constrained-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.
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 efficient, repeatable and simple to debug while allowing sophisticated decisions to be made for each of the services.
TrekSoC Incremental Deployment
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 constrained-random 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.
TrekSoC provides a framework of scenario models that are used to generate C test cases. Each test case takes the form of a randomized micro-kernel running applications that drive individual hardware devices to verify possible system interactions. TrekSoC-Si provides the same set of services, so the following applies to both products.
Scenario models may request system services that are provided by TrekSoC. The key services available to scenario models include:
|Memory Management||Allocates/frees memory buffers on demand
|Register Access||Allows scenario models to request randomization, writing and checking of register value
|Scheduler||Enables tasks to be flexibly scheduled sequentially
|Interrupts and Polls||Automatically generates interrupt handlers and non-blocking poll loops|
|System Management||Randomly switches clocking and power modes (scenario models may ask for a specific device to be powered up for the duration of an operation, possibly allowing for intermittent power downs during the operation to test state retention)|
|Testbench Actions||Allows scenario models to request arbitrary testbench activity to drive and check I/O interfaces or other testbench events|
|GPIO||Allows scenario models to request specific system GPIO routings|
|Debug Facilities||Allows scenario models to log various levels of diagnostic messages through automatic generation of diagnostics on thread progress and memory state|
|Data Checking||Allows scenario models to request checking of memory data buffers against an array of expected data|
|Timing Checks||Allows scenario models to request checking that the elapsed time between two events falls within a specified range; timing checks may be implemented using either elapsed simulation time or, if available, an onboard timer|
Integration into Full-Chip RTL Testbench
The flexible architecture of TrekSoC enables it to be integrated into multiple type of verification environments.
TrekBox is a SystemVerilog module, provided by Breker, which is instantiated at the top level of the SoC testbench and becomes 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 external input signals, 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.
Integration into Transaction-Level/IP Component RTL Testbench
In this type of verification environment, each processors is replaced by a bus functional model (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 full-chip and transaction-level environments.
The dynamic flow can also be used to reproduce failing test cases in an IP component testbench.
TrekSoC Visual Coverage
The modular graph-based structure of scenario models makes it possible to visualize the possible 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. This scenario-level coverage is complementary to traditional coverage metrics.
The modular organization of scenario models enables reuse from the IP component to the SoC level and 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 the IP component.
TrekSoC Test Case Visualization
TrekSoC provides industry-leading visualization of the multi-threaded, multi-processor C test cases that it generates. These test cases are far more complex than could be written manually, so this visualization is essential for debug when a test case uncovers an error in the SoC design.
As an example, the scenario model for a digital camera may includes multiple, parallel data paths. TrekSoC will analyze this scenario model and generate a test case that stress-tests the design by running multiple streams of multiple user scenarios in parallel, with the streams crossing back and forth between multiple threads on multiple processors.
Digital Camera Test Case Visualization
The complex test case generated for the digital camera design by TrekSoC can be visualized in a display that shows all threads across all processors and how the streams of user scenarios are scheduled across these threads. The red arrows follow a typical real-world user scenario built from three driver scenarios: reading a JPEG-encoded image on a USB port, decoding it using the still image processor, and displaying it on one of the camera’s screens.
This unique visualization display is generated by TrekBox, the module of TrekSoC that runs in simulation to coordinate activity between the testbench components on the SoC’s I/O ports and the test case running on the embedded processors. TrekBox updates this display in real time as the simulation progresses, coloring driver scenarios green as they are completed. In this example, the test case has hit a user-defined breakpoint in the code for the driver scenario colored white.