JP2014085956A - Simulation control program, simulation program, simulation control device, simulation device, simulation control method, and simulation method - Google Patents

Abstract

PROBLEM TO BE SOLVED: To shorten a processing time required for a cooperative simulation between a hardware model and software.SOLUTION: A simulation device 100 calls an API 112 when software 102 executes a RegWrite instruction or a RegRead instruction. Then, the simulation device 100 loads the processing contents of the API 112 into context information of the software 102, and executes the RegWrite instruction or the RegRead instruction. The called API 112 determines whether an access request is a read request to a specific storage area. When determining that the access request is not the read request to the specific storage area, the API 112 accesses a memory model 103_s and executes access processing for the access request.

Description

  The present invention relates to a simulation control program, a simulation program, a simulation control apparatus, a simulation apparatus, a simulation control method, and a simulation method.

  Conventionally, there is a technique for verifying hardware operation. For example, there is a technique in which an emulation device that imitates hardware distributes common control information to each of a plurality of clock domains into which the emulation device is divided, and provides individual clock control to the clock domain.

  In addition, there is a technology for performing a co-simulation of a hardware model and software. For example, there is a technique for selecting a software clock when verifying a verification target circuit according to a memory model held by a software simulator, and selecting a hardware clock when verifying a verification target circuit according to a memory model held by a hardware emulator. . In addition, there is a technique in which a part related to the operation of peripheral devices other than the central processing unit (CPU) is executed by hardware logic simulation, and a software part is executed on a general-purpose computer. In addition, there is a technology that realizes hardware simulation with a plurality of applications, and operates the realized applications in cooperation (see, for example, Patent Documents 1 to 6 below).

JP-A-8-320804 JP 2006-349699 A JP 2007-42122 A JP 2010-250365 A Japanese Patent Laid-Open No. 10-260865 Japanese Patent Laid-Open No. 11-296408

  However, in the prior art, during execution of the collaborative simulation with software as a verification target, processing for switching execution rights between the hardware model and the software may frequently occur, leading to an increase in simulation time.

  The present invention eliminates the above-described problems caused by the prior art, and includes a simulation control program, a simulation program, a simulation control apparatus, a simulation apparatus, and a simulation control for shortening the processing time required for the cooperative simulation between the hardware model and the software. It is an object to provide a method and a simulation method.

  In order to solve the above-described problems and achieve the object, according to one aspect of the present invention, a simulation control program called from software during execution of a co-simulation of a hardware model and software, which is generated from the software Whether the access request is a read request to a specific storage area with reference to the storage unit storing the address of the specific storage area whose storage contents are updated by the hardware model of the storage area of the hardware model If the access request is not a read request to a specific storage area, a simulation control program, a simulation control apparatus, and a simulation that access the storage area of the hardware model and execute access processing for the access request A control method is proposed.

  In addition, according to another aspect of the present invention, during execution of the cooperative simulation between the hardware model and the software, it is detected that an access request to the storage area of the hardware model is generated from the software, and the detected access Whether the request is a read request to a specific storage area with reference to the storage unit storing the address of the specific storage area whose storage contents are updated by the hardware model of the storage area of the hardware model When determining and determining that the access request is not a read request to a specific storage area, a simulation program, a simulation apparatus, and a simulation method for accessing the storage area of the hardware model by software and executing access processing for the access request Is proposed.

  According to one aspect of the present invention, it is possible to reduce the processing time required for the cooperative simulation between the hardware model and the software.

FIG. 1 is an explanatory diagram illustrating an operation example of the simulation apparatus according to the present embodiment. FIG. 2 is a block diagram illustrating an example of a hardware configuration of the simulation apparatus. FIG. 3 is a block diagram illustrating a functional configuration example of the simulation apparatus. FIG. 4 is an explanatory diagram showing an example of the stored contents of the processing table. FIG. 5 is an explanatory diagram showing an example of software source code. FIG. 6 is an explanatory diagram showing an example of the source code of the memory model. FIG. 7 is an explanatory diagram showing an example of the source code of the hardware model. FIG. 8A is an explanatory diagram illustrating an example of building a software source code and a hardware model source code. FIG. 8B is an explanatory diagram illustrating another example of building of a software source code and a hardware model source code. FIG. 9A is a sequence diagram illustrating an example of a simulation process when a RegWrite instruction is executed in a form in which a memory model is included in a hardware model. FIG. 9B is a sequence diagram illustrating an example of a simulation process when a RegWrite instruction is executed in the present embodiment. FIG. 10A is a sequence diagram illustrating an example of a simulation process when a RegRead instruction is executed in a form in which a memory model is included in a hardware model. FIG. 10B is a sequence diagram illustrating an example of a simulation process when the RegRead instruction is executed in the present embodiment. FIG. 11A is a sequence diagram illustrating another example of the simulation process when the RegRead instruction is executed in a form in which the memory model is included in the hardware model. FIG. 11B is a sequence diagram illustrating another example of the simulation process when the RegRead instruction is executed in the present embodiment. FIG. 12 is a sequence diagram illustrating an example of an operation when a RegWrite instruction is continuously performed on the same address. FIG. 13 is a flowchart illustrating an example of a simulation processing procedure. FIG. 14 is a flowchart illustrating another example of the simulation processing procedure. FIG. 15 is a flowchart illustrating an example of the RegRead processing procedure. FIG. 16 is a flowchart illustrating an example of a hardware model processing procedure for the address C.

  Exemplary embodiments of a disclosed simulation control program, simulation program, simulation control apparatus, simulation apparatus, simulation control method, and simulation method will be described below in detail with reference to the accompanying drawings. The simulation control program according to the present embodiment will be described using an example adopted as an Application Programming Interface (API) called from the verification target software.

  FIG. 1 is an explanatory diagram illustrating an operation example of the simulation apparatus according to the present embodiment. A simulation apparatus 100 according to the present embodiment is a computer that performs cooperative simulation of the hardware model 101 and software 102. In FIG. 1A, a software configuration example of the simulation apparatus 100 will be described. Further, in FIG. 1B, an operation example of the simulation apparatus 100 will be described.

  The simulation apparatus 100 according to the present embodiment performs cooperative simulation with the software 102 as a verification target. The developer confirms whether the operation of the software 102 conforms to the specification using the result of the co-simulation. On the other hand, the operation of the hardware model 101 may be different from the operation of the hardware to be simulated by the hardware model 101. The simulation apparatus 100 according to the present embodiment reduces the processing time required for the cooperative simulation by using the fact that the operation of the hardware model 101 may be different from the operation of the hardware to be simulated.

  1A, the simulation apparatus 100 includes a hardware model 101, software 102, a memory model 103_s, a simulator 111, and an API 112.

  The hardware model 101 is a model in which the operation of hardware in the simulation target system is described. Specifically, the hardware model 101 is described in a hardware description language such as SystemC or Verilog. The simulator 111 reads the hardware model 101 and generates a thread for executing the operation of the hardware model 101. A thread that executes the operation of the hardware model 101 has context information. The context information is information used for program execution. The context information of the hardware model 101 is, for example, a value of a variable used by the hardware model 101 or a value indicating the state of the hardware model 101.

  Further, the hardware model 101 includes a calculation process 121. The arithmetic processing 121 is processing that expresses processing executed by the hardware to be simulated using a hardware description language. The calculation process of the hardware to be simulated is a process performed on a storage area in the hardware. The storage area in the hardware is, for example, a register that indicates the state of the hardware, or a buffer that stores data used by the hardware for processing.

  At this time, when the calculation process of the hardware to be simulated is simulated as it is by the developer, the calculation process 121 is a process performed on the memory model 103_r simulating the storage area in the hardware. Become. However, using the fact that the hardware model 101 may be different from the operation of the hardware, the arithmetic processing 121 imitates a storage area in the hardware and can be directly accessed from the software 102. The processing performed for Note that the developer may define a storage area that is accessed by the software 102 as a memory model 103_s, and define a storage area that is not accessed by the software 102 as a memory model 103_r. Good. In the following description, a case where the memory model 103_r does not exist in the hardware model 101 according to the present embodiment will be described.

  The software 102 is an execution object in which processing of a CPU to be simulated in the simulation target system is described. Specifically, the software 102 is described in a language such as C language or C ++ language. The simulator 111 reads the software 102 and generates a thread for operating the CPU to be simulated. Further, the thread that performs the operation of the CPU to be simulated has context information. The context information of the software 102 is, for example, a variable value used by the software 102 or a value indicating the state of the software 102.

  Hereinafter, to simplify the description, a thread that executes the operation of the hardware model 101 is also simply referred to as the hardware model 101. Similarly, a thread that reads the software 102 and operates the CPU to be simulated is simply referred to as software 102.

  The simulator 111 executes a cooperative simulation between the hardware model 101 and the software 102. Specifically, the simulator 111 performs an execution right switching process between the hardware model 101 and the software 102 in accordance with the progress of the simulation time indicating the progress of the cooperative simulation. The simulation apparatus 100 according to the present embodiment reduces the number of switching processes to shorten the simulation time.

  Here, the execution right switching process will be described by taking as an example the case where the execution right is switched from the hardware model 101 to the software 102. The simulator 111 saves the context information of the hardware model 101 set in the CPU register of the simulation apparatus 100 to a random access memory (RAM) of the simulation apparatus 100. Next, the simulator 111 sets the context information of the software 102 stored in the RAM of the simulation apparatus 100 in the CPU register of the simulation apparatus 100. By executing the above processing, the simulator 111 switches the execution right from the hardware model 101 to the software 102.

  The API 112 is a function provided by the simulator 111 and controls the simulator 111. Specifically, the API 112 includes a RegRead instruction that provides a read process to the memory model 103_s and a RegWrite instruction that provides a write process to the memory model 103_s. As a control content to the simulator 111 performed by the API 112, for example, the execution right is transferred from the software 102 that has called the API 112, and the simulator 111 is instructed to set the execution right to the hardware model 101.

  Next, an operation example of the simulation apparatus 100 will be described with reference to FIG. FIG. 1B shows an example in which the software 102 calls “RegWrite (address A, 0x02);”. “RegWrite (address A, 0x02);” is a write process of 0x02 to address A in the memory model 103_s.

  The simulation apparatus 100 calls the API 112 when the software 102 executes a RegWrite instruction or a RegRead instruction. Subsequently, the simulation apparatus 100 loads the processing contents of the API 112 into the context information of the software 102 and executes the RegWrite instruction or the RegRead instruction. The simulation apparatus 100 executes a RegWrite instruction or a RegRead instruction according to the processing content of the API 112.

  The called API 112 determines whether or not the access request is a read request to a specific storage area. Here, the specific storage area is a storage area whose storage contents are updated by the hardware model 101 in the memory model 103_s. In the example of FIG. 1B, since the RegWrite instruction has been called and a write request has occurred, the API 112 determines that the access request is not a read request to a specific storage area.

  If it is determined that the access request is not a read request to a specific storage area, the API 112 accesses the memory model 103_s and executes an access process for the access request. In the example of FIG. 1B, the API 112 writes 0x02 to the address A and notifies the software 102 of the completion of writing.

  As described above, the simulation apparatus 100 performs processing by the API 112 called from the software 102 without causing the hardware model 101 to perform processing related to the storage area depending on the access request of the software 102. As a result, the simulation apparatus 100 can reduce the number of times of switching between the hardware model 101 and the software 102, so that the processing time required for the cooperative simulation can be shortened. Hereinafter, the simulation apparatus 100 will be described in detail with reference to FIGS.

(Hardware of the simulation apparatus 100)
FIG. 2 is a block diagram illustrating an example of a hardware configuration of the simulation apparatus. In FIG. 2, the simulation apparatus 100 includes a CPU 201, a read-only memory (ROM) 202, and a RAM 203. The simulation apparatus 100 includes a disk drive 204, a disk 205, and a communication interface 206. Further, the simulation apparatus 100 includes a display 207, a keyboard 208, and a mouse 209. Further, the CPU 201 to the mouse 209 are respectively connected by a bus 210.

  The CPU 201 is an arithmetic processing device that controls the entire simulation apparatus 100. The ROM 202 is a non-volatile memory that stores a program such as a boot program. A RAM 203 is a volatile memory used as a work area for the CPU 201.

  The disk drive 204 is a control device that controls reading and writing of data with respect to the disk 205 in accordance with the control of the CPU 201. As the disk drive 204, for example, a magnetic disk drive, an optical disk drive, a solid state drive, or the like can be adopted. The disk 205 is a non-volatile memory that stores data written under the control of the disk drive 204. For example, when the disk drive 204 is a magnetic disk drive, a magnetic disk can be adopted as the disk 205. Further, when the disk drive 204 is an optical disk drive, an optical disk can be adopted as the disk 205. When the disk drive 204 is a solid state drive, a semiconductor element memory can be adopted for the disk 205.

  The communication interface 206 is a control device that controls an internal interface with the network 211 and controls input / output of data from an external device. Specifically, the communication interface 206 is connected to a local area network (LAN), a wide area network (WAN), the Internet, or the like that is the network 211 through a communication line, and is connected to other devices via the network 211. For example, a modem or a LAN adapter may be employed as the communication interface 206.

  The display 207 is a device that displays data such as a cursor, an icon, or a tool box, as well as data such as a document, an image, and function information. As the display 207, for example, a Cathode Ray Tube (CRT), a Thin Film Transistor (TFT) liquid crystal display, a plasma display, or the like can be employed.

  The keyboard 208 is a device that has keys for inputting characters, numbers, various instructions, and the like and inputs data. The keyboard 208 may be a touch panel type input pad or a numeric keypad. The mouse 209 is a device for moving a cursor, selecting a range, moving a window, changing a size, and the like. The mouse 209 may be a trackball or a joystick as long as it has the same function as a pointing device.

(Functional configuration of simulation apparatus 100)
Next, functions of the simulation apparatus 100 will be described. FIG. 3 is a block diagram illustrating a functional configuration example of the simulation apparatus. The simulation apparatus 100 includes a determination unit 301, an output unit 302, and an execution unit 303. The determination unit 301 to the execution unit 303 serving as a control unit realize the functions of the determination unit 301 to the execution unit 303 when the CPU 201 executes a program stored in the storage device. Specifically, the storage device is, for example, the ROM 202, the RAM 203, the disk 205, etc. shown in FIG. Alternatively, the functions of the determination unit 301 to the execution unit 303 may be realized by another CPU executing via the communication interface 206.

  In addition, the simulation apparatus 100 can access the processing table 310. The processing table 310 stores an address of a specific storage area. For example, it is assumed that the memory model 103_s stores the storage contents of the address A, the address B, and the address C. At this time, the processing table 310 stores an address C as an address of a specific storage area. Further, when there are a plurality of specific storage areas, the processing table 310 may store an upper limit address and a lower limit address of the specific storage area.

  Further, the processing table 310 may store the address of the storage area of the storage area of the information used for the update process in the storage area of the hardware model 101. For example, the processing table 310 stores an address A that is an address of a storage area for storing information used for the update processing of the hardware model 101 when the storage content of the address C is updated. In the following description, the storage area of the storage destination of information used for the update process of the hardware model 101 is referred to as “storage area used for the update process”. The processing table 310 is stored in a storage device such as the RAM 203 and the disk 205. An example of the contents stored in the processing table 310 will be described later with reference to FIG.

  The determination unit 301 may refer to the processing table 310 to determine whether the access request is a read request to a specific storage area based on the access destination address of the access request. For example, if the access destination address of the access request is between the upper limit address and the lower limit address stored in the processing table 310 and the access request is a read request, the determination unit 301 specifies the access request. Is determined to be a read request to the storage area.

  Further, the determination unit 301 refers to the processing table 310 to determine whether the access request is a write request to the storage area used for the update process, based on the access destination address of the access request. Note that the determination result is stored in a storage area such as the RAM 203 or the disk 205.

  When the determination unit 301 determines that the access request is a read request to a specific storage area, the output unit 302 outputs an update process execution request for updating the specific storage area. For example, it is assumed that the determination unit 301 determines that the access request is a read request to the address C serving as a specific storage area. At this time, the output unit 302 outputs an execution request for update processing for updating the address C. As a specific output example, for example, the output unit 302 outputs an execution request for the hardware model 101 to the simulator 111. Subsequently, the simulator 111 switches the execution right from the software 102 to the hardware model 101. The hardware model 101 that has obtained the execution right executes update processing.

  If the determination unit 301 determines that the access request is not a read request to a specific storage area, the execution unit 303 accesses the memory model 103_s and executes access processing for the access request. For example, it is assumed that the determination unit 301 determines that the access request is a read request to the address B that does not become a specific storage area. At this time, the execution unit 303 accesses the memory model 103_s and executes a read process to the address B. Further, it is assumed that the determination unit 301 determines that the access request is a write request to the address C that is a specific storage area. At this time, the execution unit 303 accesses the memory model 103_s and executes a writing process to the address C.

  Further, the execution unit 303 may read a specific storage area and notify the software 102 of the read result when an update process is executed by the hardware model 101 as a result of the execution request output by the output unit 302. Good. For example, after the hardware model 101 executes the update process and the storage content of the address C is updated, the execution unit 303 reads the storage content of the address C and notifies the software 102 of the read result.

  If the determination unit 301 determines that the access request is a write request to the storage area used for the update process, the execution unit 303 writes the write data for the write request in the buffer. After the writing, the execution unit 303 may output a writing completion notification to the software 102. When the software 102 proceeds without waiting for a response to the write request, the execution unit 303 may not output a write completion notification to the software 102. Here, the buffer is a buffer for accumulating information used for update processing executed in response to a read request to a specific storage area generated after the access request. The buffer accumulates information using, for example, a first-in first-out (FIFO) method.

  For example, an address of a storage area used for update processing is address A, and a specific storage area is address C. Further, suppose that two access requests are generated from the software 102, and the first access request is a write request of the write data “0x02” for the address A. Assume that the second access request is a write request for write data “0x03” for address A. The buffer stores write data “0x02” serving as the first access request and write data “0x03” serving as the second access request. When a read request to address C occurs after the second access request, hardware model 101 executes an update process for address C using write data “0x02” and write data “0x03”. .

  By the way, in the present embodiment, when the API 112 is called, an access request is generated. Therefore, the API 112 does not need to detect the generation of the access request. On the other hand, as another form, the simulator 111 detects that an access request to the storage area of the hardware model 101 is generated from the software 102 during execution of the cooperative simulation between the hardware model 101 and the software 102. Also good. Specifically, the simulator 111 monitors an instruction executed by the software 102 and detects whether the instruction executed by the software 102 is a RegWrite instruction or a RegRead instruction. The detected result is stored in a storage area such as the RAM 203 and the disk 205.

  When it is detected that an access request has occurred, the determination unit 301 to the execution unit 303 execute the above-described processing. The determination unit 301 to the execution unit 303 may be included in the API 112 or may be included in the simulator 111.

  Subsequently, the processing table 310, the hardware model 101, the software 102, and the operation of the simulator 111 will be described with reference to FIGS. The hardware model 101 will be described using a hardware model 101 # 1 and a hardware model 101 # 2 that simulate different hardware.

  FIG. 4 is an explanatory diagram showing an example of the stored contents of the processing table. The processing table 310 illustrated in FIG. 4 stores records 401-1 to 401-3. The processing table 310 includes three fields: a designated address, a corresponding hardware model, and processing contents. In the designated address field, an address in the memory model 103_s is stored. The corresponding hardware model field stores identification information of the hardware model 101 that writes to the address. The processing content field stores processing content executed by the hardware model 101 or the software 102 on the designated address.

  For example, the record 401-1 indicates that the designated address is the address A and there is no hardware model 101 to be written to the address A. Further, the record 401-1 indicates that the processing content writes that the software 102 writes the write data to the address A at the time of Write access to the address A. In addition, the record 401-1 indicates that the content of processing indicates that the software 102 reads the address A at the time of Read access to the address A.

  Further, the record 401-3 indicates that the designated address is the address C and the hardware model 101 written to the address C is the hardware model 101 # 1. Further, in the record 401-3, at the time of Read access to the address C, the processing content is that the software 102 reads the address C after the hardware model 101 # 1 writes the sum of the address A and the address B to the address C. Show.

  Further, the processing table 310 may have a field for storing an identifier indicating whether or not the storage area is used for update processing. For example, the record 401-1 stored for the address A may have an identifier indicating that it is a storage area used for update processing. Similarly, for example, the record 401-2 stored for the address B may have an identifier indicating that it is not a storage area used for update processing.

  FIG. 5 is an explanatory diagram showing an example of software source code. In FIG. 5, the line numbers 0001 to 0003 included in the software source code 501 will be described. The instruction “RegWrite (address A, 0x02);” at line number 0001 indicates that the value 0x02 is written to address A. The instruction “RegWrite (address B, 0x03);” at line number 0002 indicates that the value 0x03 is written to address B. The instruction “Result = RegRead (address C);” of the line number 0003 indicates that the operation result is read from the address C.

  FIG. 6 is an explanatory diagram showing an example of the source code of the memory model. FIG. 6 shows source codes of address A to address C included in the memory model source code 601. Address A to address C are defined as an int type. Further, when there is a possibility that the storage area used for the update process is continuously accessed to the same address, the developer may define it by an array. For example, when there is a possibility that the address A serving as a storage area used for the update process is accessed twice in succession, the developer defines it as “int address A [2];”. Furthermore, in order to access the address A [2] by the first-in first-out method, the developer may define a read pointer and a write pointer for the address A [2]. The read pointer and the write pointer are used in the API 112 and the hardware model 101.

  FIG. 7 is an explanatory diagram showing an example of the source code of the hardware model. FIG. 7 shows source code describing the operation of the hardware model 101 according to the hardware model description language included in the hardware model source code 701. The hardware model source code 701 illustrated in FIG. 7 indicates “hw1_model.h” that is a header file of the hardware model 101 # 1 and “hw1_model.c” that is a source file. “Hw1_model.h” declares input / output ports and processes of the hardware model 101 # 1. “Hw1_model.c” describes the implementation of the process of the hardware model 101 # 1.

  FIG. 8A is an explanatory diagram illustrating an example of building a software source code and a hardware model source code. FIG. 8A shows an example of a build when an instruction set simulator that performs simulation at the instruction set level is used. The build is a process for generating an execution object, and specifically, compiling to generate an intermediate language file from source code and linking to generate an execution object by combining the intermediate language files. The apparatus that performs the build may be the simulation apparatus 100 or another apparatus. 8A and 8B will be described using an example in which the simulation apparatus 100 performs a build.

  As a definition of terms, a CPU that is a simulation target of a cooperative simulation is referred to as a “target”. The code that can be executed by the target is referred to as “target code”. On the other hand, code executable by the CPU 201 is referred to as “native code”.

  The simulation apparatus 100 compiles and links the software source code 501 for the target, and generates a software execution object 801 described in the target code. The software execution object 801 includes a code called by the RegRead instruction or RegWrite instruction. Further, the simulation apparatus 100 compiles and links the hardware model source code 701 and the API source code 802 for native use, and generates a hardware model execution object 803 described in the native code. The API source code 802 is source code in which the processing content of the API 112 is described.

  The simulator 111 reads the software execution object 801 by using an Instruction Set Simulator (ISS) 810 and generates the software 102. Further, the simulator 111 reads the hardware model execution object 803 and generates the hardware model 101.

  FIG. 8B is an explanatory diagram illustrating another example of building of a software source code and a hardware model source code. FIG. 8B shows an example in which the ISS 810 is not used.

  The simulation apparatus 100 compiles and links the software source code 501 for native, and generates a software execution object 804 described in the native code. The software execution object 804 includes code called by the RegRead instruction or the RegWrite instruction. The compiling and linking of the hardware model source code 701 and the API source code 802 are the same as those in FIG.

  The simulator 111 reads the software execution object 804 and the hardware model execution object 803 to generate the software 102 and the hardware model 101.

  9A to 11B show sequence diagrams when the RegWrite instruction is executed and when the RegRead instruction is executed. 9A and 9B show sequence diagrams when the RegWrite instruction is executed. 10A and 10B show sequence diagrams when a RegRead instruction is executed to a specific storage area. 11A and 11B show sequence diagrams when the RegRead instruction is executed to a storage area that is not a specific storage area.

  FIG. 9A is a sequence diagram illustrating an example of a simulation process when a RegWrite instruction is executed in a form in which a memory model is included in a hardware model. In FIG. 9A, the software 102 executes “RegWrite (address A, 0x02);” (step S901). Since the value 0x02 is written to the address A, the execution right is switched to the simulator 111, and the simulator 111 selects the hardware model 101 that executes the processing content corresponding to the address A (step S902). In the present embodiment, it is assumed that the hardware model corresponding to address A is hardware model 101 # 2.

  Next, the simulator 111 sets the execution right to the hardware model 101 # 2 (step S903). The hardware model 101 # 2 that has obtained the execution right writes the value 0x02 to the address A (step S904). Since the processing of the hardware model 101 # 2 is completed, the simulator 111 sets the execution right in the simulator 111 (step S905). Subsequently, the simulator 111 sets the execution right in the software 102 (step S906). The software 102 that has obtained the execution right executes the following instruction.

  FIG. 9B is a sequence diagram illustrating an example of a simulation process when a RegWrite instruction is executed in the present embodiment. In FIG. 9B, the software 102 writes “0x02” to the address A by executing “RegWrite (address A, 0x02);” (step S951). Subsequently, the software 102 executes the next instruction.

  Here, the number of execution rights switching will be described using the execution results of FIGS. 9A and 9B. In FIG. 9A, execution rights are switched in steps S901, S903, S905, and S906, and the number of execution rights switching is four. On the other hand, in FIG. 9B, the execution right is not switched, and the number of execution right switching is zero. As described above, when the RegWrite instruction is included in the instruction group executed by the software 102, the simulation apparatus 100 can reduce the processing time required for the co-simulation because the number of execution rights switching is reduced.

  FIG. 10A is a sequence diagram illustrating an example of a simulation process when a RegRead instruction is executed in a form in which a memory model is included in a hardware model. In FIG. 10A, the software 102 executes “Result = RegRead (address C);” (step S1001). Since the address C is read, the execution right is switched to the simulator 111, and the simulator 111 selects the hardware model 101 corresponding to the address C (step S1002). In the present embodiment, it is assumed that hardware model 101 corresponding to address C is hardware model 101 # 1.

  Next, the simulator 111 sets the execution right to the hardware model 101 # 1 (step S1003). The hardware model 101 # 1 that has obtained the execution right acquires the processing content corresponding to the address C (step S1004). Next, the hardware model 101 # 1 reads the value of the address A, which is the first argument of the processing content (step S1005). Similarly, hardware model 101 # 1 reads the value of address B, which is the second argument of the processing content (step S1006).

  Since the argument is read, the hardware model 101 # 1 executes “address C = address A + address B” as the processing content (step S1007). Specifically, the hardware model 101 # 1 calculates the value of the address C as the value of the address A 0x02 + the value of the address B 0x03 = 0x05. Next, the hardware model 101 # 1 writes the calculation result at the address C (step S1008). Also, the hardware model 101 # 1 notifies the software 102 of the calculation result (step S1009). Subsequently, since the processing of the hardware model 101 # 1 is completed, the simulator 111 sets the execution right in the simulator 111 (step S1010).

  Subsequently, the simulator 111 sets an execution right in the software 102 (step S1011). The software 102 that has obtained the execution right sets the value received from the hardware model 101 # 1 to Result (step S1012). Subsequently, the software 102 executes the next instruction.

  FIG. 10B is a sequence diagram illustrating an example of a simulation process when the RegRead instruction is executed in the present embodiment. In FIG. 10B, steps S1055 to S1058 have the same processing contents as steps S1005 to S1008, and thus description thereof is omitted.

  In FIG. 10B, the software 102 executes “Result = RegRead (address C);” (step S1051). In order to read the address C, the execution right is switched to the simulator 111, and the simulator 111 selects the hardware model 101 that executes the processing content for updating the value of the address C (step S1052). In the present embodiment, it is assumed that hardware model 101 that executes the processing content for updating the value of address C is hardware model 101 # 1.

  Next, the simulator 111 sets the execution right to the hardware model 101 # 1 (step S1053). The hardware model 101 # 1 that has obtained the execution right acquires the processing content for updating the value of the address C (step S1054). Next, the hardware model 101 # 1 executes the process of step S1055.

  Since the processing of the hardware model 101 # 1 is completed after the processing of step S1058, the simulator 111 sets an execution right for the simulator 111 (step S1059). Subsequently, the simulator 111 sets an execution right in the software 102 (step S1060). The software 102 that has obtained the execution right reads the value of the address C (step S1061). Next, the software 102 sets the read value to Result (step S1062). Subsequently, the software 102 executes the next instruction.

  Here, the number of execution rights switching will be described using the execution results of FIGS. 10A and 10B. In FIG. 10A, execution rights are switched in steps S1001, S1003, S1010, and S1011. The number of execution rights switching is four. On the other hand, in FIG. 10B, execution rights are switched in steps S1051, S1053, S1059, and S1060, and the number of execution rights switching is four. As described above, when the RegRead instruction to a specific address is included, the number of times of execution right switching of the simulation apparatus 100 is the same as the number of times of execution right switching with the simulation apparatus in the form in which the memory model 103_s is included in the hardware model 101. It becomes.

  FIG. 11A is a sequence diagram illustrating another example of the simulation process when the RegRead instruction is executed in a form in which the memory model is included in the hardware model. In FIG. 11A, the software 102 executes “Result = RegRead (address A);” (step S1101). Since the address A is read, the execution right is switched to the simulator 111, and the simulator 111 selects the hardware model 101 corresponding to the address A (step S1102). In the present embodiment, it is assumed that hardware model 101 corresponding to address A is hardware model 101 # 2.

  Next, the simulator 111 sets the execution right to the hardware model 101 # 2 (step S1103). The hardware model 101 # 2 that has obtained the execution right reads a value from the address A (step S1104). Next, the hardware model 101 # 2 notifies the software 102 of the read value (step S1105). Subsequently, since the processing of the hardware model 101 # 2 is completed, the simulator 111 sets the execution right in the simulator 111 (step S1106). Subsequently, the simulator 111 sets an execution right in the software 102 (step S1107). The software 102 that has obtained the execution right sets the value received from the hardware model 101 # 2 to Result (step S1108). Subsequently, the software 102 executes the next instruction.

  FIG. 11B is a sequence diagram illustrating another example of the simulation process when the RegRead instruction is executed in the present embodiment. In FIG. 11B, the software 102 executes “Result = RegRead (address A);” (step S1151). In order to read the address A, the execution right is switched to the simulator 111, and the simulator 111 refers to the processing table 310 and selects the hardware model 101 that executes the processing content for updating the value of the address A (step S1152). As shown in FIG. 4, “None” indicating that there is no hardware model 101 that executes the processing content for updating the value of A is stored in the corresponding hardware model field of the record 401-1. Therefore, the simulator 111 determines that there is no hardware model 101 corresponding to the address A, and sets the execution right in the software 102 (step S1153).

  The software 102 that has obtained the execution right reads a value from the address A (step S1154). Next, the software 102 sets the read value to Result (step S1155). Subsequently, the software 102 executes the next instruction.

  Here, the number of execution rights switching will be described using the execution results of FIGS. 11A and 11B. In FIG. 11A, execution rights are switched in steps S1101, S1103, S1106, and S1107, and the number of execution rights switching is four. On the other hand, in FIG. 11B, execution rights are switched in steps S1151 and S1153, and the number of execution rights switching is two. In this way, when the instruction group executed by the software 102 includes a RegRead instruction to a storage area that is not a specific storage area, the simulation apparatus 100 reduces the number of times of execution right switching, and therefore reduces the processing time required for the cooperative simulation. It can be shortened.

  FIG. 12 is a sequence diagram illustrating an example of an operation when a RegWrite instruction is continuously performed on the same address. In the software 102 shown in FIG. 12, the instruction of the line number 0002 has been rewritten by the developer from “RegWrite (address B, 0x03);” to “RegWrite (address A, 0x03);”. Further, the API 112 stores the value stored in the address A of the memory model 103_s in the FIFO buffer 1201 using the first-in first-out method. In the processing content field of the address C in the processing table 310, “Read access hardware model 101 # 1: address C = total value written to address A software: read address C” is stored. .

  The software 102 reads the instruction at the line number 0001 and executes “RegWrite (address A, 0x02);” to write the value 0x02 to the address A (step S1201). For the processing in step S1201, the software 102 enqueues 0x02 in the FIFO buffer 1201. As a specific implementation, the API 112 called from the software 102 writes 0x02 to the position indicated by the write pointer in the FIFO buffer 1201, and increments the value of the write pointer.

  Next, the software 102 reads the instruction of the line number 0002 and executes “RegWrite (address A, 0x03);” to write the value 0x03 to the address A (step S1202). For the processing in step S1202, the software 102 enqueues 0x03 into the FIFO buffer 1201. As a specific implementation, the API 112 called from the software 102 writes 0x03 to the position indicated by the write pointer in the FIFO buffer 1201, and increments the value of the write pointer.

  Subsequently, the software 102 reads the instruction of the line number 0003 and executes “RegRead (address C);” (step S1203). Although not shown in FIG. 12, the simulator 111 refers to the processing table 310 and searches for processing contents for updating the value of the address C. In the case of FIG. 12, it is determined that there is processing content for updating the value of the address C, and the simulator 111 sets the execution right to the hardware model 101 # 1 that executes the processing content. At this time, the processing content is a process of calculating the total value written to the address A and writing the calculated value to the address C.

  The hardware model 101 # 1 acquires the processing content for updating the value of the address C (step S1204). The hardware model 101 # 1 reads a value from an address A that is an argument of processing contents. At this time, the hardware model 101 # 1 reads all the values stored in the FIFO buffer 1201. Specifically, the hardware model 101 # 1 reads 0x02 from the FIFO buffer 1201 (step S1205). Subsequently, the hardware model 101 # 1 reads 0x03 from the FIFO buffer 1201 (step S1206). As a specific implementation, the hardware model 101 # 1 reads the value of the position indicated by the read pointer in the FIFO buffer 1201, and increments the read pointer. Subsequently, the hardware model 101 # 1 continues reading until the read pointer matches the write pointer.

  Since the argument is read, the hardware model 101 # 1 executes “calculation processing of the total value written in the address A” which is the processing content (step S1207). Specifically, the hardware model 101 # 1 calculates the value of the address C as a value 0x02 written to the address A for the first time + 0x03 = 0x05 written to the address A for the second time. Next, the hardware model 101 # 1 writes 0x05, which is the calculated value, at the address C (step S1208).

  Subsequently, since the processing of the hardware model 101 # 1 is completed, the simulator 111 sets the execution right in the software 102. The software 102 that has obtained the execution right sets the value 0x05 of the address C to Result (step S1209). Subsequently, the software 102 executes the next instruction. Subsequently, a flowchart of the simulation process will be described with reference to FIGS. 13 to 16, the address A is a storage area used for the update process, the address C is a specific storage area, and the address B is not a storage area used for the update process, but a specific storage area. However, I will explain it as something that is not.

  FIG. 13 is a flowchart illustrating an example of a simulation processing procedure. The simulation process is a process for performing a co-simulation of the hardware model 101 and the software 102. The simulation apparatus 100 sets the execution right in the software 102 by the simulator 111 (step S1301). Next, the simulation apparatus 100 reads one command by the software 102 (step S1302). Subsequently, the simulation apparatus 100 confirms the type of the read instruction using the software 102 (step S1303). When the type of the read instruction is a RegWrite instruction (step S1303: RegWrite instruction), the simulation apparatus 100 checks the address specified by the RegWrite instruction using the API 112 called from the software 102 (step S1304).

  When the address is A (step S1304: address A), the simulation apparatus 100 writes the value specified by the RegWrite instruction to the FIFO buffer 1201 of the address A by the API 112 (step S1305). If the address is other than the address A (step S1304: other address), the simulation apparatus 100 writes the value specified by the RegWrite instruction to the other address by the API 112 (step S1306). After the process of step S1305 or step S1306, the API 112 ends the process. Subsequently, the simulation apparatus 100 proceeds to the process of step S1302.

  When the type of the read instruction is a RegRead instruction (step S1303: RegRead instruction), the simulation apparatus 100 executes a RegRead process using the API 112 (step S1307). Details of the RegRead process will be described later with reference to FIG. After the end of step S1307, the simulation apparatus 100 proceeds to the process of step S1302. When the type of the read instruction is another instruction different from the RegWrite instruction and RegRead instruction (step S1303: other instruction), the simulation apparatus 100 executes processing according to the other instruction by the software 102. To do. After execution, the simulation apparatus 100 proceeds to the process of step S1302.

  FIG. 14 is a flowchart illustrating another example of the simulation processing procedure. The simulation process shown in FIG. 14 is an example of a process for detecting an access request by the simulator 111.

  The simulation apparatus 100 sets the execution right in the software 102 by the simulator 111 (step S1401). Next, the simulation apparatus 100 determines whether the simulator 111 detects that a RegWrite instruction or a RegRead instruction is called (step S1402). If not detected (step S1402: No), the simulation apparatus 100 executes the process of step S1402 again after a predetermined time has elapsed. If detected (step S1402: Yes), the simulation apparatus 100 confirms the type of the called instruction by the simulator 111 (step S1403).

  When the type of the called instruction is a RegWrite instruction (step S1403: RegWrite instruction), the simulation apparatus 100 checks the address specified by the RegWrite instruction using the API 112 called from the software 102 (step S1404).

  When the address is A (step S1404: address A), the simulation apparatus 100 writes the value specified by the RegWrite instruction to the FIFO buffer 1201 of the address A by the API 112 (step S1405). If the address is other than the address A (step S1404: other address), the simulation apparatus 100 writes the value specified by the RegWrite instruction to the other address by the API 112 (step S1406). After step S1405 or step S1406 ends, the API 112 ends the process. Subsequently, the simulation apparatus 100 proceeds to the process of step S1402.

  When the type of the called instruction is a RegRead instruction (step S1403: RegRead instruction), the simulation apparatus 100 executes a RegRead process using the API 112 (step S1407). After the end of step S1407, the simulation apparatus 100 proceeds to the process of step S1402.

  FIG. 15 is a flowchart illustrating an example of the RegRead processing procedure. The simulation apparatus 100 sets an execution right in the simulator 111 using the API 112 (step S1501). Next, the simulation apparatus 100 confirms the address specified by the RegRead instruction (step S1502).

  When the designated address is address C (step S1502: address C), the simulation apparatus 100 executes hardware model processing for address C by the simulator 111 (step S1503). Details of the hardware model processing will be described later with reference to FIG. After executing step S1503, the simulation apparatus 100 sets the execution right in the software 102 by the simulator 111 (step S1504). Next, the simulation apparatus 100 reads a value from the address C by the API 112 called from the software 102 (step S1505). Subsequently, the simulation apparatus 100 sets the read value to Result using the API 112 (step S1506). After completing the execution of step S1506, the simulation apparatus 100 ends the RegRead process.

  When the designated address is address A (step S1502: address A), the simulation apparatus 100 sets the execution right in the software 102 by the simulator 111 (step S1507). Next, the simulation apparatus 100 reads a value from the address A by the API 112 called from the software 102 (step S1508). Subsequently, the simulation apparatus 100 sets the read value to Result using the API 112 (step S1509). After completing the execution of step S1509, the simulation apparatus 100 ends the RegRead process.

  When the designated address is another address different from both the address C and the address A (step S1502: another address), the simulation apparatus 100 sets the execution right in the software 102 by the simulator 111. Next, the simulation apparatus 100 reads a value from the address A by the API 112 called from the software 102, and sets the read value to Result. Subsequently, the simulation apparatus 100 ends the RegRead process.

  FIG. 16 is a flowchart illustrating an example of a hardware model processing procedure for the address C. The simulation apparatus 100 sets the execution right to the hardware model 101 # 1 using the simulator 111 (step S1601). Next, the simulation apparatus 100 reads the value of the address A using the hardware model 101 # 1 based on the processing content field of the processing table 310 (step S1602). Subsequently, the simulation apparatus 100 reads the value of the address B by the hardware model 101 # 1 based on the processing content field of the processing table 310 (step S1603). Next, the simulation apparatus 100 adds the value of the address B to the value of the address A using the hardware model 101 # 1 (step S1604).

  Subsequently, the simulation apparatus 100 writes the added value to the address C using the hardware model 101 # 1 (step S1605). Next, the simulation apparatus 100 sets an execution right in the simulator 111 using the hardware model 101 # 1 (step S1606). After completing the execution of step S1606, the simulation apparatus 100 ends the hardware model process.

  As described above, according to the API 112 and the simulator 111, if the access request to the register of the hardware model 101 by the software 102 is not a read request to the register updated when reading from the software 102, the API 112 processes. . As a result, the simulation apparatus 100 does not have to give the execution right to the hardware model 101, so that the verification time of the software 102 can be shortened.

  Further, according to the API 112 and the simulator 111, if the access request from the software 102 is a read request to a register updated when reading from the software 102, the hardware model 101 is processed. Thereby, the simulation apparatus 100 can make the actual processing result and the simulation processing result the same.

  Further, according to the API 112 and the simulator 111, if the access request from the software 102 is a write request to a register serving as a storage destination of information used for update processing of a register updated at the time of reading, the data is written to the buffer. The requested write data may be written. As a result, even when there is a series of processing groups in which the hardware processes each time a write request from the software 102 actually exists, the simulation apparatus 100 makes the actual processing result and the simulation processing result the same. can do.

  In some cases, an embedded system is assumed as the simulation target system. In this case, the processing performed by the processor in the embedded system may occupy most of the processing for accessing other hardware. Therefore, in the simulation apparatus in which the memory model 103_s is included in the hardware model 101, the number of times of switching between the hardware model 101 and the software 102 increases. On the other hand, the simulation apparatus 100 according to the present embodiment can greatly reduce the processing time required for the cooperative simulation.

  Even in the present embodiment in which the memory model 103_r is included in the hardware model 101, the software 102 calls an API that provides a RegRead instruction and a RegWrite instruction. Therefore, when the memory model 103_r is included in the hardware model 101 and corresponds to this embodiment, the developer does not need to change the description of the software 102. The developer can obtain the simulation environment according to the present embodiment only by compiling and linking the software 112 with the API 112 according to the present embodiment.

  The simulation method described in this embodiment can be realized by executing a program prepared in advance on a computer such as a personal computer or a workstation. The simulation program is recorded on a computer-readable recording medium such as a hard disk, a flexible disk, a CD-ROM, an MO, and a DVD, and is executed by being read from the recording medium by the computer. The simulation program may be distributed through a network such as the Internet.

  The following additional notes are disclosed with respect to the above-described embodiment.

(Supplementary Note 1) A simulation control program called from the software during execution of a co-simulation between a hardware model and software,
On the computer,
The access request generated from the software refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model of the storage area of the hardware model. Determine whether it is a read request to the area,
If it is determined that the access request is not a read request to the specific storage area, access to the storage area of the hardware model to execute an access process for the access request,
A simulation control program characterized by causing a process to be executed.

(Supplementary note 2)
When it is determined that the access request is a read request to the specific storage area, a process for outputting an execution request for an update process for updating the storage contents of the specific storage area is executed,
The process to be executed is as follows:
As a result of outputting the execution request, when the update process is completed by the hardware model, the specific storage area is read, and the read result is output to the software. program.

(Additional remark 3) The said memory | storage part has further memorize | stored the address of the storage area of the storage destination of the information used for the said update process among the storage areas of the said hardware model,
In the computer,
Referencing the storage unit, causing the access request to determine whether or not the write request to the storage area of the storage destination,
The process to be executed is as follows:
When it is determined that the access request is a write request to the storage area of the storage destination, the update process executed for a read request to the specific storage area generated from the software after the access request 3. The simulation control program according to appendix 2, wherein the write data of the write request is written into a buffer for storing information used in the above.

(Appendix 4)
During the execution of the co-simulation between the hardware model and software, the software detects that an access request to the storage area of the hardware model has occurred,
The detected access request refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model, out of the storage areas of the hardware model, and enters the specific storage area To determine whether or not
If it is determined that the access request is not a read request to the specific storage area, the software accesses the storage area of the hardware model and executes an access process for the access request.
A simulation program characterized by causing processing to be executed.

(Supplementary Note 5) A simulation control program that is called from the software during execution of a co-simulation between a hardware model and software,
The access request generated from the software refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model of the storage area of the hardware model. Determine whether it is a read request to the area,
If it is determined that the access request is not a read request to the specific storage area, access to the storage area of the hardware model to execute an access process for the access request,
A recording medium on which a simulation control program for causing a computer to execute processing is recorded.

(Supplementary note 6) During execution of the co-simulation between the hardware model and the software, the software detects that an access request to the storage area of the hardware model has occurred,
The detected access request refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model, out of the storage areas of the hardware model, and enters the specific storage area To determine whether or not
If it is determined that the access request is not a read request to the specific storage area, the software accesses the storage area of the hardware model and executes an access process for the access request.
A recording medium on which a simulation program for causing a computer to execute processing is recorded.

(Supplementary note 7) A simulation control device called from the software during the execution of the co-simulation between the hardware model and the software,
The access request generated from the software refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model of the storage area of the hardware model. A determination unit for determining whether or not it is a read request to the area;
An execution unit that accesses the storage area of the hardware model and executes an access process for the access request when the determination unit determines that the access request is not a read request to the specific storage area;
A simulation control apparatus comprising:

(Supplementary note 8) A simulation control device called from the software during the execution of the co-simulation between the hardware model and the software,
The access request generated from the software refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model of the storage area of the hardware model. A determination unit for determining whether or not it is a read request to the area;
An execution unit that accesses the storage area of the hardware model and executes an access process for the access request when the determination unit determines that the access request is not a read request to the specific storage area;
A simulation control apparatus comprising: a computer having:

(Additional remark 9) The detection part which detects that the access request to the storage area of the said hardware model generate | occur | produced from the said software during execution of the co-simulation of a hardware model and software,
The access request detected by the detection unit refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model of the storage area of the hardware model, A determination unit for determining whether or not a read request to a specific storage area;
When the determination unit determines that the access request is not a read request to the specific storage area, the execution unit executes access processing for the access request by accessing the storage area of the hardware model by the software When,
A simulation apparatus comprising:

(Additional remark 10) The detection part which detects that the access request to the storage area of the said hardware model generate | occur | produced from the said software during execution of the co-simulation of a hardware model and software,
The access request detected by the detection unit refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model of the storage area of the hardware model, A determination unit for determining whether or not a read request to a specific storage area;
When the determination unit determines that the access request is not a read request to the specific storage area, the execution unit executes access processing for the access request by accessing the storage area of the hardware model by the software When,
A simulation apparatus comprising: a computer having:

(Supplementary Note 11) A simulation control method that is called from the software during the execution of a co-simulation between a hardware model and software,
Computer
The access request generated from the software refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model of the storage area of the hardware model. Determine whether it is a read request to the area,
If it is determined that the access request is not a read request to the specific storage area, access to the storage area of the hardware model to execute an access process for the access request,
The simulation control method characterized by performing a process.

(Supplementary note 12)
During the execution of the co-simulation between the hardware model and software, the software detects that an access request to the storage area of the hardware model has occurred,
The detected access request refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model, out of the storage areas of the hardware model, and enters the specific storage area To determine whether or not
If it is determined that the access request is not a read request to the specific storage area, the software accesses the storage area of the hardware model and executes an access process for the access request.
A simulation method characterized by executing processing.

101 Hardware Model 102 Software 103_s Memory Model 111 Simulator 112 API
301 Determination Unit 302 Output Unit 303 Execution Unit 310 Processing Table

Claims (8)

A simulation control program called from the software during the execution of the co-simulation between the hardware model and the software,
On the computer,
The access request generated from the software refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model of the storage area of the hardware model. Determine whether it is a read request to the area,
If it is determined that the access request is not a read request to the specific storage area, access to the storage area of the hardware model to execute an access process for the access request,
A simulation control program characterized by causing a process to be executed. In the computer,
When it is determined that the access request is a read request to the specific storage area, a process for outputting an execution request for an update process for updating the storage contents of the specific storage area is executed,
The process to be executed is as follows:
The simulation according to claim 1, wherein when the update process is completed by the hardware model as a result of outputting the execution request, the specific storage area is read and the read result is output to the software. Control program. The storage unit further stores an address of a storage area of a storage destination of information used for the update process in the storage area of the hardware model,
In the computer,
Referencing the storage unit, causing the access request to determine whether or not the write request to the storage area of the storage destination,
The process to be executed is as follows:
When it is determined that the access request is a write request to the storage area of the storage destination, the update process executed for a read request to the specific storage area generated from the software after the access request The simulation control program according to claim 2, wherein the write data of the write request is written in a buffer for storing information used in the process. On the computer,
During the execution of the co-simulation between the hardware model and software, the software detects that an access request to the storage area of the hardware model has occurred,
The detected access request refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model, out of the storage areas of the hardware model, and enters the specific storage area To determine whether or not
If it is determined that the access request is not a read request to the specific storage area, the software accesses the storage area of the hardware model and executes an access process for the access request.
A simulation program characterized by causing processing to be executed. A simulation control device called from the software during execution of a co-simulation between a hardware model and software,
The access request generated from the software refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model of the storage area of the hardware model. A determination unit for determining whether or not it is a read request to the area;
An execution unit that accesses the storage area of the hardware model and executes an access process for the access request when the determination unit determines that the access request is not a read request to the specific storage area;
A simulation control apparatus comprising: A detection unit for detecting that an access request to the storage area of the hardware model is generated from the software during execution of the co-simulation of the hardware model and the software;
The access request detected by the detection unit refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model of the storage area of the hardware model, A determination unit for determining whether or not a read request to a specific storage area;
When the determination unit determines that the access request is not a read request to the specific storage area, the execution unit executes access processing for the access request by accessing the storage area of the hardware model by the software When,
A simulation apparatus comprising: A simulation control method that is called from the software during execution of a co-simulation between a hardware model and software,
Computer
The access request generated from the software refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model of the storage area of the hardware model. Determine whether it is a read request to the area,
If it is determined that the access request is not a read request to the specific storage area, access to the storage area of the hardware model to execute an access process for the access request,
The simulation control method characterized by performing a process. Computer
During the execution of the co-simulation between the hardware model and software, the software detects that an access request to the storage area of the hardware model has occurred,
The detected access request refers to a storage unit that stores an address of a specific storage area whose storage content is updated by the hardware model, out of the storage areas of the hardware model, and enters the specific storage area To determine whether or not
If it is determined that the access request is not a read request to the specific storage area, the software accesses the storage area of the hardware model and executes an access process for the access request.
A simulation method characterized by executing processing.

Images