As system-on-chip (SoC) designs grow in complexity, test suites containing thousands of lines of code for system-level verification continue to be manually written by humans, an old tradition that does not work Make the adage "automate whenever possible." This is especially true for C tests that run on the SoC's embedded processor to validate the entire device before manufacturing.
Automating verification test combinations where possible has been shown to increase productivity at many stages of SoC development. Constrained random techniques, e.g. in Universal Verification Method (UVM) testbenches, utilize random test vectors for specific scenarios to increase coverage. Although these have improved the verification efficiency at the hardware block level, the design is still considered a black box where the incentives, checks, and coverage codes are written separately, which remains a burdensome and error-prone task for large blocks.
Scaling this approach to the system level is difficult given the need to combine processor test code with I/O transactions (usually executed on an emulator or prototype system). In order to properly validate an SoC, the processor itself must be tested. UVM and other constrained random methods cannot solve code running on the processor. In fact, to use UVM on an SoC, the processor is usually removed and replaced with virtual inputs and outputs onto the SoC bus, allowing the subsystem to be verified minus the processor.
SoC verification engineers are aware of the limitations of constrained random test benches, even though they are limited in fully executing the SoC design, forcing them to hand-write C tests to run on the processor for emulation and hardware emulation. These verification platforms are not powerful enough to run a full operating system (OS), so these tests are performed "bare metal", which adds overhead to the writing effort. Handwritten tests (especially without the help of OS services) often cannot run in a coordinated manner across multi-core processors utilizing multiple threads. The result is minimal verification of aspects of SoC behavior, such as concurrent operation and coherence.
Automatically generate C tests
Of course, automatically generated C tests will make more efficient use of engineering resources. They also increase coverage. Compared with hand-written tests, generated C test cases can play more functions of SoC, and can find unimaginably complicated corners. Multi-threaded, multi-processor test cases can use all parallel paths in the design to verify concurrency. They can move data between memory segments to enhance the consensus algorithm and coordinate with I/O transactions when data should be sent to the chip's input or read from the chip's output. The overall effect of this is to increase the coverage of the system's capabilities, usually starting from a characteristically much lower number, greater than 90%.
The test generation software, called Test Suite Synthesis, uses an easy-to-understand graph-based scenario model to capture expected design behavior. These models can be written in native C++ using the Accellera Portable Stimulus Standard, or they can be described visually. Scenario models, created by design or verification engineers, are a natural part of SoC development, as they resemble traditional chip data flow diagrams that might be drawn on a whiteboard to illustrate part of a design specification.
These models inherently contain stimulus, inspection, coverage details, and debug information, giving the generator everything it needs to generate high-quality, self-checking C test cases that affect every aspect of the design. Because they are layered and modular, any tests developed at the block level can be fully reused as part of a full SoC model and easily shared with different teams and across projects. Finally, synthesis tools can decompose a single intent model to provide concurrent testing across threads and I/O ports, all synchronized together.
Advantage Test Suite Synthesis
An important advantage of test suite synthesis is the ability to predefine coverage targets on the intent model. Once the intent is specified, the tool can analyze it to understand the amount of testing that can be done and the functional intent that will be achieved.
For SoC, it can run thousands of tests. Coverage goals can then be set by limiting the intent to test and focusing the tool on key areas. This feature avoids the painful iterative loop in the traditional approach of building tests, running validation tools, learning about achieved coverage and then resetting the tests again and again.
In a typical project for a large SoC developed by a well-known semiconductor company, verification engineers reduced test writing time to 20% of what previously required hand-written tests. Automated techniques produced more stringent test cases, increasing coverage from 84% to 97%. Plus, these models are portable.
A single model can generate test cases for virtual platforms, register transfer level (RTL) simulations, simulations, field-programmable gate array (FPGA) prototypes, or silicon-proven actual chips in the lab.
Debugging is another time-consuming task for engineers, especially at the SoC level. If a test case uncovers a lurking design bug, the verification engineer must understand which test triggered the bug to trace its source. A test case failure could be due to a bug in the scenario model, so it must be possible to associate the test case with a graph that captures the design intent. This process creates highly modular and self-contained tests that are easy to decompose, and therefore easy to spot for bugs found.
Application Scenario
Synthetic test cases can be used for actual use cases (called application scenarios) of the design. For example, consider the digital camera SoC shown in Figure 1.
Figure 1: Example image processing SoC.
SoC block-level components include two processors, peripherals and memory. A simple diagram of the SoC is shown below the block diagram. The diagram includes possible high-level paths that may be exercised during SoC verification. For example, one possible scenario, represented in the top path of the figure, is to read a JPEG image from an SD card and pass it to a photo processor via an allocated area in memory. The image is processed into a displayable form and loaded into a second block in memory. From there, it's passed to the display controller. Of course, each of these high-level blocks is hierarchical in nature, with many actions and decisions being performed as part of the process.
Synthetic tools will undergo random testing and be scheduled appropriately. In its simplest form, as shown, a test might be dispatched into a single thread before the next test, and so on. However, the ability of test cases to stress the SoC comes from interleaving applications across multiple threads and multiple processors. The tool will run multiple applications in parallel with the concurrency support inherent in its design, allocating memory in as winding a fashion as possible. In the figure, this is also shown as an alternative, where the tests are spread across three threads, utilizing various areas allocated in the SoC memory.
Of course, this example is shown at a high level to keep the process clear. In effect, the hierarchical graph will be flattened by synthesis tools, creating a large number of actions and connections. These will also include stochastic decisions, which need to be run through the solver algorithm. As the graph moves, an AI planning algorithm is employed that examines the desired output and optimizes input tests to match this output. Synthesis tools include OS-like services that allocate memory, provide address-mapped access, handle interrupts, and complete other tasks required by the test structure. Then schedule the tests randomly, and allocate storage and other resources appropriately.
in conclusion
Just as constrained-random testbenches eliminate the manual effort of block verification, comprehensive test content for embedded processor-based SoCs has been shown to reduce system-level verification efforts. Additionally, the solution is now being applied at the block level and used for post-silicon verification. In this example, automated C test cases employ the "automatically execute as much as possible" adage, greatly improving coverage while reducing verification timelines.
Embedded Internet of Things needs to learn a lot. Don't learn the wrong route and content, which will cause your salary to go up!
Share a data package with everyone, about 150 G. The learning content, face-to-face scriptures, and projects in it are relatively new and complete! (Click to find a small assistant to receive)
