The present invention relates generally to the testing of logic designs, and more particularly to a method and system for generating a test case specific to a particular design-under-test (DUT) from a generalized or comprehensive set of bus transactions characterizing a bus architecture.
A process known as verification comprises applying test cases to a DUT and checking the results against expected results to determine whether the DUT functions correctly. Functional verification of logic designs which interface to standardized buses typically involves the use of a software tool known as a bus functional model (BFM). A BFM emulates a bus protocol to apply a test case in simulation to a DUT modeled by a hardware description language (HDL).
The BFMs allow verification engineers to write test cases as bus transactions. The bus transactions may be expressed in bus functional language (BFL) statements which are decoded and executed by the BFMs using a logic simulator. For example, a standardized BFM transaction test case for a 32 bit data slave design that uses read and write transactions with address, data, and control signal information could comprise BFL statements appearing as follows (comments indicated by xe2x80x9c//xe2x80x9d):
In the foregoing example, read and write are two different transaction types, while address, byte enable, and data are parameters of the respective transaction types. The parameters were used to specify data to be written to an address, and to subsequently read the address to determine whether the data was correctly written.
In order to verify that a DUT completely complies with a standardized bus interface, all possible bus transactions must be performed to ensure that the DUT-to-bus interface operates under all legal bus conditions. This process, also known as regression testing, entails the enumeration of all possible and legal transaction combinations to ensure a complete and correct design.
Typically, test cases for applying all the possible and legal transactions for a DUT-to-bus interface must be specified manually, as BFL statements as shown in the above example. To code the BFL statements, a verification engineer must usually consult a bus architecture specification manual. As the complexity of logic designs increases, the number of transactions which must be applied to a design to fully test it for bus compliance becomes unmanageable by a manual procedure. The procedure becomes unduly time-consuming, and the likelihood that coding errors occur or that needed test cases are omitted increases.
In view of the foregoing, a method and system for efficiently generating test cases is called for.
In the method and system according to the present invention, a set of transactions characterizing a bus architecture is provided. A subset of the set corresponding to a specific DUT is selected, and a configuration file for verifying the DUT is generated from the selected subset. The configuration file includes rules specific to the DUT, and may be processed by a generator program to generate or enumerate bus transactions, as determined by the rules, for a test case to be applied to the DUT.
In an embodiment, a graphical user interface may be used to create the configuration file. The user interface presents a user with the possible bus transactions of a bus architecture, and allows the user to enter inputs corresponding to a particular DUT. The interface processes the inputs to generate a configuration file syntax used by the generator program. The interface automatically inserts parameter combination specifications and rules into the configuration file for the user.
The advantages offered by the foregoing include greater ease and speed of designing test cases for verification of designs, and avoiding the errors inherent in a manual procedure. A designer of a test case does not need to consult a bus architectural specification, since the set of transactions characterizing the bus is presented in the user interface. A test case may be designed by simply entering a series of inputs relating to a specific DUT via the interface, which then automatically produces the configuration file.