JP2015170221A - Simulation device and interface module creation device and program - Google Patents

Abstract

PROBLEM TO BE SOLVED: To enable a simulation of an entire system to be easily executed at an early stage of designing by flexibly connecting modules different in specifications.SOLUTION: A simulation device 100 simulates communication between a first model serving as a hardware module or bus model compliant with a first specification which is one of a plurality of specifications of a hardware module or bus model and a second model serving as a hardware module or bus model compliant with a second specification which is one of the plurality of specifications and different from the first specification. A master unit execution unit 1011 analyzes communication data compliant with the first specification created by the first model, and extracts from communication data, a common data element serving as a data element commonly used in simulation of all specifications. A slave unit execution unit 1013 uses the extracted common data element to create communication data addressed to the second model compliant with the second specification.

Description

  The present invention uses an existing module designed in RTL, SystemC (transaction level, pin level) or the like in LSI development, and enables an interface (I) to easily verify the entire system at an early stage. / F) For modules and the like.

Conventionally, in LSI development, design by hardware description language such as Verilog-HDL or VHDL (hereinafter referred to as RTL design) and verification have been mainly performed.
However, with the recent increase in the scale of LSIs, verification of the entire system using a hardware module (hereinafter referred to as an RTL module) designed for RTL has become a problem. Technology that shortens verification time has been put into practical use by designing (hereinafter referred to as high-level design) and verification using high-level languages such as C language, C ++ language, and System C language, which have a higher level of abstraction than languages. ing.
Furthermore, there is a technology that enables verification by mixing a high-level designed hardware module (hereinafter referred to as a high-level module) and an existing RTL module, and the entire system can be verified at an early stage of design. Yes.

However, if the protocol of the LSI to be developed is different from the protocol of the existing RTL module, or the protocol has not been decided at the early design stage, communication at the transaction level is possible for high-level modules (hardware modules and bus models). If the level of abstraction is different from the communication at the pin level of the RTL module, the modules cannot be connected as they are.
Therefore, a technique for inserting a conversion adapter (sometimes referred to as a bridge, wrapper, etc.) between modules having different abstraction levels and protocols is generally used.
However, since the processing of the conversion adapter differs for each abstraction level and protocol, as many conversion adapters are required as the number of combinations of abstraction level and protocol between the connected modules and bus models.
The creation of a conversion adapter may take the same amount of time as the hardware module design. Therefore, if there is a change in the bus peripheral configuration or protocol, a creation period will be required. It becomes a bottleneck of the whole system verification.

  In order to solve the above problems, the conventional technology enables communication between the hardware module 1 having the same protocol specification as the bus model and the hardware module 2 having a protocol specification different from the bus model. A wrapper model including a data receiving unit, a data converting unit, and a data transmitting unit is automatically generated (for example, Patent Document 1).

JP 2010-231633 A

In the prior art, when automatically generating a wrapper model in which a hardware module 2 that implements a protocol different from the bus model can be connected to the bus model, the bus connection information is obtained from the mounting information of the hardware module 2 and the hardware module Transaction information (protocol) is extracted from the specifications of 2, and a wrapper model including data receiving means, data converting means, and data transmitting means is generated based on the information and bus model specifications.
However, there are various description methods for each creator, and it is not always possible to extract information uniformly.
In addition, the entire system verification at an early stage may be performed in an environment in which high-level modules and RTL modules are mixed. However, the conventional wrapper model automatic generation method uses both the hardware module 2 and the bus model at the pin level. It is disclosed only when it is designed, and does not disclose an automatic generation method when the degree of abstraction is different.

  The main object of the present invention is to solve such problems, flexibly connect modules with different specifications such as abstraction level and protocol, and easily execute simulation of the entire system at an early stage of design. To do.

The simulation apparatus according to the present invention is
A first model that is a hardware module or bus model according to a first specification that is one of a plurality of specifications of a hardware module or a bus model; and one of the plurality of specifications. A simulation device for simulating communication with a second model which is a hardware module or a bus model according to a second specification different from the first specification,
It is a data element that is used in common in simulation of communication for all the specifications of the plurality of specifications from the communication data by analyzing the communication data according to the first specification generated by the first model. A first communication data management unit for extracting common data elements;
A second communication data management unit that generates communication data addressed to the second model according to the second specification using the common data element extracted by the first communication data management unit. Features.

  According to the present invention, common data elements that are commonly used in simulations of all specifications are extracted from communication data according to the first specification, and the second specification is used using the extracted common data elements. In order to generate communication data, modules with different specifications can be flexibly connected, and the entire system can be easily simulated at an early stage of design.

FIG. 3 illustrates a configuration example of an I / F module according to the first embodiment. FIG. 3 is a diagram illustrating a bus peripheral configuration using the I / F module according to the first embodiment. FIG. 3 shows a configuration example of a simulation apparatus according to the first embodiment. FIG. 3 shows a configuration example of a master / slave generation device according to the first embodiment. FIG. 3 is a flowchart showing a master / slave generation flow according to the first embodiment. FIG. 4 is a diagram illustrating a description example of a parameter setting file according to the first embodiment. FIG. 4 is a diagram illustrating processing timing of the master unit according to the first embodiment. FIG. 3 is a diagram illustrating a hardware configuration example of a simulation apparatus and a master / slave generation apparatus according to the first embodiment.

Embodiment 1 FIG.
FIG. 1 shows the configuration of the I / F module according to the first embodiment.

The I / F module 1 is a program executed by a computer that simulates communication between a master hardware module and a slave hardware module or a bus model.
The I / F module 1 includes a master unit 2 for connection with a hardware module serving as a data communication master, a slave unit 3 for connection with a hardware module or bus model serving as a data communication slave, and a master unit. 2 and a common unit 4 that mediates between the slave unit 3.
Hereinafter, the protocol and abstraction level of the hardware module or bus model are expressed as specifications.
In the following, the specification (protocol, abstraction) of the hardware module serving as a master is referred to as a master specification.
Further, the specification (protocol, abstraction) of the hardware module or bus model that becomes a slave is expressed as a slave specification.
Each of the master specification and the slave specification is one of a plurality of specifications of the hardware module or the bus model.

In FIG. 1, the master unit 2 corresponds to the master specification, analyzes communication data in accordance with the master specification generated by the master hardware module, and uses the communication data for all specifications of a plurality of specifications. A common data element, which is a data element commonly used in communication simulation, is extracted.
Then, the master unit 2 passes the extracted common data element to the common unit 4.
More specifically, the master unit 2 extracts command-related information, a data portion (payload), and a byte enable that designates a valid portion of the first communication data from the communication data as a common data element. .

The common unit 4 includes a command buffer 5 that stores command-related information extracted from the first communication data, a data buffer 6 that stores a data portion (payload), and an effective portion of the first communication data. Byte enable buffer 7 for storing a byte enable for designating and a buffer control unit 8.
In FIG. 1, for convenience of explanation, the command buffer 5, the data buffer 6, and the byte enable buffer 7 are components of the I / F module 1, but in reality, these buffers include the I / F module 1. A plurality of storage areas in the computer to be executed.
The buffer control unit 8 classifies the plurality of common data elements extracted by the master unit 2 for each attribute, and stores the plurality of common data elements in the corresponding attribute buffers.
That is, the buffer control unit 8 stores the command related information extracted from the first communication data in the command buffer 5, stores the data portion (payload) in the data buffer 6, and byte enable to the byte enable buffer. 7 is stored.
The buffer control unit 8 reads the common data element from each buffer and passes the read common data element to the slave unit 3.

The slave unit 3 corresponds to the slave specification.
The slave unit 3 uses the plurality of common data elements read by the buffer control unit 8 to generate communication data in accordance with the slave specifications addressed to the hardware module or bus model serving as a slave.

The signal line 9 is information related to a read / write request transmitted from the master hardware module to the master unit 2, response information transmitted from the master unit 2 to the hardware module, communication data, and the like.
The signal line 10 is information related to a read / write request transmitted from the slave unit 3 to the hardware module serving as a slave, response information transmitted from the hardware module to the slave unit 3, communication data, and the like.
The signal line 11 is information common to various abstractions / protocols transmitted / received by the buffer control unit 8 of the master unit 2 and the common unit 4, and the signal line 12 is the buffer control unit 8 of the slave unit 3 and the common unit 4. The signal lines 13, 14, and 15 are command-related information, data, and byte enable, respectively.

In a simulation in which communication data is transmitted from a hardware module serving as a master to a hardware module serving as a slave or a bus model via the I / F module 1, the master unit 2 corresponds to the first communication data management process. 3 corresponds to the second communication data management process.
A hardware module serving as a master corresponds to the first model, and a hardware module or bus model serving as a slave corresponds to the second model.
The master specification corresponds to the first specification, and the slave specification corresponds to the second specification.
In a simulation in which communication data is transmitted from a hardware module or bus model serving as a slave to a hardware module serving as a master via the I / F module 1, the slave unit 3 corresponds to the first communication data management process. 2 corresponds to the second communication data management process.
The slave specification corresponds to the first specification, and the master specification corresponds to the second specification.
In any simulation, the buffer control unit 8 corresponds to the common data element management process.

FIG. 2 shows a bus peripheral configuration using the I / F module 1 according to the first embodiment.
The bus model 20 in which the protocol A is implemented, the module 1 (21) in which the protocol A is implemented, the module 2 (22) in which the transaction level is implemented, and the module 3 (23) in which the protocol A is implemented. The module 4 (24) implemented by the protocol B is connected.
At this time, the module 1 (21) and the module 3 (23) mounted with the same protocol as the bus model 20 can be directly connected, but an abstraction level or protocol different from the bus model 20 is mounted. Since the module 2 (22) and the module 4 (24) that are present cannot be directly connected, the I / F module 1 must be inserted.

  FIG. 3 shows a configuration example of the simulation apparatus 100 which is a computer that executes the I / F module 1 shown in FIG.

The I / F module execution unit 101 executes the I / F module 1.
The buffer area 102 is a storage area corresponding to the command buffer 5, the data buffer 6, and the byte enable buffer 7 shown in FIG.
The master / slave execution unit 103 executes a hardware module serving as a master, a hardware module serving as a slave, or a bus model.
The program storage unit 104 stores a program corresponding to each of the I / F module 1, the master hardware module, the slave hardware module, or the bus model.

In the I / F module execution unit 101, the master unit execution unit 1011 executes the master unit 2 of the I / F module 1.
That is, the master unit execution unit 1011 executes the master unit 2, extracts common data elements from communication data according to the master specifications, and extracts the extracted common data elements from the buffer control unit 8 (buffer control unit execution unit 1012). Process to pass to.
In addition, the master unit execution unit 1011 executes the master unit 2 and generates communication data according to the master specification using the common data element passed from the buffer control unit 8 (buffer control unit execution unit 1012). I do.
The master unit execution unit 1011 functions as a first communication data management unit in a simulation of communication from a master hardware module to a slave hardware module or bus model.
The master unit execution unit 1011 functions as a second communication data management unit in a simulation of communication from the slave hardware module or bus model to the master hardware module.

The buffer control unit execution unit 1012 executes the buffer control unit 8 of the I / F module 1.
That is, the buffer control unit execution unit 1012 executes the buffer control unit 8 and sets the common data elements passed from the master unit 2 (master unit execution unit 1011) to the corresponding buffers (command buffer, data buffer). The data is stored in a buffer and a byte enable buffer, and the common data element in each buffer is transferred to the slave unit 3 (slave unit execution unit 1013).
In addition, the buffer control unit execution unit 1012 executes the buffer control unit 8 and sets the common data elements passed from the slave unit 3 (slave unit execution unit 1013) to the corresponding buffers (command buffer, data buffer). The data is stored in a buffer and a byte enable buffer, and the common data element in each buffer is transferred to the master unit 2 (master unit execution unit 1011).
The buffer control unit execution unit 1012 corresponds to an example of a common data element management unit.

The slave unit execution unit 1013 executes the slave unit 3 of the I / F module 1.
That is, the slave unit execution unit 1013 executes the slave unit 3 and generates communication data according to the slave specification using the common data element passed from the buffer control unit 8 (buffer control unit execution unit 1012). I do.
Also, the slave unit execution unit 1013 executes the slave unit 3 to extract common data elements from communication data according to the slave specifications, and the extracted common data elements are buffered to the buffer control unit 8 (buffer control unit execution unit 1012). Process to pass to.
The slave unit execution unit 1013 functions as a second communication data management unit in a simulation of communication from the master hardware module to the slave hardware module or bus model.
The slave unit execution unit 1013 functions as a first communication data management unit in a simulation of communication from the slave hardware module or bus model to the master hardware module.

FIG. 4 shows a configuration example of a master / slave generation device 30 that generates the master unit 2 and the slave unit 3 of the I / F module 1 shown in FIG.
The master / slave generation device 30 corresponds to an example of an I / F module generation device.

  In the master / slave generation device 30, the parameter analysis unit 31 abstracts the hardware module to which the master unit 2 is connected and the hardware module or bus model to which the slave unit 3 is connected from the parameter setting file input from the outside. Analyzes information about degrees and protocols.

  The I / O analysis unit 32 receives the I / O description file of the connection module input from the outside, the hardware module to which the master unit 2 is connected, and the I / O of the hardware module or bus model to which the slave unit 3 is connected. Analyze information.

  The generation unit 33 generates a master part description (program code corresponding to the master part 2) and a slave part description (program code corresponding to the slave part 3) according to information from the parameter analysis part 31 and the I / O analysis part 32. .

  The library 36 stores in advance template descriptions of the master unit 2 and the slave unit 3 at various levels of abstraction, and a master unit description and a slave unit description in a commonly used protocol.

  The library reading unit 35 reads the template description of the master unit 2 and the slave unit 3 from the library 36 or the master unit description and the slave unit description in a commonly used protocol from the library 36 based on the information on the abstraction level and protocol of the parameter setting file. To the generation unit 33 or the output unit 34.

  The output unit 34 outputs the master part description and the slave part description passed from the generation unit 33 or the library reading unit 35 to the outside.

The signal line 37 is a template description, a master part description, and a slave part description written in the library 36 in advance.
The signal line 38 is various parameter information input from the parameter setting file.
The signal line 39 is I / O information input from the I / O description file.
The signal line 40 is a parameter analysis command from the generation unit 33 to the parameter analysis unit 31.
The signal line 41 is a parameter analysis result output from the parameter analysis unit 31.
The signal line 42 is an I / O analysis command from the generation unit 33 to the I / O analysis unit 32.
The signal line 43 is an I / O analysis result output from the I / O analysis unit 32.
The signal line 44 is a library read command from the generation unit 33 to the library read unit 35.
The signal line 45 is a template description, a master part description, and a slave part description that are read from the library 36 to the library reading unit 35.
The signal line 46 is a template description, a master part description, and a slave part description that are passed from the library reading unit 35 to the generation unit 33 or the output unit 34.
The signal line 47 is a master part description and a slave part description generated by the generation unit 33.
The signal line 48 is a master part description output from the output part 34 to the outside.
The signal line 49 is a slave part description output from the output part 34 to the outside.

In FIG. 4, the master part description and the slave part description generated by the generation unit 33 correspond to the first program code and the second program code.
The parameter analysis unit 31, the I / O analysis unit 32, and the generation unit 33 correspond to examples of a first program code generation unit and a second program code generation unit.

  FIG. 5 is a flowchart of master / slave generation executed by the master / slave generation apparatus 30 according to the first embodiment. This flow is executed for each of the master unit 2 and the slave unit 3.

  In P01, the generation unit 33 outputs an abstraction parameter analysis command to the parameter analysis unit 31, and the parameter analysis unit 31 extracts and analyzes the abstraction level parameter from the parameter setting file.

  In P02, whether the abstraction level analyzed in P01 is an identifier indicating a transaction level (TLM) (for example, an LT of Loosely Timed or an AT of Appropriately Timed) or an identifier indicating a pin level (for example, PIN). Branch.

  In P11, if the identifier indicates TLM in P02, the generation unit 33 outputs a library read command for the TLM template to the library read unit 35, and the library read unit 35 reads the corresponding template description from the library 36 and generates it. To part 33.

  In P12, following P11, the generation unit 33 outputs a parameter analysis command for TLM to the parameter analysis unit 31, and the parameter analysis unit 31 extracts and analyzes various parameters for TLM from the parameter setting file.

  In P13, the generation unit 33 rewrites the template description acquired in P11 based on the parameter analysis result obtained in P12, and passes it to the output unit 34.

  In P03, if the identifier indicates the pin level in P02, the generation unit 33 outputs an IF classification parameter analysis command to the parameter analysis unit 31, and the parameter analysis unit 31 extracts and analyzes the IF classification parameter from the parameter setting file.

  In P04, a branch is made depending on whether the IF classification analyzed in P03 is a general protocol such as AXI or AHB and is a protocol already prepared in the library or another protocol (OTHER).

  In P21, if the identifier (OTHER) indicates other protocols in P04, the generation unit 33 outputs a library read command for a PIN template to the library read unit 35, and the library read unit 35 receives the corresponding template from the library 36. The description is read and passed to the generation unit 33.

  In P22, following P21, the generation unit 33 outputs an I / O analysis instruction to the I / O analysis unit 32, and the I / O analysis unit 32 extracts and analyzes the I / O information from the I / O description file.

  In P23, following P22, the generation unit 33 outputs a parameter analysis command for pin level to the parameter analysis unit 31, and the parameter analysis unit 31 extracts and analyzes various parameters for pin level from the parameter setting file.

  In P24, the generation unit 33 rewrites the template description acquired in P21 based on the I / O analysis results and parameter analysis results obtained in P22 and P21, and passes them to the output unit 34.

  In P31, if the identifier indicates a protocol that is a general protocol in P04 and already prepared in the library, the generation unit 33 outputs a library read instruction of the master part description or slave part description corresponding to the library read unit 35. Then, the library reading unit 35 reads the corresponding master part description or slave part description from the library 36 and passes it to the output unit 34.

  In P05, the output unit 34 outputs the master part description or the slave part description obtained in P13, P24, or P31 to the outside.

  6A, 6B, and 6C are description examples in the parameter setting file analyzed by the parameter analysis unit 31 according to the first embodiment.

FIG. 6A shows that the abstraction level of the hardware module connected to the master unit 2 is LT. Hereinafter, ARGUMENT, TL_CMD, TL_ADDR, TL_LEN and the like are parameters when the abstraction level is TLM. Yes, it indicates which variable the command related information, data, etc. stored in the common unit 4 corresponds to.
On the other hand, the level of abstraction of the hardware module or bus model connected to the slave unit 3 is pin level.

  FIG. 6B shows that the abstraction level of the hardware module connected to the master unit 2 is the pin level, the IF classification is AXI, and the master unit description is already prepared in the library 36.

FIG. 6C shows that the abstraction level of the hardware module connected to the master unit 2 is the pin level, and the IF classification is OTHER.
Hereinafter, WCMD, RCMD, RESP, WDATA, and the like are parameters when the abstraction level is a pin level, and indicate which signal the command related information, data, and the like stored in the common unit 4 correspond to.

  FIG. 7 is a timing chart showing processing of the master unit in the case of the parameter setting shown in FIG.

“WCMD = {Maddr} @ (MCmd = 1)” means that when MCmd is 1, Maddr is acquired as a write request.
“WDATA = {Mdata} @ (MCmd = 1)” means that Mdata is acquired as write data when Mcmd is 1.
For this reason, at the timing of 50 Mcmd = 1 in FIG. 7, the master unit 2 acquires MAddr and Mdata from the hardware module and transmits them to the common unit 4.
When the common unit 4 normally accepts the write request, the common unit 4 transmits an ACCEPT signal indicating acceptance to the master unit 2.
“RESP = {SCmdAccept = 1} @ACCEPT” means that 1 is asserted to SCmdAccept as a response when the ACCEPT signal is asserted. Therefore, the master unit 2 sets SCmdAccept to 51 in FIG.

As described above, if the I / F module 1 according to the present embodiment is used, the common unit 4 that processes information in common with various abstraction levels and various protocols of the hardware module or bus model is provided. Conversion for different degrees is also possible.
That is, the I / F module 1 includes the master unit 2, the slave unit 3, and the common unit 4, and information that is commonly required for various abstractions and protocols is stored in the buffer. Since the abstraction level can be specified in the setting file, conversion between different abstraction levels, which has not been disclosed in the prior art, can be handled.
In addition, by making it possible to specify information related to the abstraction level and protocol from the parameter setting file, the master unit 2 and slave unit 3 of the I / F module 1 are automatically and uniformly generated regardless of the creator. As a result, the entire system can be easily verified at an early stage of design.
In other words, since it is possible to acquire information uniformly and independently regardless of the creator, it solves the problem of the prior art that was difficult to extract information uniformly from the specification with different description methods depending on the creator. it can.

Finally, a hardware configuration example of the simulation apparatus 100 and the master / slave generation apparatus 30 shown in the present embodiment will be described with reference to FIG.
The simulation apparatus 100 and the master / slave generation apparatus 30 are computers, and each element of the simulation apparatus 100 and the master / slave generation apparatus 30 can be realized by a program.
As hardware configurations of the simulation apparatus 100 and the master / slave generation apparatus 30, an arithmetic device 901, an external storage device 902, a main storage device 903, a communication device 904, and an input / output device 905 are connected to the bus.

The arithmetic device 901 is a CPU (Central Processing Unit) that executes a program.
The external storage device 902 is, for example, a ROM (Read Only Memory), a flash memory, or a hard disk device.
The main storage device 903 is a RAM (Random Access Memory).
The communication device 904 is, for example, a NIC (Network Interface Card).
The input / output device 905 is, for example, a mouse, a keyboard, a display device, or the like.
The buffer area 102 in FIG. 3 is realized by the main storage device 903, for example.
Further, the program storage unit 104 in FIG. 3 and the library 36 in FIG. 4 are realized by, for example, the external storage device 902.

The program is normally stored in the external storage device 902, and is loaded into the main storage device 903 and sequentially read into the arithmetic device 901 and executed.
The program is a program that realizes a function described as “˜unit” (excluding the program storage unit 104, the same applies below) shown in FIG. 3 and FIG.
Further, an operating system (OS) is also stored in the external storage device 902. At least a part of the OS is loaded into the main storage device 903, and the arithmetic device 901 executes the OS as shown in FIG. 3 and FIG. Executes a program that realizes the function of "~ part".
Further, in the description of the present embodiment, it is described as “extraction of”, “analysis of”, “generation of”, “detection of”, “setting of”, “selection of”, etc. Information, data, signal values, and variable values indicating the results of processing are stored in the main storage device 903 as files.

  The configuration in FIG. 8 is merely an example of the hardware configuration of the simulation device 100 and the master / slave generation device 30, and the hardware configuration of the simulation device 100 and the master / slave generation device 30 is described in FIG. It is not limited to this configuration, and other configurations may be used.

  1 I / F module, 2 master unit, 3 slave unit, 4 common unit, 5 command buffer, 6 data buffer, 7 byte enable buffer, 8 buffer control unit, 9 signal line, 10 signal line, 11 signal line , 12 signal lines, 13 signal lines, 14 signal lines, 15 signal lines, 30 master / slave generation device, 31 parameter analysis unit, 32 I / O analysis unit, 33 generation unit, 34 output unit, 35 library read unit, 36 Library, 37 signal line, 38 signal line, 39 signal line, 40 signal line, 41 signal line, 42 signal line, 43 signal line, 44 signal line, 45 signal line, 46 signal line, 47 signal line, 48 signal line, 49 Signal line, 100 Simulation device, 101 I / F module execution unit, 102 Buffer area, 103 Master Over Bed execution unit, 104 a program storage unit, 1011 a master unit executing unit, 1012 a buffer controller execution unit, 1013 a slave unit executing unit.

Claims (6)

A first model that is a hardware module or bus model according to a first specification that is one of a plurality of specifications of a hardware module or a bus model; and one of the plurality of specifications. A simulation device for simulating communication with a second model which is a hardware module or a bus model according to a second specification different from the first specification,
It is a data element that is used in common in simulation of communication for all the specifications of the plurality of specifications from the communication data by analyzing the communication data according to the first specification generated by the first model. A first communication data management unit for extracting common data elements;
A second communication data management unit that generates communication data addressed to the second model according to the second specification using the common data element extracted by the first communication data management unit. A characteristic simulation device. The first communication data management unit includes:
Extracting a plurality of common data elements of a plurality of attributes from the communication data according to the first specification;
The simulation apparatus further includes:
A plurality of storage areas provided for each attribute of the common data element;
The plurality of common data elements extracted by the first communication data management unit are classified for each attribute, and the plurality of common data elements are respectively stored in storage areas of corresponding attributes, and the plurality of storages A common data element management unit that reads the plurality of common data elements from the area,
The second communication data management unit
The communication data according to the second specification is generated using the plurality of common data elements read from the plurality of storage areas by the common data element management unit. Simulation device. A first model that is a hardware module or bus model according to a first specification that is one of a plurality of specifications of a hardware module or a bus model; and one of the plurality of specifications. A computer that simulates communication with a second model that is a hardware module or a bus model according to a second specification different from the first specification;
It is a data element that is used in common in simulation of communication for all the specifications of the plurality of specifications from the communication data by analyzing the communication data according to the first specification generated by the first model. A first communication data management process for extracting common data elements;
Executing a second communication data management process for generating communication data addressed to the second model according to the second specification using the common data element extracted by the first communication data management process A program characterized by In the first communication data management process,
In the computer,
Extracting a plurality of common data elements of a plurality of attributes from the communication data according to the first specification;
The program further includes:
The plurality of common data elements extracted by the first communication data management process are classified for each attribute, and the plurality of common data elements are respectively provided in the computer provided for each attribute of the common data element. Storage in the storage area of the corresponding attribute of the storage area, and causing the computer to execute a common data element management process of reading the plurality of common data elements from the plurality of storage areas,
In the second communication data management process,
In the computer,
The communication data according to the second specification is generated using the plurality of common data elements read from the plurality of storage areas by the common data element management processing. program. A first model that is a hardware module or bus model according to a first specification that is one of a plurality of specifications of a hardware module or a bus model; and one of the plurality of specifications. When a simulation of communication with a second model which is a hardware module or a bus model according to a second specification different from the first specification is performed, the first model and the second model An interface module generation device that generates an interface module that is a program that functions as an interface with a model,
Analyzing the first specification and using it in communication simulation for all specifications of the plurality of specifications among the data elements included in the communication data generated according to the first specification by the first model A common data element that is a data element to be processed, and a program code that is included in the interface module based on the determination result and that extracts the common data element from the communication data is a first program code A first program code generation unit for generating
Analyzing the second specification and using the common data element extracted by execution of the first program code, which is a program code included in the interface module, the second specification according to the second specification An interface module generation device comprising: a second program code generation unit that generates a program code for generating communication data addressed to the model as a second program code. A first model that is a hardware module or bus model according to a first specification that is one of a plurality of specifications of a hardware module or a bus model; and one of the plurality of specifications. When a simulation of communication with a second model which is a hardware module or a bus model according to a second specification different from the first specification is performed, the first model and the second model To a computer that generates an interface module, which is a program that functions as an interface with the model,
Analyzing the first specification and using it in communication simulation for all specifications of the plurality of specifications among the data elements included in the communication data generated according to the first specification by the first model A common data element that is a data element to be processed, and a program code that is included in the interface module based on the determination result and that extracts the common data element from the communication data is a first program code A first program code generation process generated as
Analyzing the second specification and using the common data element extracted by execution of the first program code, which is a program code included in the interface module, the second specification according to the second specification A program for causing a program code for generating communication data addressed to the model to be generated as a second program code.

Images