JP2010102372A - Data processor, verification system, data processor verification method - Google Patents

Abstract

<P>PROBLEM TO BE SOLVED: To provide a data processor and the like dynamically switching between a real machine and a simulator, or synchronizing events between cores to simulate a multi-core data processor. <P>SOLUTION: The data processor includes: an operation log recording means 23 recording event information such as input/output information, operation time information, or operation content information, which are associated with operation of a command, along with time information based on a predetermined time; a range registration means 25 registering a range for acquiring verification information in an operation log; a range detection means 29 referring to the operation log stored in the operation log storage means to detect that a running program has reached an event within the range; and an operation-verification switching means 27 starting acquisition of verification information when that the event within the range has been reached is detected. When the acquisition of the verification information in the range is completed, the operation-verification switching means terminates the acquisition of the verification information, and the program is executed again from the event at the time of completion. <P>COPYRIGHT: (C)2010,JPO&INPIT

Description

  The present invention relates to a data processing apparatus, a verification system, and a data processing apparatus verification method that output verification information for verifying the state of software or hardware.

  With respect to a data processing apparatus that executes a program or controls a system including a device or the like, a method of reproducing the same environment by a simulator may be used to analyze the performance of the program or the system and verify a logic failure. This simulator is designed to reproduce the environment of a data processing device (hereinafter referred to as an actual machine), for example, and to process all branches and logic that can be processed, for example, but resources are used to reproduce the execution environment. In many cases, it is slower than the actual machine under development, and it takes time that cannot be compared with the actual machine.

  With respect to this point, a technique for shortening the time spent for scheduling an instruction in a simulator that simulates an actual machine instruction in machine cycle units has been proposed (for example, see Patent Document 1). In Patent Document 1, when a loop is detected from a series of instructions, a target instruction sequence in a state in which the loop is detected is registered, and the execution instruction of this time and the registered instruction are compared and matched each time the loop circulates Describes an instruction schedule simulation method for skipping the instruction. Therefore, since the instruction is not scheduled if the state during the loop lap is the same, the time required for the simulation can be shortened.

  By the way, various events such as I / O, communication between cores, system calls, and interrupts occur in the actual machine. Generally, the actual machine adjusts or controls the occurrence timing of this event due to restrictions on the execution speed and monitoring functions of various devices. I can't do it. On the other hand, since the simulator can generate an event at a predetermined timing, the simulator can adjust the timing so that the event occurs at the same timing as the actual machine. However, since the simulator differs greatly in environment and execution speed from the actual machine, the event occurrence timing cannot be changed.

With regard to this point, a technique has been proposed in which reproduction information of an actual machine at a specified operating point is collected and provided to a simulator (see, for example, Patent Document 2). Patent Document 2 describes a logic test method for an actual machine that supplies a simulator with reproduction information when the actual machine is stopped immediately before a logic failure is detected by the actual machine. Therefore, the occurrence timing of the event can be acquired by an actual machine, and the cause of the logic failure can be analyzed over time by the simulator.
JP 2004-78599 A JP 62-2111739 A

  However, after the analysis by the simulator, the contents and time of the event that occurred in the actual machine are greatly deviated, and therefore there is a problem that it is difficult to resume the program after returning to the actual machine once the process is shifted to the simulator. That is, in the logic test method described in Patent Document 2, there is a problem that the actual machine and the simulator cannot be dynamically switched, and the program must be executed again from the beginning after eliminating the logic failure.

  By the way, in a multi-core data processing apparatus in which a plurality of CPU cores are mounted on one IC, each core can execute a different OS, or a different event can occur for each core, so the actual machine is multi-core. And it becomes difficult to reproduce the phenomenon with a simulator as the number of cores increases. Conventionally, there has not been proposed a technique for simulating the multi-core real machine in synchronization with events between cores.

  In view of the above problems, an object of the present invention is to provide a data processing device, a verification system, and a data processing device verification method capable of dynamically switching between a real machine and a simulator. It is another object of the present invention to provide a data processing device, a verification system, and a data processing device verification method capable of simulating a multi-core data processing device by synchronizing events between cores.

  In view of the above problems, the present invention is a data processing apparatus that reads a program AP defining instructions and data from a memory, executes the program AP on an operating system, and outputs verification information for verifying the state of software or hardware. An execution log recording means for recording event information such as input / output information, execution time information, or execution content information associated with execution of an instruction together with time information based on a predetermined time, and a range for acquiring verification information. Referring to the range registration means (for example, the reproduction section registration unit 25) to be registered in the execution log and the execution log stored in the execution log storage means, it detects that the program being executed has reached an event in the range. Range detection means (for example, the reproduction section detection unit 29), and execution of starting verification information acquisition when it is detected that a range event has been reached. And when the acquisition of the verification information of the range is completed, the execution / verification switching unit terminates the acquisition of the verification information and restarts the program from the event at the completion. It is characterized by performing.

  According to the present invention, the real machine mode is executed until the reproduction section and the reproduction section is executed in the simulation mode, so that the real machine and the simulator can be dynamically switched.

  In one embodiment of the present invention, a plurality of OSs are operated by a plurality of CPUs, or a single OS is operated by a plurality of CPUs, and the execution log recording unit records event information for each CPU. The detection means waits for each CPU to reach the event of the event information at the same time, and detects that the CPU has reached the range or the front thereof.

  According to the present invention, since each CPU waits until the event of the event information at the same time arrives, it is possible to switch to the simulation mode by synchronizing the events between the cores.

  It is possible to provide a data processing device, a verification system, and a data processing device verification method that can dynamically switch between a real machine and a simulator. It is possible to provide a data processing apparatus, a verification system, and a data processing apparatus verification method capable of simulating a multi-core data processing apparatus by synchronizing events between cores.

  Hereinafter, the best mode for carrying out the present invention will be described with reference to the accompanying drawings.

  FIG. 1 is a diagram conceptually illustrating a verification procedure of the data processing apparatus 100 according to the present embodiment. The data processing apparatus 100 includes a plurality of CPU cores or CPUs, for example, a so-called multi-core system or multi-CPU (hereinafter simply referred to as multi-core system) having a core 1 to a core n (n ≧ 2). Computer. Each core executes OS_A to OS_X (the OS executed by each core is not fixed), and various applications (hereinafter referred to as AP) 1 to n are executed on the OS. Here, since the data processing apparatus 100 includes an I / O device (device driver), specific hardware (IC for image recognition), and the like, in this embodiment, the core, OS, AP, etc. including the hardware are included. May be referred to as a system.

<First phase>
(1) The data processing apparatus 100 records events processed for each core and each OS in time series in association with time (hereinafter, the recorded information is referred to as an execution log). The execution log can be edited as will be described later.

  Here, an event is an AP and OS to be executed, and if it is an AP, an event, operation information input / output, data input / output, a function to be executed, error information, a system call, etc. are events. Processes to be executed, inter-core communication, data input / output, used device driver, memory allocated to AP, and the like are events. Further, for example, the event “execution function” of the AP is an instruction, data, etc. to be executed, and for example, the event “inter-core communication” of the OS is an event of communication issue time, communication end time, communication result, etc. It becomes. Therefore, the events can be managed hierarchically, and it is possible to set up to what level of events are included in the execution log. For example, when a user sets a hierarchy by level, it can be set to record up to an event of a hierarchy associated with that level in the execution log or to record only a predetermined event.

  In the present embodiment, there are a mode in which the data processing apparatus 100 switches between the actual machine mode and the simulation mode, and a mode in which a simulator (another computer) is prepared separately from the data processing apparatus 100. The data processing apparatus 100 or simulator in the simulation mode outputs verification information for verifying the state of software or hardware.

  Since the data processing apparatus 100 executes the OS and AP as time elapses from the time of activation, events are recorded in chronological order based on the activation time. Therefore, even if there is a difference in execution speed between the real machine mode and the simulation mode, and even if there is a difference in execution speed between the data processing device and the simulator, a similar event will occur over time.

  (2) Therefore, the user can register an event to be verified in the execution log. You may register only one event that you want to verify, but you can specify the time series of event ranges (hereinafter referred to as the reproduction interval), for example, by specifying the start time and end time so that the event you want to reproduce at the time of verification is included. Events to be verified can be registered. An event to be reproduced may be designated and a predetermined time before and after that may be automatically registered.

  (3) By the way, when reproducing this reproduction section at the time of verification, in principle, the data processing apparatus 100 must be operated until the start time of the reproduction section. However, when all the execution logs are executed in the simulation mode or the simulator. Since it may be necessary to elapse for a long time until the event in the reproduction section is reached, it is preferable to checkpoint regularly and irregularly and store snapshot information. The snapshot information is information for reproducing the state of the actual machine, and is, for example, memory contents, PSW (processor status word), PC (Program Counter), and the like. If this snapshot information is stored, the AP can be executed by tracing the event from the check point immediately before the reproduction section.

<Second phase>
When the data processing apparatus 100 is activated, the reproduction section is reached over time.

  (4) When this reproduction section is detected, as will be described later, a phenomenon that each core does not always reach the same event at the same timing as the actual machine occurs as a phenomenon peculiar to the multi-core system. Therefore, at the time of verification, it waits until the core that has reached the specified reproduction interval earliest reaches the reproduction interval specified by other cores, and when all cores reach the specified reproduction interval, It is preferable to execute the AP while the core is synchronized.

  (5) If snapshot information is stored, the check point before the reproduction section can be reached by the snapshot information.

  (6) When the data processing apparatus 100 switches between the real machine mode and the simulation mode, when the reproduction section is detected, the data processing apparatus 100 is switched to the simulation mode. In the simulation mode, well-known system function verification, performance measurement, evaluation, and failure investigation (hereinafter simply referred to as verification) are performed, and verification information is output. When verified by another computer (simulator), it is verified in the simulated environment of the simulator.

  (7) When the reproduction section ends, the data processing apparatus 100 returns to the real machine mode. Since each core is synchronized in the reproduction section, all the cores are synchronized and return to the real machine mode. When the simulator verifies, the process shifts to the data processing apparatus 100. Thereafter, the data processing apparatus 100 executes the processing after the reproduction section as an actual machine. If there is a reproduction section, the data processing apparatus 100 similarly switches to the simulation mode or shifts to the simulator and executes verification.

  Therefore, the data processing apparatus 100 of the present embodiment can efficiently verify the actual machine mode and the simulation mode, or dynamically switching between the data processing apparatus 100 and the simulator. In addition, since the events between the cores are synchronized with the multi-core system, even the data processing apparatus 100 of the multi-core system can accurately reproduce the events of the data processing apparatus 100.

  In this embodiment, a data processing apparatus 100 that switches between a simulation mode and an actual machine mode and verifies the system in the simulation mode will be described.

  FIG. 2 shows an example of a functional block diagram of the data processing apparatus 100. Each block is realized, for example, by the CPU executing the verification program 40 or hardware such as an ASIC (Application Specific Integrated Circuit).

  When implemented by the verification program 40, each function is provided as an aspect of an AP or OS, and the verification program 40 is executed on a predetermined OS executed by a predetermined core. That is, it is not necessary to limit the core and OS that execute the verification program 40. Moreover, since the core and OS which execute the verification program 40 acquire the event of the core which executes different OS, the verification program 40 can perform communication between cores and communication between OSs. The verification program 40 is stored in a hard disk drive or a flash memory (referred to as a hard disk or the like) at the time of shipment of the data processing apparatus 100, or downloaded from a predetermined server.

  The data processing apparatus 100 has an event recording unit 23 for storing an execution log, and the event recording unit 23 records events in the execution log storage unit 20. In addition, a hierarchy designation unit 21 is provided to set how much detailed events are recorded. For example, the hierarchy designating unit 21 displays selectable hierarchies on a display device serving as a user interface, and instructs the event recording unit 23 to record events according to the hierarchy selected by the user. In addition to the designation by such a hierarchy, the user can set events to be recorded individually.

  FIG. 3 shows an example of an execution log recorded in the execution log storage unit 20. The execution log is recorded for each OS and AP in association with each core. Further, it is recorded in time series in association with the time measured from the time of system activation (for example, switch-on, energization, activation start operation, etc.). Periodically or when a predetermined event such as an error occurs, the event of each core at that time is recorded.

  Since the time for recording the execution log is common to each core, the event of each core is recorded at the same time. Considering the delay until recording, etc., it is not always recorded at the exact same time (for example, accuracy of about 1 / 100th to 100th of a second), but the time difference that can occur between the cores is known. Because there is, it can be treated as an error.

  Further, the reproduction information recording unit 24 records the snap shop information in the snapshot information storage unit 30. With the snapshot information, the system status can be reproduced as well as functions such as so-called resume, suspend, and hibernation.

  The period designating unit 22 displays a field for inputting a period (for example, XX seconds, XX minutes) on the display device, so that the user can input a desired interval. The reproduction information recording unit 24 records snapshot information periodically for each input period and triggered by a predetermined event. The snapshot information is recorded along with the time as in the execution log. The time of the snapshot information is the time measured on the basis of the start-up time of the system, similar to the time of the execution log.

  The reproduction section registration unit 25 displays a field for inputting time or event on the display device, and registers the reproduction section in the execution log based on the time or event input by the user. In FIG. 3, the “reproduction section start point” to the “reproduction section end point” are the reproduction sections designated by the user. There may be a plurality of reproduction sections in one log. The data processing apparatus 100 enters the simulation mode from the start time of the reproduction section to the end time of the reproduction section, and enters the real machine mode otherwise.

  The execution log editing unit 26 allows the user to edit the execution log. There are two methods of editing, one of which is a method of changing the execution log recorded by the execution log recording unit. For example, if you want to generate an event such as an interrupt in multiple cores at the same time, but it is difficult to cause such a situation in the actual machine mode, the time of the event is synchronized with each core. Information can be changed. Another method is to add a new event. Since the execution log is recorded in time series as shown in FIG. 3, a new event can be added between the previous and subsequent times.

  The execution log editing unit 26 displays, for example, an execution log on the display device, receives an input of such editing by the user, and records it in the execution log storage unit 20. If the reproduction section registration unit 25 designates this event to be included in the reproduction section, it is possible to verify an event that is difficult to realize in the actual machine mode.

  The mode switching unit 27 switches between the simulation mode and the actual machine mode. There are two ways of switching: a method of switching automatically according to the start time and end time of the reproduction section, and a method of user operation. In the present embodiment, it is possible to dynamically switch between the actual machine mode and the simulation mode by adopting a mode in which switching is automatically performed mainly according to the reproduction section.

  Although the snapshot information may or may not be stored, the reproduction section detection is the same in either case. The reproduction section detection unit 29 compares each event one by one with the event in the execution log storage unit 20 while executing the AP, and notifies the mode switching unit 27 when the system reaches the event set in the reproduction section. Thereby, the mode switching unit 27 switches the system to the simulation mode.

  Here, even if an event set in the reproduction section is reached in a certain core, the same event may not be reached at the same time in another core. This is because, for example, data is accessed with a magnetic head in a hard disk, but it is difficult to reproduce data up to the position of the actual machine head, so the time is shifted every time the hard disk is accessed. Further, for example, when one side is communicating as in CSMA (Carrier Sense Multiple Access), when communication from the other side is not accepted, the time of subsequent processing is shifted if a communication collision occurs. Since such a process is executed independently by each core, a time lag of events between the cores cannot be avoided.

  Therefore, in the present embodiment, the reproduction section detection unit 29 detects the core that has reached the earliest event set in the reproduction section, and until each of the other cores reaches the event set in the reproduction section, Make the core wait. When each core reaches the event set in the reproduction section, the simulation mode is switched.

  There are two methods for reaching the reproduction section using the snapshot information. One is a method in which, when the reproduction section detection unit 29 detects a reproduction section, the system reproduction unit 32 reads the snapshot information that is temporally earlier than the start time of the reproduction section and sets it in the system. The second is that the reproduction section detection unit 29 detects a checkpoint that is earlier in time and closest to the start time of the reproduction section, and when the event reaches the checkpoint, the system reproduction unit 32 snaps. This is a method for setting shot information in a reading system. In this way, by using the snapshot information, for example, the time lag between the events between the cores can be reduced, and the reproduction of the events in the reproduction section becomes easy.

  Further, instead of dynamically switching, the data processing apparatus 100 can execute the AP only in the reproduction section (simulation mode only). In this case, the reproduction section detection unit 29 reads the disclosure time of the reproduction section from the execution log storage unit 20. Then, the system reproduction unit 32 reads the snapshot information that is temporally earlier than the start time read from the snapshot information storage unit 30 and sets it in the reading system. Thereby, since the reproduction section is reached early, the verification time can be shortened.

  Conversely, all of the APs may be executed in the simulation mode from the time of system startup. In this case, even if a reproduction section is set in the execution log, verification is performed without distinguishing between the reproduction section and other than the reproduction section, and the system is verified even if the reproduction section is not set in the execution log. That is, the mode switching unit 27 fixes the system to the simulation mode.

  Similar to the reproduction section detection unit 29, the synchronization unit 31 synchronizes all the cores in the simulation mode. That is, the core that has already reached the event is waited until all the cores arrive for each event, and when all the cores have reached the same event, the system verification unit 28 is allowed to resume the process. Therefore, the data processing apparatus 100 of the present embodiment can verify a system that accurately reproduces the events of each core of the multi-core system.

  In the simulation mode, the system verification unit 28 executes verification information for verifying the state of the system (software or hardware) for each core while executing the same OS and AP as in the actual machine mode, for example, an execution instruction, an error code. , CPU load factor, instruction execution speed, etc. are recorded.

  Regardless of whether or not snapshot information is stored, when the system event reaches the end time of the reproduction section, the reproduction section detection unit 29 notifies the mode switching unit 27, so that the mode switching unit 27 enters the real machine mode. Switch. When the verification of the reproduction section is completed, the inspection result output unit displays the verification information on a display device or stores it in a hard disk or the like.

  FIG. 4 is a flowchart showing a procedure in which the data processing apparatus 100 stores an execution log and snapshot information. The flowchart shown in FIG. 4 starts when the system is started, for example. A period for storing snapshot information is specified in advance from the period specifying unit 22, and a hierarchy of events to be stored is specified from the hierarchy specifying unit 21. In addition, the event is set so as to be periodically and predeterminedly detected and stored irregularly.

  When the system is activated (S10), each core executes the OS and AP based on the activation time. The reproduction information recording unit 24 reads the period for storing the snapshot information, for example, from the hard disk or the like in which the period specifying unit 22 stores the period information, and the event recording unit 23 sets the timing for recording the event and the hierarchy of the event to the hard disk or the like. Read from.

  Then, the event recording unit 23 determines whether to record the event based on the time or the event that has occurred (S30). When recording an event (Yes in S30), the event recording unit 23 acquires an event to be stored according to the designated hierarchy, and records it in the execution log storage unit 20 together with time information for each core (S40). .

  When the event is not recorded (No in S30), the reproduction information recording unit 24 determines whether or not it is time to record the snapshot information based on the period information (S50). When it is time to record the snapshot information (Yes in S50), the reproduction information recording unit 24 records the snapshot information in the snapshot information storage unit 30 (S60). When an event for recording snapshot information occurs, snapshot information is stored irregularly.

  The data processing apparatus 100 repeats the above processing for a predetermined time until the user stops or until a predetermined time elapses.

  When the processing of FIG. 4 is completed, the execution log is recorded in the execution log storage unit 20, and the snapshot information is recorded in the snapshot information storage unit 30, for example, the reproduction section registration unit 25 is operated by the user operation. Is specified. Alternatively, an event such as a predetermined error may be detected, and the reproduction interval registration unit 25 may automatically specify the reproduction interval. In this case, the end time of the reproduction section is determined after a predetermined time has elapsed from the start time or as a specific event.

  Further, the execution log editing unit 26 may edit the execution log by a user operation. This makes it possible to verify events that are unlikely to occur in a real machine (such as setting critical values that cause interrupts to occur simultaneously between cores, occurrence of branches that are unlikely to occur).

  FIG. 5 is a flowchart showing a procedure in which the data processing apparatus 100 dynamically switches between the real machine mode and the simulation mode and verifies the system. The flowchart in FIG. 5 starts when the user inputs a system verification operation, for example. In FIG. 5, a reproduction section is set, and a procedure for verifying only the reproduction section is shown. Since it operates as a real machine mode outside the reproduction section, the data processing apparatus 100 operates in the real machine mode at the start of the flowchart.

  First, the system is activated (S10). Then, the reproduction section detection unit 29 reads the start time of the reproduction section with reference to the execution log storage unit 20 (S110). Moreover, in order to reach the reproduction section early, the system reproduction unit 32 determines whether snapshot information is stored (S120). When the snapshot information is stored (Yes in S120), the system reproduction unit 32 reads the snapshot information at the closest time before the start time of the reproduction section (S130). Then, the state of the memory and each core is reproduced based on the snapshot information, and the system processing is resumed (S140).

  When the snapshot information is not stored, it is executed in the real machine mode from the start of the system to the start time of the reproduction section. However, since it can be executed in the real machine mode, it does not take an unrealistic time.

  Next, the reproduction section detection unit 29 determines whether any core has reached the event of the reproduction section (S150). That is, the core that reaches the event in the reproduction section earliest among the plurality of cores is detected. When any of the cores reaches the event in the reproduction section (Yes in S150), the reproduction section detection unit 29 waits for the core that has reached the event first until all other cores reach the same event (S160). . Since the event of each core in the reproduction section is stored at the same time, this “same event” indicates “the same time”.

  When all other cores reach the same event (Yes in S170), the mode switching unit 27 switches from the real machine mode to the simulation mode (S180). As a result, the system verification unit 28 starts system verification (S190). The synchronization unit 31 synchronizes all the cores (refers to the execution log, and when all the cores reach the event at the same time, permits the system to resume for the next event), the same OS as the actual machine mode Executes function verification, performance verification, failure investigation, etc. Thus, by synchronizing between cores, the same event as in the actual machine mode can be accurately reproduced for an event such as inter-core communication.

  During the simulation mode, the reproduction section detection unit 29 determines whether or not the end time of the reproduction section has been reached (S200). When each core reaches the end time of the reproduction section (Yes in S200), a verification result output unit. 33 outputs verification information (S210). Further, the mode switching unit 27 is notified of the end of the reproduction section, and switches from the simulation mode to the real machine mode (S220).

  Thereafter, the processing is repeated from step 130, and the data processing apparatus 100 switches to the simulation mode in the reproduction section, and switches to the real machine mode when the reproduction section ends. Therefore, the system can be verified while the mode is dynamically switched.

  As described above, the data processing apparatus 100 according to the present embodiment dynamically verifies the simulation mode and the real machine mode, thereby enabling the verification in the simulation mode thereafter according to the occurrence timing of the event in the real machine mode. Verification that combines the advantages of real machine mode and simulation mode is possible. In addition, by synchronizing events between cores, it is possible to accurately verify the system even in a multi-core system.

  In this embodiment, verification using a simulator 200 provided separately from the data processing apparatus 100 will be described. FIG. 6 is a diagram schematically illustrating a verification system 300 including the data processing apparatus 100 and the simulator 200.

  The simulator 200 is a computer. The simulator 200 is preferably provided with the same hardware as the data processing apparatus 100, but in many cases, it is difficult in practice, and the so-called emulator reproduces the core and OS of the data processing apparatus 100 to realize a pseudo environment. . Therefore, although the speed of AP execution by the simulator 200 often decreases, the AP operating on the data processing apparatus 100 can be executed on the same pseudo environment as the data processing apparatus 100. The data processing apparatus 100 and the simulator 200 are connected via a network, for example, and can communicate with each other.

  The functional block diagram is the same as that in FIG. 2, but the data processing apparatus 100 includes the hierarchy designation unit 21, the period designation unit 22, the event recording unit 23, the reproduction information recording unit 24, and the reproduction section detection unit 29. The simulator 200 includes the system verification unit 28, the reproduction section detection unit 29, the system reproduction unit 32, the synchronization unit 31, and the verification result output unit 33. The reproduction section registration unit 25 and the execution log editing unit 26 may have either the data processing device 100 or the simulator 200.

  Both the data processing apparatus 100 and the simulator 200 have the reproduction section detection unit 29. The data processing apparatus 100 needs to detect the reproduction section as in the first embodiment, and the simulator 200 detects the reproduction section from the checkpoint. It is because there is a case to do. Further, both the data processing device 100 and the simulator 200 can access the execution log storage unit 20 and the snapshot information storage unit 30.

  There are two methods for switching from the data processing apparatus 100 to the simulator 200. One is a method in which, when the data processing apparatus 100 executes processing as an actual machine and reaches the reproduction section, actual machine information for reproducing the state of the actual machine is transmitted to the simulator 200. Since the actual machine information is equivalent to the snapshot information, the simulator 200 can reproduce the system state.

  The other is a method using snapshot information. If the data processing apparatus 100 or the simulator 200 acquires the reproduction section, the simulator 200 can read the snapshot information that is temporally earlier than the reproduction section and set it in the system.

  Considering that the data processing apparatus 100 executes the AP until the reproduction section, the same processing is repeated in the data processing apparatus 100 and the simulator 200 from the check point to the start time of the reproduction section. In order to avoid this, the data processing apparatus 100 may notify the simulator 200 when it has executed up to the check point before the reproduction section, and the simulator 200 may read the snapshot information and set it in the system.

  If the simulator 200 is executed until the end time of the reproduction section, the simulator 200 transmits simulator information equivalent to the snapshot information to the data processing device 100. Thereby, the data processing apparatus 100 can execute the processing after the reproduction section.

  FIG. 7 is a sequence diagram illustrating a procedure in which the data processing apparatus 100 and the simulator 200 are dynamically switched to verify the reproduction section. The sequence diagram of FIG. 7 shows a procedure when snapshot information is not stored.

  First, the data processing apparatus 100 is activated (S10). Then, the reproduction section detection unit 29 reads the start time of the reproduction section with reference to the execution log storage unit 20 (S110). Next, the data processing apparatus 100 executes each process of the AP from the start of the system to the start time of the reproduction section.

  Then, the reproduction section detection unit 29 determines whether any core has reached the event of the reproduction section (S150). That is, the core that reaches the event in the reproduction section earliest among the plurality of cores is detected. When any of the cores reaches the event in the reproduction section (Yes in S150), the reproduction section detection unit 29 waits for the core that has reached the event first until all other cores reach the same event (S160). .

  When all other cores reach the same event, the data processing apparatus 100 transmits actual machine information to the simulator 200 (S210). Since the actual machine information is equivalent to the snapshot information, the reproduction information recording unit 24 acquires the actual machine information from the system.

  The simulator 200 receives the real machine information (S310), reproduces the state of the memory and each core on the simulated environment based on the real machine information, and restarts the system processing (S320).

  Next, the system verification unit 28 starts system verification (S330). That is, the synchronization unit 31 executes the same OS and AP on the pseudo environment while synchronizing all the cores, and performs function verification, performance verification, failure investigation, and the like.

  During verification of the system, the reproduction section detection unit 29 determines whether or not the end time of the reproduction section has been reached (S340), and when each core reaches the end time of the reproduction section (Yes in S340), a verification result output unit 33 outputs verification information (S350). Further, the simulator 200 transmits simulator information to the data processing apparatus 100 (S360).

  When the data processing device 100 receives the simulator information, the process proceeds to the processing of the data processing device 100, and the data processing device 100 repeats the processing from step S110. That is, the data processing apparatus 100 executes the AP until the next reproduction section, and executes the verification by the simulator 200 when the reproduction section is reached. Thus, even if the data processing apparatus 100 and the simulator 200 are separate, the system can be verified while dynamically switching the processing.

  Since the verification system 300 of this embodiment uses the dedicated simulator 200 in addition to the effects of the first embodiment, highly accurate verification information can be acquired.

It is a figure which illustrates notionally the verification procedure of a data processor. It is an example of a functional block diagram of a data processor. It is a figure which shows an example of the execution log recorded on an execution log memory | storage part. It is a flowchart figure which shows the procedure in which a data processor memorize | stores an execution log and snapshot information. It is a flowchart figure which shows the procedure in which a data processor switches a real machine mode and a simulation mode dynamically, and verifies a system. It is a figure which shows typically the verification system which has a data processor and a simulator. It is a sequence diagram which shows the procedure in which a data processor and a simulator change dynamically, and verify a reproduction area.

Explanation of symbols

DESCRIPTION OF SYMBOLS 20 Execution log memory | storage part 23 Event recording part 24 Reproduction information recording part 30 Snapshot information storage part 100 Data processing apparatus 200 Simulator 300 Verification system

Claims (7)

A data processing device that reads a program defining instructions and data from a memory, executes the program on an operating system, and outputs verification information for verifying the state of software or hardware,
Execution log recording means for recording event information such as input / output information, execution time information or execution content information along with execution of the instruction together with time information based on a predetermined time;
Range registration means for registering the time range for acquiring the verification information in the execution log;
Range detection means for referring to the execution log stored in the execution log storage means and detecting that the program being executed has reached the event in the range;
Execution / verification switching means for starting acquisition of the verification information when it is detected that an event in the range has been reached,
When the acquisition of the verification information in the range is completed, the execution / verification switching unit ends the acquisition of the verification information, and causes the program to be executed again from the event at the completion.
A data processing apparatus. Run multiple operating systems with multiple CPUs, or run one operating system with multiple CPUs,
The execution log recording means records the event information for each CPU,
The range detecting means waits for each of the CPUs to reach the event of the event information at the same time, and detects that the event of the range has been reached.
The data processing apparatus according to claim 1. When the execution / verification switching unit starts acquiring the verification information,
Synchronizing means for allowing the CPUs that have already reached the event to wait until all the CPUs have reached the same time information event, and permitting processing for the next event when all the CPUs have reached the same event Having
The data processing apparatus according to claim 2. Reproduction information recording means for recording reproduction information that reproduces the state of the software and the hardware together with the time information periodically or based on the event information;
Reproduction means for reading out the reproduction information nearest and temporally before the range, and reproducing the state of the software and the hardware,
From the state reproduced by the reproduction means, the range detection means detects that the event of the range has been reached,
The data processing device according to claim 1, wherein the data processing device is a data processing device. Having an execution log editing means for changing the event information or adding new event information to the execution log;
The data processing device according to claim 1, wherein the data processing device is a data processing device. A data processing device that executes a program that defines instructions and data stored in a memory, and a hardware and software pseudo-environment of the data processing device are generated, the program is executed, and the software or the hardware A verification system having a simulator for outputting verification information for verifying a state,
The data processing device includes:
Execution log recording means for recording event information such as input / output information, time information, or execution content information associated with execution of the instruction together with time information based on a predetermined time;
First transmission means for transmitting the execution log to the simulator;
Range registration means for registering the range for acquiring the verification information in the execution log;
Range detection means for referring to the execution log stored in the execution log storage means and detecting that the program being executed has reached the event in the range;
And second transmission means for transmitting data processing device information for reproducing the software and the hardware state to the simulator when the range detection means detects that the event of the range has been reached. And
The simulator
Reproducing means for reproducing the software and the hardware state based on the data processing apparatus information,
The acquisition of the verification information is started from the state reproduced by the reproduction means, and when the acquisition of the verification information in the range is completed, simulator information for reproducing the state of the software and the hardware is obtained from the data processing device. Send to
A verification system characterized by that. A data processing device verification method for outputting verification information of software or hardware status of a data processing device that reads and executes a program defining instructions and data from a memory,
Execution log recording means, event information such as input / output information, execution time information or execution content information accompanying the execution of the instruction, together with time information based on a predetermined time, an execution log recorded in time series, Recording in storage means;
A range registering unit for registering a range in which the verification information is acquired in the execution log;
A range detecting means referring to the execution log stored in the execution log storage means to detect that the program being executed has reached an event in the range;
When it is detected that an event in the range has been reached, the execution / verification switching unit starts acquiring the verification information; and
When the acquisition of the verification information in the range is completed, the execution / verification switching unit ends the acquisition of the verification information, and executes the program again from the event at the completion;
A data processing device verification method comprising:

Images