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 Incremental Deployment
- 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.
TrekSoC in a Typical Verification Flow
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 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.