JP2023032451A - Simulation device and simulation method - Google Patents

Abstract

To suppress reduction in a simulation speed.SOLUTION: A simulation device includes a first simulator that simulates operation of software executed by a microcomputer and a second simulator having a calculation period different from that of the first simulator. In the second simulator, a microcomputer peripheral model indicating operation of a peripheral device to be verified by the microcomputer is arranged. The first simulator has a first register capable of reading out a register value to be read from the microcomputer peripheral model during the calculation period of the first simulator. The first register can read out and rewrite a specific value of the first register during one period of calculation of the first simulator.SELECTED DRAWING: Figure 1

Description

TECHNICAL FIELD The present invention relates to a simulation apparatus, and more particularly to an embedded system verification technique using software, hardware, and mechanism simulators on a computer.

2. Description of the Related Art In recent years, the number of electronic control units (ECUs) has increased as vehicle control has become more sophisticated and complicated, and the ECUs are interlocked to control vehicle systems. In this way, because the system is becoming more complicated, a single modification may have an effect beyond the designer's intention. sex is increasing.

In addition, in automobile development, the shortening of the development period and the elimination of prototyping are accelerating, and how to efficiently develop the increasing software in a short period of time and ensure the quality is an important issue. .

One solution to this problem is a verification environment using a virtual verification environment. In a virtual environment, tests can be performed under various conditions, and automatic execution of tests is easy. Due to the large number of tests required to run, high speed simulation equipment and tools are required.

Introduction Study Support Guide for Users for Virtual ECU Utilization, Virtual Microcomputer Application Promotion Council, September 29, 2015, http://www.vecu-mbd.org/wp-content/uploads/downloads/2015/10 /e981a9b1ad2267412627ee3c0f0e3f24.pdf

Simulated-processor-in-the-loop simulation (hereinafter referred to as SPILS) is a verification environment for verifying software including peripheral control of a microcomputer. SPILS models the entire microcomputer including microcomputer peripherals and executes software on it, so the scope of software verification is wide.

On the other hand, since the entire microcomputer is modeled, the scale of the model is large, the calculation load is high, and the simulation speed is slow.

A form of simulation by SPILS is co-simulation using a microcomputer simulator that simulates software using a microcomputer model and a simulator that simulates a circuit model and a plant model. Another method is to make the microcomputer model, the circuit model, and the plant model into modules, load them into one simulator, and use a simulator that operates at the calculation cycle of each module.

In contrast to SPIL, Software-In-the-Loop-Simulation (SILS) is software that does not include a microcomputer model, but converts software into code for the CPU (Central Processing Unit) installed in a computer (PC) and executes it. Since a simulator is used, the computational load is low and simulation can be performed at a higher speed than SPILS.

However, since it does not include a microcomputer model, the software portion that controls the peripherals of the microcomputer cannot be verified, and the verification range is narrower than SPILS.

A form of simulation by SILS is co-simulation using a software simulator and a model simulator that simulates a plant model. As another method, similar to SPILS, there is a method in which the software and the plant are made into modules and loaded into one simulator, and the simulation is performed at the calculation cycle of each module.

If SILS can create a high-speed simulation environment, including the software that controls microcomputer peripherals, the scope of verification by SILS will expand, and opportunities to use it will increase. For that purpose, it is necessary to add a microcomputer peripheral model. However, not all peripherals to be mounted on the microcomputer are required, and only the microcomputer peripheral model to be controlled should be mounted.

In order to add a microcomputer peripheral model to SILS, first of all, when looking at the access operation from software to the microcomputer peripheral, an interrupt triggers the reading of the status register, the confirmation of the interrupt status, and the clearing of the interrupt. , there are register settings for executing specific processing, and software and microcomputer peripherals are linked and accessed frequently.

Since the operation of the microcomputer peripheral itself operates in synchronization with the internal clock of the microcomputer and handles timing, the microcomputer peripheral model also needs to handle timing, and the calculation cycle becomes shorter, though not as much as the internal clock of the microcomputer.

Next, looking at the relationship between the calculation cycle and the simulation speed when simulating with a simulator, if the calculation cycle is short even for the same model, the overhead of the simulator stop processing and restart processing is large, and the simulation speed decreases. Conversely, if the calculation cycle is long, the overhead is small and the simulation speed is high. In order not to lower the simulation speed in this way, it is necessary not to shorten the calculation cycle.

As a method of incorporating a microcomputer peripheral model into SILS, when a microcomputer peripheral model is incorporated into a software simulator, frequent accesses are made between the software and the microcomputer peripheral, so the calculation cycle of the software is affected by the calculation cycle of the microcomputer peripheral. Among the calculation cycle of the software simulator and the calculation cycle of the microcomputer peripheral model, the calculation cycle of the microcomputer plant model is shorter, and it is necessary to shorten the calculation cycle of the software simulator. Changing the calculation cycle requires changing the schedule conditions of the scheduler of the simulator or replacing the scheduler.

Another method of incorporating the microcomputer peripheral model into SILS is co-simulation of a simulator that simulates the microcomputer peripheral model separately from the software simulator. It will only increase the load. As a result, a decrease in simulation speed can be suppressed. However, this method requires frequent access to microcomputer peripherals from software. In other words, it is necessary to solve the problem of suppressing speed reduction even when data transfer between simulators occurs frequently.

Looking at the transfer of data between simulators, each simulator advances the simulation according to the instructions of the co-simulation scheduler, and transfers data between the simulators at the timing when each simulator stops.

As mentioned above, if the data transfer between the software and the microcomputer peripheral in co-simulation is simply register read and register write, there is no problem with the co-simulation data transfer method. Inside, it is necessary to read a register with an interrupt from a microcomputer peripheral as a trigger, or to read another register value that has been rewritten by writing a register. Furthermore, in co-simulation, data can only be transferred at synchronous timing, resulting in a delay in data transfer timing. These issues need to be resolved.

A representative example of the invention disclosed in the present application is as follows. That is, the simulation apparatus includes a first simulator that simulates the operation of software executed by a microcomputer, and a second simulator that has a calculation cycle different from that of the first simulator, and the second simulator includes , a microcomputer peripheral model indicating the operation of a peripheral device to be verified by the microcomputer is arranged, and the first simulator reads a register value to be read from the microcomputer peripheral model in a calculation cycle of the first simulator. having a readable first register therein, the first register being capable of reading and rewriting a specific value of the first register during one cycle of calculation of the first simulator characterized by

According to one aspect of the present invention, it is possible to expand the software verification area and suppress a decrease in simulation speed. Problems, configurations, and effects other than those described above will be clarified by the following description of the embodiments.

1 is a diagram showing a co-simulation environment of Example 1; FIG. FIG. 3 is a diagram showing a register map of a microcomputer peripheral and register mounting positions of Example 1; 4 is a timing chart showing transfer of data between simulators of Example 1. FIG. 4 is a diagram showing the relationship between the calculation cycle of the software simulator of Example 1 and software processing; FIG. 2 is a block diagram showing the configuration of a microcomputer of Example 1; FIG. 4 is a time chart inside the microcomputer of Example 1; 5 is a time chart showing interrupt reporting and reading of register values in Example 1; 4 is a time chart showing the operation of the high-speed response register of Example 1; FIG. 10 is a diagram showing a co-simulation environment of Example 2;

The configuration and processing of an embodiment of the present invention will be described below with reference to the drawings. In the following description, the same elements are referred to by the same reference numerals across multiple drawings unless otherwise specified. It should be noted that the configuration and processing described in this specification are described as an example, and it should be understood that there is no intention to limit the technical scope of the present invention to this example.

<Example 1>
FIG. 1 shows a co-simulation environment using two simulators.

The simulation apparatus of this embodiment is composed of a software simulator 100 and a plant simulator 120 . The software simulator 100 simulates the verification target software 101 . Some registers of microcomputer peripherals are implemented as high-speed response registers 102 in the software simulator 100 .

The plant simulator 120 includes a microcomputer peripheral model 111 to be controlled by software and a plant model 121 to simulate the movement of the controlled object. A normal register 114 , a capture register 112 and a selector 113 are implemented in the microcomputer peripheral model 111 .

The normal register 114 is a register originally implemented as a function of the microcomputer peripheral.

The capture register 112 is a register that is referenced by software and by interrupt processing, and whose register value changes. When an interrupt factor occurs, the value of the normal register 114 is captured. Then, the value of the capture register 112 is read at the time of reading the register corresponding to the interrupt factor. In particular, register values that change over time are copied from the normal register 114 to the capture register 112 at the timing of the occurrence of an interrupt factor. The selector 113 is a switching function that refers to the capture register 112 when an interrupt is reported from the microcomputer peripheral model 111 and refers to the normal register 114 otherwise. Data is transferred between the two simulators.

FIG. 2 is a diagram showing a register map of a microcomputer peripheral and a register mounting position.

A fast response register 102 is implemented as part of the registers of the software simulator 100 . Registers other than the high-speed response register 102 are implemented as normal registers 114 in the microcomputer peripheral model 111 . A part of the normal register 114 is implemented as a capture register 112 that captures a register value, and a selector 113 switches between reading from the capture register 112 and reading from the normal register 114 .

FIG. 3 is a timing diagram showing the transfer of data between simulators. In FIG. 3, the calculation period of the software simulator 100 is 100 μs, and the calculation period of the plant simulator 120 is 10 μs.

The software simulator 100 executes software simulation processing 320 in each calculation cycle (100 μs), and the plant simulator 120 executes model simulation processing 330 in one calculation cycle (10 μs). When transferring data from the software simulation processing 320 to the model simulation processing 330, the data can be received with a delay of 10 μs in the calculation period of the model simulation processing 330. FIG. This data transfer is also used when the software simulator 100 writes the registers of the plant simulator 120 .

Transferring data from the model simulation process 330 to the software simulation process 320 in the opposite direction incurs a maximum delay of 100 μs. This data transfer is also used when the software simulator 100 reads data from the register of the plant simulator 120, and the software simulation processing 320 can receive the output value of the previous model simulation processing 330.

When the interrupt event 340 occurs in the microcomputer peripheral model 111, the software simulator 100 can be notified of the next calculation cycle of the software simulation process 320, resulting in a maximum delay of 100 μs.

FIG. 4 is a diagram showing the relationship between the calculation cycle of the software simulator 100 and software processing.

Software includes periodic processing for executing a series of tasks at a predetermined period and event processing for executing a series of tasks when an event such as an interrupt occurs. The software simulator 100 manages these processes with a scheduler and performs simulations according to priority.

FIG. 5 is a block diagram showing the configuration of the microcomputer.

CPU core 510 executes software. The CPU core 510 accesses registers of microcomputer peripherals 511 such as timers, AD converters, CAN controllers, DMA controllers, I/Os, interrupt controllers, RAMs, and ROMs via an internal bus 512 .

FIG. 6 is a time chart inside the microcomputer, showing three main processes of register access between the software 600 executed by the CPU core 510 and the microcomputer peripheral 610 .

The first interrupt process 620 accesses the status register of the microcomputer peripheral 610 in the interrupt process routine of the software 600 when an interrupt occurs in the microcomputer peripheral 610 .

A second clear status 630 is the case where a register access affects another register. For example, in interrupt processing, first read the interrupt status register to read the interrupt factor, then write the interrupt factor clear register to clear the interrupt status bit of the interrupt factor register, and then read the interrupt status register. to confirm that the interrupt factor has been cleared. In this processing, there is logic between the first read of the interrupt factor register and the second read of the interrupt factor register, and access to one register (interrupt factor register) causes another register (interrupt status register) to be read. rewrite the value.

The third specific process instruction 640 instructs the start of the specific process by successively writing to the register of the microcomputer peripheral 610 to instruct the contents of the order for the process and to start the process.

In this embodiment, the capture register 112, the high-speed response register 102, and the normal register 114 are properly used for these three processes. That is, the capture register 112 is accessed in the interrupt process that requires the register value at the time of the interrupt, and the high-speed response register 102 is accessed in the case of updating the accessed register value in the software simulation process 320 of one calculation cycle. , the normal register 114 is accessed for reading and writing normal register values.

FIG. 7 is a time chart showing interrupt reporting and reading of register values.

The microcomputer peripheral model 111 detects an interrupt and reports the interrupt to software. The software interrupt processing does not start processing until the start of the calculation cycle, and if the register value of the normal register 114 to be read is updated, the value of the normal register 114 is held in the capture register 112 when an interrupt occurs, and the select signal The value of the capture register 112 switched by the selector 113 at the rising edge of is passed to the software. When the interrupt ends, the select signal falls and the selector 113 selects reading from the normal register 114 . If it is not an interrupt report, the value of the normal register 114 switched by the selector 113 is passed to the software.

8 is a time chart showing the operation of the high-speed response register 102. FIG.

The fast response register 102 is implemented within the software simulator 100 and operates during processing of the software simulator. The software to be verified 101 executed during one calculation cycle may access a certain register to update the value of another register and refer to the updated another register. In an actual microcomputer, the update of another register value is processed by microcomputer peripheral logic, but since the software simulator cannot communicate with the outside during one calculation cycle, it must be processed within the software simulator. The high-speed response register 102 is provided to simulate peripheral logic processing of the microcomputer during one calculation processing period. The operation of the high-speed response register 102 will be described by taking interrupt status check and interrupt clear processing as examples. When an interrupt due to an interrupt signal is detected before execution of a calculation cycle, the corresponding bit of the interrupt status is set in the high-speed response register 102, and then a software interrupt is executed at the beginning of the calculation cycle execution process. During interrupt processing, the interrupt status of the high-speed response register 102 is read, and then a value for interrupt clear is written in the interrupt factor clear register. In the actual microcomputer peripheral, the interrupt status is cleared by this writing, but instead, the relevant bit of the interrupt status register is cleared by a clear function inserted during execution of the verification target software 101 in the software simulator. Alternatively, an external software debugger may monitor a write to the interrupt status clear and clear the interrupt status when a write to the interrupt status clear is detected. After that, the verification target software 101 can obtain the cleared value by reading the interrupt status register. Thereby, register access can be completed within the software simulator 100 .

<Example 2>
Next, Example 2 of the present invention will be described. In Example 2, as shown in FIG. 9 , the microcomputer peripheral model 111 is separated from the plant simulator 120 and the microcomputer peripheral simulator 110 is provided separately from the plant simulator 120 . In the second embodiment, differences from the first embodiment will be mainly described, and descriptions of the same configurations and processes as in the first embodiment will be omitted.

In the second embodiment, since the plant model 121 and the microcomputer peripheral model 111 are separate simulators, a simulation environment utilizing existing models can be constructed, and co-simulation of the software simulator 100 and the plant simulator 120 becomes possible.

As described above, the simulation apparatus according to the embodiment of the present invention includes a first simulator (software simulator 100) that simulates the operation of software executed by a microcomputer, and a second simulator (software simulator 100) that has a calculation cycle different from that of the software simulator 100. simulators (a microcomputer peripheral simulator 110 and a plant simulator 120), in which a microcomputer peripheral model 111 representing the operation of a peripheral device to be verified by the microcomputer is arranged; 110 has a first register (high-speed response register 102) capable of reading a register value to be read from the software simulator 100 during one calculation cycle of the software simulator 100. Since it is possible to read and rewrite a specific value (interrupt status) of the high-speed response register 102 in the SILS environment, the addition of the microcomputer peripheral model 111 to the SILS environment expands the software verification area and suppresses the decrease in simulation speed. can. That is, since the calculation cycle does not have to be changed, the calculation load on the software simulator 100 does not increase, and by localizing the simulation of the microcomputer peripheral model 111 with a large calculation load, an increase in the calculation load can be suppressed.

In addition, since the high-speed response register 102 that can rewrite the value of the high-speed response register 102 by writing to the capture register 112 is provided on the software simulator 100 side, the expected value will not be returned when the registers are read in the next cycle. It is possible to prevent the occurrence of errors due to

In addition, the microcomputer peripheral model 111 outputs the register value at the time of interrupt processing instruction from the capture register 112 to the software simulator 100 during interrupt processing, so that speed reduction due to shortening of the synchronization cycle can be suppressed.

In addition, the microcomputer peripheral model 111 selects a capture register 112 that holds a register value when an interrupt instruction is given to the software simulator 100, and selects a register value held in the capture register 112 during interrupt processing and outputs it to the software simulator 100. Since the selector 113 is provided, it is possible to eliminate the need for synchronization at fine timings separate from the operation timings of the software, and to arbitrarily set the synchronization timings.

It should be noted that the present invention is not limited to the embodiments described above, but includes various modifications and equivalent configurations within the scope of the appended claims. For example, the above-described embodiments have been described in detail for easy understanding of the present invention, and the present invention is not necessarily limited to those having all the described configurations. Also, part of the configuration of one embodiment may be replaced with the configuration of another embodiment. Moreover, the configuration of another embodiment may be added to the configuration of one embodiment. Further, additions, deletions, and replacements of other configurations may be made for a part of the configuration of each embodiment.

In addition, each configuration, function, processing unit, processing means, etc. described above may be realized by hardware, for example, by designing a part or all of them with an integrated circuit, and the processor realizes each function. It may be realized by software by interpreting and executing a program to execute.

Information such as programs, tables, and files that implement each function can be stored in storage devices such as memories, hard disks, SSDs (Solid State Drives), or recording media such as IC cards, SD cards, and DVDs.

In addition, the control lines and information lines indicate those considered necessary for explanation, and do not necessarily indicate all the control lines and information lines necessary for mounting. In practice, it can be considered that almost all configurations are interconnected.

100: software simulator 101: verification target software 102: high-speed response register 110: microcomputer peripheral simulator 111: microcomputer peripheral model 112: capture register 113: selector 114: normal register 120: plant simulator 121: plant model 320: software simulation processing 330 : Model simulation processing 340: Interrupt event 510: CPU core 511: Microcomputer peripheral 512: Internal bus

Claims (6)

A simulation device,
A first simulator that simulates the operation of software executed by a microcomputer, and a second simulator that has a calculation cycle different from that of the first simulator,
A microcomputer peripheral model indicating the operation of a peripheral device to be verified by the microcomputer is arranged in the second simulator,
The first simulator has a first register capable of reading a register value to be read from the microcomputer peripheral model during a calculation period of the first simulator,
The simulation apparatus, wherein the first register is capable of reading and rewriting a specific value during one cycle of calculation of the first simulator. The simulation device according to claim 1,
The simulation apparatus, wherein the microcomputer peripheral model outputs a register value at the time of instructing the interrupt processing to the first simulator during interrupt processing. The simulation device according to claim 1,
The microcomputer peripheral model is
a second register holding a register value at the time of an interrupt instruction to the first simulator;
and a selection unit that selects the register value held in the second register and outputs the register value to the first simulator during interrupt processing. The simulation device according to any one of claims 1 to 3,
The simulation device, wherein the second simulator has the microcomputer peripheral model and the plant model. The simulation device according to any one of claims 1 to 3,
A simulation apparatus, wherein the second simulator is provided separately from a simulator in which the plant model is provided. A simulation method by a simulation device,
The simulation device has a first simulator that simulates the operation of software executed by a microcomputer, and a second simulator that has a calculation cycle different from that of the first simulator,
arranging a microcomputer peripheral model indicating the operation of a peripheral device to be verified by the microcomputer separately from the first simulator;
The first simulator stores a first register value to be read from the microcomputer peripheral model as a response register that can be read during a calculation cycle of the first simulator and a write target from the microcomputer peripheral model. and a second register of
The simulation method is
the first simulator reads a value of a first register to be read from the microcomputer peripheral model from the response register during a calculation period of the first simulator;
A simulation method, wherein the first simulator is capable of reading and rewriting a specific value of the first register during one cycle of calculation of the first simulator.

Images