Method for distributed and coordinated solution of system-level verification task request (01-Oct-2009)

System-level functional verification of hardware designs heavily relies on simulation of test-cases.

A successful practice is to generate these test-cases

based on a

specification given using a test-template language. The basic building blocks in the language are interactions between various components in the system. The desired scenarios are defined using these interactions. In the pre-silicon stage, these test-case are simulated on the system model. In this article we show how to continue this approach into the post-silicon stage using a distributed exerciser,

without having communications or synchronizations between the components in the

system.

    We consider system-level functional verification of hardware designs using simulation.

At this stage,

                the simulated model includes several components, each already extensively tested on its own. The main goal now is to test the interactions between the different components. This requires test-cases that include stimuli for creating various interactions in the system.

A successful practice for doing it is via a

test-case generator that accepts a test-template language. The language is suited for this task, and its building blocks are the different interactions in the system, along

with their attributes such as initiating component,

                               length of transaction, etc. Note that a single test-template describes the scenario for the entire system with all its components.

    System-level verification continues into the post-silicon stage. This typically involves exercisers. Exercisers are programs that run on the silicon itself in the lab in order to test it. Take an SMT (Simultaneous Multi-Threading) machine, including several threads, memory and I/O.

A simple scheme is for the exerciser to be a

with all threads running concurrently,

interactions as above by having each thread execute the stimuli it is responsible for. We show how this can be achieved for a test-template as proposed above,

without

              in the language is essentially a tree. Typically, it includes structural statements such as "Generate all of the following", "Generate one of the following", "Repeatedly generate the following", etc, as well as basic building blocks, the interactions in the system we are interested in (leaves in the tree). Our goal is for the all the threads to ob...