A New Era for Analysis and Debug

Analysis and debug have been stuck in a sequential world. Traces from a simulator or emulator define what happened while analysis and debug tools attempt to find out why they happened the way they did when something goes wrong. Even high-level synthesis starts with a sequential description and attempts to find out how much concurrency can be extracted from it.

Systems are made up of a growing number of concurrent activities that interact with each other to perform the intended functions of the device. System-on-Chips (SoCs) also contain one or more processors, many of which are deeply embedded into the design. Functionality is defined by both the hardware and the software that runs on those embedded processors.

The emerging Portable Stimulus (PS) standard from Accellera Systems Initiatives will define a new way to approach the verification of such systems, a capability that has only been available through proprietary languages and tools so far. The target of PS is the verification of SoCs, including the integration between hardware and software, although it can be applied to other types of systems. One use case is an extension of the Unified Verification Methodology (UVM) where sequences, scoreboards and coverage are synthesized from a PS verification intent description that combines previously separate pieces into a single unified model. Another use case is to utilize the processors that exist within most designs to run parts of the testbench. This makes the technology not only useful to simulators and emulators, but can also target field programmable gate array (FPGA)-based prototypes and real silicon.

A PS model defines primitive action blocks, attributes on those blocks and the preconditions necessary for them to execute. This concept is similar to control and dataflow graphs. Once assembled, they represent functions that a block should be capable of performing, leaving out details about how they are implemented in the design. When a path through that model is selected by a PS standard tool, it generates a test scenario that includes the stimulus, expected results and coverage that corresponds to the path taken. Each path is a thread of activity that will propagate through the design, such that at any point during execution, it is known why something is happening without having to try and work that out by going backward through the design.

In many systems, multiple paths can be executed concurrently through a model, constrained only by the resources available in the system. Resources may be processors, memory, DMA channels or functional blocks. Actions request the necessary resources before execution and may be blocked until they become available. To create a complete SoC-level test, the testcase generator combines multiple concurrent scenarios and schedules them so that certain resources are stressed or communications channels stretched. The final step of the test case generator is to target the execution engine chosen for executing the test. If the design contains embedded processors, it may generate code that will run on those processors. It may inject more traditional stimulus into the primitive I/O interfaces. Generated code that runs on the embedded processors also coordinates internal activity and I/O traffic.

As previously stated, the test generator does not know the implementation of the design and has no way of knowing the exact timing of the system. When a test is created, it makes assumptions about how long tasks will take and may not know when certain resource conflicts will occur. Will a block have enough memory to be able to execute? Will another task be slowed down so that a necessary piece of hardware is not available when expected? Will two tasks be fighting in the cache and lengthening execution times for both of them? These are the types of things that a system integrator wants to be able to investigate and to help them find performance bottlenecks within the design or unexpected ways in which tasks interact with each other.

Consider a design composed of a camera, a photo processor, a display controller and an SD Card controller. Figure 1 shows the paths in which data can flow through the system.

Figure 1: Actions and dependences within an image sub-system system illustrates the complexity of the design.

Generated scenarios are dependent on available resources, such as the number of CPUs, constraints about simultaneous SD card read and write or the ability to do encode and decode simultaneously. The tool may schedule when each application scenario gains access to the necessary resources. Figure 2 shows how tests may be put together when one CPU or three CPUs are available. The schedule shows the first approximation and assumes certain tasks will require a CPU for various lengths of time. Actual execution times will depend on factors such as the memory architecture.

Figure 2: A conceptualized schedule of a test with shared resources assumes certain tasks will require a CPU for various lengths of time.

Because the dependencies are captured in the chart, progress through the test is easily monitored and, if unexpected things happen during execution, tasks and dependencies can be traced. Figure 3 shows a more realistic system with multiple UARTs and DMA engines moving traffic into and out of an AES encryption block. The screen captures are from Breker’s proprietary tool TrekSoC, but an almost identical one could be displayed in a tool supporting the viewing of multiple synchronized tests, based on Portable Stimulus once that standard has been completed and released by Accellera.

Figure 3: Progress through the test is monitored using the scheduled chart during debug.

Now, the user will see the actual results of running the test. In this example, the DMA0_CH0.2 operation fails, detected because the test is a self-checking test case. This failure impacts other tasks dependent on the transfer having been successful. Other parts of the test subsequently fail. In a traditional simulation/debug loop, it is unlikely that intermediate results checking is performed and thus the first failure may go unnoticed until results are made available on the primary outputs of the design when checking is performed. Debug would have to start there and a user would attempt to backtrack through the operations of the design until the root cause of the problem is found. While the display does not define why the original task failed, it provides a starting point for more traditional debug methods and tools, such as Synopsys Verdi, enabling the user to see exactly what was happening in the hardware at the point where the first failure was discovered.

The graph-based definition of test cases means that it is known a priori, exactly what a test is meant to accomplish and the intervening tasks and their dependencies. This not only means that better tests are created, but the traditional simulation/debug cycle undergoes a dramatic transformation from being a backward exploration to one where problems can be immediately found. Given that almost half of a design and verification engineer’s time is spent in debug, it results in a dramatic improvement in productivity which could allow for more in-depth verification, or more time spent in design. The pending release of the Portable Stimulus Standard will make this technology available to a much wider audience and allow tool vendors to concentrate on adding more value in areas such as this.


Share and Enjoy:
  • Digg
  • Sphinn
  • Facebook
  • Mixx
  • Google
  • TwitThis
Extension Media websites place cookies on your device to give you the best user experience. By using our websites, you agree to placement of these cookies and to our Privacy Policy. Please click here to accept.