Patent Publication Number: US-8112263-B2

Title: Method for logic checking to check operation of circuit to be connected to bus

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     The present application is a division of U.S. application Ser. No. 10/291,508, filed on Nov. 12, 2002, now U.S. Pat. No. 7,548,841, issued Jun. 16, 2009, the entire disclosure of which is incorporated by reference herein. 
    
    
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention relates to a logic checking method for checking operation of circuit which is to be connected to bus in System LSI or the like. 
     2. Description of the Related Art 
     Hitherto, checking of logic during development of System LSI which has an integrated CPU is conducted using actual logic circuit by performing simulation using software which runs on an actual machine. 
     First, a prior art logic checking method is described with an example in which an arbiter is an object to be checked. When a plurality of bus master circuits connected to a certain bus try to access to one or more bus slave circuit or circuits, one of them must first obtain priority of accessibility to avoid collision of signals from different bus masters over the bus. 
     An arbiter is a circuit of which function is to arbitrate the accessibility. In the prior art checking of an arbiter is conducted by actually connecting logic circuits which are used as bus masters. 
       FIG. 20  shows a prior art checking method of an arbiter in which Master A  220 , Master B  221  and Master C  222  are blocks to operate as masters on bus  240 . Slave D  230  is a block to operate as a slave on bus  240 . Only single slave is connected to the bus  240  in this example but more than one slave may be connected. The Arbiter  210  is a block to perform arbitration of the accessibility to bus  240 . This Arbiter  210  is an object of logic checking. 
     A master block first requests the Arbiter  210  to give accessibility priority to the bus  240  to avoid collision with other masters when it tries to gain access to a slave block (to transmit data or to request data). The Arbiter  210  arbitrates requests for bus accessibility from masters to issue bus access permission signals to a master. A master block can gain access to a Slave D  230  via bus  240  only after it obtained this permission signals. 
     As shown in the example of  FIG. 20 , there may be various kinds of bus masters with various functionality, such as, for example, a Master A  220  which receives data via bus  250  which is a different path from the bus  240  to transmit them to the Slave D  230  after given processing, or a Master B  221  which has an additional functionality for requesting data to the Slave D  230  to output obtained data via the bus  251  after given processing besides the similar functionality with Master A  220 , or a Master C  222  which has no other interface than the bus  240  for data reception and transmission and requests data to the Slave D  230  for returning obtained data to the Slave D  230  after given processing. 
       FIG. 21  shows the way how arbitration is conducted. In this case, the order of priority of bus accessibility to be issued by the function of the Arbiter  210  between the Master A  220 , the Master B  221  and the Master C  222  is set as “Master A&gt;Master B  221 &gt;Master C”. Also, in this example, any of the bus masters conducts only data transmission to the Slave D  230  but makes no request for data to it. The burst length of data transmission is fixed at 4 bursts. 
     In  FIG. 21  the Master A  220  issues a request for bus accessibility req a at timing a and the Arbiter  210  returns an acknowledgement signals ack a at timing b. Receiving this, the Master A  220  starts data transmission at timing c. During the same period, the Master B  221  issues a request for bus accessibility req b at timing c and the Master C  222  req c at timing d, respectively, but it is shown that they are kept waiting. 
     When data transmission of the Master A  220  is over, the Arbiter  210  returns acknowledgement signals ack b to Master B  221  at timing g. At timing g requests for bus accessibility for Master B  221  and Master C  221  compete but since a higher priority is given to Master B  221 , an acknowledgement is given to Master B  221 . In this way the Arbiter  210  arbitrates bus accessibility to prevent collision over the bus  240 . Bus  240  in  FIG. 21  shows this. 
     In such bus arbitration, if only such a case is considered as Master A  220  and Master B  221  are in competition, for example, test items to be checked on bus arbitration circuit are those events where; (1) only req a is issued, (2) only req b is issued, (3) both req a and req b are issued, with req a issued earlier, (4) both req a and req b are issued, with req b issued earlier, (5) both req a and req b are issued simultaneously, (6) both req a and req b are simultaneously issued, while currently Master A  220  is receiving acknowledgement signals ack a, and (7) both req a and req b are simultaneously issued, while currently Master B  221  is receiving acknowledgement signals ack b. To check logic of the arbiter circuit, it is required to cause all of the above events occur but, for example, even if it is desired to cause “(5) both req a and req b are issued simultaneously”, Master A  220  and Master B  221  which are actual circuitries can issue request signals only after a given processing, so that it is impossible to control timing of issuance of a bus access request at will. Accordingly, it is necessary to keep two masters executing transactions for issuing a bus access request until simultaneous output of requests for access is achieved by both masters. 
     The more number of bus master circuits is, the more complex their combination becomes, thus increasing the number of test items. As a result it would take very long simulation time to perform tests of all the test items necessitating a large number of test statements. 
     Further, as for the timing of start of checking, checking of an arbiter can be conducted only after completion of each of bus master circuits (completion of checking). If checking of an arbiter is conducted using a bus master circuit of which checking is not completed and any failure develops, it would be difficult to specify whether the cause of the failure lies in the bus master circuits or in the arbiter, resulting in a long checking period. 
     Next, described is logic checking for such circuits as memory controllers, I/O interfaces and bus bridges.  FIG. 22  shows a prior art test bench consisting of actual circuits only. As shown here, a test is conducted using such circuitries as CPU and DMA (Direct Memory Access) controller which are actually connected to an object to be checked.  FIG. 23  shows an example of statements of a prior art test sequence for logic checking. Main flow of the test code is described as follows. 
     1. (step 1.1) initialize checking the test bench as a whole, 2. (step 1.2) initialize the actual circuits which are connected to the object to be checked, 3. (step 1.3) initialize the object to be checked, 4. (step 1.4) setting for data transmission the actual circuits connected to the object to be checked, 5. (step 1.5) activate data transmission of the actual circuits connected to the object to be checked, 6. (step 1.6) finalize the actual circuits connected to the object to be checked after data transmission is completed, 7. (step 1.7) finalize the object to be checked, and 8. (step 1.8) finalize the test bench as a whole. 
     In the above steps 1 and 2 included are such processes as fetching from memory of a program to be processed in the CPU and initialization of DMA. Steps 2, 4, 5 and 6 are the processes required for operation of the actual circuits connected to the object to be checked. The larger the scale of an LSI is, the more complex these processes tends to become and those processes become overheads at a time of a simulation, when the object to be checked is being checked. If some malfunction develops in the related portion resulting in a failure of achieving a desired performance, testing of the object to be checked would be made difficult. Also, in case of DMA, it would be difficult to test the object to be checked under a situation in which all modes of data transmission specified by the bus are caused to take place. Also, selection of addresses required in data transmission at will or arrangement of such addresses in desired order would be difficult to conduct only by setting of DMA. 
       FIG. 24  is a block diagram showing an object of a simulation in a prior art. A bus bridge  2  connects various buses within circuit to control data transmission between buses. A memory  3  is a storage device. A memory controller  4  controls write/read operations into or out of the memory  3 . An IO-bus  5  provides a data path for data transmission within the circuit between various input/output devices or machines. Each of IO1 interface  6 , IO2 interface  7  and IO3 interface  8 , respectively controls data transmission to and from I/O devices connected to this circuit. A device bus  11  is a data path for data transmission between logic circuits within the circuit. A device ( 1 )  12  and a device ( 2 )  13  have logic function such as compression and/or expansion, respectively. A CPU  20  controls the circuit as a whole. A ROM  21  stores programs etc. 
     The prior art example described in  FIG. 24  is solely comprised of functions used in actual circuit. A CPU  20  executes programs retrieved from the ROM  21 , for example, to transfer the resulting contents to the memory  3  and then executes instructions read out of memory  3 . In this case the instruction read out of memory  3  decides what to be executed next by CPU  20 , so that instruction fetching necessarily takes place before any transmission of data, except that an instruction is held in a cache within the CPU  20 . 
     As described above, checking of a logic circuit requires a simulation to be conducted by preparing actual software statements to produce a ROM image. However, it is not easy to make statements in actual software to produce stimuli for achieving checking of a desired functional block and requirement of initialization of various components such as a CPU makes it difficult to conduct a checking simply. Furthermore, if a CPU is actually used in a simulation, execution will be very time-consuming. What will take only about 10 seconds in an actual machine would sometimes take 24 hours for a run in a simulation. 
     In the prior art example given in  FIG. 24  starting data transmission from other devices than the CPU  20  would require activation of DMA by setting IO1 interface  6  etc. In this case different setting methods must be applied to each I/O and transfer rate is decided depending on what kind of I/O device is used. 
     Accordingly, in addition to complex setting processes themselves, only limited number of transfer modes is available. This makes it impossible to achieve consecutive transmission to take place, thus complex situation under which various cases occur can not be created. As a result complete checking is difficult to be performed. 
     SUMMARY OF THE INVENTION 
     It is an object of the present invention to provide a method for logic checking which can easily start operation without complex setting and which allows complete checking even on a complex situation. 
     Another object of the present invention is to provide a method for logic checking which can be performed under severer than actual conditions. 
     According to one aspect, the present invention which achieves these objectives relates to a method for logic checking to check operation of a circuit to be checked connected to a bus to which at least one master circuit and at least one slave circuit are connected, comprising the steps of connecting a model or models to said bus in place of said master circuit or said slave circuit, outputting given signals at given timing from said model or models and checking the operation of said circuit to be checked. 
     Further objects, features and advantages of the present invention will become apparent from the following description of the preferred embodiments with reference to the attached drawings. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
         FIG. 1  shows the method for checking an arbiter circuit according to an embodiment of the present invention. 
         FIG. 2  is a block diagram showing a construction of a bus master model. 
         FIG. 3  is a flow chart showing operational sequence of the bus master model. 
         FIG. 4  shows another embodiment of the method for checking. 
         FIG. 5  shows a test bench using a bus master model. 
         FIG. 6  shows an example of statements for a test sequence of the present invention. 
         FIG. 7  shows an example of bus protocol to which the models are connected. 
         FIG. 8  shows an example of statements for a master model. 
         FIG. 9  shows an example of statements for a test sequence focusing on the transfer timing of bus according to an embodiment of the present invention. 
         FIG. 10  shows a test bench using a slave model. 
         FIG. 11  shows a test bench using a plurality of master models. 
         FIG. 12  shows an example of statements for a slave model. 
         FIG. 13  shows a test bench using a plurality of slave models. 
         FIG. 14  shows a test bench using a plurality of both master models and slave models. 
         FIG. 15  is a block diagram showing an object of a simulation. 
         FIG. 16  shows an example of statements for a test to execute a simulation. 
         FIG. 17  shows another example of statements for a test to execute a simulation. 
         FIG. 18  shows other example of statements for a test to execute a simulation. 
         FIG. 19  shows further example of statements for a test to execute a simulation. 
         FIG. 20  shows a method for checking arbiter circuit according to a prior art. 
         FIG. 21  is a timing chart showing a sequence of the bus arbitration. 
         FIG. 22  shows a prior art test bench using only actual circuits. 
         FIG. 23  shows an example of statements for a test sequence according to a prior art. 
         FIG. 24  is a block diagram showing an object of a simulation according to a prior art. 
     
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENTS 
     A preferred embodiment of the present invention will be described in detail with reference to the drawings. 
     First Embodiment 
       FIG. 1  shows a construction of a system for the checking method according to an embodiment of the present invention. In this example connected to the bus in place of the prior art bus master circuits are bus master models which are capable to perform bus access according to bus protocol. 
       FIG. 2  shows the construction of the bus master models. The bus master model  100  in  FIG. 2  has a start trigger  110 , a offset timer  120 , a bus access sequencer  130  and various parameters  140 . The start trigger  110  receives a start command from the test statements. 
     Parameters included in the various parameters  140  are “offset time” which specifies offset time between reception of a start command and activation of a bus access, “command interval” which specifies an interval between an end of a bus access and activation of the next bus access, “Write/Read” which distinguishes whether an access is for a data transmission or for a request of data, “transfer data” which specifies a value of transfer data and “number of transfer data” which specifies a number of transfer data. The parameters  140  may be directly designated from the test statements or may be generated dynamically within the master model. 
     The Offset timer  120  refers to the offset time in the parameters  140  to hold start of a bus access for clock cycles corresponding to its value. The bus access sequencer  130  is activated after being held for offset time by the offset timer  120  to activate a bus access according to the bus protocol. Details of an access are defined by the parameter  140 . How many times the transfer is to be conducted is defined by the “number of transfer data” parameter. If an access is defined as “data transfer access”, the value of transfer data is available by referring to the “transfer data” parameter. 
     At the end of an access the next access is activated after waiting for clock cycles given by the “command interval” parameter. “Transfer data” parameter may be provided as a list directly from the test statements or may be dynamically generated by the bus master model  100  every time it activates a bus access.  FIG. 3  is a flow chart illustrating details of operation of the master model. 
     In step S 310 , determined is whether a preset offset time is to be used or not. If not, in step S 311 , an offset time parameter is generated. In step S 312 , processing is kept waiting for a time period defined by “offset time×clock cycles” using the preset offset time or the generated offset time. In step S 320 , determined is whether a preset number of the transfer data is to be used or not. If not, in step S 321 , a number of the transfer data is generated. In step S 330 , determined is whether a preset command interval is to be used or not. If not, in step S 331 , a command interval parameter is generated. In step S 332 , processing is kept waiting for a time period defined by “command interval×clock cycles” using the preset command interval or the generated command interval parameter. 
     In step S 340 , determined is whether a preset write/read is to be used or not. If not, in step S 341 , a write/read parameter is generated. In step S 342 , determined is whether an access is “write” or not. If it is “write”, in step S 350 , determined is whether a preset transfer data is to be used or not. If not, in step S 351 , a transfer data is generated. In step S 352 , the transfer data is transferred to perform a write access. On the other hand, if an access is not “write” but “read”, in step S 353 , a data request access is performed. After the end of an access, in step S 360 , one is deducted from the number of transfer data to determine, in step S 361 , whether the number of transfer data is 0 or not. If it is not 0, processing returns to step S 340  to repeat steps from S 340  to S 361  until the number of transfer data is determined to be 0 in step S 361 . 
     In  FIG. 1  each of the bus masters in  FIG. 20  is replaced with the bus master model  100  of  FIG. 2 .  FIG. 1  illustrates an embodiment according to the present invention of a method for checking a bus arbiter. Master A  220 , Master B  221  and Master C  222  in  FIG. 20  are replaced with Master A Model  200 , Master B Model  201  and Master C Model  202  in  FIG. 1 , respectively. 
     According to the checking method shown in  FIG. 1  if it is desired to simulate a situation, for example, where “both Master A and Master B request bus accessibility simultaneously” which is mentioned previously as one of checking items for an arbiter  210 , this is achieved by providing the same “offset time” parameter to both Master A Model  200  and Master B Model  201 , thus realizing easy control. Other combinations of cases may be available easily by controlling the “offset time” parameter and the “command interval” parameter of the master model. Preparing test statements to bring forth all test items by controlling those master models could be very time consuming but this arrangement allows generating such parameters as “offset time” parameter and “command interval” parameter during operation of master models as shown in steps S 311  or S 331  in the flow chart of  FIG. 3 , so that shorter checking period may be achieved by automatically activating some of test items, while only test statements for the remainder may be produced under control of a human operator. 
     In  FIG. 20  bus master circuits with various functions are connected to the bus arbiter circuit, but all of them are replaced with the same bus master models in the present checking method. This master model can be made to perform only data transfer access to a slave, as is the case of the Master A of  FIG. 20 , by fixing “write/read” parameter to write. Accordingly, it can not only conduct of checking of a bus arbiter circuit by simulating operation of the actual circuit faithfully but as it has more functionality than an actual circuit, it can check an arbiter circuit as a more universally applicable unit and warrant its functionality. 
     Second Embodiment 
     In the first embodiment, all of bus master circuits connected to a bus arbiter circuit are replaced with bus master models but in the second embodiment only Master B  221  and Master C  222  in  FIG. 20  of a prior art are replaced with master models to use a combination of an actual circuit bus master and the master models.  FIG. 4  illustrates this example. 
     In this case Master B Model  201  and Master C Model  202  can cause various bus accesses against a bus access of Master A  220 . As described above, a bus master model can both intentionally or randomly perform a bus access, so that it allows conducting efficient checking of bus access function of Master A  220 . This provides an advantage that a logic checking can be conducted regardless of progress in development of design for Master B and Master C. 
     According to the above embodiment, it is possible to achieve complex cases (combinations of request signals from each master model) easily and shorten time required to cause these cases to occur, which serves to facilitate, to enhance accuracy and to improve efficiency in logic checking of an arbiter. 
     Third Embodiment 
     Next described is logic checking for such circuits as a memory controller, an I/O interface or a bus bridge.  FIG. 6  gives an example of test statements using master models. In this checking method, as shown in  FIG. 5 , used is a master model which is connected in a location in the circuit as near as possible to an object to be checked in stead of using an actual CPU and circuit. This allows to eliminate such pre-processing and post-processing steps of circuits connected to the object to be checked as steps 1.2, 1.4 and 1.6 which are required in the prior art example of  FIG. 23 . 
     Now, reference is made to  FIGS. 6 to 10  to describe logic checking method and example of statements for the present embodiment. In this method, as shown in  FIG. 5 , used is a master model which is connected in a location in the circuit as near as possible to an object to be checked in stead of using an actual CPU and circuit. This allows to eliminate such pre-processing and post-processing steps of circuits connected to an object to be checked as steps 1.2, 1.4 and 1.6 which are required in the prior art example of  FIG. 23 . This allows achieving a more rapid simulation. There is no need to restrict address area in software which is actually to be run on a CPU or restrict address in setting for DMA, so that address can be selected arbitrarily. 
     Next described is a mode of data transfer such as one given in  FIG. 7  as an example of data communication between bus masters and bus slaves on a bus to which an object to be checked is connected. In this instance data transfer is performed in synchronization with clock signal clk. 
     In the transfer sequence, first a bus master asserts request signals as a request for transfer. Against these request signals any one of devices such as a bus slave or an arbiter asserts gnt signals to grant transfer permission to the bus master. Secondly, the bus master asserts during one cycle str signals which indicates start of transfer after it confirmed that gnt signals are asserted. Simultaneously with assertion of str signals, the bus master asserts such signals as burst signals which indicate number of transfer data, addr signals which indicate transfer address and data signals which indicate transfer data. Burst signals, addr signals and data signals are kept asserted until transfer is completed. 
     Thirdly, the bus slave asserts rdy signals when it is ready to receive data to be transferred to obtain data. Rdy signals are continuously asserted during clock cycles of which number is indicated by the burst signals to receive data continuously. If, for any reason, the bus slave fails to receive transfer data against transfer start signals str asserted by the bus master, it will assert err signals in place of rdy signals. In case it cannot receive transfer data at the moment but it will be able to receive them after a while, it may assert rtr signals as a request for retrial of transfer. 
     In this case if the timing for a period after assertion of req signals by a master I/F and assertion of gnt signals for transfer permission until assertion of str signals is not uniquely defined, the timing may vary depending on connected modules or mode. Even in such a case, as shown in  FIG. 8 , transfer can be executed simply with available timing defined in the protocol by providing the master model a function for executing transfer by simply changing its timing. This enables to perform more thorough checking based on the protocol.  FIG. 9  illustrates an example of test statements of a case in which such a master model is provided. In such a test, described are examples of statements for a test sequence in which timing is randomly selected and a test sequence in which execution is performed with timing being delayed by one cycle for each run. 
     Next discussed is checking of such master I/F as a DMA controller or a bus bridge shown in  FIG. 10 . Similarly as the case using a bus master model described in  FIG. 5 , a slave model is used in place of an actual slave I/F to be connected. This eliminates time consuming pre-processing and post-processing of an actual slave I/F. Further, if a protocol provides setting of timing for changing signals arbitrarily for a certain extent, transfer can be simply conducted in an available timing defined in the transfer protocol by preparing a slave model as shown in  FIG. 12 , so that all possible cases are realized. This enables to perform more thorough checking based on such a protocol. 
     Next, discussed is an advantage available by using a combination of those master models and slave models. 
     When checking is performed on a slave circuit such as a memory controller, an I/O interface circuit or a bus bridge, in case a transfer protocol allows successive transfers to overlap each other, or in case a plurality of slave I/Fs operate to respond a plurality of transfer requests simultaneously and arbitration is conducted within the object to be checked itself, a plurality of master models are used to conduct the checking as shown in  FIG. 11 . This enables to confirm complex transactions such as overlapped and continuous transfers or overlapping transfers with one of which is an error transfer. 
     Similarly, as shown  FIG. 13 , it is possible to respond a plurality of transfer requests simultaneously by using a plurality of slaves. This allows easily confirming overlapped transfers, realizing various cases easily such as a combination of an error response and a normal response. 
     Combining those arrangements will enable to check more complex operations. As shown  FIG. 14 , it is possible to confirm behaviors in such cases as collision or competition of transfer, the concurrent execution of a plurality of processes, overlapping of error and normal transfer, resource control or unpredicted events by causing such cases develop intentionally. 
     Accordingly, as described above, the present method is advantageous for checking many of such functional blocks comprising system LSI as a bus bridge, memory controller, modules to be connected to general purpose buses and bus arbiters. 
     The present embodiment, in the first place, is able to cause a logic circuit to be checked to develop interesting operation, even without actual software by using bus functional models in place of actual CPUs, as well as to cause random data transfer with random values to develop which cannot be achieved by actual software. This makes it possible to check, by a simulation, such situations as a designer did not intend. 
     According to the present embodiment it is possible, by providing a plurality of master models and/or slave models, to cause data transfer of random varieties with random values to occur which cannot be achieved by actual software. This makes it possible to check, by a simulation, such situations as a designer did not intend. 
     Now, a method for checking logic according to the present embodiment will be described referring to  FIGS. 15 to 19 . In  FIG. 15  illustrating one of configuration of the present embodiment, reference numerals  2  to  8  and  11  to  13  denote the like components in  FIG. 24 . A bus function model  1  generates only bus operation signals of CPU which controls a whole circuit. IO-bus master model( 1 )  9 , IO-bus master model( 2 )  10 , device-bus master model( 1 )  14  and device-bus master model( 2 )  15  generate data transfer in place of actual circuits. IO-bus slave model( 1 )  16 , IO-bus slave model( 2 )  17 , device-bus slave model( 1 )  18  and device-bus slave model( 2 )  19  respond to data transmission requests from masters in place of actual circuits. 
     The bus function model  1  in  FIG. 15  can generate, by command, only changes of signals which appear on the bus out of actual CPU functions. In this case, instruction fetching conducted by the CPU is not necessary. As a result, generation of desired data transfer can be easily achieved without any redundant transfer. For example, writing data into an address in the memory  3  etc. can be executed by only issuing such a command as write(address, data); included in the bus function model  1 . 
     IO-bus master model( 1 )  9  or IO-bus master model( 2 )  10  in  FIG. 15  can generate various data transfer over the IO-bus  5  without complex setting. In those cases only issuing such a command as io_write(address, data) is required. The same applies to device-bus master model( 1 )  14  and device-bus master model( 2 )  15 . 
     IO-bus slave model( 1 )  16  and IO-bus slave model( 2 )  17  are slave models which respond to transfer requests from the bus function model  1  or the master models such as IO-bus master model( 1 )  9 . They can respond not only in preset cycles but also, can respond by waiting for only random cycles. Random data may be generated when data is transferred from those slave models. In many cases bugs of logic circuits tends to exists at the time of such other than normal transactions as bus errors or retry. It is possible to have those salves respond to a bus error or a retry and this will be effective to find bugs in a logic circuit. The same applies to device-bus slave model( 1 )  18  and device-bus slave model( 1 )  19 . 
     As described above it is possible to check such situations as a designer did not intend or a combination of transactions in complex cases by using master models and/or slave models which does not exist in actual circuit. 
       FIG. 16  describes an example of test statements for checking by activating various models above described. In this example, in a portion between “fork” and “join”, tasks stated in each line works concurrently. For example, cpu_master_kick and io1_master_kick will be started concurrently. 
     For example, in  FIG. 16 , cpu_master_kick makes such statements as to generate transfer to the memory  3  or IO-bus slave model( 1 )  16  etc. from the bus function model  1  in random sequences with random addresses. Similarly, in io1_master_kick stated is a transfer sequence from IO-bus master model( 1 )  9 , in io2_master_kick a transfer sequence from IO-bus master model( 2 )  10 , in io1_slave_kick a transfer sequence to IO-bus slave model( 1 )  16 , in io2_slave_kick a transfer sequence to IO-bus slave model( 2 )  17 , in dev1_master_kick a transfer sequence from device-bus master model( 1 )  14 , in dev2_master_kick a transfer sequence from device-bus master model( 2 )  15 , in dev1_slave_kick a transfer sequence to device-bus slave model( 1 )  18 , in dev2_slave_kick a transfer sequence to device-bus slave model( 2 )  19 , respectively. 
     As described above, by stating such transfer sequences in each task as data transfer sequences from each master model or transfer sequences from a CPU to slave models, transactions from each master to the memory or each of slaves will occur, so that the logic circuit under checking conducts processing according to its designed logic. 
     In an example of  FIG. 16 , a “for” portion exists outside of a “fork-join” portion, so that every time the “for” loop is executed, each transaction will start concurrently to run the next “for” loop at the end of each sequence. Namely, a task, of which transaction is completed earlier, will hold starting of the next transaction until all other tasks complete their transactions. 
     In an example of  FIG. 17 , a “for” portion is allocated to each task within a “fork-join” portion. In this case, each task will start their first transactions concurrently but each task will repeat its loop by preset number. Namely, transaction of each task will be executed consecutively on and on regardless of the states of transactions of other tasks. In this case, the bus bridge  2  is required to process transactions from every direction without any pause. This enables to burden the bus bridge with more stresses than those experienced in actual operation. 
     Also, as described in an example of  FIG. 18 , it is possible to avoid transactions falling into a particular pattern by first generating random values at the beginning of each task and then starting transactions after waiting for cycles corresponding to the value. Further, as described in an example of  FIG. 19 , it is easy to delay start of transactions by one cycle consecutively using a “for loop” instead of waiting for random cycles. Also, Sweeping start of a transaction of a certain task against start of transaction of other tasks is easily achieved. 
     As stated above, without rewriting most portions of a test program but only slightly modifying the way to call each task, various situations or complex situations can be executed by a simulation. 
     According to embodiments above described it is possible to easily start transactions without complex setting by using master models and/or slave models in place of actually connected logic circuits. Also, it is possible to control starting time of transfer, so that checking under severer conditions than actually take place is made possible by causing complex situations which is not intended by a designer to occur. 
     Further, bugs in logic circuits can be detected earlier by checking situations not intended by a designer. Also, checking under severer conditions than actually take place would enable to find hidden bugs. This makes it possible to develop high quality functional blocks without bugs to eliminate occurrence of failures at the time of reuse of each functional block. 
     Especially, usage of bus function models in place of an actual CPU allows performing a simulation without software for CPU, enabling logic checking. Also, usage of bus function models in place of a DMA controller other than CPU allows omitting cumbersome setting inherent to a DMA controller to enable to occur similar transactions, allowing easy checking of operation. Also, even before a logic circuit is completed which should exist outside of the object to be checked, logic checking can be conducted by executing a simulation. 
     Tendency of bus transactions issued by an actual DMA controllers to fall into a certain particular pattern would reduce probability to develop complex situations but usage of active models enables to develop random transfer with no particular pattern, enhancing probability of development of complex situations not intended by a designer, allowing more accurate, more thorough checking. 
     Further, it is difficult to control by one cycle base in an actual DMA controller but an active model allows cycle-by-cycle control of issuance of transfer, enabling such sweep testing as transfers from a plurality of active models are delayed by one cycle to overlap each other. As it is possible to cause transfer to occur in any given cycle, concurrent transfer would be easily issued from a plurality of active models to enable to check complex situations. Also, by using slave models, response from slaves may be issued arbitrary or randomly, further enabling to check more complex situations. 
     While the present invention has been described with reference to what are presently considered to be the preferred embodiments, it is to be understood that the invention is not limited to the disclosed embodiments. On the contrary, the invention is intended to cover various modifications and equivalent arrangements included within the spirit and scope of the appended claims. The scope of the following claims is to be accorded the broadest interpretation so as to encompass all such modifications and equivalent structures and functions.