US20010041972A1 - Transaction class - Google Patents
Transaction class Download PDFInfo
- Publication number
- US20010041972A1 US20010041972A1 US09/262,545 US26254599A US2001041972A1 US 20010041972 A1 US20010041972 A1 US 20010041972A1 US 26254599 A US26254599 A US 26254599A US 2001041972 A1 US2001041972 A1 US 2001041972A1
- Authority
- US
- United States
- Prior art keywords
- transaction
- class
- test
- classes
- subsystem
- Prior art date
- Legal status (The legal status is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the status listed.)
- Granted
Links
Images
Classifications
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F11/00—Error detection; Error correction; Monitoring
- G06F11/22—Detection or location of defective computer hardware by testing during standby operation or during idle time, e.g. start-up testing
- G06F11/26—Functional testing
- G06F11/261—Functional testing by simulating additional hardware, e.g. fault simulation
-
- G—PHYSICS
- G06—COMPUTING; CALCULATING OR COUNTING
- G06F—ELECTRIC DIGITAL DATA PROCESSING
- G06F30/00—Computer-aided design [CAD]
- G06F30/30—Circuit design
- G06F30/32—Circuit design at the digital level
- G06F30/33—Design verification, e.g. functional simulation or model checking
Definitions
- the present invention relates generally to computer systems and more particularly to methods and apparatus for facilitating the testing and verification of integrated circuit designs using simulation tools.
- HDL hardware description language
- the design engineers use an HDL to generate a detailed functional description of the circuitry including, for example, the input signals to be provided to the circuitry and the output signals which are produced in response thereto.
- the description of the circuitry may comprise descriptions of sub-components or “cells” and the interrelationships between these components.
- the resulting model can be used to simulate the behavior of the circuitry.
- the HDL model of the circuitry is implemented in a simulation system to verify the proper functioning of the circuitry.
- the simulation system may comprise any one of a number of such systems, one example being the Verilog system, which is well known to those in the art. “Verilog” also refers to a particular HDL.
- the simulation system accepts data which defines the behavior of the circuitry as well as the signals to be input to the circuitry and, in response, generates data corresponding to simulated output signals.
- HDL High-Demand Language
- ASICs Application-Specific Integrated Circuits
- HDL is used to form a detailed functional description of circuitry such as ASICs (Application-Specific Integrated Circuits)
- ASICs Application-Specific Integrated Circuits
- verification of functionality at the gate level is often insufficient because of the difficulty of observing the internal state of the circuitry at its I/O interface.
- generating a set of tests for this circuitry can be a daunting task since HDL does not have many of the features which are found in higher-level languages and which make it easier for programmers to handle large software projects. It is therefore desirable to have an interface mechanism which allows tests written in higher-level languages to control a simulation written in HDL.
- the CVI mechanism allows the design of device objects which present a low-level register interface to the test writer. This is useful because it presents the test writer with a consistent interface style shared by all transactors and provides a consistent documentation format.
- the low-level register interface is also intuitively appealing because the register model mimics modern computer system operation and is well understood by programmers.
- the CVI mechanism introduces a device driver abstraction which shields users from the low-level details of complex circuitry. This level of abstraction again provides test writers with a consistent view of many dissimilar devices.
- the device drivers in the simulation system maintain state information regarding the devices in order to simplify control and scheduling of the operations of the device.
- One embodiment of the invention comprises a simulation system configured to model a circuit design and a test system configured to operate in cooperation with the simulation system.
- the systems comprise one or more software applications which may be stored on computer-readable media such as magnetic disks or tape, and which may be executed on a suitable computer system.
- One embodiment of the invention comprises a hierarchical set of transaction classes.
- the uppermost class defines a base transaction. All transaction classes inherit from this class.
- Below the base transaction class are a device transaction class and a system transaction class.
- the device transaction class is associated with the device class through an object reference.
- the system transaction class is used to collect convenience routines.
- the system transaction class contains pointers to each of the required device transaction classes.
- the next level in the hierarchy includes one or more configuration transaction classes which reference selected device objects.
- This class structure provides a mechanism through which a test writer can easily write and maintain program code to test a simulated device.
- the system transaction class provides an infrastructure upon which the test writer can build the code.
- the system transaction class contains pointers to device transaction objects for all of the devices in the simulated system and aggregates the convenience routines which may be useful in writing the tests.
- the system transaction class is not instantiated directly, but is instead used as the basis for the configuration transaction classes.
- Each configuration transaction class represents a selected subset of the devices in the simulated system and is instantiated to test transactions involving the corresponding devices. Because the configuration transaction classes use object references to the device objects, the user is forced to supply the appropriate device objects at the time of instantiation and the compiler is therefore able to perform static type checking.
- the configuration transaction classes thus enable the test writer to use all of the convenience routines defined in the system transaction class while only instantiating those device objects which are needed for the corresponding configuration. At the same time, the test writer can more easily maintain the test code because all of the convenience routines are written only once and collected in the system transaction class.
- FIG. 1 is a functional diagram of a simple simulation system in one embodiment of the invention.
- FIG. 2 is a block diagram of a design verification system in one embodiment of the invention.
- FIG. 3 is a diagram of a class structure implemented in a test subsystem in one embodiment of the invention.
- a set of transaction classes is implemented in the test subsystem of a circuit design verification system.
- the test system comprises one or more tests written in a high-level language.
- the high-level language is C++.
- a different high-level language can be used.
- the test system is used in conjunction with a simulation system which is written in a lower-level language such as the Verilog HDL.
- the test system and the simulation system are coupled by an interface such as CVI.
- different HDL's and interface systems can be used.
- the transaction classes provide a mechanism through which a programmer can easily test selected functions in a circuit design.
- the classes form a hierarchy, the top of which is a base transaction class.
- the base transaction class contains several virtual functions which are used to initialize device objects and enable the device objects to handle signals and drive transactions during testing.
- a device transaction class is derived from the base transaction class and is used to provide a level of abstraction between the test writer and the device objects.
- a system transaction class is derived from the base transaction class and is used to provide an abstracted model of the circuit design under test.
- the system transaction class contains pointers to device transaction classes corresponding to device objects in the design under test.
- a configuration transaction class is derived from the system transaction class and is used to configure and test selected portions of the circuit design model. Both the device transaction class and the configuration transaction class contain references to device objects and, in fact, the configuration transaction class sets up device transactions for device objects to be used for executing tests.
- the design verification system is designed to be implemented in a general-purpose computer system.
- the design verification system comprises a set of software applications which model the functions of a circuit design and perform a series of tests to verify these functions. It should be noted that, in alternate embodiments, one or more parts of the system can be implemented in hardware designed specifically for that purpose.
- the design verification system includes a test subsystem, a hardware simulation system and an interface subsystem.
- the hardware simulation system is a software application which includes functional descriptions of the hardware to be simulated, including the newly designed circuitry.
- the hardware simulation system is used to model the operation of the hardware.
- the simulation system is typically written in a computer language specifically designed for that purpose (i.e., an HDL). In this instance, the simulation system is a written in Verilog.
- the hardware simulation system includes a number of functional models representative of portions of the system being modeled. These functional models will be referred to herein as bus functional models, although it should be noted that the portions of the system being modeled may comprise items other than buses.
- the simulation system includes a functional model of the newly designed circuitry (i.e. the design under test, or device under test).
- the simulation system 10 includes a simulation core 18 and a hardware functional model 20 .
- the hardware functional model 20 includes a host bus functional model 12 and an I/O bus functional model 16 which represent the behavior of the model's interfaces.
- the functional model of the design under test 14 is inserted into the system and is operatively coupled to the host and I/O bus functional models 12 and 16 , just as the hardware device would be coupled to the hardware buses.
- the host bus functional model 12 would provide a signal as a stimulus to the design under test 14 , which would then respond to this stimulus.
- the stimulus consists of a set of signals which may correspond to a function call or some other command to the design under test.
- the design under test 14 may in turn convey one or more signals to the I/O bus functional model 16 .
- the I/O bus functional model 16 would then convey a responsive signal to the design under test 14 , which would subsequently convey a signal to the host bus functional model 12 so that the proper operation of the system could be verified for the corresponding function.
- a portion of the bus functional models and the design under test are written in HDL. These functional models interact on a chip I/O level. That is, the models operate on individual bits or signals in the same way the physical devices which they represent operate on individual bits or signals which are input to the respective devices. The models and the corresponding designs can therefore be examined with a very high level of detail.
- the interface subsystem translates test commands in a high-level language (e.g., C or C++) to the appropriate chip I/O level signals in HDL.
- a high-level language e.g., C or C++
- the programmer is able to write tests in the high-level language.
- the test system can therefore take advantage of features such as object-oriented programming constructs, which are available in the high-level language, but not in the HDL.
- CVI (described above) is employed as the interface system.
- FIG. 2 a block diagram of the design verification system, test subsystem 32 , interface subsystem system 34 and hardware simulation subsystem 36 execute within the environment of operating system 38 .
- the interface subsystem system 34 controls the interaction between the HDL based hardware simulation subsystem 36 and the C++ based test subsystem 32 .
- the interface subsystem allows tests to be written using an object-oriented paradigm and provides the programmer with device objects which translate the tests into HDL bus signals.
- test subsystem adds a first level of abstraction between the test writer and the HDL test environment
- object-oriented programming principles in the test system allows additional levels of abstraction to be obtained within the test subsystem. For example, system level transactions may be defined to generate activity in several devices in response to a single system level function call. Object-oriented principles also provide benefits to the programmer such as the ability to re-use code and to hide data from the test subsystem writer.
- the test subsystem controls each of the device functional objects in the simulated hardware system in order to verify the functionality of the design.
- the test subsystem utilizes device transaction objects to abstract away some of the details of the device operation.
- Configuration transaction objects likewise abstract away some of the details of transactions involving more than one functional device.
- the configuration transaction objects are derived from a system transaction class in order to group together convenience routines and make them available to the configuration transactions. Convenience routines are functions that simplify the process of managing test data and control sequences.
- the system transaction class also collects test flow control routines for use in simulation of the configuration transactions.
- FIG. 3 a diagram of a class structure used in one embodiment of the test system is shown.
- a triangular shape on the line between the two classes indicates inheritance from the higher class.
- Object references in the figure are indicated by an arrow with an accompanying ampersand (&).
- Pointers are indicated by an arrow with an accompanying asterisk (*).
- One-to-one relationships between objects and/or classes in the figure are indicated by an open circle at the head of the corresponding pointer or object reference arrow.
- a blackened circle indicates that there may be one or more pointers or object references.
- the dashed lines from the configuration transaction classes to the device transaction classes indicate that the latter are created in the process of instantiating the former.
- FIG. 3 shows a hierarchical class structure which has a base transaction class 40 at the top of the class hierarchy.
- Base transaction class 40 is an abstract class which is not directly instantiated. Instead, base transaction class 40 serves to provide a set of basic services which are common to all of the transactions. The services are provided through methods or functions which are declared in the base transaction class and are inherited by the classes which will be derived therefrom.
- base transaction class 40 includes several virtual functions which are common to all of the transaction classes in the hierarchy.
- the use of a common set of interface function names is necessary to take advantage of polymorphism, which is a useful feature of object-oriented programming languages.
- Polymorphism allows the programmer to create transaction objects and work with these objects in an abstract way while deferring to run time that task of figuring out which device is actually being used.
- Polymorphism provides several other advantages, including providing consistent high-level interfaces to similar objects, hiding from the programmer object information which he doesn't need to see and simplifying program code by encapsulating object-specific variations within the objects themselves.
- the functions declared by base transaction class 40 include the following: init( ); setup_trans( ); setup_resp( ); and service_signal( ).
- Init( ) initializes the device associated with the transaction class.
- Setup_trans( ) enables the associated device to drive transactions in the simulation.
- Setup_resp( ) controls how the associated device responds to transactions directed to it.
- Service_signal( ) is called to handle CVI signal messages sent from the HDL to the device.
- a base device class (not shown in the figure) is used in the same manner as the base transaction class.
- One or more sub-classes can be derived from the base device class.
- the sub-classes inherit a common set of methods from the base device class and may define additional methods which are specific to the sub-classes.
- the base device class and its sub-classes enable the instantiation of the device objects which are shown in the figure. Through inheritance, the base device class provides a common interface to all of the bus functional models in the hardware simulation system.
- Device transaction class 44 is derived from base transaction class 40 .
- Device transaction class 44 therefore inherits the four methods listed above from base transaction class 40 .
- the methods declared in base transaction class 40 are virtual methods. That is, they are declared, but the implementation of each of the methods is not defined. It is left to the device transaction classes (e.g., device transaction class 44 ) to provide the program code which implements each of the methods.
- Device transaction class 44 becomes associated with a single device object 42 through an object reference.
- Device transaction class 44 controls the transactions which device 42 executes. Because an object reference must always be satisfied, the use of an object reference to associate device 42 with device transaction class 44 forces the user to supply a device object when the device transaction class is instantiated. By forcing the user to supply the device object at instantiation, the possibility of changing the pointer or using a NULL pointer is eliminated and the compiler is allowed to perform static type checking. These properties make the object reference inherently safer to use than a standard C pointer. They add some complexity to the system, however, which will be discussed in more detail below.
- Device transaction class 44 serves to hide the low-level details of the operation of device 42 from the test writer and thereby simplifies the communications between the test subsystem and the bus functional models of the hardware simulation subsystem. Device transaction class 44 also serves to maintain the state of device 42 between invocations of transactions involving the device.
- the test writer can set up high-level transaction information such as data, address, size and mode in the transaction class and then call a function such as setup_trans( ) to translate this information into individual register operations at the device level. Therefore, the test writer does not need to know which specific register operations are involved in performing a particular function call.
- Device transaction class 44 thus acts in a manner similar to that of a device driver while also enabling the compiler to perform static type checking.
- device transaction class 44 allows the test writer to define convenience methods associated with the device or device transaction. The test writer is free to define these test methods and any necessary instance variables, both of which may be encapsulated into the device transaction class.
- the test writer might therefore create a system transaction class in which all of these convenience routines are defined. This would provide a grouping of common routines and would therefore potentially achieve the best re-use of program code, but might cause problems in terms of the desired use of object references. Because the test writer wants to have static type checking and wants to avoid NULL pointers, as explained above, the system transaction classes should use object references. The use of object references, however, requires that the associated device object be provided when the system transaction class and the object reference are instantiated. If the system transaction class contains convenience routines relating to all the devices in the design under test, any test which uses this system transaction class (i.e. any of the convenience routines in the class) must instantiate every device referenced in the class (i.e. all of the devices.) This would limit the performance of the system because tests would automatically reserve devices which would never be used for those tests. The unnecessary reservation of devices would also make it very difficult for tests to share device objects.
- Another approach which might be taken by a test writer would be to define a configuration transaction class for every possible system configuration. In other words, a separate configuration transaction class would be written for each combination of devices which might be tested. Using this approach, only those devices which are involved in a transaction are instantiated for each test configuration. There is no unnecessary reservation of devices which are not used. The improved efficiency in the instantiation of device objects, however, is obtained at the expense of the efficient re-use of program code. Many of the configurations defined by the test writer would probably need very similar [access and] convenience routines, but these routines could not be collected in a single transaction class. Instead, the test writer would have to reproduce the code for particular routines in each of the transaction classes which uses the respective routines. Any code sharing could only be achieved by physically copying the routines from one transaction class to another. This would create more work for the test writer and would result in a program which is very difficult to maintain because each of the copies of a routine must be individually updated.
- system transaction class 46 is created as a subclass of base transaction class 40 .
- System transaction class 46 is a collector of all the convenience routines which may be needed by the test writer. Because system transaction class 46 uses pointers to device objects instead of object references, it is not necessary to instantiate each device in the system for every test. The instantiation of device objects is left to the configuration transaction classes.
- the system transaction class 46 is sub-classed to create one or more configuration transaction classes 47 , 48 .
- the configuration transaction classes contain object references to each of the device objects which are involved in a transaction of the respective configuration.
- the configuration transaction class is used to create all of the required device transaction classes.
- the device object reference of the system transaction class is used to set the device transaction class pointers inherited from the system transaction class, so the system transaction class' use of pointers is acceptable from a type checking perspective.
- the configuration transaction class inherits all of the convenience routines from the system transaction class, so the programmer does not have to rewrite or copy the routines into each of the configuration transaction classes. This reduces the workload of the programmer and greatly increases the maintainability of the program code.
- CVI uses an interrupt driven model for the test environment.
- An interrupt driven model allows the test to retain very tight control over execution in the simulation subsystem.
- the use of an interrupt driven model may, however, create difficulties for a test writer because he or she must be prepared to receive any type of interrupt at any point in the simulation—the test subsystem cannot only handle those types of interrupts which are of interest to the test writer.
- the use of the class hierarchy shown in FIG. 3 simplifies the program code required to implement an interrupt driven model and reduces the burden on the test writer by enabling a state driven style of test writing.
- the control flow of the tests are tied to a state sequencer (i.e., finite state machine, or FSM) in a manner resembling a hardware design style.
- the state sequencer may be defined in the base transaction class or in the system transaction class.
- the purpose of the state sequencer is to handle signals directed to the device based on the current state of the sequencer. This generally improves the readability of threads in the test subsystem because state information which is usually embedded in the program code is removed. This state information is moved into the device transaction class and stored in a format suitable for the state sequencer.
- the program code of the test subsystem can therefore be written as a simple stimulus generator. This greatly reduces the complexity of the code.
- the state driven style of test writing may also simplify the writing of convenience routines. Using other styles of test writing, it may be necessary to include code in convenience methods which returns control to the simulation subsystem. In a state driven style, routines can return control to the simulation subsystem at a high level, allowing parallel operation without the need for multi-threading. This is a great benefit in a random testing environment.
Abstract
Description
- 1. Field of the Invention
- The present invention relates generally to computer systems and more particularly to methods and apparatus for facilitating the testing and verification of integrated circuit designs using simulation tools.
- 2. Description of the Relevant Art
- Because of the complexity of the circuitry in modem integrated circuits (ICs), the design of the circuitry is thoroughly tested before the actual circuit is manufactured. The testing is intended to identify errors in the design of the circuitry so that the errors can be corrected with minimal effort and expense. Typically, this testing is accomplished by simulating the functioning of the circuitry on a computer system using a hardware description language. (References herein to “HDL” will indicate a hardware reference language which may be Verilog or any other hardware description language.) The design engineers use an HDL to generate a detailed functional description of the circuitry including, for example, the input signals to be provided to the circuitry and the output signals which are produced in response thereto. The description of the circuitry may comprise descriptions of sub-components or “cells” and the interrelationships between these components. The resulting model can be used to simulate the behavior of the circuitry.
- The HDL model of the circuitry is implemented in a simulation system to verify the proper functioning of the circuitry. The simulation system may comprise any one of a number of such systems, one example being the Verilog system, which is well known to those in the art. “Verilog” also refers to a particular HDL. The simulation system accepts data which defines the behavior of the circuitry as well as the signals to be input to the circuitry and, in response, generates data corresponding to simulated output signals.
- Traditionally, the entire simulation system, including the functional description of the newly designed circuitry, has been written in HDL. Because HDL is used to form a detailed functional description of circuitry such as ASICs (Application-Specific Integrated Circuits), it is by nature a specialized and complex language. With the increasing complexity of these circuits, verification of functionality at the gate level is often insufficient because of the difficulty of observing the internal state of the circuitry at its I/O interface. Further, generating a set of tests for this circuitry can be a daunting task since HDL does not have many of the features which are found in higher-level languages and which make it easier for programmers to handle large software projects. It is therefore desirable to have an interface mechanism which allows tests written in higher-level languages to control a simulation written in HDL.
- The need to allow tests to be written in high level languages and then interfaced to the HDL resulted in the development of interface systems such as CVI. CVI is described in U.S. Pat. No. 5,732,247 to Dearth, et al. CVI allows tests to be written in higher-level languages such as C and C++ and serves as an interface between the HDL simulation system and the higher-level-language test system. CVI translates the test statements into simulated bus activity in the simulation system. CVI is particularly useful in the development of simulation systems because the verification engineers who write the test procedures normally are not the same engineers who write the functional description of the new circuitry.
- One important aspect of the CVI mechanism is that it allows the design of device objects which present a low-level register interface to the test writer. This is useful because it presents the test writer with a consistent interface style shared by all transactors and provides a consistent documentation format. The low-level register interface is also intuitively appealing because the register model mimics modern computer system operation and is well understood by programmers. The CVI mechanism introduces a device driver abstraction which shields users from the low-level details of complex circuitry. This level of abstraction again provides test writers with a consistent view of many dissimilar devices. The device drivers in the simulation system maintain state information regarding the devices in order to simplify control and scheduling of the operations of the device.
- The issues surrounding the abstractions outlined above may be solved by various embodiments of the system and method of the present invention. One embodiment of the invention comprises a simulation system configured to model a circuit design and a test system configured to operate in cooperation with the simulation system. The systems comprise one or more software applications which may be stored on computer-readable media such as magnetic disks or tape, and which may be executed on a suitable computer system.
- In one embodiment, a mechanism is provided to facilitate testing of circuitry designs in a device simulation environment. The mechanism is implemented in a high-level programming language and is used in conjunction with a simulation system, which is written in an HDL, and a simulation system interface. The mechanism simplifies test writing by performing a function similar to that of an operating system device driver. The mechanism provides consistent high-level interfaces to device objects, device object information hiding, simplification of random environment testing, effective parallel operation without threading, state driven test writing style, encapsulation/aggregation of convenience routines, simplification of device object configuration management and storage of parameters for convenience routines in class member variables.
- One embodiment of the invention comprises a hierarchical set of transaction classes. The uppermost class defines a base transaction. All transaction classes inherit from this class. Below the base transaction class are a device transaction class and a system transaction class. The device transaction class is associated with the device class through an object reference. The system transaction class is used to collect convenience routines. The system transaction class contains pointers to each of the required device transaction classes. The next level in the hierarchy includes one or more configuration transaction classes which reference selected device objects.
- This class structure provides a mechanism through which a test writer can easily write and maintain program code to test a simulated device. The system transaction class provides an infrastructure upon which the test writer can build the code. The system transaction class contains pointers to device transaction objects for all of the devices in the simulated system and aggregates the convenience routines which may be useful in writing the tests. The system transaction class is not instantiated directly, but is instead used as the basis for the configuration transaction classes. Each configuration transaction class represents a selected subset of the devices in the simulated system and is instantiated to test transactions involving the corresponding devices. Because the configuration transaction classes use object references to the device objects, the user is forced to supply the appropriate device objects at the time of instantiation and the compiler is therefore able to perform static type checking. The configuration transaction classes thus enable the test writer to use all of the convenience routines defined in the system transaction class while only instantiating those device objects which are needed for the corresponding configuration. At the same time, the test writer can more easily maintain the test code because all of the convenience routines are written only once and collected in the system transaction class.
- Other objects and advantages of the invention will become apparent upon reading the following detailed description and upon reference to the accompanying drawings in which:
- FIG. 1 is a functional diagram of a simple simulation system in one embodiment of the invention.
- FIG. 2 is a block diagram of a design verification system in one embodiment of the invention.
- FIG. 3 is a diagram of a class structure implemented in a test subsystem in one embodiment of the invention.
- While the invention is subject to various modifications and alternative forms, specific embodiments thereof are shown by way of example in the drawings and will herein be described in detail. It should be understood, however, that the drawing and detailed description thereto are not intended to limit the invention to the particular form disclosed, but on the contrary, the intention is to cover all modifications, equivalents and alternatives falling within the spirit and scope of the present invention as defined by the appended claims.
- One embodiment of the invention is described below. In this embodiment, a set of transaction classes is implemented in the test subsystem of a circuit design verification system. The test system comprises one or more tests written in a high-level language. In this instance, the high-level language is C++. In other embodiments, a different high-level language can be used. The test system is used in conjunction with a simulation system which is written in a lower-level language such as the Verilog HDL. The test system and the simulation system are coupled by an interface such as CVI. In other embodiments, different HDL's and interface systems can be used.
- The transaction classes provide a mechanism through which a programmer can easily test selected functions in a circuit design. The classes form a hierarchy, the top of which is a base transaction class. The base transaction class contains several virtual functions which are used to initialize device objects and enable the device objects to handle signals and drive transactions during testing. A device transaction class is derived from the base transaction class and is used to provide a level of abstraction between the test writer and the device objects. A system transaction class is derived from the base transaction class and is used to provide an abstracted model of the circuit design under test. The system transaction class contains pointers to device transaction classes corresponding to device objects in the design under test. A configuration transaction class is derived from the system transaction class and is used to configure and test selected portions of the circuit design model. Both the device transaction class and the configuration transaction class contain references to device objects and, in fact, the configuration transaction class sets up device transactions for device objects to be used for executing tests.
- It should be noted that, while the embodiment described here refers to a structure of interrelated classes, the invention contemplates a structure of interrelated objects as well. As will be appreciated by persons skilled in the art of the invention, objects are instantiations of classes The distinction between classes and objects may therefore be viewed as one of code implementation versus memory implementation, or of source code versus executable code. Persons skilled in the art will appreciate these distinctions as well as the fact that the invention need not be limited to one or the other. Accordingly, the references herein to classes are intended to encompass objects which are instantiated from the classes. Likewise, references to objects are, for the purposes of this description, intended to encompass the classes from which they are instantiated.
- The design verification system is designed to be implemented in a general-purpose computer system. The design verification system comprises a set of software applications which model the functions of a circuit design and perform a series of tests to verify these functions. It should be noted that, in alternate embodiments, one or more parts of the system can be implemented in hardware designed specifically for that purpose. The design verification system includes a test subsystem, a hardware simulation system and an interface subsystem.
- The hardware simulation system is a software application which includes functional descriptions of the hardware to be simulated, including the newly designed circuitry. The hardware simulation system is used to model the operation of the hardware. The simulation system is typically written in a computer language specifically designed for that purpose (i.e., an HDL). In this instance, the simulation system is a written in Verilog.
- The hardware simulation system includes a number of functional models representative of portions of the system being modeled. These functional models will be referred to herein as bus functional models, although it should be noted that the portions of the system being modeled may comprise items other than buses. In addition to the bus functional models, the simulation system includes a functional model of the newly designed circuitry (i.e. the design under test, or device under test).
- Referring to FIG. 1, a functional diagram of a
simple simulation system 10 is shown. Thesimulation system 10 includes asimulation core 18 and a hardwarefunctional model 20. The hardwarefunctional model 20 includes a host busfunctional model 12 and an I/O busfunctional model 16 which represent the behavior of the model's interfaces. The functional model of the design undertest 14 is inserted into the system and is operatively coupled to the host and I/O busfunctional models functional model 12 would provide a signal as a stimulus to the design undertest 14, which would then respond to this stimulus. The stimulus consists of a set of signals which may correspond to a function call or some other command to the design under test. The design undertest 14 may in turn convey one or more signals to the I/O busfunctional model 16. The I/O busfunctional model 16 would then convey a responsive signal to the design undertest 14, which would subsequently convey a signal to the host busfunctional model 12 so that the proper operation of the system could be verified for the corresponding function. - A portion of the bus functional models and the design under test are written in HDL. These functional models interact on a chip I/O level. That is, the models operate on individual bits or signals in the same way the physical devices which they represent operate on individual bits or signals which are input to the respective devices. The models and the corresponding designs can therefore be examined with a very high level of detail.
- This level of detail, however, is very difficult to work with when a programmer is interested in testing the high level operations of the devices. For example, if the programmer wants to test a simple function, such as copying a file from one location to another, the number of signals which need to be controlled at the device I/O level may be very high. The programmer therefore needs a mechanism by which he can use a simple command or set of commands to achieve this function instead of individually programming each bit signal. In other words, a level of abstraction is necessary to simplify the programmer's task.
- This level of abstraction is provided by the interface subsystem. The interface subsystem translates test commands in a high-level language (e.g., C or C++) to the appropriate chip I/O level signals in HDL. As a result, the programmer is able to write tests in the high-level language. The test system can therefore take advantage of features such as object-oriented programming constructs, which are available in the high-level language, but not in the HDL. In one embodiment, CVI (described above) is employed as the interface system.
- As shown in FIG. 2, a block diagram of the design verification system,
test subsystem 32,interface subsystem system 34 andhardware simulation subsystem 36 execute within the environment ofoperating system 38. Theinterface subsystem system 34 controls the interaction between the HDL basedhardware simulation subsystem 36 and the C++ basedtest subsystem 32. The interface subsystem allows tests to be written using an object-oriented paradigm and provides the programmer with device objects which translate the tests into HDL bus signals. - Just as the interface subsystem adds a first level of abstraction between the test writer and the HDL test environment, the use of object-oriented programming principles in the test system allows additional levels of abstraction to be obtained within the test subsystem. For example, system level transactions may be defined to generate activity in several devices in response to a single system level function call. Object-oriented principles also provide benefits to the programmer such as the ability to re-use code and to hide data from the test subsystem writer.
- The test subsystem controls each of the device functional objects in the simulated hardware system in order to verify the functionality of the design. The test subsystem utilizes device transaction objects to abstract away some of the details of the device operation. Configuration transaction objects likewise abstract away some of the details of transactions involving more than one functional device. The configuration transaction objects are derived from a system transaction class in order to group together convenience routines and make them available to the configuration transactions. Convenience routines are functions that simplify the process of managing test data and control sequences. The system transaction class also collects test flow control routines for use in simulation of the configuration transactions.
- Referring to FIG. 3, a diagram of a class structure used in one embodiment of the test system is shown. (In FIG. 3, a triangular shape on the line between the two classes indicates inheritance from the higher class.) Object references in the figure are indicated by an arrow with an accompanying ampersand (&). Pointers are indicated by an arrow with an accompanying asterisk (*). One-to-one relationships between objects and/or classes in the figure are indicated by an open circle at the head of the corresponding pointer or object reference arrow. A blackened circle indicates that there may be one or more pointers or object references. The dashed lines from the configuration transaction classes to the device transaction classes indicate that the latter are created in the process of instantiating the former.
- FIG. 3 shows a hierarchical class structure which has a base transaction class40 at the top of the class hierarchy. Base transaction class 40 is an abstract class which is not directly instantiated. Instead, base transaction class 40 serves to provide a set of basic services which are common to all of the transactions. The services are provided through methods or functions which are declared in the base transaction class and are inherited by the classes which will be derived therefrom.
- In this embodiment, base transaction class40 includes several virtual functions which are common to all of the transaction classes in the hierarchy. The use of a common set of interface function names is necessary to take advantage of polymorphism, which is a useful feature of object-oriented programming languages. Polymorphism allows the programmer to create transaction objects and work with these objects in an abstract way while deferring to run time that task of figuring out which device is actually being used. Polymorphism provides several other advantages, including providing consistent high-level interfaces to similar objects, hiding from the programmer object information which he doesn't need to see and simplifying program code by encapsulating object-specific variations within the objects themselves.
- In this embodiment, the functions declared by base transaction class40 include the following: init( ); setup_trans( ); setup_resp( ); and service_signal( ). Init( ) initializes the device associated with the transaction class. Setup_trans( ) enables the associated device to drive transactions in the simulation. Setup_resp( ) controls how the associated device responds to transactions directed to it. Service_signal( ) is called to handle CVI signal messages sent from the HDL to the device.
- A base device class (not shown in the figure) is used in the same manner as the base transaction class. One or more sub-classes can be derived from the base device class. The sub-classes inherit a common set of methods from the base device class and may define additional methods which are specific to the sub-classes. The base device class and its sub-classes enable the instantiation of the device objects which are shown in the figure. Through inheritance, the base device class provides a common interface to all of the bus functional models in the hardware simulation system.
-
Device transaction class 44 is derived from base transaction class 40.Device transaction class 44 therefore inherits the four methods listed above from base transaction class 40. In this embodiment, the methods declared in base transaction class 40 are virtual methods. That is, they are declared, but the implementation of each of the methods is not defined. It is left to the device transaction classes (e.g., device transaction class 44) to provide the program code which implements each of the methods. -
Device transaction class 44 becomes associated with asingle device object 42 through an object reference.Device transaction class 44 controls the transactions whichdevice 42 executes. Because an object reference must always be satisfied, the use of an object reference toassociate device 42 withdevice transaction class 44 forces the user to supply a device object when the device transaction class is instantiated. By forcing the user to supply the device object at instantiation, the possibility of changing the pointer or using a NULL pointer is eliminated and the compiler is allowed to perform static type checking. These properties make the object reference inherently safer to use than a standard C pointer. They add some complexity to the system, however, which will be discussed in more detail below. -
Device transaction class 44 serves to hide the low-level details of the operation ofdevice 42 from the test writer and thereby simplifies the communications between the test subsystem and the bus functional models of the hardware simulation subsystem.Device transaction class 44 also serves to maintain the state ofdevice 42 between invocations of transactions involving the device. The test writer can set up high-level transaction information such as data, address, size and mode in the transaction class and then call a function such as setup_trans( ) to translate this information into individual register operations at the device level. Therefore, the test writer does not need to know which specific register operations are involved in performing a particular function call.Device transaction class 44 thus acts in a manner similar to that of a device driver while also enabling the compiler to perform static type checking. - In addition to enabling static type checking and providing a level of abstraction between device-level operations and the test writer,
device transaction class 44 allows the test writer to define convenience methods associated with the device or device transaction. The test writer is free to define these test methods and any necessary instance variables, both of which may be encapsulated into the device transaction class. - Although the use of device classes and device transaction classes may considerably enhance the test writing environment, there remain some problems associated with multiple-device transactions which are not resolved simply by the use of these classes. For example, a test writer may want to develop convenience routines for transactions involving several devices. These convenience routines may manipulate data, affect the control flow of the simulation (e.g., advance the simulation time) or perform some other function. The convenience routines must, of course, be defined so that they have access to the appropriate devices.
- The test writer might therefore create a system transaction class in which all of these convenience routines are defined. This would provide a grouping of common routines and would therefore potentially achieve the best re-use of program code, but might cause problems in terms of the desired use of object references. Because the test writer wants to have static type checking and wants to avoid NULL pointers, as explained above, the system transaction classes should use object references. The use of object references, however, requires that the associated device object be provided when the system transaction class and the object reference are instantiated. If the system transaction class contains convenience routines relating to all the devices in the design under test, any test which uses this system transaction class (i.e. any of the convenience routines in the class) must instantiate every device referenced in the class (i.e. all of the devices.) This would limit the performance of the system because tests would automatically reserve devices which would never be used for those tests. The unnecessary reservation of devices would also make it very difficult for tests to share device objects.
- Another approach which might be taken by a test writer would be to define a configuration transaction class for every possible system configuration. In other words, a separate configuration transaction class would be written for each combination of devices which might be tested. Using this approach, only those devices which are involved in a transaction are instantiated for each test configuration. There is no unnecessary reservation of devices which are not used. The improved efficiency in the instantiation of device objects, however, is obtained at the expense of the efficient re-use of program code. Many of the configurations defined by the test writer would probably need very similar [access and] convenience routines, but these routines could not be collected in a single transaction class. Instead, the test writer would have to reproduce the code for particular routines in each of the transaction classes which uses the respective routines. Any code sharing could only be achieved by physically copying the routines from one transaction class to another. This would create more work for the test writer and would result in a program which is very difficult to maintain because each of the copies of a routine must be individually updated.
- In one embodiment, the problems of the two approaches described above are overcome by using a combination of the different approaches. As described in the first approach, a
system transaction class 46 is created as a subclass of base transaction class 40.System transaction class 46 is a collector of all the convenience routines which may be needed by the test writer. Becausesystem transaction class 46 uses pointers to device objects instead of object references, it is not necessary to instantiate each device in the system for every test. The instantiation of device objects is left to the configuration transaction classes. - As shown in FIG. 3, the
system transaction class 46 is sub-classed to create one or moreconfiguration transaction classes - One embodiment of the invention uses CVI as the interface subsystem. CVI uses an interrupt driven model for the test environment. An interrupt driven model allows the test to retain very tight control over execution in the simulation subsystem. The use of an interrupt driven model may, however, create difficulties for a test writer because he or she must be prepared to receive any type of interrupt at any point in the simulation—the test subsystem cannot only handle those types of interrupts which are of interest to the test writer. The use of the class hierarchy shown in FIG. 3 simplifies the program code required to implement an interrupt driven model and reduces the burden on the test writer by enabling a state driven style of test writing.
- In a state driven style of test writing, the control flow of the tests are tied to a state sequencer (i.e., finite state machine, or FSM) in a manner resembling a hardware design style. The state sequencer may be defined in the base transaction class or in the system transaction class. The purpose of the state sequencer is to handle signals directed to the device based on the current state of the sequencer. This generally improves the readability of threads in the test subsystem because state information which is usually embedded in the program code is removed. This state information is moved into the device transaction class and stored in a format suitable for the state sequencer. The program code of the test subsystem can therefore be written as a simple stimulus generator. This greatly reduces the complexity of the code.
- The state driven style of test writing may also simplify the writing of convenience routines. Using other styles of test writing, it may be necessary to include code in convenience methods which returns control to the simulation subsystem. In a state driven style, routines can return control to the simulation subsystem at a high level, allowing parallel operation without the need for multi-threading. This is a great benefit in a random testing environment.
- In a system in which there is only one pending transaction and in which the transaction involves only two bus functional models there will be no random interaction of signals within the system. Thus, when a system is tested with only one transaction at a time, the testing cannot account for such random interactions and the possible effects of these interactions. Using a state driven style of testing, several transactions can be pending at once, allowing the random interaction of the transactions in much the same way as they would occur in the actual operation of the device under test. Because the test transactions are written as objects in a state driven test program, they may easily be performed in parallel to obtain the random interaction which cannot be obtained by the individual transactions.
- While the present invention has been described with reference to particular embodiments, it will be understood that the embodiments are illustrative and that the invention scope is not limited to these embodiments. Many variations, modifications, additions and improvements to the embodiments described are possible. These variations, modifications, additions and improvements may fall within the scope of the invention as detailed within the following claims.
Claims (22)
Priority Applications (4)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/262,545 US6360192B2 (en) | 1999-03-04 | 1999-03-04 | Transaction class |
PCT/US2000/005778 WO2000052607A1 (en) | 1999-03-04 | 2000-03-03 | Transaction class |
AU38673/00A AU3867300A (en) | 1999-03-04 | 2000-03-03 | Transaction class |
EP00917745A EP1159694A1 (en) | 1999-03-04 | 2000-03-03 | Transaction class |
Applications Claiming Priority (1)
Application Number | Priority Date | Filing Date | Title |
---|---|---|---|
US09/262,545 US6360192B2 (en) | 1999-03-04 | 1999-03-04 | Transaction class |
Publications (2)
Publication Number | Publication Date |
---|---|
US20010041972A1 true US20010041972A1 (en) | 2001-11-15 |
US6360192B2 US6360192B2 (en) | 2002-03-19 |
Family
ID=22997958
Family Applications (1)
Application Number | Title | Priority Date | Filing Date |
---|---|---|---|
US09/262,545 Expired - Lifetime US6360192B2 (en) | 1999-03-04 | 1999-03-04 | Transaction class |
Country Status (4)
Country | Link |
---|---|
US (1) | US6360192B2 (en) |
EP (1) | EP1159694A1 (en) |
AU (1) | AU3867300A (en) |
WO (1) | WO2000052607A1 (en) |
Cited By (8)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US20050091028A1 (en) * | 2003-10-22 | 2005-04-28 | Takahiro Kondo | Simulator and simulation method |
US20060036422A1 (en) * | 2004-08-13 | 2006-02-16 | Gryba John S | Methods and systems for electronic device modelling |
US20060101166A1 (en) * | 2004-11-10 | 2006-05-11 | Microsoft Corporation | Method and system for structured DMA transactions |
US20060150199A1 (en) * | 2004-11-10 | 2006-07-06 | Microsoft Corporation | Method and system for structured programmed input/output transactions |
US7194705B1 (en) * | 2003-03-14 | 2007-03-20 | Xilinx, Inc. | Simulation of integrated circuitry within a high-level modeling system using hardware description language circuit descriptions |
CN102147829A (en) * | 2011-03-29 | 2011-08-10 | 李姮乐 | IC (integrated circuit) function verification method |
US20140107994A1 (en) * | 2012-10-15 | 2014-04-17 | International Business Machines Corporation | Enabling reuse of unit-specific simulation irritation in multiple environments |
US20150121347A1 (en) * | 2013-10-28 | 2015-04-30 | Aliphcom | Platform framework for wireless media device simulation and design |
Families Citing this family (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
GB2406416A (en) * | 2000-10-31 | 2005-03-30 | Advanced Risc Mach Ltd | Describing an integrated circuit configuration |
US20030033085A1 (en) * | 2001-05-10 | 2003-02-13 | Sanchez Humberto A. | Mechanism for ensuring defect-free objects via object class tests |
US7478018B1 (en) * | 2004-09-30 | 2009-01-13 | Emc Corporation | System and methods for network call load simulation |
US8205174B2 (en) * | 2009-08-17 | 2012-06-19 | Hong Kong Applied Science And Technology Research | Integrated circuit modeling method and framework tool |
US10055327B2 (en) | 2014-09-30 | 2018-08-21 | International Business Machines Corporation | Evaluating fairness in devices under test |
Family Cites Families (5)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US5870585A (en) * | 1995-10-10 | 1999-02-09 | Advanced Micro Devices, Inc. | Design for a simulation module using an object-oriented programming language |
US5732247A (en) | 1996-03-22 | 1998-03-24 | Sun Microsystems, Inc | Interface for interfacing simulation tests written in a high-level programming language to a simulation model |
US5848236A (en) | 1996-03-22 | 1998-12-08 | Sun Microsystems, Inc. | Object-oriented development framework for distributed hardware simulation |
US5751941A (en) | 1996-04-04 | 1998-05-12 | Hewlett-Packard Company | Object oriented framework for testing software |
US6053947A (en) * | 1997-05-31 | 2000-04-25 | Lucent Technologies, Inc. | Simulation model using object-oriented programming |
-
1999
- 1999-03-04 US US09/262,545 patent/US6360192B2/en not_active Expired - Lifetime
-
2000
- 2000-03-03 EP EP00917745A patent/EP1159694A1/en not_active Withdrawn
- 2000-03-03 AU AU38673/00A patent/AU3867300A/en not_active Abandoned
- 2000-03-03 WO PCT/US2000/005778 patent/WO2000052607A1/en not_active Application Discontinuation
Cited By (16)
Publication number | Priority date | Publication date | Assignee | Title |
---|---|---|---|---|
US7194705B1 (en) * | 2003-03-14 | 2007-03-20 | Xilinx, Inc. | Simulation of integrated circuitry within a high-level modeling system using hardware description language circuit descriptions |
EP1530130A2 (en) * | 2003-10-22 | 2005-05-11 | Matsushita Electric Industrial Co., Ltd. | Simulator and simulation method |
US20050091028A1 (en) * | 2003-10-22 | 2005-04-28 | Takahiro Kondo | Simulator and simulation method |
EP1530130A3 (en) * | 2003-10-22 | 2006-07-05 | Matsushita Electric Industrial Co., Ltd. | Simulator and simulation method |
US7577557B2 (en) | 2003-10-22 | 2009-08-18 | Panasonic Corporation | Simulator and simulation method for behaviors of processors |
US20060036422A1 (en) * | 2004-08-13 | 2006-02-16 | Gryba John S | Methods and systems for electronic device modelling |
US7734832B2 (en) * | 2004-11-10 | 2010-06-08 | Microsoft Corporation | Method and system for structured programmed input/output transactions |
US20060150199A1 (en) * | 2004-11-10 | 2006-07-06 | Microsoft Corporation | Method and system for structured programmed input/output transactions |
US20060101166A1 (en) * | 2004-11-10 | 2006-05-11 | Microsoft Corporation | Method and system for structured DMA transactions |
US8079036B2 (en) | 2004-11-10 | 2011-12-13 | Microsoft Corporation | Method and system for structured DMA transactions |
CN102147829A (en) * | 2011-03-29 | 2011-08-10 | 李姮乐 | IC (integrated circuit) function verification method |
US20140107994A1 (en) * | 2012-10-15 | 2014-04-17 | International Business Machines Corporation | Enabling reuse of unit-specific simulation irritation in multiple environments |
US20140107996A1 (en) * | 2012-10-15 | 2014-04-17 | International Business Machines Corporation | Enabling reuse of unit-specific simulation irritation in multiple environments |
US9009018B2 (en) * | 2012-10-15 | 2015-04-14 | International Business Machines Corporation | Enabling reuse of unit-specific simulation irritation in multiple environments |
US9015024B2 (en) * | 2012-10-15 | 2015-04-21 | International Business Machines Corporation | Enabling reuse of unit-specific simulation irritation in multiple environments |
US20150121347A1 (en) * | 2013-10-28 | 2015-04-30 | Aliphcom | Platform framework for wireless media device simulation and design |
Also Published As
Publication number | Publication date |
---|---|
WO2000052607A1 (en) | 2000-09-08 |
US6360192B2 (en) | 2002-03-19 |
WO2000052607A8 (en) | 2001-02-08 |
EP1159694A1 (en) | 2001-12-05 |
AU3867300A (en) | 2000-09-21 |
Similar Documents
Publication | Publication Date | Title |
---|---|---|
US5847955A (en) | System and method for controlling an instrumentation system | |
US5710727A (en) | System and method for creating resources in an instrumentation system | |
US7865350B1 (en) | Partitioning a model in modeling environments | |
US6421634B1 (en) | Interface independent test system | |
US6212489B1 (en) | Optimizing hardware and software co-verification system | |
US7913170B2 (en) | System and method for performing type checking for hardware device nodes in a graphical program | |
US5915115A (en) | Control system and method for direct execution of software application information models without code generation | |
US5745767A (en) | Method and system for testing the interoperability of application programs | |
US8739129B1 (en) | Multi-domain unified debugger | |
US7743335B2 (en) | System and method for accessing registers of a hardware device in a graphical program | |
US5848236A (en) | Object-oriented development framework for distributed hardware simulation | |
US5640572A (en) | System and method for mapping driver level event function calls from a process-based driver level program to a session-based instrumentation control driver level system | |
US6360192B2 (en) | Transaction class | |
US5627998A (en) | System and method for mapping calls to functions in a first driver level library to a session-based instrumentation control driver level system | |
US7072820B1 (en) | Accessing state information in a hardware/software co-simulation | |
US6453450B1 (en) | Timing diagram compiler and runtime environment for interactive generation of executable test programs for logic verification | |
US7490032B1 (en) | Framework for hardware co-simulation by on-demand invocations from a block model diagram design environment | |
Krause et al. | Timing simulation of interconnected AUTOSAR software-components | |
US9329840B1 (en) | Graphical programming of custom device drivers | |
US20020059563A1 (en) | Method and system for self-adaptive code | |
Copstein et al. | SIMOO-An environment for the object-oriented discrete simulation | |
US8707306B1 (en) | Implementing user-selectable concurrent access protection mechanism in a multi-tasking modeling environment | |
Jonkers | Interface-centric architecture descriptions | |
Bitter et al. | LabVIEW Advanced Programming Techiniques | |
US6937973B1 (en) | Design of an application specific processor (ASP) |
Legal Events
Date | Code | Title | Description |
---|---|---|---|
AS | Assignment |
Owner name: SUN MICROSYSTEMS, INC., CALIFORNIA Free format text: ASSIGNMENT OF ASSIGNORS INTEREST;ASSIGNORS:DEARTH, GLENN A.;WHITTEMORE, PAUL M.;PLOUFFE, GEORGE R., JR.;AND OTHERS;REEL/FRAME:009948/0029;SIGNING DATES FROM 19980427 TO 19990505 |
|
STCF | Information on status: patent grant |
Free format text: PATENTED CASE |
|
FPAY | Fee payment |
Year of fee payment: 4 |
|
FPAY | Fee payment |
Year of fee payment: 8 |
|
FPAY | Fee payment |
Year of fee payment: 12 |
|
AS | Assignment |
Owner name: ORACLE AMERICA, INC., CALIFORNIA Free format text: MERGER AND CHANGE OF NAME;ASSIGNORS:ORACLE USA, INC.;SUN MICROSYSTEMS, INC.;ORACLE AMERICA, INC.;REEL/FRAME:037278/0625 Effective date: 20100212 |