Timing diagram compiler and runtime environment for interactive generation of executable test programs for logic verification

[0002] This invention relates to an improved method for constructing irritator programs from a graphical description useful to verify logic at the logic design level and also, more particularly, to facilitate the construction of stimulation and checker programs to exercise the logic to be tested.

[0003] Trademarks: S/390 and IBM are registered trademarks of International Business Machines Corporation, Armonk, N.Y., U.S.A. Other names may be registered trademarks or product names of International Business Machines Corporation or other companies.

[0004] The task of verification of a logic design is usually done by examining small pieces of logic (called units) first. Then these pieces are grouped together to form bigger blocks, up to the point where a simulation model contains the whole system. In this way, large systems are debugged and verified bottom-up in a hierarchical manner.

[0005] Below system level, state of the art verification methods replace missing hardware components by software, so-called irritator behaviorals (i.e. random simulation driver inputs). They are attached to the interfaces of the logic under test.

[0006] This approach to logic design verification are deficient in at least two respects. If the task of verification is the responsibility of the logic designer, the programming language which is used (usually C/C++) is often unfamiliar to him or her.

[0007] In any case, programming an irritator program is tedious and error-prone. Given ever increasing design complexity and therefore number of units, increasing numbers of irritators are required. In current designs, a substantial amount of time is necessary to write and debug the irritator programs.

[0008] A big improvement has been the introduction of the Timediag/Genrand tools (IBM's Bruce Wile's U.S. Pat. No. 5,745,386, entitled “Timing Diagram Method For Inputting Logic Design Parameters To Build A Testcase For The Logic Diagram”), which allowed the use of timing diagrams as irritator programs for S/390 designer level efforts for a few designs. Using Timediag, timing diagrams could be constructed easily using a graphical interface. While the improvement was great, the tools created in accordance with this patent were as described for support of designer level simulation, and this was achieved for the lowest level of verification using small designs only (e.g restriction in the number of timing diagrams).

[0009] This current invention provides a method for verifying logic designs which uses the concepts of irritator behaviorals but with a timing diagram input format, which can be used intuitively by logic designers without knowledge about the underlying programming language. The preferred embodiment enables the designer user to lay out and/or edit a timing diagram using a Timing Diagram Editor with a TD-compile (Timing Diagram compile which now generates in accordance with this invention an executable timing diagram for the graphical input provided by the user). Instead of manually programming a behavioral description of a logic circuit, the behavior of signals at any given time is specified in a spreadsheet like editor. These spreadsheets then are compiled into an executable irritator program for logic verification. Providing a graphical user interface to specify logic behavior makes testcase generation much easier and more intuitive. This results in significant savings of time.

[0010] In accordance with this invention a method is provided to translate a behavioral description of a logic design or an interface protocol, available in timing diagram format, into a C++ class. The C++ file generated then is compiled into a stand-alone executable file or a shared library, whatever the preferences of the user are. Shell scripts are used to control compilation of the C++ file, so the user can modify the way an executable is generated (e.g. with compile optimization, and with debug support and with other user desired modification of generation of compiles).

[0011] In accordance with the invention a random driver program is used to read a configuration file containing a list of timing diagrams and other parameters to generate therefrom a random simulation driver.

[0012] The invention provides support for multiple clock domains, where different parts of a design under test run at different clock speeds.

[0013] These and other improvements are set forth in the following detailed description. For a better understanding of the invention with advantages and features, refer to the detailed description and to the drawings.

[0014] FIG. 1 shows the preferred embodiment in which the user lays out and/or edits a timing diagram using a Timing Diagram Editor with a TD-compile.

[0015] FIG. 2 shows how the graphical representation of a timing diagram 1 is processed.

[0016] FIG. 3 illustrates the graphical interface which provides a spreadsheet.

[0017] FIG. 4 shows the class definition of the timing diagram of FIG. 3.

[0018] As shown in FIG. 5, the include file for the class definition contains an array of all the signal names used in a timing diagram.

[0019] FIG. 6 shows the entry function of an executable timing diagram.

[0020] FIG. 7 shows the sequence function of the example timing diagram.

[0021] FIG. 8 illustrates the case for the special (recurring) cycle C2 condition of the timing diagram shown in FIG. 3, while

[0022] FIG. 9 shows the code translation of this special recurring cycle.

[0023] FIG. 10 it shows the limitor function and the facility initialization function.

[0024] FIG. 11 shows the simulation driver TD-control.

[0025] FIG. 12 shows the contents of a configuration file, and

[0026] FIG. 13 shows a statistics file generated by TD-Control about a simulation run.

[0027] Before considering our preferred embodiments in detail, it may be worthwhile, by way of example, to note, briefly, that this invention contemplates the provision of a tool set to provide logic verification at subsystem level. External stimulus to the design is derived from a series of generalized timing diagrams describing the behavior of interfaces or operations.

[0028] A timing diagram editor provides a graphical user interface that allows the user to describe his or her logic in a general timing diagram format incorporating permutations of the behavior described. The output of the timing diagram editor is a set of executable programs, where each timing diagram is translated into one file. A suitable simulation driver reads a configuration file containing a list of names of the timing diagram executables and uses randomization algorithms to drive the simulation model according to the behavior specified in the timing diagrams. For each timing diagram, a limitor function can be specified. This limitor function contains conditions that must be true for a timing diagram sequence to be initiated. As a timing diagram is translated into a C++ class, multiple instances of a timing diagram can be initiated by simply creating additional objects of that class.

[0029] Timing diagrams are used in two basic ways: a first way is to describe an interface in part or in whole, so that a timing diagram or a set of timing diagrams can replace a piece of hardware usually attached to this interface (interface oriented approach). A second way is to describe an operation in the system, from it's beginning to it's end, possibly covering multiple interfaces (operation oriented approach).

[0030] Turning now to our invention in greater detail, it will be seen from FIG. 1 which illustrates the preferred embodiment in which the user lays out and/or edits a timing diagram 1 using a Timing Diagram Editor 2. In accordance with this invention there has been a TD-compile, which is a new part of the timing diagram editor which now generates an executable timing diagram for the graphical input provided by the user. The set of executable timing diagrams makes up the Timing Diagram Database 3. TD-Control 4, a random simulation driver, randomly picks up timing diagrams from the database to drive the simulation model 8 via a simulation monitor 5 and a simulator 7. The simulation monitor controls simulation and provides services like traces to the use. In addition, it forms a layer of abstraction between the simulation driver and the simulator. Therefore, different simulators can be used without need to change the code of TD-Control. In contrast to U.S. Pat. No. 5,745,386, executable timing diagrams are stored in separate files. Therefore, they need a means to communicate, e.g. when one timing diagram looks for a condition set by another. A Support Function Library 6 provides these and other services, for example all of the built-in functions, to the timing diagram executables. Referring now to FIG. 2, it shows how the graphical representation of a timing diagram 1 is processed: The timing diagram compiler TD_compile 2 reads the input and generates a C++ source Figure file 3 as well as an include file 4. A standard C++-compiler 5 is then used to generate an executable timing diagram file 6. By default, the generated source files are deleted after compilation. A Timediag option alternatively allows to just create the C++ code, which could then be modified by the user. In this way, the timing diagram editor can be used to create a frame to simplify development of behavior programs.

[0031] As illustrated in FIG. 3, the graphical interface provides a spreadsheet, where rows represent signals and columns represent cycles. Signals 1 are specified as either inputs or outputs, indicated by an ‘I’ or ‘O’ before the signal name. Bi-directional signals are specified as both inputs and outputs. Signals can be modified in full or in part, depending on the bit range specified after the signal name.

[0032] A cell 2 (the intersection of row x and column y) contains the value for signal x at the time y or an ‘X’, if the cell is don't care. Values in a cell can be specified directly, derived from another cell or evaluated by a function. Besides the built-in functions, the user can include user-defined programs to extend the functionality of the tool.

[0033] A column can be declared to be a special cycle (a so-called recurring cycle) 3, lasting until either a random or fixed number of cycles elapsed, or until a given condition is met (e.g. to wait for a handshake signal). If a condition is given, a time-out value specifies how long to wait before an error is flagged. A limitor condition is used to specify when a timing diagram can be activated, how many instances of a timing diagram can be active and a default probability the timing diagram is selected with.

[0034] Referring now to FIG. 4, the class definition of the timing diagram of FIG. 3 is shown. This class definition is part of the include file generated by TD-Compile. Besides the constructor and the destructor (lines 4 and 5), there is only the ‘sequence’, function accessible from outside the class (line 6). The sequence function contains the description of a timing diagram. It is used to step through a timing diagram during execution. Private members of a timing diagram class are arrays to hold values to be driven or checked (lines 11 and 12). In this case, there are 4 signals to set and 2 signals to check per cycle. Several counters are included also in the timing diagram class: td_cycle (line 15) represents the cycle the timing diagram is in (CO . . . Cn). state_cycle_count (line 9) counts how long a timing diagram remains in a timing diagram cycle. It is used to check for ending and/or time-out conditions in recurring cycles. The number of cycles a timing diagram comprises is stored in numcycles (line 14).

[0035] In addition to the class definition, the include file contains an array of all the signal names used in a timing diagram. It is shown in FIG. 5. Each entry defines a signal type, which is set to ‘x’ for don't care in this case. After the signal name, storage for a pointer to the signal is provided, initialized to a NULL pointer. The real values are determined at runtime. After the bit range, a flag indicates whether a signal is a facility in the simulation model, or a program variable just used for communication between timing diagrams. If during runtime a signal is not found in the simulation model, it is converted automatically to a program variable. A warning message is printed to tell the user about the conversion.

[0036] Referring now to FIG. 6 it shows the entry function of an executable timing diagram (line 2). It has the same name as the timing diagram and takes two arguments: A request describing what the entry function should do, and a pointer to the object the operation should be performed on. When called for the first time, the entry function initiates a search for the signal names used by the timing diagram (lines 9-13). This has to be done only once per simulation run. The entry function accepts four requests. When called with ‘N’ (New, line 14), the limitor function of the timing diagram is called (line 16) to evaluate, if the conditions to activate the timing diagram are met. If the limitor function evaluates to true, a new instance of the timing diagram class is generated, the object pointer is set to that newly created object and the entry function returns true to the calling program (lines 18 and 19). Otherwise, the object pointer is set to a NULL pointer and the entry function returns false (lines 23 and 24).

[0037] After initialization, the entry function is called twice per cycle (line 27), once at the beginning with a request of ‘P’ (Put) and once at the end with a request of ‘G’ (Get). During the put state, all input signals specified in a timing diagram are set. Then, the logic of the simulation model is evaluated and at the get cycle, all output signal specified in a timing diagram are read and compared to their expected values. These requests are simply passed on to the sequence function (line 30).

[0038] The return value is sent back to the calling program (TD-Control).

[0039] After a timing diagram has been executed successfully, the entry function is called with a ‘K’ (Kill) request (line 32) and the corresponding object is destroyed (line 34).

[0040] FIG. 7 shows the sequence function of the example timing diagram. The cycles of a timing diagram are translated into a C++ switch construct (line 6), where each timing diagram cycle is represented as a case statement (line 8). In put state, the values specified in the timing diagram are set to the signals (lines 11 and 12). A function of the support function library SFL is used to set signals, to keep the code of a timing diagram small. The actual setting of model signals and program variables is done inside the SFL. In the same way, signals are checked in the get state (lines 16-21). In addition to the pointer to the signal and the bit range, the sfl_geti function (line 18) takes the expected value and the name of the timing diagram as arguments, so the checking can be done inside the SFL. Therefore the checking code doesn't have to be replicated multiple times in all the timing diagram executables.

[0041] The special (recurring) cycle C2 condition of the timing diagram shown in FIG. 3 is depicted in FIG. 8. In this case, the timing diagram waits for 3 to 5 simulation cycles when in timing diagram cycle C2 (other choices would be to wait for a condition to become true, to wait for a fixed time, or to wait for a number of cycles specified by the contents of another timing diagram cell). The code translation of this recurring cycle is shown in FIG. 9. When entering cycle C2, a time-out value is loaded by calling a function of the support function library (lines 2-6). It returns a random value between the lower and the upper limit specified in the recurring cycle condition dialogue (line 5). For the number of simulation cycles determined this way, the timing diagram signals are driven and checked according to the values specified for C2 (lines 9-21). In addition, the state cycle counter is incremented (line 20). When the time-out value is reached, the timing diagram cycle is incremented and the recurring conditions are reset (lines 25-29).

[0042] Referring to FIG. 10 it shows the limitor function and the facility initialization function. The limitor function is unconditional, it just returns true (line 4). Therefore this timing diagram can be activated whenever it is selected by TD-Control.

[0043] To get a pointer to a signal name specified in a timing diagram, a function of the SFL is called (line 26). Signal names not found in the simulation model are treated as program variables and are handled by the SFL, because program variables must be visible to all active timing diagrams. Before calling the lookup function in line 26, the function checks whether the pointer is already available. The same signal may appear more than one time, for example with different bit ranges. In this case, the pointer and the program variable flag are just copied from the one already available (lines 18-23).

[0044] Referring now to FIG. 11, the simulation driver TD-control 3 is shown. TD-control uses a configuration file (config file) 1 to select executable timing diagrams from the database 2 and drives simulation by executing the selected timing diagrams. In case an error occurs, the user must be able to reproduce a simulation run. For this purpose, a repro file 4 is written. If a simulation run is successful, a statistics file 5 can be written if selected by the user.

[0045] On startup, TD-Control reads a set of parameters, provided by the simulation monitor, to determine how a simulation run should be set up. The name of the config file must be specified using the “RND_ConfigFile <config file name>” statement. All other parameters are optional. By default, TD-control activates timing diagrams after a reset interval (per default 5 cycles, can be modified using the “RND_ResetCycles <decimal value>” statement) until simulation is stopped by the user. In this mode, timing diagrams might not be complete when simulation is stopped, so an error might be flagged. To avoid errors due to still running timing diagrams, a quiesce cycle can be specified using the “RND_QuiesceCycle <decimal value>” statement. When this cycle is reached, no more timing diagrams are activated (unless they don't have the “noquiesce” attribute, see below). The “RND_EndAfterQuiesce [YES|NO]” statement determines what happens when all timing diagrams are finished after reaching the quiesce cycle. If set to YES, simulation is stopped after the last active timing diagram is finished, no matter how many cycles the simulation was supposed to run (to avoid clocking the model without stimulus) and control is returned to the user. Finally, using the “RND_Messages <hex value>” determines the level of information given by TD-Control. Each bit in <hex value> enables specific messages.

[0046] The contents of a configuration file is shown in FIG. 12. It basically is a text list of timing diagrams available for simulation. Each line contains a timing diagram name and a specification, how it should be activated. After the name, a counter is specified. The Max_Active value determines, how many instances of a timing diagram can be active per counter. For example, timing diagrams c0req and clreq in the table above both use the same counter c0q with a Max_Active value of 1, so only one instance of either c0req or c1req can be active. The probability determines the startup probability of a timing diagram. Clockarea specifies the clock domain in which the timing diagram should run. This is required because some designs have interfaces running at different speeds (e.g. fast processor interface and slow memory interface). TD-control keeps a list of active timing diagrams for each clock domain, so timing diagrams are called only when the corresponding clock domain is active. Timing diagrams can be activated even if simulation is quiesced, if they have a noquiesce marker in their config file entry. Generally, timing diagrams responding to other timing diagrams should use this to avoid errors due to incomplete sequences. Clockarea and noquiesce are optional, if omitted, the timing diagram will be called every cycle and quiesced after the quiesce cycle is reached.

[0047] Three types of special entries are given in the config file. The reset timing diagram is run only once, before activation of other timing diagrams starts. After execution of timing diagrams ended, the endcheck timing diagram is called once before simulation stops. If a timing diagram name ends with “.pty”, it is treated as parity timing diagram. Parity timing diagrams only require a clock domain specification, they are always started with a probability of 100%. In addition, a config file may contain a hex number to be used as a starting seed. This is necessary to reproduce simulation runs. If the seed is not specified, a random seed will be used.

[0048] One advantage of using a config file using a text list of timing diagrams as testcase bucket is that the file can be easily changed. Copying or moving timing diagrams between config files is just a matter of adding/deleting/modifying/commenting out an entry. In Timediag, a testcase bucket consists of a single file, containing all timing diagrams, which makes it hard to perform add, copy and move operations in or between testcase bucket files. TD-Control is therefore better suited for the standard testcase development cycle, where a single testcase (timing diagram) is developed and debugged, then added to a regression bucket.

[0049] While the quiesce cycle is not reached, TD-control activates timing diagrams for each clock domain in the following way:

[0050] (a) Randomly select a timing diagram in the clock domain as a starting point,

[0051] (b) then for all timing diagrams in the clock domain, check if another instance of this timing diagram is allowed, and

[0052] (c) when (b) allows another instance of the timing diagram, and thus the condition is satisfied as yes, then select timing diagram in <probability> percent of all cases;

[0053] (d) if a timing diagram is selected in step (c), then load that selected timing diagram executable (if not already loaded).

[0054] Then, when step (d) is complete, the process evaluates the timing diagram limitor function, and

[0055] if the process evaluates the timing diagram limitor function as true, then the evaluated timing diagram is appended to the list of active timing diagrams for that clock domain.

[0056] All active instances of timing diagrams are called twice in cycles where the corresponding clock domain is active, at the beginning and at the end of the cycle. Timing diagrams returning true ran successfully. They are called again to delete the corresponding object and are removed from the list of active timing diagrams. The config file is copied into a repro file and the random seed used for the simulation run is appended. The repro file could be specified as a config file to TD-control in order to reproduce simulation runs.

[0057] Referring now to FIG. 13 it shows a statistics file generated by TD-Control about the simulation run. In addition to the information printed out by Genrand like how many times a timing diagram was activated and how often it wasn't activated due to the limitor function, timing information is included in the statistics file. It shows the minimum time a timing diagram required to run, the average time and the maximum time. This could be used to check whether the design is performing as expected.

[0058] TD-Control itself behaves like an irritator function which is called twice per cycle, so it could be integrated into existing simulation environments.

[0059] While in accordance with the preferred embodiment of this invention, the TD-Compile currently generates code to be called by TD-Control, it is possible to change code generation, so that the resulting executable directly fits into the simulation environment (without TD-Control). In this way, the TD-compiler could be used to directly specify irritator behavior routines in a graphical way. If such a routine should be active always during a simulation run as shown in FIG. 13, the random start mechanism of TD-control is not required. Even if a behavioral routine cannot be specified completely in a graphical fashion (e.g. cell contents too complex), using TD-Compile to provide a framework, where the user just have to fill out the section which could not be described in the timing diagram editor, would be advantageous.

[0060] While the preferred embodiment, and an alternative, to the invention has been described, it will be understood that those skilled in the art, both now and in the future, may make various improvements and enhancements which fall within the scope of the claims which follow. These claims should be construed to maintain the proper protection for the invention first described.