Simulator engine development system and simulator engine development method

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.

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.

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.

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.

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.