Abstract:
A simulator development system is disclosed, including a data file management part to create a data file storing data concerning a plurality of types of integrated circuits, for each update and to manage the data file with a file name including a date and time when the data file is updated; and a simulator generation part to specify a latest data file from a plurality of the data files retrieved based on a type name, by referring to the date and time included in the file name in response to a selection of the type name of the integrated circuit, and to generate the simulator corresponding to the type of the integrated circuit, which type is specified by a type name.

Description:
CROSS-REFERENCE TO RELATED APPLICATION 
     The present application is based on Japanese Priority Application No. 2007-042494 filed Feb. 22, 2007, the entire contents of which are hereby incorporated by reference. 
     BACKGROUND OF THE INVENTION 
     1. Field of the Invention 
     The present invention generally relates to a simulator development system and a simulator development method which automatically generates a simulator for each of various types of semiconductor circuits. 
     2. Description of the Related Art 
     In developing micro processors (MPUs: Micro Processing Units), various types of the micro processors were developed by modifying Input/Output (I/O) parts and combining the I/O parts while maintaining the same control part for controlling the entire process. Each of the micro processors was verified by using an I/O simulator. 
     On the other hand, it is required to develop the I/O simulator based on a hardware specification of the developed micro processor. The I/O simulator is developed by a software tool developer who has technical knowledge so that I/O parts of the developed type of the micro processor are developed by using an object oriented language. 
     Japanese Laid-open Patent Application No. 2002-354039 discloses to automatically generate a test bench by making models as objects of the object oriented language based on text data created from a specification in order to reduce workload of a simulator developer. 
     Conventionally, as shown in  FIG. 1 , when developing an Large Scale Integration (LSI)  2   b , an LSI hardware developer  2  generally creates an LSI specification  2   a  for a user  4  who uses the developed LSI  2   b . The LSI specification  2   a  may be a manual document. 
     A software tool developer  3  provides the user  4  an I/O simulator engine  4   a  for simulating the LSI  2   b  to allow the user  4  develop a user program  4   b  using the LSI  2   b , before the LSI  2   b  is completely developed. In order to provide the I/O simulator engine  4   a , the software tool developer  3  creates I/O related data  3   a  which defines parameter data such as initial values of I/O registers, and develops a program of an I/O behavior simulator  3   b  for simulating a behavior of the developed LSI  2   b , based on the LSI specification  2   a . Then, the software tool developer  3  creates the I/O simulator engine  4   a  by using the I/O related data  3   a  and the I/O behavior simulator  3   b , and provides the I/O simulator engine  4   a  to the user  4 . 
     Instead of waiting until the LSI  2   b  is completed, the user  4  can develop and verify a user program  4   b  being original by using the I/O simulator engine  4   a  provided from the software tool developer  3 . 
     However, even if there is no change for the control part for controlling the entire process of the micro processor, various types of LSIs  2   b  have been developed by modifying the I/O parts or/and combining some I/O parts. Accordingly, the software tool developer  3  is required to create the I/O related data  3   a , the I/O behavior simulator  3   b , and the I/O simulator engine  4   a , and a workload of the software tool developer  3  has increased. 
     In addition, since the LSI specification  2   a  is a document created by the LSI hardware developer  2 , there is a problem in that a development of the software tool developer  3  is delayed due to human errors such as missing descriptions and typographical errors in the LSI specification  2   a  and the I/O simulator engine  4   a  devoted to the LSI  2   b  being completed cannot be provided timely to the user  4 . Moreover, if the software tool developer  3  begins to develop the I/O behavior simulator  3   b  and a completion time of the I/O behavior simulator  3   a  is delayed, the user  4  begins to verify the user program  4   b  by using the completed LSI  2   b  without using the I/O simulator engine  4   a  which is based on the I/O behavior simulator  3   b . Thus, there is a problem that the I/O simulator engine  4   a  is not effectively used by the user program  4   b.    
     SUMMARY OF THE INVENTION 
     According to one of the aspect of an embodiment, a simulator development system for developing a simulator of an integrated circuit, including: a data file management part configured to create a data file storing data concerning a plurality of types of integrated circuits, for each update and to manage the data file with a file name including a date and time when the data file is updated; and a simulator generation part configured to specify a latest data file from a plurality of the data files retrieved based on a type name, by referring to the date and time included in the file name in response to a selection of the type name of the integrated circuit, and to generate the simulator corresponding to the type of the integrated circuit, which type is specified by a type name. 
     According to one of the aspect of an embodiment, a simulation development method for a computer to execute the above-described process parts as functions, a program product for causing the computer to conduct the above-described process parts as the functions, and a computer-readable recording medium recorded with a computer program for causing the computer to conduct the above-described process parts as the functions. 
    
    
     
       BRIEF DESCRIPTION OF THE DRAWINGS 
       Other objects, features and advantages of the present invention will become more apparent from the following detailed description when read in conjunction with the accompanying drawings, in which: 
         FIG. 1  is a diagram for explaining a conventional simulator development method; 
         FIG. 2  is a block diagram showing a functional configuration of a simulation development system according to an embodiment of the present invention; 
         FIG. 3  is a block diagram showing a hardware configuration of a computer realizing the simulator development system according to the embodiment of the present invention; 
         FIG. 4  is a diagram showing an example of a type-macro combination table according to the embodiment of the present invention; 
         FIG. 5  is a diagram showing an example of I/O related data; 
         FIG. 6  is a diagram showing an example of the I/O behavior diagram data; 
         FIG. 7  is a flowchart for explaining a process conducted by a program source auto-generation part; 
         FIG. 8A  is a flowchart for explaining a process conducted by an evaluation program auto-generation part included in an execution program generation part, and  FIG. 8B  is a flowchart for explaining a process conducted by a determination process part; and 
         FIG. 9A  is a diagram showing an example of an edit menu screen for an LSI hardware developer, and  FIG. 9B  is a diagram showing an example of a simulator auto-development screen for a software tool developer. 
     
    
    
     DESCRIPTION OF THE PREFERRED EMBODIMENT 
     An embodiment according to the present invention will be described with reference to the accompanying drawings. 
       FIG. 2  is a block diagram showing a functional configuration of a simulation development system according to an embodiment of the present invention. In  FIG. 2 , a simulator development system  100  includes a data file management part  10 , a type correspondence process part  20 , and an execution program generation part  30 . 
     The simulator development system  100  may be realized by a single computer or two or three computers. For example, in a case of realizing by two computers, the data file management part  10  and the type correspondence process part  20  may be realized by one computer and the execution program generation part  30  may be realized by another computer. Alternatively, the data file management part  10  may be realized by one computer and the type correspondence process part  20  may be realized by another computer. Moreover, the data file management part  10 , the type correspondence process part  20 , and the execution program generation part  30  may be individually realized by three computers. 
     The data file management part  10  is a process part which stores and manages various data created by an LSI hardware developer  2  in a predetermined storage area, and includes a type-macro combination table  10   a , I/O related data  10   b , and I/O behavior diagram data  10   c.    
     The type-macro combination table  10   a  is a table for defining combinations of internal macros which describes interfaces of I/O parts for each type of an LSI  2   b . The I/O related data  10   b  are stored in a table for defining initial values of parameters such as I/O registers for each internal macro. The I/O behavior diagram data  10   c  are data for defining a state transition for each macro with an abstract and conceptual diagram. The abstract and conceptual diagram is a diagram rendering relationships between states which change in response to a behavior of each macro. For example, the abstract and conceptual diagram may be an UML (Unified Modeling Language), a class diagram, a sequence diagram, or a like rendered by using CASE (Computer Aided Software Engineering). 
     The type correspondence process part  20  is a process part that automatically generates data corresponding to a type of the LSI  2   b  which is selected by an LSI hardware developer  2  or a software tool developer  3  (hereinafter, the selected type is called type(x)), and includes a program source auto-generation part  21 . The program source auto-generation part  21  automatically generates a type(x)-LSI specification  20   a , a type(x)-I/O related data  20   b , and a type(x)-I/O behavior simulator  20   c.    
     The program source auto-generation part  21  reads out the type-macro combination table  10   a , the I/O related data  10   b , and the I/O behavior diagram data  10   c  stored in the data file management part  10 , and automatically generates the type(x)-LSI specification  20   a , the type(x)-I/O related data  20   b , and the type(x)-I/O behavior simulator  20   c  which correspond to a selected type(x). 
     For example, the program source auto-generation part  21  outputs the type(x)-LSI specification  20   a , which explains functions and operations of the type (x) of the LSI  2   b , into a file of a document format, outputs the type(x)-I/O related data  20   b  to a program source of a definition file, and outputs the type(x)-I/O behavior simulator  20   c  to a program source for simulating a behavior of each of I/O parts of the type(x). 
     For example, in order to generate a program source from the abstract and conceptual diagram, the program source auto-generation part  21  generates a program source of the type(x)-I/O behavior simulator  20   c  from the I/O behavior diagram data  10   c  by using the CASE tool. 
     The execution program generation part  30  includes an evaluation program auto-generation part  31 , an I/O simulator engine  30   a  of a prototype program, an I/O simulator engine  30   b  to be a finished program which is provided to a user  4 , a test program  30   u , and a determination process part  32 . 
     The evaluation program auto-generation part  31  reads the type(x)-I/O related data  20   b  and the type(x)-I/O behavior simulator  20   c  which are generated by the type correspondence process part  20 , and automatically generates the I/O simulator engine  30   a  of prototype programs in accordance with a predetermined algorithm. Also, the evaluation program auto-generation part  31  evaluates the I/O simulator engine  30   a  of the prototype program which is automatically generated, by using the test program  30   u  which is prepared by the software tool developer  3  beforehand and evaluates whether or not the I/O simulator engine  30   a  is suitable for a product developed by the user  4 . Then, the evaluation program auto-generation part  31  outputs an evaluation result. 
     The determination process part  32  retrieves a latest evaluation result output from the evaluation program auto-generation part  31 . Based on the retrieved latest evaluation result, the determination process part  32  informs contents of feedback used by the LSI hardware developer  2  to the software tool developer  3 , or sets the I/O simulator engine  30   a  of the prototype program as the I/O simulator engine  30   b  of the finished program. 
     As described above, the software tool developer  3  simply confirms the latest evaluation result alone if necessary. Accordingly, it is possible to reduce workload of developing the I/O simulator engine  30   b  which is provided to the user  4 , and to provide the user  4  the I/O simulator engine  30   b  at an earlier stage. In addition, it is possible to provide the LSI hardware developer  2  the I/O simulator engine  30   b  which is provided to the user  4 . 
     Moreover, since the I/O simulator engine  30   a  of the prototype program is automatically evaluated, it is possible to effectively feedback the evaluation result to the LSI hardware developer  2 . 
     At a side of a user system  40  which receives the I/O simulator engine  30   b  from the simulator development system  100 , the user  4 , who develops a program for a product mounting the LSI  2   b , conducts an operation check of a user program  40   u  developed by using the I/O simulator engine  30   b . After completing the operation check, a product in which the LSI  2   b  and the user program  40   u  are embedded is produced. 
     Each of one to three computers realizing the simulator development system  100  includes a hardware configuration as shown in  FIG. 3 .  FIG. 3  is a block diagram showing a hardware configuration of a computer realizing the simulator development system according to the embodiment of the present invention. 
     In  FIG. 3 , a computer  100   a  realizing the simulator development system  100  includes a CPU (Central Processing Unit)  11 , a memory unit  12 , a display unit  13 , an input unit  15 , a storage unit  17 , and a driver  18 , which are mutually connected to each other by a system bus B. 
     The CPU  11  controls the computer  100   a  in accordance with a program stored in the memory unit  12 . The memory unit  12  includes a RAM (Random Access Memory), a ROM (Read-Only Memory), and a like to store a program executed by the CPU  11 , data necessary for a process conducted by the CPU  11 , and data acquired in the process of the CPU  11 . Also, a part of a storage area of the memory unit  12  is assigned as a work area used in the process of the CPU  11 . 
     The display unit  13  displays various necessary information under a control of the CPU  11 . The input unit  15  includes a mouse, a keyboard, and a like, and is used by a user to input various information required for the computer  100   a  to process. 
     For example, the storage unit  17  includes a hard disk unit and stores data such as a program to conduct various processes. 
     For example, the program realizing the process which is conducted by the computer  100   a  is provided to the computer  100   a  by a recording medium  19  such as a CD-ROM (Compact Disk Read-Only Memory) That is, when the recording medium  19  storing the program is set in the driver  18 , the driver  18  reads out the program from the recording medium  19 , and the program being read out is installed into the storage unit  17  via the system bus B. Then, the CPU  11  executes the program installed in the storage unit  17  and conducts the process in accordance with the program. 
     It should be noted that the recording medium is not limited to the CD-ROM to store the program and any recording medium which is computer-readable can be used. In a case in that the computer  100   a  includes a communication unit that conducts communication through a network, the program realizing the process according to the present invention may be downloaded through the network by using the communication unit and be installed into the storage unit  17 . In a case in that the computer  100   a  includes an interface such as a USB (Universal Serial Bus) or a like to connect with an external storage device, the program may be read from the external storage device with a USB connection. 
     Next, the type-macro combination table  10   a , the I/O related data  10   b , and the I/O behavior diagram data  10   c  which are created by the LSI hardware developer  2  will be described with reference to  FIG. 4 ,  FIG. 5 , and  FIG. 6 . 
       FIG. 4  is a diagram showing an example of the type-macro combination table according to the embodiment of the present invention. The type-macro combination table  10   a  shown in  FIG. 4  stores a macro list file  11   a  recording a combination of the internal macros which is to be embedded in the LSI  2   b , for each type name specifying a type of LSI  2   b . A new macro list file  11   a  is generated for each update of adding and deleting the type names and changing the combination of the internal macros, and is accumulated in the type-macro combination table  10   a.    
     A combination of a date and time when the macro list file  11   a  is generated, and a name specifying the macro list file  11   a  is set as a file name of the macro list file  11   a . For example, “200602171115-macrolist.txt” is set as the file name. 
     The macro list file  11   a  includes items of a type name, an internal macro type, and a like. For example, referring to the macro file  11   a  of a file name “200602171115-macrolist.txt”, internal macros “A”, “B”, and “ID” are combined for the LSI  2   b  of a type “90595”, internal macros “A”, “C”, and “D” are combined for the LSI  2   b  of a type “90545”, and internal macros “C”, “D”, “E”, and “G” are combined for the LSI  2   b  of a type “90345”. 
       FIG. 5  is a diagram showing an example of the I/O related data. The I/O related data  10   b  shown in  FIG. 5  stores a parameter list file  11   b  recording register names specifying registers and initial values to set to the registers for each internal macro. The parameter list file  11   b  is generated for each update of adding and deleting the internal macro, adding and deleting the register, and changing the initial value, and is accumulated in the I/O related data  10   b.    
     A combination of a date and time when the parameter list file  11   b  is generated, and a name specifying the parameter list file  11   b  as a file name of the parameter list file  11   b . For example, “200602171121-paramlist.txt” is set as the file name. 
     The parameter list file  11   b  is a file which describes a template defining the initial values corresponding to the register names for each internal macro. For example, in the parameter list file  11   b  of a file name “200602171121-paramlist.txt”, regarding the registers and the initial values for the internal macro “A”, an initial value “5” is defined for a register “Reg1”, an initial value “23” is defined for a register “Reg2”, an initial value “128” is defined for a register “Reg3”, and an initial value “3” is defined for a register “Reg4”. 
       FIG. 6  is a diagram showing an example of the I/O behavior diagram data. The I/O behavior diagram data  10   c  shown in  FIG. 6  stores the state transition model file  11   c  that records diagram data of a state transition model representing a behavior of one internal macro. A new state transition model file  11   c  is generated for each update of changing the state transition and is accumulated in the I/O behavior diagram data  10   c.    
     A combination of a date and time when the state transition model file  11   c , a macro name specifying the internal macro, and a name specifying the state transition model file  11   c  is set as a file name of the state transition model file  11   c . For example, “200602171121-A-behavior.stm” is set as the file name. 
     The state transition model file  11   c  is a file in which a template of one internal macro is drawn by using a tool for creating the state transition model. For example, referring to the state transition model file  11   c  of a file name “200602171121-A-behavior.stm”, a state S 1 , a state S 2 , and a state S 3  is defined for the internal macro “A”. 
     A process conducted by the program source auto-generation part  21  using the type-macro combination table  10   a , the I/O related data  10   b , and the I/O behavior diagram data  10   c  will be described with reference to  FIG. 7 .  FIG. 7  is a flowchart for explaining the process conducted by the program source auto-generation part. 
     Referring to  FIG. 7 , the program source auto-generation part  21  acquires a type name of the LSI  2   b  selected by a user from a simulator auto-development screen  72  as shown in  FIG. 9B  (step S 201 ). 
     The program source auto-generation part  21  selects and opens a latest macro list file  11   a  from one or more macro list files  11   a  accumulated in the type-macro combination table  10   a , based on the date and time included in the file name (step S 202 ). The program source auto-generation part  21  specifies the internal macro corresponding to the type name acquired in the step S 201  from the latest macro list file  11   a . For example, if the type name is “90595”, the internal macros “A”, “B”, and “D” are specified. 
     Subsequently, the program source auto-generation part  21  selects and opens a latest parameter list file  11   b  from one or more parameter list files  11   b  accumulated in the I/O related data  10   b , based on the date and time included in the file name (step S 204 ). 
     The program source auto-generation part  21  extracts a definition list of each internal macro specified in the step S 203  from contents of the latest parameter list file  11   b , and generates the type(x)-I/O related data  20   b  that has a file name in a file name format including a current date and time and the type name (for example, format of a text sequence of a date and time, a type name, and a suffix “.h”). The type(x)-I/O related data  20   b  generated in the step S 205  is accumulated in a storage area. 
     Also, the program source auto-generation part  21  selects and opens the latest state transition model file  11   c  for each internal macro from one or more state transition model files  11   c  accumulated in the I/O behavior diagram data  10   c  and specified in the step S 203 , based on the date and time of the file name (step S 206 ). 
     The program source auto-generation part  21  creates the type(x)-LSI specification  20   a  by writing out the state transition diagram included in the latest state transition model file  11   c  for each internal macro to the latest state transition model file  11   c , and adds the current date and time to the file name (step S 207 ). The type(x)-LSI specification  20   a  created in the step S 207  is accumulated in the storage area. 
     Moreover, the program source auto-generation part  21  generates the type(x)-I/O behavior simulator  20   c  by converting the state transition diagram into a C source program (step S 208 ). The type(x)-I/O behavior simulator  20   c  generated in the step S 208  is accumulated in the storage area. 
     A process conducted by the execution program generation part  30  using the type(x)-I/O related data  20   b  and the type(x)-I/O behavior simulator  20   c , which are generated by the program source auto-generation part  21 , will be described with reference to  FIG. 8A  and  FIG. 8B . 
       FIG. 8A  is a flowchart for explaining the process conducted by the evaluation program auto-generation part included in the execution program generation part. In  FIG. 8A , the evaluation program auto-generation part  31  determines whether or not the type(x)-I/O related data  20   b  and the type (x)-I/O behavior simulator  20   c  which are the latest from the date and time of a previous process (step S 301 ). When the type(x)-I/O related data  20   b  and the type(x)-I/O behavior simulator  20   c  are not found, the process of the evaluation program auto-generation part  31  is terminated. 
     When the latest type (x)-I/O related data  20   b  and the latest type(x)-I/O behavior simulator  20   c  are found in the step S 301 , the evaluation program auto-generation part  31  conducts a batch process for creating a new makefile with a file name including a current date and time, in order to compile the latest type (x)-I/O related data  20   b  and the latest type (x)-I/O behavior simulator  20   c  which file names include a type(x) and a latest date and time (step S 302 ). 
     Then, the evaluation program auto-generation part  31  executes the new makefile created in the step S 302  (step S 303 ). After compiling and linking, the evaluation program auto-generation part  31  creates the I/O simulator engine  30   a  of a new prototype program as an execution file for the type(x) with the file name including the current date and time (step S 304 ). 
     The evaluation program auto-generation part  31  executes the I/O simulator engine  30   a  of a newest prototype program. The evaluation program auto-generation part  31  inputs a test program  30   u  including a sequence of test data and expected values, compares execution results of the I/O simulator engine  30   a  of the newest prototype program based on the test data with the expected values of the test program  30   u , and evaluates the I/O simulator engine  30   a  of the newest prototype program based on a comparison result (step S 305 ). 
     When the execution results are identical to the expected values, an evaluation result includes normal end information indicating that a test conducted by the test program  30   u  normally ends. On the other hand, when the execution results are not identical to the expected values, the evaluation result includes abnormal end information indicating that the test conducted by the test program  30   u  does not normally end and feedback is necessary to the LSI hardware developer  2 . The abnormal end information may include test items in which the execution results are not identical to the expected values, the execution results themselves, and the expected values themselves. 
     The evaluation program auto-generation part  31  outputs the evaluation result obtained in the step S 305  to a new evaluation result file with a file name including a current date and time (step S 306 ). The new valuation result file is accumulated in the storage area. 
     The determination process part  32  conducts a process shown in  FIG. 8B  in response to a process end of the evaluation program auto-generation part  31 .  FIG. 8B  is a flowchart for explaining the process conducted by the determination process part. In  FIG. 8B , the determination process part  32  acquires the evaluation result by searching for the latest evaluation result file (step S 321 ), and determines whether or not the evaluation result acquired in the step S 321  indicates a normal end (step S 323 ). 
     When the evaluation result indicates the normal end, the determination process part  32  informs the software developer  3  by displaying that the evaluation normally ends, at the display unit  13 , and stores the I/O simulator engine  30   a  as the I/O simulator engine  30   b  of the finished program which can be provided to the user  4  (step S 324 ). Then, the determination process part  32  terminates the process. 
     On the other hand, when the evaluation result indicates the abnormal end, the determination process part  32  informs the software developer  3  by displaying that the feedback is necessary to the LSI hardware developer  2  (step S 324 - 2 ), and terminates the process. 
     Screens displayed by the simulator development system  100  will be described with reference to  FIG. 9A  and  FIG. 9B .  FIG. 9A  is a diagram showing an example of an edit menu screen for the LSI hardware developer. In  FIG. 9A , an edit menu screen  71  is a menu screen for the LSI hardware developer  2  to edit data maintained by the data file management part  10 . 
     The edit menu screen  71  includes a button  71   a  for editing the latest macro list file  11   a  from the type-macro combination table  10   a , a button  71   b  for editing the latest parameter list file  11   b  from the I/O related data  10   b , and a button  71   c  for editing the latest state transition model file  11   c  of the type(x) from the I/O behavior diagram data  10   c.    
     When the LSI hardware developer  2  selects the button  71   a , the data file management part  10  selects the latest macro list file  11   a  from the type-macro combination table  10   a , and displays contents of the latest macro list file  11   a  in a macro list screen  81   a  which allows the LSI hardware developer  2  to edit the contents. The latest macro list file  11   a  edited by the LSI hardware developer  2  is stored as a new macro list file  11   a  and accumulates in the type-macro combination table  10   a.    
     When the LSI hardware developer  2  selects the button  71   b , the data file management part  10  selects the latest parameter list file  11   b  from the I/O related data  10   b , and displays contents of the latest parameter list file  11   b  in a parameter list screen  81   b  which allows the LSI hardware developer  2  to edit the contents. The latest parameter list file  11   b  edited by the LSI hardware developer  2  is stored as a new parameter list file  11   b  and accumulated in the I/O related data  10   b.    
     When the LSI hardware developer  2  selects the button  71   c , the data file management part  10  urges the LSI hardware developer  2  to input a desired type (x). Based on the type name of the desired type (x) input in a predetermined input area, the data file management part  10  selects the latest state transition model file  11   c  of the type (x) from the I/O behavior diagram data  10   c , and displays contents of the latest state transition model file  11   c  in a state transition screen  81   c  which allows the LSI hardware developer  2  to edit the contents. The latest state transition model file  11   c  of the type(x) edited by the LSI hardware developer  2  is stored as a new state transition model file  11   c  of the type (x) and is accumulated in the I/O behavior diagram data  10   c.    
       FIG. 9B  is a diagram showing an example of a simulator auto-development screen for the software tool developer. In  FIG. 9B , a simulator auto-developer screen  72  is a screen to acquire a type name of the desired type(x) from the software tool developer  3  by the program auto-generation part  21 . 
     The simulator auto-development screen  72  includes a selection area  72   a  for selecting a type name of a simulator which is to be created, an execution button  72   b  for generating the simulator with the selected type name, a display area  72   c  showing a generation state of the simulator, and a display area  72   d  showing the evaluation result of the generated simulator. 
     The edit menu screen  71  shown in  FIG. 9A  and the simulator auto-development screen  72  shown in  FIG. 9B  may be formed together in one screen. 
     As described above, the LSI hardware developer  2  simply creates the type-macro combination table  10   a , the I/O related data  10   b , and the I/O behavior diagram data  10   c . The I/O simulator engine  30   a  can be automatically generated and evaluated in response to the type of the LSI  2   b  which is provided to the user  4 . Moreover, the type(x)-LSI specification  20   a , which corresponds to the type of the LSI  2   b  to be provided to the user  4 , can be automatically generated. 
     Accordingly, since the I/O simulator engine  30   a  is automatically generated and evaluated at the approximately same time of automatically generating the type(x)-LSI specification  20   a , a development until a completion of evaluating the I/O simulator engine  30   a  can be conducted in a shorter time. 
     Moreover, since it is automatically determined whether or not the feedback to the LSI hardware developer  2  is required based on the evaluation result, it is possible to reduce a workload of the evaluation conducted by the software tool developer  3 . In addition, since the feedback of the evaluation result can be immediately forwarded to the LSI hardware developer  2 , it is possible to promptly correcting missing descriptions and typographical errors in the type(x)-LSI specification  20   a . By forwarding the feedback to the LSI hardware developer  2 , the I/O simulator engine  30   a  can be generated faster at a higher evaluation level. 
     Furthermore, instead of creating a document, the LSI hardware developer  2  simply input data, so that the type (x)-I/O specification  20   a  can be easily created for each specified type within a shorter time. The LSI hardware developer  2  is not required to make a document for each of various types of the LSI  2   b . In addition, since it can be easily conducted to maintain additions or like of types of the LSI  2   b , it is possible for the LSI hardware developer  2  to dedicate hardware developments of various types of the LSI  2   b.    
     Moreover, even in a case of divert existing internal macros, it is simply required to change the I/O related data  10   b  alone. The latest state transition model file  11   c  being accumulated in the I/O behavior diagram data  10   c  can be automatically selected. 
     Furthermore, the date and time are additionally included in the file names of the macro list files  11   a , the parameter list files  11   b , and the state transition model files  11   c  which are respectively accumulated in the type-macro combination table  10   a , the I/O related data  10   b , and the I/O behavior diagram data  10   c . Therefore, it is possible to easily search for a latest file and maintain existing files being accumulated in a time sequence. Also, it is not required to install a special tool for a version management. 
     The present invention is not limited to the specifically disclosed embodiments, and variations and modifications may be made without departing from the scope of the invention.