1. Field of the Invention
This invention relates to a medium storing a model creation program for creating a model for communicating with an object apparatus to be verified, or an object apparatus of verification, a model creation apparatus and a model creation method.
2. Description of the Related Art
Verifications of hardware can be roughly classified into “function verifications” and “interface verifications”. The objective of function verifications is to verify that the object hardware to be verified is functioning properly. On the other hand, the objective of interface verifications is to verify that the object hardware to be verified is exchanging properly data and signals with some other piece of hardware. Generally, attention is paid to function verifications of hardware. However, interface verifications are equally important.
Attention is paid to three items listed below when verifying an interface of hardware.
(Verification item 1) Can the interface exchange signals properly in a manner as specified in the applicable specification?
(Verification item 2) Does the interface exchange signals properly, processing exceptional operations that are expected in the applicable specification?
(Verification item 3) Does not the interface fall into an unrecoverable condition due to an exchange of signals not specified in the applicable specification and can it process normal exchanges of signals that are input subsequently?
For ordinary interface verifications, it is sufficient to check the verification item 1 and the verification item 2. However, it is necessary to check the verification item 3 for some special pieces of hardware in addition to the verification item 1 and the verification item 2, although such a sort of hardware does not take a large part. For example, so-called bus bridges belong to such a sort of hardware. Since a bus bridge connects two buses, the buses can no longer communicate with each other once the bus bridge falls in trouble. Therefore, it is necessary to check and see that the bus bridge does not fall into an incommunicable state if a signal pattern that is not specified in the applicable interface specification and hence not expected to appear flows to either bus beside the normal patterns and the abnormal patterns that are specified in the applicable interface specification.
New types of hardware have been and being designed by utilizing the IPs (intellectual properties) that were designed in the past and the IPs that have been procured externally to show a trend of hardware design in recent years. If such is the case, the IP that is reutilized is required to exchange signals with some other piece of hardware in different operation environments. Additionally, the IP that is reutilized may also be required to withstand exchanges of signals that are not normal and abnormal signals that are not expected in operation environments. Then, it is necessary to verify that the hardware does not fall into an unrecoverable condition when it comes to a deadlock, a livelock or the like.
A piece of verifier communication hardware that is adapted to communicate with the object hardware to be verified in order to verify the interface of the object hardware to be verified.
A verifier communication model (pseudo-master/slave model) can be used to replace the verifier communication hardware that transmits a signal to and receives a signal from the object hardware to be verified as input signal and output signal. The verifier communication model is a model created by describing the verifier communication hardware by means of a hardware description language. Basically, a verifier communication model outputs a signal provided by the applicable interface specification to the object hardware to be verified. Then, it receives the signal output from the object hardware to be verified as a response and outputs a signal that is provided next if the received signal conforms to the specification.
It is possible to do two different types of test as listed below by means of a verifier communication model for the purpose of interface verification of hardware.
(Test technique 1) A test pattern is generated for each use case. With this test technique, it is necessary to check the operation for each use case provided by the interface specification.
(Test technique 2) Test patterns are generated at random.
For these test types, there are two types of test pattern that are input to the interface of the object hardware to be verified. They include exchanges of signals provided by the specification (protocol) of the interface and signals not provided by (and hence violating) the interface specification.
Techniques for generating test patterns have been developed to date (see, inter alia, Patent Document 1: Jpn. Pat. Appln. Laid-Open Publication No. 9-91315 and Patent Document 2: Jpn. Pat. Appln. Laid-Open Publication No. 6-231063). The most primitive test pattern generation technique is a technique of manually generating a test pattern on the basis of the applicable interface specification. Techniques for creating a verifier communication model by converting the interface specification into a finite state machine (FSM) and subsequently automatically generating a test pattern by means of the technique described in Non-Patent Document 1 (J. Yuan, K. Albin, A. Aziz and C. Pixley, “Constraint Synthesis for Environment Modeling in Functional Verification”, in Proc. Design Automation Conference, pp. 296-299, 2003) are known. This sort of approach is suitable for creating a verifier communication model by generating a test pattern for normal operations provided by the applicable interface specification or a test pattern for expected abnormal operations.
Known techniques that relate to the present invention include those for creating an FSM from a timing chart (see, inter alia, Non-Patent Document 2: K. Ara and K. Suzuki, “A proposal for Transaction-Level Verification with Component Wrapper Languate”, in Process. Design Automation and Test in Europe Conference, pp. 82-87, 2003 and Non-Patent Document 3: K. Ara and K. Suzuki, “Fine-Grained Transaction-Level Verification: Using a Variable Transactor for Improved Coverage at the Signal Level”, In IEEE Trans. on Computer-Aided Design of Integrated Circuits and Systems, vol. 24, no. 8, pp. 1234-1240, August 2005.
However, it is not possible to create a verifier communication model for creating a test pattern that is not expected in the applicable interface specification by means of any of the state of art techniques. To date, such test patterns have been created manually. While manual creation provides a high degree of freedom, the efficiency of the operation of creating a test pattern is very low. Additionally, a scheme for not only inputting normal test patterns and abnormal test patterns but also inputting abnormal test patterns into normal test patterns is required when verifying the interface of hardware.
In view of the above-identified problems, it is therefore the object of the present invention to provide a medium storing a model creation program for creating a model for communicating with an object apparatus to be verified, a model creation apparatus and a model creation method.
In the first aspect of the present invention, the above object is achieved by providing a medium storing a model creation program for causing a computer to create a model for communicating with an object apparatus to be verified so as to be readable to the computer, the program causing the computer to execute: an acquisition step that acquires a first finite state machine expressing the interface specification of the object apparatus to be verified as a finite state machine; a first addition step that adds an error state and a state transition to the error state to the first finite state machine to produce a second finite state machine and sets the transition conditions of the second transition machine according to the set error probability; and a conversion step that converts the second finite state machine into a model for communicating with the object apparatus to be verified.
In the second aspect of the present invention, there is provided a model creation apparatus for creating a model adapted to communicate with an object apparatus to be verified, or an object of verification, the apparatus including: an acquisition section that acquires a first finite state machine expressing the interface specification of the object apparatus to be verified as a finite state machine; a first addition step section adds an error state and a state transition to the error state to the first finite state machine to produce a second finite state machine and sets the transition conditions of the second transition machine according to the set error probability; and a conversion section that converts the second finite state machine into a model for communicating with the object apparatus to be verified.
In the third aspect of the present invention, there is provided a model creation method for creating a model adapted to communicate with an object apparatus to be verified, or an object of verification, the method including: an acquisition step that acquires a first finite state machine expressing the interface specification of the object apparatus to be verified as a finite state machine; a first addition step that adds an error state and a state transition to the error state to the first finite state machine to produce a second finite state machine and sets the transition conditions of the second transition machine according to the set error probability; and a conversion step that converts the second finite state machine into a model for communicating with the object apparatus to be verified.
Thus, according to the present invention, it is possible to create a model for communicating with an object apparatus to be verified that can be used to do tests not expected in the applicable interface specification.
Now, the present invention will be described in greater detail by referring to the accompanying drawings that illustrate preferred embodiments of the invention.
Firstly, the configuration of a verifier communication model creation apparatus (model creation apparatus) of this embodiment will be described.
Now, the operation of the verifier communication model creation apparatus of this embodiment will be described below.
Subsequently, the transition adding section 13 executes a transition adding process of adding a transition to the error state defined by the error state defining process to the FSM stored in the FSM memory section 32 and storing it in the FSM memory section 32 (S20). Then, the model creation section 21 executes a model creation process of creating a verifier communication model from the FSM stored in the FSM memory section 32 and storing it in the model memory section 34 (S21).
Thereafter, the mechanism adding section 22 executes a mechanism adding process of adding a coverage collection mechanism (recording mechanism) to the verifier communication model stored in the model memory section 34 and storing it in the model memory section 34 (S22) to end the flow of operation.
Now, the operation of the verifier communication model creation apparatus of this embodiment will be described in detail below by way of an exemplar interface specification.
Now, the FSM creation process will be described below.
An interface specification is normally expressed as a waveform (timing chart).
The initial state of the FSM is state S0. Transition T01 to state S1 takes place to state S0 when transition condition a is satisfied. The state S1 does not show any transition (or transition T11 to state S1 takes place) when transition condition b is satisfied but transition T12 to state S2 takes place when transition condition c is satisfied.
Transition T20 to state S0 takes place to state S2 when transition condition d is satisfied.
Now, the error state defining process will be described below.
In this embodiment, the error state defining section 12 defines an error state E. However, the error state defining section 12 may alternatively define a plurality of error states or randomly define one or more error states.
Then, the error state defining section 12 selects and sets the error probabilities that are the probabilities with which those error transitions respectively take place. More specifically, the error state defining section 12 receives the input of the probability of each error transition from the user (verifier) and then stores it in the error probability memory section 33. Then, the error state defining section 12 selects and sets the input error probabilities and stores them in the error probability memory section 33 as error probability table.
With this error state defining process, it is possible to automatically create a transition from a normal state to an error state. Additionally, the user can control transition probabilities to an error state and hence can conduct an appropriate test.
Now, the transition adding process will be described below.
The transition adding section 13 adds the error transitions from the individual states and, at the same time, corrects the normal transitions.
Firstly, the transition adding section 13 adds transition T0E from state S0 and corrects the transition T01. Assume that the transition condition of error transition T0E is r(a). On the other hand, the transition condition of transition T01 is that error transition T0E does not take place and the original transition condition a is satisfied and hence it is expressed by (r(1−a) && a). Note that the output signal for error transition T0E is the logical NOT, or A′, of the output signal A for normal transition T01. Similarly, the transition adding section 13 selects and sets the transition conditions and the output signals of transitions T11, T12, T1E, T20 and T2E.
With this transition adding process, it is possible to create an FSM that transits into an error state with the set error probabilities.
Now, the model creation process will be described below.
The model creation section 21 converts the FSM to which error transitions are added as a result of an transition adding process into a verifier communication model that is described in a hardware description language or a general purpose programming language and stores the model in the model memory section 34 as a verifier communication model. Now, both a verifier communication model created when no error transition is added and a verifier communication model creased when error transitions are added will be described below. The model is described in hardware simulation language Verilog (tradename)-HDL in the following instance.
With this model creation process, it is possible to create a verifier communication model that transits into an error state with a set error probability.
Now, the mechanism adding process will be described below.
The mechanism adding section 22 adds a coverage collection mechanism to the transition part of the verifier communication model created by the model creation process. The coverage collection mechanism counts the number of times of passage of each transition and outputs it.
All the state transitions in the FSM are listed up in the scoreboard and the number of times of each state transition is recorded there.
A test tool can conduct a test by using the verifier communication model created by this verifier communication model creation apparatus and the object hardware to be verified. The test tool can acquire the degree of sufficiency of the test by means of a scoreboard and can conduct one or more additional tests or terminate the test according to the degree of sufficiency.
The verifier communication model creation apparatus may reset the error probabilities, for example, by raising the error probability of each error transition whose number of times of passage is small according to the scoreboard. It may allow a test tool to access the error probability table so that the test tool may reset the error probabilities according to the scoreboard and repeat the test.
With this mechanism adding process, the user can know the number of times of passage of each and every state transition, the number of times of output of each and every test pattern and so on. Then, as a result, the test tool and the user can see the degree of sufficiency of each test.
Thus, it is possible to test the error processing capabilities of the object hardware to be verified such as if the object hardware to be verified can appropriately cope with a situation where a transition to an error state takes place by using the verifier communication model created by this embodiment.
A verifier communication model creation apparatus adapted to create a verifier communication mode that outputs a test pattern according to test requirements will be described in the following description of this embodiment.
The verifier communication model created by the verifier communication model creation apparatus of Embodiment 1 makes a transition to an error state only once. In other words, this verifier communication model outputs an abnormal test pattern only once and thereafter it no longer outputs any abnormal test pattern. Such a test may be not appropriate depending on the case of testing the interface of hardware. Examples of such cases may include a case where it is desirable to output an abnormal test pattern only in a specific test and a case where it is desirable to output an abnormal test pattern and immediately thereafter a normal test pattern.
Firstly the configuration of the verifier communication model creation apparatus of this embodiment will be described below.
Now, the operation of the verifier communication model creation apparatus of this embodiment will be described below.
After the process S11 is executed as in Embodiment 1, the error state defining section 42 sets test requirements and executes the test requirements defining process stored in the requirements memory section 55 (S15). Then, the error state defining section 42 executes an error state defining process for defining an error state for partial FSM so as to satisfy the test requirements (S16). Thereafter, the processes S20, S21, S22 are executed as in Embodiment 1.
Now, the operation of the verifier communication model creation apparatus of this embodiment will be described in detail below by way of an exemplar interface specification.
Now, the test requirements defining process will be described below.
The error state defining section 42 receives an input of test requirements from the user and stores it in the requirements memory section 55. Test requirements specify the transactions for outputting an error according to the interface specification, the types of error states to be added, the state of the origin of transition that can make a transition to an error state in specific transactions and so on. If the error state defining section 42 defines a plurality of error states, test requirements specify the error state of the destination of transition.
Now, the error state defining process will be described below.
The error state defining section 42 defines error states according to the test requirements stored in the requirements memory section 55.
Then, the error state defining section 42 sets the error probabilities that are the probabilities with which transitions T0A, T3B and T4C to error states E1, E2 and E3 take place respectively. More specifically, the error state defining section 42 receives the input of the error probability of each error transition and stores it in the error probability memory section 33. Then, the error state defining section 42 sets the input error probabilities and stores them in the error probability memory section 33 as error probability table.
With the test requirements defining process and the error state defining process as described above, it is possible to create a verifier communication model that generates errors in specific transactions in the interface specification. It is also possible to automatically create state transitions that satisfy the test requirements.
Now, the mechanism adding process will be described below.
Thus, it is possible to test with ease the ability of withstanding errors of the object hardware to be verified such as if the object hardware to be verified can restore the normal state when a transition to an error state takes place by using a verifier communication model created by this embodiment.
The acquisition step corresponds to the error state defining process and the test requirements defining process of the above-described embodiments. The first addition step corresponds to the transition adding process of the embodiments. The conversion step corresponds to the model creation process of the embodiments. The second addition step corresponds to the mechanism adding process of the embodiments. The specification conversion step corresponds to the FSM creation process of the embodiments.
The acquisition section corresponds to the error state defining section of the embodiments. The first addition section corresponds to the transition adding section of the embodiments. The conversion section corresponds to the model creation section of the embodiments. The second addition section corresponds to the mechanism adding section of the embodiments. The specification conversion section corresponds to the FSM creation section of the embodiments.
The embodiments of model creation apparatus can easily find applications in information processing apparatus to raise the performance of the information processing apparatus. Information processing apparatus to which the present invention is applicable include PCs (personal computers), servers and work stations.
It is possible to provide a program for causing the computer that operates as model creation apparatus to execute the above-described steps. It is possible to cause a computer that operates as model creation apparatus to execute the program by storing it in a computer-readable recording medium. Computer readable recording mediums that can be used for the purpose of the present invention include portable storage mediums such as CD-ROMs, flexible disks, DVDs, magneto-optic disks and IC cards, data bases adapted to hold computer programs, other computers, the data bases of such computers and transmission mediums on communication lines.
Number | Date | Country | Kind |
---|---|---|---|
2007-005367 | Jan 2007 | JP | national |