WO2012070137A1 - プロセッサ、電子制御装置、作成プログラム - Google Patents

プロセッサ、電子制御装置、作成プログラム Download PDF

Info

Publication number
WO2012070137A1
WO2012070137A1 PCT/JP2010/071049 JP2010071049W WO2012070137A1 WO 2012070137 A1 WO2012070137 A1 WO 2012070137A1 JP 2010071049 W JP2010071049 W JP 2010071049W WO 2012070137 A1 WO2012070137 A1 WO 2012070137A1
Authority
WO
WIPO (PCT)
Prior art keywords
core
execution
instruction
processor
program
Prior art date
Application number
PCT/JP2010/071049
Other languages
English (en)
French (fr)
Inventor
本谷　謙治
Original Assignee
トヨタ自動車株式会社
Priority date (The priority date is an assumption and is not a legal conclusion. Google has not performed a legal analysis and makes no representation as to the accuracy of the date listed.)
Filing date
Publication date
Application filed by トヨタ自動車株式会社 filed Critical トヨタ自動車株式会社
Priority to PCT/JP2010/071049 priority Critical patent/WO2012070137A1/ja
Priority to JP2012545575A priority patent/JP5532144B2/ja
Priority to EP10859993.7A priority patent/EP2645254A4/en
Priority to US13/885,495 priority patent/US20130246736A1/en
Publication of WO2012070137A1 publication Critical patent/WO2012070137A1/ja

Links

Images

Classifications

    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F15/00—Digital computers in general; Data processing equipment in general
    • G06F15/76—Architectures of general purpose stored program computers
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/28—Error detection; Error correction; Monitoring by checking the correct order of processing
    • G—PHYSICS
    • G06—COMPUTING; CALCULATING OR COUNTING
    • G06F—ELECTRIC DIGITAL DATA PROCESSING
    • G06F11/00—Error detection; Error correction; Monitoring
    • G06F11/36—Preventing errors by testing or debugging software
    • G06F11/362—Software debugging
    • G06F11/3636—Software debugging by tracing the execution of the program

Definitions

  • the present invention relates to a processor that executes a program, and more particularly to a processor that stores an execution history of a program executed by a plurality of cores or CPUs.
  • Each electronic control device executes various programs to control various on-vehicle devices.
  • the vehicle manufacturer fully verifies the in-vehicle device including the program and then ships it, but continuously improves the completeness of the program and the in-vehicle device based on information obtained from the vehicle after shipment.
  • a function for recording the execution history of the program may be installed in the electronic control unit.
  • PC program counter
  • a large amount of storage capacity is required to store the PC value for each step. If a memory with sufficient storage capacity is not prepared, the execution history of the steps (a past time) required for the analysis is erased by overwriting. It is easy to occur.
  • a memory with sufficient storage capacity for PC recording is prepared, the number of objects to be analyzed increases, which causes the inconvenience that it becomes difficult to specify the cause of an event and what processing has been performed during the analysis. .
  • Patent Document 1 discloses an address trace apparatus that writes a branch instruction or a microinstruction address in the vicinity thereof to a trace register when the branch condition indicates success.
  • Patent Document 2 discloses a trace method in which it is checked whether or not a branch address has already been stored when a branch occurs, and the branch address is written in the trace register only when the branch is not traced.
  • an object of the present invention is to provide a processor capable of recording an execution history effective for event occurrence analysis in a processor equipped with a multi-core or multi-CPU type CPU.
  • the present invention is a processor in which a plurality of cores each execute a program, and when the first core executes an execution history recording instruction described in an execution history recording point of the program, the series of instructions of the first core are First self-core execution point acquisition means for acquiring first code block information instructed by one address, and an instruction executed by the second core when the first core executes the execution history recording instruction
  • the first other core execution point acquisition means for acquiring the first execution address information, the first code block information and the first execution address information are associated with each other and stored in time series in the shared memory Execution point information recording means.
  • a processor capable of recording an execution history effective for event occurrence analysis can be provided.
  • FIG. 1 It is an example of the figure which illustrates typically the memory
  • FIG. 3 is an example of a diagram schematically illustrating storage of code block addresses in one ring buffer by two cores.
  • An example of a block diagram of a multiprocessor microcomputer is shown.
  • FIG. 3 is an example of a flowchart illustrating a procedure in which two processors 1 and 2 store data in a code block address of a ring buffer 40, respectively.
  • An example of the hardware block diagram of a processor is shown.
  • FIG. 1 is an example of a diagram for schematically explaining execution history storage by the processor 100 of the present embodiment.
  • the processor 100 according to the present embodiment has one type of function called EDR (Event Dialog Recorder) that records diagnostic information for later analysis by a vehicle manufacturer or the like when any event occurs.
  • EDR Event Dialog Recorder
  • Core 1 executes program 1 and core 2 executes program 2 separately.
  • the instruction of the program 1 being executed by the core 1 is specified by the pointer 1
  • the instruction of the program 2 being executed by the core 2 is specified by the pointer 2.
  • the processor 100 of this embodiment stores, for example, a code block address (which will be described later) indicated by the pointer 1 or the pointer 2 when executing a branch instruction. Since the code block is a block of several instructions, the storage capacity of the execution history can be suppressed rather than storing the value of the program counter.
  • the core 1 executes a branch instruction
  • the core 1 stores not only its own code block address but also the execution point of the core 2 (indicated by the pointer 2). By doing this, it is possible to specify which instruction was executed by the core 2 when the core 1 executed the branch instruction. The same applies to the core 2.
  • the core 2 executes a branch instruction
  • the core 2 stores not only its own code block address but also the execution point of the core 1.
  • the core 1 and the core 2 repeatedly store the execution history in the shared ring buffer 40 in time series and overwrite the oldest one.
  • the core 1 and the core 2 repeatedly store the execution history in the shared ring buffer 40 in time series and overwrite the oldest one.
  • the processor 100 of this embodiment is mounted on an electronic control unit (ECU). It is assumed that the electronic control device of the present embodiment provides a single function that has conventionally been provided separately by a plurality of electronic control devices. The integration of the functions of the electronic control device leads to a reduction in development costs because the number of ECUs is reduced, and as a result, it can be expected that the price competitiveness of the vehicle is improved. Further, although depending on the design of the processor 100, if the developed program can be installed in the electronic controller after function integration without greatly modifying it, it can be expected that the development cost of the program will be greatly reduced.
  • integrating a plurality of functions into the electronic control unit means that instructions for providing the plurality of functions are executed in parallel, and thus the cause when a problem occurs is complicated. It is also expected.
  • the processor 100 can appropriately record diagnostic information even if a multi-core or multi-CPU is mounted on a function-integrated electronic control unit.
  • the functions to be integrated include, for example, integrating the electronic control devices of the control system and the information processing system, such as a CAN gateway and a hybrid ECU, in addition to the electronic control devices.
  • the execution history recording method of the present embodiment is particularly effective for analyzing a program of a control system with high real-time characteristics (for example, hybrid control, engine control, brake control, transmission control, etc.).
  • FIG. 2 shows an example of a hardware configuration diagram of the processor 100.
  • the processor 100 includes a core 13 (core 1 and core 2 when distinguished), a DMAC 15, an SDRAM 16, an I / O bridge 17, and a ROM 18 connected via a multilayer bus 19.
  • Each core has a CPU 12, an INT 15, and a RAM 14. That is, the core 1 has a CPU 1, INT 1, and RAM 1, and the core 2 has a CPU 2, INT 2, and RAM 2.
  • the core 1 and the core 2 may be AMP (Asymmetric Multi-processing) that assigns a predetermined OS and task to each core, and the core 1 and the core 2 execute a common OS and share a memory (for example, SDRAM 16).
  • SMP Symmetric Multi-processing
  • BMP Bit Multi-processing having an intermediate property between AMP and SMP may be used.
  • the programs 1 and 2 in FIG. 1 may be the same program or may be independent programs. Even in the case of an independent program, the EDR of the present embodiment is effective when the execution of one instruction is likely to affect the execution of the other instruction. Therefore, even if the implementation of the core 11 is AMP, the processing of the program 1 Relationship that gives some influence on core 2 or processing of program 2 (uses computation results, program 1 and program 2 have execution order dependency, program 1 and program 2 synchronize, etc.) It is assumed that
  • CPUs 1 and 2 perform operations such as IFU (Instruction Fetch Unit), DEC (DECoder), RF (Register Fetch), REG (REGister), LSU (Load Store Unit), SH (Shifter), ALU, MUL, and FPU, respectively. It has a circuit and can execute one instruction in one clock by pipeline control.
  • the RAM 1 is a memory dedicated to the core 1 (primary cache), and the RAM 2 is a memory dedicated to the core 2 (primary cache).
  • a snoop controller (SNC) (not shown) monitors update of data in RAM 1 and RAM 2 and communicates update data between RAM 1 and RAM 2.
  • INT1 and INT2 control inter-CPU interrupts and control transmission / reception of parameters and the like from core 1 to core 2 or from core 2 to core 1.
  • INT1 and INT2 can also send and receive parameters and the like using RAM1, RAM2, or SDRAM 16 as a shared communication memory.
  • the parameter communication between the cores using INT1 and INT2 is a hardware implementation.
  • the core 1 and the core 2 can communicate with each other using an API for inter-core communication provided by the OS.
  • the DMAC 15 receives a request from the core 1 and the core 2 and reads the program 20 into the SDRAM 16, RAM 1, RAM 2, arbitrates a memory access request from a peripheral device, and also from the I / O bridge 17 to the SDRAM 16 or from the SDRAM 16. Data is transferred to the I / O bridge 17 without going through the cores 1 and 2.
  • the SDRAM 16 is a memory (secondary cache) for providing the program 20 or data when a miss occurs in the RAM 1 or the RAM 2 while the core 1 and the core 2 execute the program 20. At least a part of the SDRAM 16 is shared by the core 1 and the core 2.
  • the ROM 18 stores a characteristic program 20 that provides functions after integration.
  • the generation factor storage program is embedded in the program 20.
  • the embedding method is also one of the features of this embodiment.
  • the ROM 18 may be disposed outside the processor 100, and stores an OS and a device driver (platform) according to the capacity.
  • the I / O bridge 17 converts the frequency, voltage value, and the like between the multi-layer bus 19 and the I / O bus 21.
  • Various I / Os 22 are connected to the I / O bus 21.
  • the I / O 22 is an interface that connects the processor 100 and an external device. For example, a CAN controller, various actuators, sensors, switches, and the like are connected to the I / O 22.
  • FIG. 3 is an example of a diagram illustrating a method for generating the program 20.
  • the program 20 is generated by embedding the generation factor storage program 33 in the program binary code 32.
  • the extraction processing unit 35 and the code embedding unit 36 are functions provided by the creation program 30.
  • the computer that executes the creation program 30 may be a general PC (personal computer) including a CPU, RAM, ROM, HDD, input / output device, and the like.
  • the program binary code 32 is a program after function integration, and is a program before including a function (EDR function) for recording an execution history provided by the processor 100.
  • EDR function a function
  • 4A shows an example of a part of the program binary code 32
  • FIG. 4B is a diagram for explaining the correspondence between the branch condition and the program binary code 32.
  • FIG. 4 shows the object code in assembly language so that it can be read.
  • C language there are many descriptions in which a group of functions is described by a function name and " ⁇ code ⁇ " and the function is called from the main function. When such a description is compiled, the function is labeled. Is granted. Therefore, it can be considered that the assembler code immediately before the next label from the label in FIG. 4 corresponds to a function or a group of functions.
  • If-Else statement, Switch statement, While statement, etc. are prepared as control statements, there is a case where a function is called when a certain condition is met or not met.
  • Such a description of the source code is described as “Jmp label name” in the assembler code.
  • the branch condition (diamond) described in the control statement is satisfied or not satisfied, the instructions are not executed in the order of addresses.
  • the flow of this process is represented by “Jmp” in the assembler code. Therefore, it can be considered that the processing (function) differs greatly before and after the description of “Jmp”.
  • “Jmp” may be referred to as a conditional branch instruction.
  • the creation program 30 stores the conditional branch instructions in the conditional branch instruction list 31 in advance, or describes them in the HDD or the creation program 30.
  • “Jmp” is a conditional branch instruction.
  • the label name may be registered in the conditional branch instruction list 31.
  • conditional branch instruction it is also effective to register “Call” in the conditional branch instruction list 31 because the instruction “Call” is the same in the sense that the execution history changes to call a subroutine. .
  • code blocks can be specified in the conditional branch instruction list 31 with sufficiently fine granularity.
  • making the code block finer means increasing the number of places to be embedded, as will be described below, and thus increasing the overhead of the program. For this reason, it is preferable to adjust the granularity of code blocks (branch instructions and labels registered in the conditional branch instruction list 32) according to the processing capability of the processor 100.
  • code block address is the address of the conditional branch instruction, but in the sense of the address indicated by the pointer, it is a subordinate concept of the execution point that means the address of the instruction being executed. In this embodiment, both are distinguished, but there is no big difference.
  • the extraction processing unit 35 reads out the operation code (mnemonic) of the program binary code 32 one by one and registers it in the code block address list 34 when it matches the conditional branch instruction list 31.
  • FIG. 5 is a diagram showing an example of the code block address list 34.
  • the extraction processing unit 35 reads the assembler code in the order of addresses, and registers the addresses “0x30, 0x50, 0xC0, 0xE0” that match the conditional branch instruction list 31 in the code block address list 34.
  • Each of these addresses becomes an address designating each code block, and is used for recording an execution history. This address is a relative address from the beginning of the program.
  • the code embedding unit 36 in FIG. 3 embeds the generation factor storage program 33 in the program binary code 32.
  • the occurrence factor storage program 33 is a conventional program that records an execution history, and can record or stop the recording of an execution history with an event as a trigger.
  • the generation factor storage program 33 stores the address of the instruction being executed. Since the processor 100 provides this function, it is assumed that the description embedded in this embodiment is, for example, a description “Call SAVE_Log”.
  • the code embedding unit 36 describes “Call SAVE_Log” before the address registered in the code block address list 34.
  • FIG. 6 shows an example of the program binary code 32 in which the generation factor storage program 33 is embedded. “Call SAVE_Log” is described before the address “0x30, 0x50, 0xC0, 0xE0”.
  • the core 1 or the core 2 executes “Call SAVE_Log”
  • the address of the next instruction is stored in the ring buffer 40 as a code block address.
  • the address of the next Jmp instruction is already set in the PC (program counter), so the address of the next instruction is the current PC value.
  • the program 20 created by the creation program 30 in this way is stored in the ROM 18 of the processor 100 and shipped with the vehicle, or overwritten after shipment.
  • FIG. 7 is an example of a flowchart illustrating a procedure in which the program 20 stores an execution history in the case of a single core.
  • the procedure of FIG. 7 is repeatedly executed when the ignition of the vehicle is turned on (or in the case of a hybrid vehicle or an electric vehicle, the main system is turned on).
  • the program 20 monitors whether or not an event has occurred in the vehicle (S10). Typical events are the deployment of an airbag, the detection of G above a threshold, the driver pressing a call button to an emergency support center, and so on. In other words, an event is that a situation where there is a high possibility that a relatively large abnormality has occurred in the vehicle is detected.
  • the electronic control device on which the processor 100 is mounted detects an event
  • the program 20 detects the event.
  • the event is notified to the processor 100 by CAN communication or the like.
  • the processor 100 executes the program 20 in the order of addresses (S20).
  • the processor 100 executes “Call SAVE_Log” embedded in the program 20 (S30), it stores the code block address in the ring buffer 40 (S40).
  • the program 20 does not actively determine whether or not the code block address storage point has been reached, but as a result, the code block address is stored only when the code block address is reached.
  • the program 20 stores “0x40” at the address where the oldest code block address of the ring buffer 40 is stored. If the code block address is known, a group of function codes can be specified, so that an execution history can be efficiently recorded with a small capacity of the ring buffer 40. Note that the address of the ring buffer 40 in which the oldest code block address is stored is indicated by a pointer.
  • step S10 since the processing returns to step S10, the program 20 repeatedly stores the code block address until an event occurs.
  • the program 20 calls an event processing unit (for example, shown in FIG. 8) corresponding to the event occurrence, stores the execution point in the ring buffer 40, and thereafter Is stopped (S50). In this way, the execution path of the program 20 before the event occurrence can be saved.
  • the event processing unit sets a flag indicating recording prohibition in the ring buffer 40 or sets a predetermined value (for example, NULL or FFFF) is set in advance. “Call SAVE_Log” embedded in the program 20 determines whether or not to record the code block address based on the flag and pointer values of the ring buffer 40, thereby stopping the storage of the code block address after the occurrence of the event. be able to.
  • FIG. 8 is an example of a functional block diagram of each core
  • FIG. 9 is an example of a flowchart showing a procedure for storing an execution history by the program 20 in the case of multi-core
  • FIG. 3 is an example of a diagram schematically illustrating storage of code block addresses in a ring buffer 40.
  • the core 1 and the core 2 include, as functions included in “SAVE_Log”, their own core execution point acquisition units 42 and 46, other core execution point acquisition units 43 and 47, and a ring buffer recording unit 44. , 48.
  • event processing units 45 and 49 are provided as processing corresponding to event occurrence.
  • the ring buffer 40 is stored in a shared memory (RAM1, RAM2 or SDRAM 16).
  • the pointer 41 is maintained at the same value in each of the core 1 and core 2 registers, or is shared by the shared memory.
  • the pointer 41 indicates the address where the code block address is to be stored next in the ring buffer 40.
  • Step S40 of FIG. 9A is Performed
  • the own core execution point acquisition unit 42 acquires an execution point serving as a code block address.
  • the execution point may be a PC value.
  • the own core execution point acquisition unit 42 acquires the code block address “0x11” and notifies the ring buffer recording unit 44 of the code block address. .
  • the other core execution point acquisition unit 43 of the core 1 inquires the execution point of the core 2 from the core 2 and acquires the execution point of the core 2.
  • the other-core execution point acquisition unit 43 acquires an execution point from the core 2 using a hardware or software communication method between cores. Assuming that the core 2 is executing an instruction at the address “0x07”, the other core execution point acquisition unit 43 acquires the address “0x07” and notifies the ring buffer recording unit 44 of it.
  • the ring buffer recording unit 44 stores the code block address of the core 1 and the execution pointer of the core 2 in association with the address of the ring buffer 40 indicated by the pointer 41 (in a pair).
  • Corresponding storage means a storage mode in which one can be uniquely identified from the other, storing in the upper byte and lower byte of a predetermined address, storing in consecutive addresses, and the same identification number. It means attaching.
  • the ring buffer recording unit 44 increases the value of the pointer 41 by one (only the address length), and returns it to the initial value when the maximum address of the ring buffer 40 is reached.
  • core 1 conditional branch core 1x0x11, core 2 0x07
  • Core 1 conditional branch makes it clear which core recorded
  • Core 1 0x11, Core 2 0x07 causes Core 2 to execute the 0x07 conditional branch instruction when Core 1 executes a 0x11 conditional branch instruction. It becomes clear that it was running.
  • step S40 of FIG.9 (b) is performed The procedure at the time of the core 2 performing step S40 is also the same.
  • the step executed by the core 2 reaches “Call SAVE_Log”
  • the own core execution point acquisition unit 46 acquires an execution point as a code block address.
  • the own core execution point acquisition unit 46 acquires the address “0x06” and notifies the ring buffer recording unit 48 of the address.
  • the other core execution point acquisition unit 47 of the core 2 inquires the execution point of the core 1 from the core 1 and acquires the execution point of the core 1.
  • the other core execution point acquisition unit 47 acquires the address “0x23” and notifies the ring buffer recording unit 48 of the address.
  • the ring buffer recording unit 48 stores the execution pointer of the core 1 and the code block address of the core 2 in association with the address of the ring buffer 40 indicated by the pointer 41.
  • the core 1 and the core 2 record the code block addresses in time series in one ring buffer 40, the relative execution order of the conditional branch instructions executed by the core 1 and the core 2 becomes clear. That is, only the core 1 stores the code block address in time series, and only the core 2 records the code block address. If the core 1 conditional branch instruction and the core 2 conditional branch instruction are taken out one by one at the time of analysis, the core It is difficult to determine which of the 1 conditional branch instruction and the core 2 conditional branch instruction is executed first. This is especially true for the ring buffer 40. Therefore, the execution history of the core 1 and the core 2 cannot be integrated and reproduced.
  • the processor 100 of this embodiment records the execution history of the core 1 and the core 2 in the same ring buffer 40 in time series even if the core 1 and the core 2 execute the conditional branch instruction independently.
  • the execution order of the conditional branch instruction of core 1 and the conditional branch instruction of core 2 becomes clear.
  • the execution order of the conditional branch instructions of the core 1 and the core 2 can be determined even if the core 1 and the core 2 record the code block address separately. There is an inconvenience that it increases and the capacity of the ring buffer 40 increases.
  • both the event processing unit 45 of the core 1 and the event processing unit 49 of the core 2 store code block addresses. In this case, it is considered that the two event processing units 45 and 49 start recording the code block address almost simultaneously. However, since access to the ring buffer 40 is controlled exclusively by hardware or software, whichever comes first The code block address is stored in order.
  • the event processing unit 45 of the core 1 executes a series of processes of the own core execution point acquisition unit 42, the other core execution point acquisition unit 43, and the ring buffer recording unit 44, and is referred to as “0x40” as an execution point.
  • the code block address is acquired, and an address “0x09” is acquired as the execution point of the core 2 and stored in the ring buffer 40.
  • “core 1 event occurrence: core 1 0x40, core 2 0x09” is recorded.
  • the event processing unit 49 of the core 2 executes a series of processes of the own core execution point acquisition unit 46, the other core execution point acquisition unit 47, and the ring buffer recording unit 48, and a code block “0x11” as an execution point An address is acquired, an address “0x50” is acquired as an execution point of the core 1, and stored in the ring buffer 40. As a result, “core 2 event occurrence: core 1 0x50, core 2 0x11” is recorded.
  • the event processing units 45 and 49 of the cores 1 and 2 that have previously recorded the code block address notify the other core of the completion of the recording.
  • the event processing units 45 and 49 of the cores 1 and 2 that have acquired the notification record that the other core has finished recording the code block address due to the event occurrence for example, by setting a flag to ON.
  • the event processing units 45 and 49 of the other core determine whether or not to stop the recording with reference to the flag when the recording of the code block address due to the event occurrence is completed. When it is determined that the recording can be stopped, the event processing units 45 and 49 stop the recording as in the case of the single core.
  • the code block address and the execution pointer due to the event occurrence are “core 1 event occurrence: core 1 ⁇ ⁇ 0x40, core 2 0x09” “core 2 event occurrence: core 1 0x50, core 2” It is recorded as “0x11”.
  • a vehicle manufacturer or a dealer service person reads the ring buffer 40 using an external tool.
  • the code block addresses are read in the order of addresses from the address next to the address recorded as “event occurrence” in the ring buffer 40.
  • the code block address is returned to the beginning and the recorded contents of the ring buffer 40 are recorded up to the address “event occurrence”
  • the execution history of the core 1 and the core 2 is obtained. Even if the information “event occurrence” is not recorded, the serviceman or the external tool can specify the address where the code block address at the time of the event is recorded by the address indicated by the pointer 41.
  • the service person or the like examines the execution history of the program 20 of the core 1 and the core 2 and determines whether or not the program 20 is executed in the scheduled order and whether or not there is an unexpected execution history. By such determination, it is possible to distinguish whether the event occurrence is caused by the program 20 or not, and it is possible to improve the identification accuracy of the cause of the event occurrence or to shorten the time until the identification.
  • Core 1 and core 2 general-purpose registers, flags, stack pointers, input value core 1 and core 2 have various registers. Not only general-purpose registers but also flags and stack pointers are types of registers.
  • the general-purpose register stores the value being calculated (temporarily stored for saving data during work). By storing this value together with the code block address, the service person can It is possible to infer whether or not the calculation result has affected the event occurrence.
  • the flag stores a value indicating an execution result when the CPU 1 or 2 executes a specific instruction. For example, the overflow flag is set to “1” when the digit overflows, the zero flag is set to “1” when the calculation result is zero, and the SF flag is set to “1” when the calculation result is a negative value. Therefore, by storing this value together with the code block address, it becomes possible for a service person or the like to infer whether or not an unexpected result has affected the event occurrence.
  • the stack contains the contents of the register when the function is executed, the address of the function, arguments, variables, etc. If this function calls another function, the stack contains the register of the called function. Contents, function addresses, arguments, variables, etc. are stored.
  • the stack pointer indicates the latest storage location of these pieces of information. Therefore, by storing the stack pointer together with the code block address, it becomes possible for a serviceman or the like to verify the execution history from the transition.
  • the input value is, for example, a detection value of a sensor input from the I / O 22, data received from another electronic control device, or the like.
  • the input value is stored in, for example, the SDRAM 16, RAM 1, RAM 2, or stored in the core 1 or core 2. Since the input value is a calculation target, storing this value together with the code block address enables a serviceman or the like to verify whether or not the input value is appropriate as a calculation target.
  • Branch destination information The code block address is the branch source address, but if the branch destination address is also recorded, the execution history can be recorded in more detail.
  • the branch destination address is described in the operand, for example, “Jmp a ELSE_STATE1”. Therefore, when the cores 1 and 2 execute “Call SAVE_Log”, not only the execution pointer but also the operand of the instruction of the execution pointer may be read and recorded together with the code block address.
  • the core 1 or the core 2 may interrupt each other, or the core 1 or the core 2 may receive an interrupt from another core (not shown).
  • INT1 and INT2 activate an interrupt handler according to the interrupt content (interrupt vector) and execute a predetermined process, so that the address of an instruction to be executed greatly changes even when an interrupt occurs.
  • interrupt vector interrupt vector
  • FIG. 11 shows an example of a configuration diagram of a multiprocessor microcomputer.
  • Processor 1 and processor 2 are connected via a bus.
  • the processors 1 and 2 only need to have one or more cores or CPUs.
  • the processor 1 has a ring buffer 40 for the processor 1
  • the processor 2 has a ring buffer 40 for the processor 2.
  • the reason why the ring buffers 40 are separated is that the degree of freedom of memory sharing is taken into consideration, and either one of the ring buffers 40 may be shared.
  • processors 1 and 2 communicate using inter-processor communication means such as a DMAC or a debug port. As a result, the processor 1 can obtain the PC value of the processor 2 and the processor 2 can obtain the PC value of the processor 1.
  • each processor has PC response tasks 1 and 2.
  • the PC response tasks 1 and 2 are tasks for recording the execution point of the own processor when the other processor executes “SAVE_Log”.
  • FIG. 12 is an example of a flowchart for explaining a procedure in which the two processors 1 and 2 store the code block addresses in the ring buffer 40, respectively.
  • the process of FIG. 12 differs from the process of FIG. 9 in step S40.
  • the own core execution point acquisition unit 42 acquires an execution point that is a code block address.
  • the own core execution point acquisition unit 42 acquires a code block address “0x40”, for example, and notifies the ring buffer recording unit 44 of the code block address.
  • the other core execution point acquisition unit 43 of the processor 1 inquires the execution point of the processor 2 using DMA communication or the like, and acquires the execution point of the processor 2. Assuming that the processor 2 is executing the instruction at the address “0x09”, the other core execution point acquisition unit 43 acquires the address “0x09” and notifies the ring buffer recording unit 44 of it.
  • the ring buffer recording unit 44 stores the code block address of the processor 1 and the execution pointer of the processor 2 in association with the address of the ring buffer 40 indicated by the pointer 41 (in a pair). As described above, as shown in the ring buffer 40 of the processor 1 in FIG. 11, “processor 1 conditional branch: processor 1x0x40, processor 2 0x09” is recorded.
  • the processor 2 generates an interrupt by receiving an execution point inquiry from the other core execution point acquisition unit 43 of the processor 1 and executes the PC response task 2.
  • the PC response task 2 of the processor 2 acquires an execution point that is a PC value.
  • the PC response task 2 inquires the execution point of the processor 1 using DMA communication or the like, and acquires the execution point of the processor 1. This execution point is equal to or around the code block address.
  • the other core execution point acquisition unit 43 of the processor 1 may notify the processor 2 of the execution point (in this case, equal to the code block address) when inquiring about the execution point.
  • the PC response task 2 of the processor 2 stores the code block address of the processor 1 and the execution pointer of the processor 2 in the ring buffer 40 in association with each other.
  • “processor 1 conditional branch: processor 1x0x40, processor 2 0x09” is recorded. That is, since a copy of the ring buffer 40 is obtained, the same information as when the processors 1 and 2 share the ring buffer 40 is obtained.
  • processors 1 and 2 store the same (or almost the same) execution history in the ring buffer 40 (S501).
  • the processors 1 and 2 store the same (or almost the same) execution history in the ring buffer 40 respectively, and when the processor 2 executes “SAVE_Log”, the processors 1 and 2 execute. The same (or almost the same) execution history is stored in the ring buffer 40, respectively.
  • the execution history can be recorded in association with each other not only in one processor but also in a multiprocessor equipped with a plurality of processors. If there are three or more processors, all the processors will only record the same execution history, and the execution procedure is the same as in the case of two processors.
  • FIG. 13 shows an example of a hardware configuration diagram of the processor 100.
  • the description of the same part as in FIG. 2 is omitted.
  • INT3 of the core 3 is connected to INT1 and INT2.
  • the core 3 is not responsible for the execution of the program 20 for control or the like, and executes a dedicated execution history recording program for recording the execution history.
  • FIG. 14 is an example of a flowchart showing a procedure for recording an execution history by the execution history program of the core 3.
  • the core 3 includes an instruction monitoring unit, an execution point acquisition unit, a ring buffer recording unit, and an event processing unit that are realized by executing the execution history program.
  • the instruction monitoring unit acquires the value of each instruction buffer (or instruction decoder) via INT1 to 3 every time the PC of core 1 and core 2 is updated, and the instruction executed by core 1 or core 2 is Jmp It is monitored whether or not it coincides with a previously registered instruction (the same as the conditional branch instruction list 31) (S110). If they match, the execution point acquisition unit is notified.
  • the execution point acquisition unit requests the code block address from the core 1 or core 2 that has executed the conditional branch instruction, and requests the execution pointer from the other core (S120).
  • the ring buffer recording unit stores the code block address and execution pointer acquired from the core 1 or core 2 in the ring buffer 40 (S130). By doing so, regardless of which of the core 1 and the core 2 executes the conditional branch instruction, the core 3 can record the code block addresses and the execution pointers of the core 1 and the core 2. Note that which core executed the conditional branch instruction is also recorded.
  • the processing of the event processing unit when an event occurs is the same as when there are two cores.
  • the event processing unit requests execution pointers from core 1 and core 2 (S150). And stored in the ring buffer 40 in association with each other (S160), and then recording is stopped (S170).
  • the creation program 30 does not need to embed “Call SAVE_Log” in the program 20, and the development cost can be reduced.
  • the processor 100 may have a core in addition to the cores 1 and 2. However, even if there are three or more cores, the processing procedure of each core does not change significantly. That is, when the core 3 executes “Call SAVE_Log”, the own core execution point acquisition unit of the core 3 acquires the address of the own core, and the other core execution point acquisition unit acquires the execution points from the core 1 and the core 2. .
  • the ring buffer recording unit of the core 3 stores the code block address of the core 3 and the execution points of the cores 1 and 2 in association with the address of the ring buffer 40 indicated by the pointer 41. The same applies to the cores 1 and 2.
  • the cores 1 and 2 need to execute the execution point of the core 3. Absent. For example, if cores 1 and 2 do not communicate at all (does not have INT13), if cores 1 and 2 are SMP and core 3 is AMP, or if cores 1, 2 and 3 are processed If you are running a program that does not affect each other at all (does not use computation results, program 1 and program 2 have no execution order dependency, program 1 and program 2 are not synchronized, etc.) It is.
  • the processor 100 can record the execution history when a plurality of cores execute a program so that the execution order of instructions between the cores can be specified.
  • a group of code blocks can be recorded with a smaller number of code block addresses, and an execution history can be efficiently recorded.

Abstract

　複数のコアがそれぞれプログラムを実行するプロセッサであって、第１コアがプログラムの実行履歴記録ポイントに記述された実行履歴記録命令を実行した場合、前記第１コアの一連の命令を１つのアドレスで指示する第１のコードブロック情報を取得する第１の自コア実行ポイント取得手段と、前記第１コアが前記実行履歴記録命令を実行した場合、第２コアが実行している命令の第１の実行アドレス情報を取得する第１の他コア実行ポイント取得手段と、前記第１のコードブロック情報及び前記第１の実行アドレス情報を対応づけて共有メモリに時系列に記憶する第１の実行ポイント情報記録手段と、を有することを特徴とする。

Description

プロセッサ、電子制御装置、作成プログラム
　本発明は、プログラムを実行するプロセッサに関し、特に、複数のコア又はＣＰＵが実行するプログラムの実行履歴を記憶するプロセッサに関する。
　車両には数多くの電子制御装置が搭載されており、各電子制御装置が各種のプログラムを実行して様々な車載装置を制御している。車両メーカはプログラムを含む車載装置を十分に検証した後、出荷するが、出荷後の車両から得られる情報によりさらにプログラムや車載装置の完成度を向上させることを継続的に行っている。
　このため、車両になんらかのイベントが生じると、プログラムの実行履歴を記録する機能が電子制御装置に搭載されることがある。例えば、従来であればプログラムカウンタ（以下、ＰＣという）の値を時系列に記憶する技術が知られている。しかしながら、ＰＣの値をステップ毎に記憶するには多くの記憶容量が必要となり、十分な記憶容量のメモリを用意しないと、解析に必要なステップ（過去のある時刻）の実行履歴が上書きにより消去されていることが生じやすい。一方で、ＰＣの記録のため十分な記憶容量のメモリを用意すると分析の対象が増えるため、分析時にイベントの原因やどのような処理が行われたかを特定することが困難になるという不都合をもたらす。
　また、プログラムの実行時に条件分岐命令が検出されると、分岐命令のアドレスをトレースレジスタに書き込む技術も考案されている（例えば、特許文献１，２参照）。特許文献１には分岐条件が成功を示す場合に分岐条件ないしはその近傍のマイクロ命令アドレスをトレースレジスタに書き込むアドレストレース装置が開示されている。また、特許文献２には、分岐の発生時、すでに分岐アドレスが記憶されているか否かをチェックして、トレースされていない場合にだけ分岐アドレスをトレースレジスタに書き込むトレース方式が開示されている。
　ところで、近年、車載される電子制御装置の数を抑制しようとそれまでは複数の電子制御装置に分散されていた機能を１つの電子制御装置に集約する試みがある。また、電子制御装置のＣＰＵも一般のコンピュータと同様にマルチコア化が図られるようになってきている。すると、１つのＣＰＵ内の複数のコアが別々にプログラムを実行することになる。このような状況でイベントが発生すると、複数のコアのプログラムの分岐アドレスを別々に記憶するだけでは、イベントの発生に関連する不具合等の特定が困難であるという問題がある。すなわち、コアＡが実行する命令Ａ、コアＢが実行する命令Ｂの実行履歴が別々に記録されていると、命令Ａと命令Ｂの相対的な実行順序が分からないので、解析が困難になる。
特開昭６３－２５７０３９号公報 特開昭６１－２９０５４６号公報
　本発明は、上記課題に鑑み、マルチコア又はマルチＣＰＵ型のＣＰＵが搭載されたプロセッサにおいて、イベント発生の解析に有効な実行履歴を記録できるプロセッサを提供することを目的とする。
　本発明は、複数のコアがそれぞれプログラムを実行するプロセッサであって、第１コアがプログラムの実行履歴記録ポイントに記述された実行履歴記録命令を実行した場合、前記第１コアの一連の命令を１つのアドレスで指示する第１のコードブロック情報を取得する第１の自コア実行ポイント取得手段と、前記第１コアが前記実行履歴記録命令を実行した場合、第２コアが実行している命令の第１の実行アドレス情報を取得する第１の他コア実行ポイント取得手段と、前記第１のコードブロック情報及び前記第１の実行アドレス情報を対応づけて共有メモリに時系列に記憶する第１の実行ポイント情報記録手段と、を有することを特徴とする。
　マルチコア又はマルチＣＰＵ型のＣＰＵが搭載されたプロセッサにおいて、イベント発生の解析に有効な実行履歴を記録できるプロセッサを提供することができる。
本実施形態のプロセッサによる実行履歴の記憶を模式的に説明する図の一例である。 プロセッサのハードウェア構成図の一例である。 プログラムへの発生要因記憶プログラムの埋め込み方法を説明する図の一例である。 プログラムバイナリコードの一部の一例を示す図である。 コードブロックアドレス一覧の一例を示す図である。 発生要因記憶プログラムが埋め込まれたプログラムバイナリコードの一例を示す図である。 シングルコアの場合のプログラムが実行履歴を記憶する手順を示すフローチャート図の一例である。 各コアの機能ブロック図の一例である。 マルチコアの場合のプログラムが実行履歴を記憶する手順を示すフローチャート図の一例である。 ２つのコアによる１つのリングバッファへのコードブロックアドレスの記憶を模式的に説明する図の一例である。 マルチプロセッサマイコンの構成図の一例を示す。 ２つのプロセッサ１，２がそれぞれリングバッファ４０のコードブロックアドレスに記憶する手順を説明するフローチャート図の一例である プロセッサのハードウェア構成図の一例を示す。 コア３が実行履歴を記録する手順を示すフローチャート図の一例である
１１　　コア
１２　　ＣＰＵ
１３　　ＩＮＴ
１４　　ＲＡＭ
１６　　ＳＤＲＡＭ
２０　　プログラム
４０　　リングバッファ
１００　プロセッサ
　以下、本発明を実施するための形態を図面を参照しながら説明する。
図１は本実施形態のプロセッサ１００による実行履歴の記憶を模式的に説明する図の一例である。本実施形態のプロセッサ１００は、何らかのイベントが生じた際に、車両メーカ等が後に解析するための診断情報を記録するＥＤＲ（Ｅｖｅｎｔ　Ｄｉａｇ　Ｒｅｃｏｒｄｅｒ）という機能の一種を有する。
　コア１はプログラム１を、コア２はプログラム２をそれぞれ別々に実行している。コア１が実行しているプログラム１の命令はポインタ１により特定され、コア２が実行しているプログラム２の命令はポインタ２により特定される。
　本実施形態のプロセッサ１００は、例えば分岐命令を実行する際にポインタ１又はポインタ２が指示するコードブロックアドレス（これについては後述する）を記憶する。コードブロックはいくつかの命令のブロックであるので、プログラムカウンタの値を記憶するよりも実行履歴の記憶容量を抑制することができる。
　また、コア１が分岐命令を実行する際、コア１は自身のコードブロックアドレスだけでなくコア２の実行ポイント（ポインタ２に指示される）も共に記憶する。こうすることで、コア１が分岐命令を実行した際にコア２がどの命令を実行していたかを特定できる。コア２についても同様であり、コア２が分岐命令を実行する際、コア２は自身のコードブロックアドレスだけでなくコア１の実行ポイントも共に記憶する。
　そして、コア１とコア２は、共有のリングバッファ４０に実行履歴を時系列に記憶していき、古いものから上書きすることを繰り返す。こうすることで、コア１とコア２の命令の実行経路だけでなく、ブロック単位でコア１とコア２による相対的な命令の実行順序が明らかになり、イベント発生にコア１とコア２の命令実行がどのように作用したかの解析が容易になる。
　〔機能統合について〕
　本実施形態のプロセッサ１００は電子制御装置（ＥＣＵ：electronic control unit）に搭載される。本実施形態の電子制御装置は、従来は複数の電子制御装置が別々に提供していた機能を１つで提供することが想定されている。電子制御装置の機能統合は、ＥＣＵの数が少なくなることから開発費の低減に繋がり、この結果、車両の価格競争力が向上することも期待できる。また、プロセッサ１００の設計にもよるが、開発済みのプログラムを大きく修正することなく機能統合後の電子制御装置に搭載できれば、プログラムの開発費を大きく削減することも期待できる。
　しかしながら、電子制御装置に複数の機能を統合することは、複数の機能を提供するための命令が同時並行的に実行されることを意味するので、何らかの不具合が発生した場合の原因が複雑になることも予想される。また、統合前の複数のプログラムの実行タイミングと統合後のプログラムの実行タイミングが大きく異なることは望ましくないので、統合後の電子制御装置にマルチコアやマルチＣＰＵを搭載して、マルチコアやマルチＣＰＵが別々にプログラムを実行することが実用的である。
　本実施形態のプロセッサ１００は、機能統合した電子制御装置にマルチコアやマルチＣＰＵが搭載されていても、適切に診断情報を記録することができる。
　なお、統合する機能としては、例えば電子制御装置同士の他、ＣＡＮゲートウェイとハイブリッドＥＣＵのように、制御系と情報処理系の電子制御装置同士を統合することも含まれる。しかし、本実施形態の実行履歴の記録方法は、特に、リアルタイム性の高い制御系のプログラムの解析に有効である（例えば、ハイブリッド制御、エンジン制御、ブレーキ制御、トランスミッション制御等）。
　図２は、プロセッサ１００のハードウェア構成図の一例を示す。プロセッサ１００は、マルチレイヤーバス１９を介して接続されたコア１３（区別する場合コア１、コア２という）、ＤＭＡＣ１５、ＳＤＲＡＭ１６、Ｉ／Ｏブリッジ１７及びＲＯＭ１８を有する。
　各コアはＣＰＵ１２、ＩＮＴ１５、及び、ＲＡＭ１４を有する。すなわち、コア１はＣＰＵ１、ＩＮＴ１、及び、ＲＡＭ１を有し、コア２はＣＰＵ２、ＩＮＴ２、及び、ＲＡＭ２を有する。コア１とコア２は、それぞれのコアに決まったＯＳとタスクを割り当てるＡＭＰ（Asymmetric Multi-processing）でもよく、コア１とコア２が共通のＯＳを実行してメモリ（例えば、ＳＤＲＡＭ１６）を共有するＳＭＰ（Symmetric Multi-processing）でもよい。または、ＡＭＰとＳＭＰの中間的な性質のＢＭＰ（Bound Multi-processing）でもよい。
　したがって、図１のプログラム１，２は同じプログラムの場合もあるし、互いに独立したプログラムの場合もある。独立したプログラムの場合でも、本実施形態のＥＤＲは一方の命令の実行が他方の命令の実行に影響する可能性が高い場合に有効なので、コア１１の実装がＡＭＰの場合でも、プログラム１の処理がコア２に又はプログラム２の処理がコア１に何らかの影響（互いに演算結果を利用する、プログラム1とプログラム２に実行順依存関係がある、プログラム1とプログラム２が同期を取る等）を与える関係にあることが想定される。
　ＣＰＵ１，２は、それぞれ、ＩＦＵ（Instruction　Fetch　Unit）、ＤＥＣ（DECoder）、ＲＦ（Register　Fetch）、ＲＥＧ（REGister）、ＬＳＵ（Load　Store　Unit）、ＳＨ（ＳＨｉｆｔｅｒ）、ＡＬＵ、ＭＵＬ及びＦＰＵ等の演算回路を有し、パイプライン制御により１クロックで１命令を実行することができる。
　ＲＡＭ１はコア１に専用のメモリ（一次キャッシュ）であり、ＲＡＭ２はコア２に専用のメモリ（一次キャッシュ）である。ＳＭＰの場合、キャッシュのコヒーレンシを維持するため、不図示のスヌープコントローラ（SNC）がＲＡＭ１とＲＡＭ２のデータの更新を監視して、更新データをＲＡＭ１とＲＡＭ２間で通信する。　
　ＩＮＴ１とＩＮＴ２は、ＣＰＵ間割り込みを制御すると共に、コア１からコア２又はコア２からコア１に、パラメータ等の送受信を制御する。また、ＩＮＴ１，ＩＮＴ２は、ＲＡＭ１、ＲＡＭ２、又は、ＳＤＲＡＭ１６を共有の通信用メモリにしてパラメータ等を送受信することもできる。ＩＮＴ１とＩＮＴ２を使用したコア間のパラメータ通信はハードウェア的な実装であり、この他、ＯＳが提供するコア間通信のＡＰＩを利用してもコア１とコア２は通信することができる。
　ＤＭＡＣ１５は、コア１及びコア２から要求を受けてプログラム２０をＳＤＲＡＭ１６、ＲＡＭ１、ＲＡＭ２に読み込んだり、周辺機器からのメモリアクセス要求を調停すると共に、Ｉ／Ｏブリッジ１７からＳＤＲＡＭ１６へ、又は、ＳＤＲＡＭ１６からＩ／Ｏブリッジ１７へ、コア１、コア２を介することなくデータを転送する。ＳＤＲＡＭ１６は、コア１及びコア２がプログラム２０を実行している間、ＲＡＭ１又はＲＡＭ２にミスヒットするとプログラム２０又はデータを提供するためのメモリ（二次キャッシュ）である。ＳＤＲＡＭ１６の少なくとも一部はコア１とコア２により共有される。
　ＲＯＭ１８には統合後の機能を提供する特徴的なプログラム２０が記憶されているが、このプログラム２０に発生要因記憶プログラムが埋め込まれている。埋め込み方法も本実施形態の特徴の1つである。なお、ＲＯＭ１８はプロセッサ１００の外部に配置されていてもよく、容量に応じてＯＳやデバイスドライバ（プラットフォーム）も記憶されている。
　Ｉ／Ｏブリッジ１７は、マルチレイヤーバス１９とＩ／Ｏバス２１の間で相互に周波数や電圧値などを変換する。Ｉ／Ｏバス２１には種々のＩ／Ｏ２２が接続されている。Ｉ／Ｏ２２はプロセッサ１００と外部の機器を接続するインタフェースであり、例えば、ＣＡＮコントローラ、各種のアクチュエータ、センサ、スイッチ等が接続される。
　〔発生要因記憶プログラムの埋め込み〕
　図３は、プログラム２０の生成方法を説明する図の一例である。概略的には、
プログラムバイナリコード３２に発生要因記憶プログラム３３を埋め込むことでプログラム２０が生成される。
　図３の処理は、不図示のコンピュータが実行するプログラム（区別するために作成プログラム３０という）が実行する。抽出処理部３５とコード埋め込み部３６は作成プログラム３０が提供する機能である。なお、作成プログラム３０を実行するコンピュータは、ＣＰＵ、ＲＡＭ，ＲＯＭ、ＨＤＤ、入出力装置等を備えた一般的なＰＣ（パーソナルコンピュータ）でよい。
　プログラムバイナリコード３２は機能統合後のプログラムであり、プロセッサ１００が提供する実行履歴を記録する機能（ＥＤＲ機能）が含まれる前のプログラムである。
図４（ａ）は、プログラムバイナリコード３２の一部の一例を示し、図４（ｂ）のフローチャート図は分岐条件とプログラムバイナリコード３２の対応を説明するための図である。例えば、Ｃ言語で記述されたソースコードをコンパイラがコンパイルすると機械語のオブジェクトコードが得られるが、図４はオブジェクトコードを可読なようにアセンブリ言語で示したものである。Ｃ言語では、一まとまりの機能を関数名と"｛コード｝"で記述しておき、その関数をmain関数から呼び出すような記述が多いが、このような記述がコンパイルされると、関数にラベルが付与される。したがって、図４のラベルから次のラベルの直前のアセンブラコードが関数に相当するかひとまとまりの機能とみなすことができる。
　また、Ｃ言語などでは制御文としてＩｆ～Ｅｌｓｅ文、Ｓｗｉｃｈ文、Ｗｈｉｌｅ文等が用意されており、ある条件が成立した場合又は不成立の場合に関数を呼び出す記述がなされることがある。このようなソースコードの記述はアセンブラコードでは、"Ｊｍｐ　ラベル名"と記述されている。
図４（ｂ）のフローチャート図に示すように制御文で記述される分岐条件（ひし形）が成立した場合又は不成立の場合、命令がアドレス順に実行されなくなる。この処理の流れは、アセンブラコードの"Ｊｍｐ"により表される。したがって、"Ｊｍｐ"という記述の前後で処理（機能）が大きく異なるとみなすことができる。なお、以下、"Ｊｍｐ"を条件分岐命令という場合がある。
　以上のようなアセンブラコードの記述の特徴を考慮すると、ラベルからラベル、ラベルから"Ｊｍｐ"、又は、"Ｊｍｐ"～から次の"Ｊｍｐ"までが一つのまとまりのある機能が記述されており、１つの機能として抽出することが適切であると考えられる。本実施形態では、機能的１つと見なせる一連のコードをコードブロックと称す。
　コードブロックの間は処理が分岐しないので、コードブロックを特定するアドレス（以下、コードブロックアドレスという）を１つ記録すれば、少ない情報で多くのコードを特定できることになる。上記の一まとまりの機能は、仮にラベルから始まってもその前に"Ｊｍｐ"が実行されるので、この"Ｊｍｐ"（条件分岐命令）のアドレスをコードブロックアドレスとすることができる。
　そこで、作成プログラム３０は、条件分岐命令を予め条件分岐命令一覧３１を記憶しておいたり、ＨＤＤや作成プログラム３０内に記述しておく。図４の例では"Ｊｍｐ"が条件分岐命令である。なお、さらに、ラベル名を条件分岐命令一覧３１に登録しておいてもよい。
　また、条件分岐命令ではないが、サブルーチンをコールするために命令「Call」も実行履歴が変化するという意味では同じであるので、条件分岐命令一覧３１に「Call」を登録することも有効である。
　こうすることで、十分に細かい粒度でコードブロックを条件分岐命令一覧３１に特定できたことになる。しかしながら、コードブロックの粒度を細かくすることは、次述するように埋め込むべき場所が多くなることを意味するので、プログラムのオーバーヘッドを大きくしてしまう。このため、コードブロックの粒度（条件分岐命令一覧３２に登録する分岐命令やラベル）は、プロセッサ１００の処理能力に応じて調整することが好ましい。
　なお、コードブロックアドレスは条件分岐命令のアドレスであるが、ポインタにより指示されるアドレスという意味では、実行されている命令のアドレスを意味する実行ポイントの下位概念になる。本実施形態では両者を区別するが、大きな違いはない。
　図３に戻り、抽出処理部３５はプログラムバイナリコード３２のオペコード（ニーモニック）を１つずつ読み出し、条件分岐命令一覧３１に一致する場合、コードブロックアドレス一覧３４に登録する。
　図５は、コードブロックアドレス一覧３４の一例を示す図である。コードブロックアドレス一覧３４では、アドレスとニーモニックが対応づけられているが、ニーモニックは説明のために記載したものであり実際には不要である。抽出処理部３５は、アセンブラコードをアドレスの順番に読んでいき、条件分岐命令一覧３１に一致するアドレス「0x30，0x50，0xC0，0xE0」をコードブロックアドレス一覧３４に登録する。これらの各アドレスが各コードブロックを指定するアドレスとなり、実行履歴の記録に利用されることになる。なお、このアドレスはプログラムの先頭からの相対アドレスである。
　次に、図３のコード埋め込み部３６は、プログラムバイナリコード３２に発生要因記憶プログラム３３を埋め込む。発生要因記憶プログラム３３は、実行履歴を記録する従来のプログラムであり、特にイベントをトリガーに実行履歴を記録したり記録を停止することができる。発生要因記憶プログラム３３は実行している命令のアドレスを記憶する。プロセッサ１００がこの機能を提供するため、本実施形態で埋め込まれる記述は、例えば「Call SAVE_Log」という記述であるとする。
　よって、コード埋め込み部３６は、コードブロックアドレス一覧３４に登録されたアドレスの手前に「Call SAVE_Log」を記述していく。
図６は、発生要因記憶プログラム３３が埋め込まれたプログラムバイナリコード３２の一例を示す。アドレス「0x30，0x50，0xC0，0xE0」の手前に「Call SAVE_Log」が記述されている。コア１又はコア２は「Call SAVE_Log」を実行すると、次の命令のアドレスをコードブロックアドレスとしてリングバッファ４０に記憶する。なお、「Call SAVE_Log」の実行時には次のＪｍｐ命令のアドレスがＰＣ（プログラムカウンタ）にすでに設定されているので、次の命令のアドレスは現在のＰＣの値である。作成プログラム３０がこのように作成したプログラム２０は、プロセッサ１００のＲＯＭ１８に記憶して車両と共に出荷されるか、出荷後に上書きされる。
　〔シングルコアの場合の動作手順〕
　図７は、シングルコアの場合にプログラム２０が実行履歴を記憶する手順を示すフローチャート図の一例である。図７の手順は、車両のイグニッションがオン（又は、ハイブリッド車や電気自動車の場合はメインシステムがオンの間）されると、繰り返し実行される。
　プログラム２０は、車両にイベントが発生したか否かを監視している（Ｓ１０）。典型的なイベントは、エアバッグが展開したこと、閾値以上のＧが検出されたこと、運転者が緊急サポートセンタへの通話ボタンを押下したこと、等である。すなわち、車両に比較的大きな異常が生じた可能性が高い状況が検出されることがイベントである。プロセッサ１００が搭載された電子制御装置がイベントを検出した場合は、このプログラム２０がイベントを検出し、他の電子制御装置がイベントを検出した場合はＣＡＮ通信などにより、プロセッサ１００にイベントが通知される。
　イベント発生が検出されない場合（Ｓ１０のＮｏ）、プロセッサ１００はアドレスの順番にプログラム２０を実行する（Ｓ２０）。
　そして、プロセッサ１００はプログラム２０に埋め込まれた「Call SAVE_Log」を実行すると（Ｓ３０）、リングバッファ４０にコードブロックアドレスを記憶する（Ｓ４０）。プログラム２０は、積極的にコードブロックアドレスの記憶ポイントに到達したか否かを判定しているわけではないが、結果的に、コードブロックアドレスに到達した場合にだけ、コードブロックアドレスを記憶する。
　例えば、プロセッサ１００の実行ポイント（ＰＣの値）が「０ｘ４０」であるとすると、プログラム２０はリングバッファ４０の最も古いコードブロックアドレスが記憶されているアドレスに「０ｘ４０」を記憶する。コードブロックアドレスが分かれば、一まとまりの機能のコードを特定できるので、少ないリングバッファ４０の容量で効率的に実行履歴を記録できる。なお、最も古いコードブロックアドレスが記憶されているリングバッファ４０のアドレスは、ポインタにより指示されている。
　次いで、処理はステップＳ１０に戻るので、イベントが発生するまでプログラム２０はコードブロックアドレスの記憶を繰り返す。ステップＳ１０においてイベント発生が検出されると（Ｓ１０のＹｅｓ）、プログラム２０はイベント発生に対応したイベント処理部（例えば図８に示す）を呼び出し、実行ポイントをリングバッファ４０に記憶すると共に、それ以降の記憶を停止する（Ｓ５０）。こうすることで、イベント発生よりも前のプログラム２０の実行経路を保存することができる。イベント発生以後のコードブロックアドレスの記憶を停止するには、イベント処理部が例えば、リングバッファ４０に記録禁止を意味するフラグを設定したり、ポインタに記録禁止を意味する所定値（例えば、ＮＵＬＬやＦＦＦＦ）を設定しておく。プログラム２０に埋め込まれた「Call SAVE_Log」は、リングバッファ４０のフラグやポインタの値に基づきコードブロックアドレスを記録するか否かを判定することで、イベント発生以後のコードブロックアドレスの記憶を停止することができる。
　〔マルチコアの場合の動作手順〕
　図８は、各コアの機能ブロック図の一例であり、図９は、マルチコアの場合のプログラム２０が実行履歴を記憶する手順を示すフローチャート図の一例であり、図１０は２つのコアによる１つのリングバッファ４０へのコードブロックアドレスの記憶を模式的に説明する図の一例である。
　図８に示すように、コア１とコア２は、「SAVE_Log」に含まれる機能として、自コア実行ポイント取得部４２、４６、他コア実行ポイント取得部４３、４７、及び、リングバッファ記録部４４，４８、を有する。また、イベント発生に対応した処理としてイベント処理部４５，４９を有する。これらの各機能はフローチャート図と共に説明する。また、リングバッファ４０は共有メモリ（ＲＡＭ１，ＲＡＭ２又はＳＤＲＡＭ１６）に記憶されている。ポインタ４１はコア１及びコア２の各レジスタで同じ値に維持されるか、又は、共有メモリで共有されている。ポインタ４１によりリングバッファ４０において次にコードブロックアドレスを記憶すべきアドレスが指示されている。
　図９の手順はほぼ図７のシングルコアの場合の手順と同様であるが、図９ではコア１とコア２が別々に図７のフローチャート図を実行する。
・図９（ａ）のステップＳ４０が実行される場合
　コア１が実行する命令が「Call SAVE_Log」に到達すると、自コア実行ポイント取得部４２はコードブロックアドレスとなる実行ポイントを取得する。実行ポイントはＰＣの値としてよい。図１０によれば、コア１は次のステップで「0x11」のアドレスを実行するので、自コア実行ポイント取得部４２は「0x11」というコードブロックアドレスを取得し、リングバッファ記録部４４に通知する。
　次に、コア１の他コア実行ポイント取得部４３は、コア２にコア２の実行ポイントを問い合わせ、コア２の実行ポイントを取得する。他コア実行ポイント取得部４３はハード的又はソフト的なコア間の通信方法を利用して、コア２から実行ポイントを取得する。コア２が「0x07」のアドレスの命令を実行していると仮定すると、他コア実行ポイント取得部４３は「0x07」というアドレスを取得し、リングバッファ記録部４４に通知する。
　リングバッファ記録部４４は、ポインタ４１の指示するリングバッファ４０のアドレスに、コア1のコードブロックアドレスとコア2の実行ポインタを対応づけて（１対に）記憶する。対応づけて記憶するとは、一方から他方を一意に特定できるような記憶態様をいい、所定のアドレスの上位バイトと下位バイトに記憶することや、連続したアドレスに記憶することや、同じ識別番号を付することなどをいう。なお、リングバッファ記録部４４はポインタ４１の値を1つ（アドレス長だけ）大きくし、リングバッファ４０の最大アドレスまで到達したら初期値に戻す。
　以上により、図１０のリングバッファ４０に示すように、「コア１条件分岐：コア１ 0x11、コア２ 0x07」と記録される。「コア１条件分岐」によりどちらのコアが記録したかが明らかになり、「コア1　0x11、コア２ 0x07」により、コア１が0x11の条件分岐命令を実行する際、コア２が0x07の命令を実行していたことが明らかとなる。
　・図９（ｂ）のステップＳ４０が実行される場合
　コア２がステップＳ４０を実行する際の手順も同じである。コア２の実行するステップが「Call SAVE_Log」に到達すると、自コア実行ポイント取得部４６はコードブロックアドレスとして実行ポイントを取得する。ここでは、自コア実行ポイント取得部４６は「0x06」というアドレスを取得し、リングバッファ記録部４８に通知するものとする。
　コア２の他コア実行ポイント取得部４７は、コア１にコア１の実行ポイントを問い合わせ、コア１の実行ポイントを取得する。ここでは、他コア実行ポイント取得部４７は「0x23」というアドレスを取得し、リングバッファ記録部４８に通知するものとする。
　リングバッファ記録部４８は、ポインタ４１の指示するリングバッファ４０のアドレスに、コア１の実行ポインタとコア２のコードブロックアドレスを対応づけて記憶する。
　以上により、図１０のリングバッファ４０に示すように、「コア２条件分岐：コア１ 0x23、コア２ 0x06」と記録される。「コア２条件分岐」によりどちらのコアが記録したかが明らかになり、「コア1　0x23、コア２ 0x06」により、コア２が0x06の条件分岐命令を実行する際、コア１が0x23の命令を実行していたことが明らかとなる。
　また、１つのリングバッファ４０にコア１とコア２が時系列にコードブロックアドレスを記録するので、コア１とコア２が実行した条件分岐命令の相対的な実行順が明らかになる。すなわち、コア１だけが時系列にコードブロックアドレスを記憶し、コア２だけがコードブロックアドレスを記録すると、解析時にコア１の条件分岐命令とコア２の条件分岐命令を１つずつ取り出してもコア１の条件分岐命令とコア２の条件分岐命令ではどちらが先に実行されたかを判別することが困難である。リングバッファ４０であればなおさらである。したがって、コア１とコア２の実行履歴を統合して再現できないことになる。これに対し、本実施形態のプロセッサ１００は、コア１とコア２がそれぞれ単独に条件分岐命令を実行しても、コア１とコア２の実行履歴を同じリングバッファ４０に時系列に記録するので、コア１の条件分岐命令とコア２の条件分岐命令の実行順が明らかになる。
　なお、コードブロックアドレスの記録時にタイムスタンプを記録すればコア１とコア２が別々にコードブロックアドレスを記録してもコア１とコア２の条件分岐命令の実行順が判別できるが、処理負荷の増大やリングバッファ４０の容量を増大させるという不都合がある。
　・イベントが検出された場合
コア１とコア２は同じプロセッサ１００に配置されているので、コア１とコア２はいずれもほぼ同時にイベント発生を検出する。よって、コア１のイベント処理部４５とコア２のイベント処理部４９とはいずれもコードブロックアドレスの記憶を行う。この場合、２つのイベント処理部４５，４９はほぼ同時にコードブロックアドレスの記録を開始すると考えられるが、リングバッファ４０へのアクセスはハード的又はソフト的に排他制御されるので、いずれか早い方から順番にコードブロックアドレスを記憶する。
　例えば、コア１のイベント処理部４５は、自コア実行ポイント取得部４２、他コア実行ポイント取得部４３、及び、リングバッファ記録部４４の一連の処理を実行して、実行ポイントとして「0x40」というコードブロックアドレスを取得し、コア２の実行ポイントとして「0x09」というアドレスを取得し、リングバッファ４０に記憶する。これにより、「コア１イベント発生：コア１ 0x40、コア２ 0x09」と記録される。
　コア２のイベント処理部４９についても同様である。コア２のイベント処理部４９は、自コア実行ポイント取得部４６、他コア実行ポイント取得部４７、及び、リングバッファ記録部４８の一連の処理を実行して、実行ポイントとして「0x11」というコードブロックアドレスを取得し、コア１の実行ポイントとして「0x50」というアドレスを取得し、リングバッファ４０に記憶する。これにより、「コア２イベント発生：コア１ 0x50、コア２ 0x11」と記録される。
　コードブロックアドレスの記録を停止するため、例えば先にコードブロックアドレスを記録したコア１，２のイベント処理部４５，４９は、記録の完了を他方のコアに通知する。通知を取得したコア１，２のイベント処理部４５，４９はフラグをオンに設定するなどして、他方のコアがイベント発生によるコードブロックアドレスの記録を終了したことを記録する。他方のコアのイベント処理部４５，４９は、イベント発生によるコードブロックアドレスの記録を終了するとフラグを参照して記録を停止してよいか否かを判定する。記録を停止してよいと判定した場合、イベント処理部４５，４９はシングルコアの場合と同様に記録を停止する。
　以上により、図１０のリングバッファ４０に示すように、イベント発生によるコードブロックアドレスと実行ポインタが「コア１イベント発生：コア１ 0x40、コア２ 0x09」「コア２イベント発生：コア１ 0x50、コア２ 0x11」のように記録される。
　解析時には、車両メーカやディーラのサービスマンが外部ツールによりリングバッファ４０を読み出す。リングバッファ４０に「イベント発生」と記録されているアドレスの次のアドレスからアドレス順にコードブロックアドレスを読み出し、最後のアドレスまで到達したら先頭に戻り「イベント発生」のアドレスまでリングバッファ４０の記録内容を読み出すことで、コア１とコア２の実行履歴が得られる。なお、「イベント発生」という情報が記録されていなくても、サービスマンや外部ツールはポインタ４１が指示するアドレスによりイベント発生時のコードブロックアドレスが記録されたアドレスを特定できる。
　サービスマン等はコア１とコア２のプログラム２０の実行履歴を精査し、プログラム２０が予定された順に実行されているか否かや、想定外の実行履歴がないか否かなどを判断する。このような判断により、イベント発生がプログラム２０によるものなのかそうでないかの峻別が可能になり、イベント発生の原因の特定精度を向上させ又は特定までの時間を短縮できる。
　〔アドレス以外に記憶することが有効な情報〕
　コア１とコア２がリングバッファ４０に記憶する情報としてコードブロックアドレスと実行ポインタを例示したが、イベント発生の原因を特定するため以下の情報をコードブロックアドレス及び実行ポインタと共に記憶してもよい。　
(i)　コア１とコア２の汎用レジスタ、フラグ、スタックポインタ、入力値
コア１、コア２は種々のレジスタを備えている。汎用レジスタだけでなく、フラグやスタックポインタもレジスタの一種である。汎用レジスタには演算中の値（作業中のデータの保存のために一時的に記憶される）が格納されるので、コードブロックアドレスと共にこの値を記憶しておくことで、サービスマン等は、演算結果がイベント発生に影響したか否か等を推測することが可能になる。
　フラグは、ＣＰＵ１、２が特定の命令を実行した際の実行結果を示す値が格納される。例えば、桁あふれした場合はオーバーフローフラグが、演算結果がゼロになった場合にはゼロフラグが、演算結果が負の値になった場合にはＳＦフラグが、それぞれ「１」に設定される。したがって、コードブロックアドレスと共にこの値を記憶しておくことで、サービスマン等は、演算結果が不測の値になったことがイベント発生に影響したか否か等を推測することが可能になる。
　スタックには関数が実行された際の、レジスタの内容、関数のアドレス、引数、変数などが格納されるが、この関数が別の関数を呼び出すような場合、スタックには呼び出された関数のレジスタの内容、関数のアドレス、引数、変数などが格納される。スタックポインタは、これらの情報の最新の格納位置を示す。したがって、コードブロックアドレスと共にスタックポインタを記憶しておくことで、サービスマン等がその推移から実行履歴を検証することが可能になる。
　入力値は、例えば、Ｉ／Ｏ２２から入力されたセンサの検出値、他の電子制御装置から受信したデータなどである。入力値は例えばＳＤＲＡＭ１６、ＲＡＭ１，ＲＡＭ２に記憶されているかコア１又はコア２に記憶されている。入力値は演算対象となるものなので、コードブロックアドレスと共にこの値を記憶しておくことで、サービスマン等は演算の対象として入力値が適当であったかな否かを検証することが可能になる。
　(ii)　分岐先の情報
　コードブロックアドレスは分岐元のアドレスであるが、分岐先のアドレスも記録すれば実行履歴をより詳細に記録できたことになる。分岐先のアドレスは例えば「Jmp a ELSE_STATE1」のようにオペランドに記述されている。したがって、コア１，２が「Call SAVE_Log」を実行することにより、実行ポインタだけでなく実行ポインタの命令のオペランドを読み出してコードブロックアドレスと共に記録すればよい。
　また、分岐先に再度、「Call SAVE_Log」を記述しておき、分岐先においてコアが「Call SAVE_Log」を実行することで、ＰＣに記憶された実行ポインタを読み出せば分岐先のアドレスを記憶することができる。
　〔割込みについて〕
　コア１又はコア２が互いに割り込みしたり、不図示の他のコアからコア１又はコア２が割込みを受ける場合がある。割込み発生時はＩＮＴ１、２が割込み内容（割り込みベクター）に応じて割り込みハンドラを起動して所定の処理を実行するので、割込み発生時も実行する命令のアドレスが大きく変化することになる。しかし、条件分岐命令と違いコア１又はコア２にとっていつ割込みが発生するかは予測が困難である。
　このため、割込み発生時にコードブロックアドレスを記録するには以下のよう方法がある。
・プログラムバイナリコード３２の所定ステップ毎に「Call SAVE_Log」を記述する。
すなわち、いつ割込みが発生しても所定ステップ以内に割込みの直前のコードブロックアドレスを記録することができる。しかし、「Call SAVE_Log」が多くなるとオーバーヘッドになるので、どのくらいのステップ数の間隔で記述するかは最適化することが好ましい。
・割込みハンドラが起動するプログラムに「Call SAVE_Log」を記述する
　割込みの発生時、ＰＣ等を含むコンテキストはスタックされているので、割込みの発生後に起動されるプログラムはスタックポインタにより割込み発生時のコンテキストを参照できる。コンテキストにはＰＣの値が記憶されるので、コア１やコア２は割込み発生時の実行ポインタを記憶することができる。
　〔マルチプロセッサマイコンの場合〕
　上記では、１つのプロセッサが複数のコア又はＣＰＵを有する態様を説明したが、１つ以上のコア又はＣＰＵを有する複数のプロセッサが搭載された態様でも、本実施形態の実行履歴の記録方法は有効である。
　図１１は、マルチプロセッサマイコンの構成図の一例を示す。プロセッサ１とプロセッサ２がバスを介して接続されている。プロセッサ１、２は1つ以上のコア又はＣＰＵを有していればよい。プロセッサ１はプロセッサ１用のリングバッファ４０を有し、プロセッサ２はプロセッサ２用のリングバッファ４０を有している。リングバッファ４０を別々にしたのは、メモリの共有の自由度を考慮したためで、いずれか一方のリングバッファ４０を共有してもよい。
　これまで説明したように条件分岐命令の手前に「SAVE_Log」が記述されており、「SAVE_Log」が実行されることによりコードブロックアドレスと実行ポインタが対応づけて記録される。プロセッサ１と２はＤＭＡＣやデバッグポートなどのプロセッサ間通信手段を利用して通信する。これにより、プロセッサ１はプロセッサ２のＰＣの値を、プロセッサ２はプロセッサ１のＰＣの値を、それぞれ取得することができる。
　また、図１１では、リングバッファ４０を別々にしたため、各プロセッサがＰＣ応答タスク１，２を有する。ＰＣ応答タスク１，２は相手のプロセッサが「SAVE_Log」を実行した際に、自機のプロセッサの実行ポイントを記録するタスクである。
　図１２は２つのプロセッサ１，２がそれぞれリングバッファ４０へコードブロックアドレスを記憶する手順を説明するフローチャート図の一例である。図１２の処理は図９の処理とステップＳ４０において異なる。
　・図１２（ａ）のＳ４０１
　プロセッサ１が実行する命令が「Call SAVE_Log」に到達すると、自コア実行ポイント取得部４２はコードブロックアドレスとなる実行ポイントを取得する。自コア実行ポイント取得部４２は例えば「0x40」というコードブロックアドレスを取得し、リングバッファ記録部４４に通知する。
　次に、プロセッサ１の他コア実行ポイント取得部４３は、ＤＭＡ通信などを利用してプロセッサ２に実行ポイントを問い合わせ、プロセッサ２の実行ポイントを取得する。プロセッサ２が「0x09」のアドレスの命令を実行していると仮定すると、他コア実行ポイント取得部４３は「0x09」というアドレスを取得し、リングバッファ記録部４４に通知する。
　リングバッファ記録部４４は、ポインタ４１の指示するリングバッファ４０のアドレスに、プロセッサ1のコードブロックアドレスとプロセッサ２の実行ポインタを対応づけて（１対に）記憶する。以上により、図１１のプロセッサ１のリングバッファ４０に示すように、「プロセッサ１条件分岐：プロセッサ１ 0x40、プロセッサ２ 0x09」と記録される。
　さらに、プロセッサ２は、プロセッサ１の他コア実行ポイント取得部４３から実行ポイントの問い合わせを受けることで割込みを発生させ、ＰＣ応答タスク２を実行する。まず、プロセッサ２のＰＣ応答タスク２は、ＰＣの値である実行ポイントを取得する。また、ＰＣ応答タスク２は、ＤＭＡ通信などを利用してプロセッサ１に実行ポイントを問い合わせ、プロセッサ１の実行ポイントを取得する。この実行ポイントはコードブロックアドレスと等しいかその周辺のアドレスとなる。この問い合わせを省略するため、プロセッサ１の他コア実行ポイント取得部４３が実行ポイントの問い合わせる際に実行ポイント（この場合はコードブロックアドレスと等しい）をプロセッサ２に通知してもよい。
　そして、プロセッサ２のＰＣ応答タスク２は、リングバッファ４０にプロセッサ1のコードブロックアドレスとプロセッサ２の実行ポインタを対応づけて記憶する。以上により、図１１のプロセッサ２のリングバッファ４０に示すように、「プロセッサ１条件分岐：プロセッサ１ 0x40、プロセッサ２ 0x09」と記録される。すなわち、リングバッファ４０の複製が得られるので、プロセッサ１と２がリングバッファ４０を共有する場合と同じ情報が得られる。
　なお、イベント発生時の実行履歴の記録についても同様に、プロセッサ１と２が同じ（又はほぼ同じ）実行履歴をそれぞれリングバッファ４０に記憶する（Ｓ５０１）。
　・図１２（ｂ）のＳ４０１
　プロセッサ２が起点となる以外は、図１２（ａ）のＳ４０１と同様である。ただし、条件分岐命令を実行したのがプロセッサ２なので、実行履歴はプロセッサ１，２のどちらにおいても例えば「プロセッサ２条件分岐：プロセッサ１ 0x50、プロセッサ２ 0x11」と記録される。
　以上のように、プロセッサ１が「SAVE_Log」を実行するとプロセッサ１と２が同じ（又はほぼ同じ）実行履歴をそれぞれリングバッファ４０に記憶し、プロセッサ２が「SAVE_Log」を実行するとプロセッサ１と２が同じ（又はほぼ同じ）実行履歴をそれぞれリングバッファ４０に記憶する。
　このように、プロセッサ１，２のどちらが「SAVE_Log」を実行してもそれぞれが同じ実行履歴を記録するので、マルチプロセッサマイコンにおいても、プロセッサ１と２の命令の実行経路だけでなく、プロセッサ１と２の相対的な命令の実行順序が明らかになる。
　以上のように、１つのプロセッサ内だけでなく複数のプロセッサが搭載されたマルチプロセッサにおいて、互いの実行履歴を対応づけて記録することができる。なお、プロセッサが３つ以上ある場合、全てのプロセッサが同じ実行履歴を記録することになるだけであり実行手順はプロセッサが２つの場合と同様である。
　〔別の形態〕
　プログラム２０を実行するコア１やコア２が実行履歴を記憶すると、上記のように「Call SAVE_Log」など実行履歴を記録するための命令をプログラム２０に予め埋め込んでおく必要が生じる。これは、コア１、コア２がプログラム２０を実行しながら条件分岐命令を実行するか否かを判定すると仮定すると、全ステップを実行する毎に１つ先の命令が条件分岐命令か否かを判定する必要が生じるためである。
　しかし、プログラム２０を実行するコア１やコア２とは別に、実行履歴を記憶するコア３を設けることで、「Call SAVE_Log」など実行履歴を記録するための命令をプログラム２０に予め埋め込んでおく必要性を低減できる。
　図１３は、プロセッサ１００のハードウェア構成図の一例を示す。図１３において図２と同一部の説明は省略する。コア３のＩＮＴ３は、ＩＮＴ１及びＩＮＴ２と接続されている。コア３は制御などのためのプログラム２０の実行を受け持たず、実行履歴を記録する専用の実行履歴記録プログラムを実行する。
　図１４は、コア３の実行履歴プログラムが実行履歴を記録する手順を示すフローチャート図の一例である。コア３は、実行履歴プログラムを実行することで実現される命令監視部、実行ポイント取得部、リングバッファ記録部、及び、イベント処理部を有する。
　命令監視部は、コア１及びコア２のＰＣが更新される毎にそれぞれの命令バッファ（又は命令デコーダ）の値をＩＮＴ１～３を介して取得し、コア１又はコア２が実行する命令がＪｍｐなど予め登録されている（条件分岐命令一覧３１と同じもの）命令と一致するか否かを監視している（Ｓ１１０）。一致する場合は、実行ポイント取得部に通知する。
　実行ポイント取得部は、条件分岐命令を実行したコア１又はコア２にコードブロックアドレスを要求し、他方のコアに実行ポインタを要求する（Ｓ１２０）。
　リングバッファ記録部は、コア１又はコア２から取得したコードブロックアドレス及び実行ポインタをリングバッファ４０に記憶する（Ｓ１３０）。こうすることで、コア１とコア２のどちらが条件分岐命令を実行しても、コア３がコア１及びコア２のコードブロックアドレスと実行ポインタを記録できる。なお、どちらかのコアが条件分岐命令を実行したかも記録される。
　なお、イベントが発生した場合のイベント処理部の処理はコアが２つの場合と同様であり、イベント発生を検出すると（Ｓ１４０）、イベント処理部はコア１とコア２に実行ポインタを要求し（Ｓ１５０）、互いに対応づけてリングバッファ４０に記憶し（Ｓ１６０）、その後、記録を停止する（Ｓ１７０）。
　したがって、３つめのコア３をＥＤＲ専用にすることで作成プログラム３０がプログラム２０に「Call SAVE_Log」を埋め込む必要がなくなり開発コストを低減できる。
　〔３つ以上のコアのプロセッサ１００について〕
　上記ではコアが２つの場合を例に説明したが、プロセッサ１００がコア１，２以外にコアを有する場合がある。しかしながら、コアが３つ以上存在しても、各コアの処理手順は大きく変わらない。すなわち、コア３が「Call SAVE_Log」を実行すると、コア３の自コア実行ポイント取得部は自コアのアドレスを取得し、他コア実行ポイント取得部は、コア１とコア２から実行ポイントを取得する。コア３のリングバッファ記録部は、ポインタ４１の指示するリングバッファ４０のアドレスに、コア３のコードブロックアドレスとコア１，２の実行ポイントを対応づけて記憶する。コア１，２についても同様である。
　また、一方で、コアが３つ以上存在しても、例えばコア３がコア１，２と関係のない処理を実行している場合、コア１，２がコア３の実行ポイントを実行する必要がない。例えば、コア１，２とコア３が全く通信しない（ＩＮＴ１３を有さない）場合、コア１，２がＳＭＰなのに対しコア３はＡＭＰのような場合、又は、コア１，２とコア３が処理上互いに全く影響しない（互いに演算結果を利用しない、プログラム1とプログラム２に実行順依存関係がない、プログラム1とプログラム２が同期を取ることがない等）プログラムを実行しているような場合、である。
　このような場合、コア３がコア１，２の検出するイベントに影響する可能性が低いのでコア１，２がコア３の実行履歴を記録する必要性が小さい。
　以上説明したように、本実施形態のプロセッサ１００は、複数のコアがそれぞれプログラムを実行した際の実行履歴をコア間の命令の実行順を特定できるように記録することができる。また、一まとまりのコードブロックをより少ないコードブロックアドレスにより記録することができ、効率的に実行履歴を記録できる。

Claims (14)

  1. 　複数のコアがそれぞれプログラムを実行するプロセッサであって、
    　第１コアがプログラムの実行履歴記録ポイントに記述された実行履歴記録命令を実行した場合、前記第１コアが実行する一連の命令を１つのアドレスで指示する第１のコードブロック情報を取得する第１の自コア実行ポイント取得手段と、
    　前記第１コアが前記実行履歴記録命令を実行した場合、第２コアが実行している命令の第１の実行アドレス情報を取得する第１の他コア実行ポイント取得手段と、
    　前記第１のコードブロック情報及び前記第１の実行アドレス情報を対応づけて共有メモリに時系列に記憶する第１の実行ポイント情報記録手段と、
    　を有することを特徴とするプロセッサ。
  2. 　前記第２コアが前記実行履歴記録命令を実行した場合、前記第２コアが実行する一連の命令を１つのアドレスで指示する第２のコードブロック情報を取得する第２の自コア実行ポイント取得手段と、
    　前記第２コアが前記実行履歴記録命令を実行した場合、第１コアが実行している命令の第２の実行アドレス情報を取得する第２の他コア実行ポイント取得手段と、
    　前記第２のコードブロック情報及び前記第２の実行アドレス情報を対応づけて前記共有メモリに時系列に記憶する第２の実行ポイント情報記録手段と、
    　を有する請求項１記載のプロセッサ。
  3. 　前記共有メモリは、前記第１のコア及び前記第２のコアが、前記共有メモリのアドレス順に、前記第１のコードブロック情報と前記第１の実行アドレス情報、又は、前記第２のコードブロック情報と前記第２の実行アドレス情報を書き込むリングバッファである、
    　ことを特徴とする請求項１又は２記載のプロセッサ。
  4. 　予め定められた事象の発生を検出した場合、前記第１の実行ポイント情報記録手段又は前記第２の実行ポイント情報記録手段は、前記共有メモリに、前記第１のコードブロック情報と前記第１の実行アドレス情報、又は、前記第２のコードブロック情報と前記第２の実行アドレス情報を記録することを停止する、
    　ことを特徴とする請求項３記載のプロセッサ。
  5. 　前記第１の実行ポイント情報記録手段は、前記第１のコードブロック情報と前記第１の実行アドレス情報に加え、前記第１コアの汎用レジスタの値、フラグレジスタの値、スタックポインタの値、又は、入力インターフェースを介して取得した入力値、の１つ以上を前記共有メモリに時系列に記憶する、
    　ことを特徴とする請求項１項記載のプロセッサ。
  6. 　前記第１の実行ポイント情報記録手段は、前記第１のコードブロック情報と前記第１の実行アドレス情報に加え、前記第１コアが前記実行履歴記録命令の次の命令を実行することで移動する移動先のアドレス情報を、前記共有メモリに時系列に記憶する、ことを特徴とする請求項１記載のプロセッサ。
  7. 　前記実行履歴記録ポイントは、条件分岐命令又はサブルーチンコール命令の直前のステップである、ことを特徴とする請求項１記載のプロセッサ。
  8. 　前記実行履歴記録ポイントは、一まとまりの機能を提供する一連の命令の終わり又は始まりの命令の直前のステップである、ことを特徴とする請求項１記載のプロセッサ。
  9. 　前記事象はエアバッグの展開である、ことを特徴とする請求項４記載のプロセッサ。
  10. 　請求項１記載のプロセッサが搭載された車両用の電子制御ユニット。
  11. 　請求項１記載の前記プログラムを作成する作成プログラムであって、ＣＰＵに
    　前記プログラムのバイナリコードを読み出すステップと、
    　条件分岐命令一覧に登録された条件分岐命令のいずれかに一致する前記バイナリコードの命令のアドレスを抽出する抽出処理ステップと、
    　前記第１の自コア実行ポイント取得手段、前記第１の他コア実行ポイント取得手段、及び、前記第１の実行ポイント情報記録手段、に対応する命令又は呼び出す命令を、前記抽出処理ステップで抽出したアドレスの直前に記述するコード埋め込みステップと、
    　を実行させる作成プログラム。
  12. 　第２のプロセッサと接続されたプロセッサであって、
    　第１のプログラムの実行履歴記録ポイントに記述された実行履歴記録命令を実行した場合、前記第１のプログラムの一連の命令を１つのアドレスで指示する第１のコードブロック情報を取得する第１の自コア実行ポイント取得手段と、
    　前記実行履歴記録命令を実行した場合、前記第２のプロセッサが実行している第２のプログラムの命令の第１の実行アドレス情報を取得する第１の他コア実行ポイント取得手段と、
    　前記第１のコードブロック情報及び前記第１の実行アドレス情報を対応づけて第１のメモリに時系列に記憶する第１の実行ポイント情報記録手段と、
    　を有することを特徴とするプロセッサ。
  13. 　請求項１２に記載のプロセッサと接続された第２のプロセッサであって、
    　前記第１の他コア実行ポイント取得手段から前記第１の実行アドレス情報を要求された際、実行している前記第２のプログラムの命令の第２の実行アドレス情報を取得する第２の自コア実行ポイント取得手段と、
    　前記第１の他コア実行ポイント取得手段から前記第１の実行アドレス情報を要求された際、前記第１のプロセッサが実行している前記第１のプログラムの命令の第３の実行アドレス情報を取得する第２の他コア実行ポイント取得手段と、
    　前記第２の実行アドレス情報及び前記第３の実行アドレス情報を対応づけて第２のメモリに時系列に記憶する第２の実行ポイント情報記録手段と、
    　を有する第２のプロセッサ。
  14. 　複数のコアがそれぞれプログラムを実行するプロセッサであって、
    　第１コア及び第２コアが実行する命令が、予め登録された命令と一致するか否かを判定する命令監視手段と、
    　第１コア又は第２コアが実行する命令が予め登録された命令と一致する場合、前記第１コアが実行する一連の命令を１つのアドレスで指示する第１のコードブロック情報又は前記第２コアが実行する一連の命令を１つのアドレスで指示する第２のコードブロック情報、及び、第２コアが実行している命令の第１の実行アドレス情報又は第１コアが実行している命令の第２の実行アドレス情報、を取得する実行ポイント取得手段と、
    　前記第１のコードブロック情報及び前記第１の実行アドレス情報、又は、前記第２のコードブロック情報及び前記第２の実行アドレス情報を、対応づけてメモリに時系列に記憶する実行ポイント情報記録手段と、
    　を有することを特徴とするプロセッサ。
PCT/JP2010/071049 2010-11-25 2010-11-25 プロセッサ、電子制御装置、作成プログラム WO2012070137A1 (ja)

Priority Applications (4)

Application Number Priority Date Filing Date Title
PCT/JP2010/071049 WO2012070137A1 (ja) 2010-11-25 2010-11-25 プロセッサ、電子制御装置、作成プログラム
JP2012545575A JP5532144B2 (ja) 2010-11-25 2010-11-25 プロセッサ、電子制御装置、作成プログラム
EP10859993.7A EP2645254A4 (en) 2010-11-25 2010-11-25 PROCESSOR, ELECTRONIC CONTROL DEVICE, CREATION PROGRAM
US13/885,495 US20130246736A1 (en) 2010-11-25 2010-11-25 Processor, electronic control unit and generating program

Applications Claiming Priority (1)

Application Number Priority Date Filing Date Title
PCT/JP2010/071049 WO2012070137A1 (ja) 2010-11-25 2010-11-25 プロセッサ、電子制御装置、作成プログラム

Publications (1)

Publication Number Publication Date
WO2012070137A1 true WO2012070137A1 (ja) 2012-05-31

Family

ID=46145514

Family Applications (1)

Application Number Title Priority Date Filing Date
PCT/JP2010/071049 WO2012070137A1 (ja) 2010-11-25 2010-11-25 プロセッサ、電子制御装置、作成プログラム

Country Status (4)

Country Link
US (1) US20130246736A1 (ja)
EP (1) EP2645254A4 (ja)
JP (1) JP5532144B2 (ja)
WO (1) WO2012070137A1 (ja)

Cited By (3)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017199117A (ja) * 2016-04-26 2017-11-02 日立オートモティブシステムズ株式会社 情報処理装置、情報処理システム
JP2018163656A (ja) * 2017-03-24 2018-10-18 エイアールエム リミテッド 追跡データ表現
JP7327076B2 (ja) 2019-10-17 2023-08-16 株式会社リコー 情報処理装置、情報処理方法、及びプログラム

Families Citing this family (2)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
US9659342B2 (en) * 2013-06-29 2017-05-23 Intel Corporation Mid command buffer preemption for graphics workloads
US9727502B2 (en) * 2013-07-26 2017-08-08 Infineon Technologies Ag System and method for direct memory access transfers

Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS61290546A (ja) 1985-06-19 1986-12-20 Ricoh Co Ltd マイクロプログラム制御装置のトレ−ス方式
JPS63257039A (ja) 1987-04-14 1988-10-24 Nec Corp アドレストレ−ス装置
JPH0675858A (ja) * 1992-05-13 1994-03-18 Nec Corp キャッシュ内蔵マイクロプロセッサ及びそのトレースシステム
JPH07248939A (ja) * 1994-03-10 1995-09-26 Mitsubishi Electric Corp プロセッサ及びプロセッサシステム
JP2003076577A (ja) * 2001-09-04 2003-03-14 Matsushita Electric Ind Co Ltd デバッグ装置
JP2008140162A (ja) * 2006-12-01 2008-06-19 Hitachi Ltd デバッグ情報収集方法
JP2008293420A (ja) * 2007-05-28 2008-12-04 Denso Corp 電子制御装置

Family Cites Families (19)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPH1078889A (ja) * 1996-09-04 1998-03-24 Mitsubishi Electric Corp マイクロコンピュータ
US6243735B1 (en) * 1997-09-01 2001-06-05 Matsushita Electric Industrial Co., Ltd. Microcontroller, data processing system and task switching control method
US6145123A (en) * 1998-07-01 2000-11-07 Advanced Micro Devices, Inc. Trace on/off with breakpoint register
US7454666B1 (en) * 2005-04-07 2008-11-18 Sun Microsystems, Inc. Real-time address trace generation
US7444499B2 (en) * 2006-03-28 2008-10-28 Sun Microsystems, Inc. Method and system for trace generation using memory index hashing
US8245199B2 (en) * 2006-05-05 2012-08-14 International Business Machines Corporation Selectively marking and executing instrumentation code
US7743279B2 (en) * 2007-04-06 2010-06-22 Apple Inc. Program counter (PC) trace
US20090037886A1 (en) * 2007-07-30 2009-02-05 Mips Technologies, Inc. Apparatus and method for evaluating a free-running trace stream
US7962314B2 (en) * 2007-12-18 2011-06-14 Global Foundries Inc. Mechanism for profiling program software running on a processor
US20090187747A1 (en) * 2008-01-18 2009-07-23 Infineon Technologies Ag System and method for tracing instruction pointers and data access
US20090249046A1 (en) * 2008-03-31 2009-10-01 Mips Technologies, Inc. Apparatus and method for low overhead correlation of multi-processor trace information
US7992052B2 (en) * 2009-02-19 2011-08-02 Freescale Semiconductor, Inc. Program correlation message generation for debug
US7984337B2 (en) * 2009-02-19 2011-07-19 Freescale Semiconductor, Inc. Address translation trace message generation for debug
US8433885B2 (en) * 2009-09-09 2013-04-30 Board Of Regents Of The University Of Texas System Method, system and computer-accessible medium for providing a distributed predicate prediction
US20110258421A1 (en) * 2010-04-19 2011-10-20 International Business Machines Corporation Architecture Support for Debugging Multithreaded Code
US8489787B2 (en) * 2010-10-12 2013-07-16 International Business Machines Corporation Sharing sampled instruction address registers for efficient instruction sampling in massively multithreaded processors
US8910125B2 (en) * 2012-09-27 2014-12-09 International Business Machines Corporation Monitoring software performance
JP6122749B2 (ja) * 2013-09-30 2017-04-26 ルネサスエレクトロニクス株式会社 コンピュータシステム
US20150269054A1 (en) * 2014-03-18 2015-09-24 Lsi Corporation Multiple Core Execution Trace Buffer

Patent Citations (7)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JPS61290546A (ja) 1985-06-19 1986-12-20 Ricoh Co Ltd マイクロプログラム制御装置のトレ−ス方式
JPS63257039A (ja) 1987-04-14 1988-10-24 Nec Corp アドレストレ−ス装置
JPH0675858A (ja) * 1992-05-13 1994-03-18 Nec Corp キャッシュ内蔵マイクロプロセッサ及びそのトレースシステム
JPH07248939A (ja) * 1994-03-10 1995-09-26 Mitsubishi Electric Corp プロセッサ及びプロセッサシステム
JP2003076577A (ja) * 2001-09-04 2003-03-14 Matsushita Electric Ind Co Ltd デバッグ装置
JP2008140162A (ja) * 2006-12-01 2008-06-19 Hitachi Ltd デバッグ情報収集方法
JP2008293420A (ja) * 2007-05-28 2008-12-04 Denso Corp 電子制御装置

Non-Patent Citations (1)

* Cited by examiner, † Cited by third party
Title
See also references of EP2645254A4

Cited By (4)

* Cited by examiner, † Cited by third party
Publication number Priority date Publication date Assignee Title
JP2017199117A (ja) * 2016-04-26 2017-11-02 日立オートモティブシステムズ株式会社 情報処理装置、情報処理システム
JP2018163656A (ja) * 2017-03-24 2018-10-18 エイアールエム リミテッド 追跡データ表現
JP7116562B2 (ja) 2017-03-24 2022-08-10 アーム・リミテッド 追跡データ表現
JP7327076B2 (ja) 2019-10-17 2023-08-16 株式会社リコー 情報処理装置、情報処理方法、及びプログラム

Also Published As

Publication number Publication date
US20130246736A1 (en) 2013-09-19
EP2645254A1 (en) 2013-10-02
JPWO2012070137A1 (ja) 2014-05-19
EP2645254A4 (en) 2014-01-15
JP5532144B2 (ja) 2014-06-25

Similar Documents

Publication Publication Date Title
US7600155B1 (en) Apparatus and method for monitoring and debugging a graphics processing unit
US8612978B2 (en) Code execution utilizing single or multiple threads
JP4222370B2 (ja) デバッグ支援装置及びデバッグ処理方法をコンピュータに実行させるためのプログラム
JP5532144B2 (ja) プロセッサ、電子制御装置、作成プログラム
US7711990B1 (en) Apparatus and method for debugging a graphics processing unit in response to a debug instruction
US20070226740A1 (en) Method and apparatus for global breakpoint for parallel debugging on multiprocessor systems
JP5905911B2 (ja) シングルステップ実行を用いる診断コード
EP2076837A1 (en) Performing diagnostic operations upon an asymmetric multiprocessor apparatus
US20090271583A1 (en) Monitoring transactions in a data processing apparatus
US7558990B2 (en) Semiconductor circuit device and method of detecting runaway
US20180157571A1 (en) Method for the realistic estimation of function run times in pil simulation
US6910120B2 (en) Speculative counting of performance events with rewind counter
EP3486811A1 (en) Simulation device, simulation system, simulation method and simulation program
JP5699896B2 (ja) 情報処理装置、異常判定方法
US20190034259A1 (en) Systems and Methods for Implementing a Thread Trace Log
JP2004192052A (ja) ソフトウェア処理方法およびソフトウェア処理システム
JP2013061783A (ja) マルチコア・プロセッサ
US9600422B2 (en) Monitoring accesses to memory in a multiprocessor system
JP7095513B2 (ja) マルチコアマイコン、及び車載装置
US20080133838A1 (en) Data processing device
WO2013073009A1 (ja) マイコンシステム、監視マイコン
JP4725240B2 (ja) データトレース方法およびトレースモジュール
JP5425445B2 (ja) 処理制御システム、方法及びプログラム
JP2020086807A (ja) 車両制御装置およびプログラム実行方法
EP0525672A2 (en) Microprocessor with program tracing

Legal Events

Date Code Title Description
121 Ep: the epo has been informed by wipo that ep was designated in this application

Ref document number: 10859993

Country of ref document: EP

Kind code of ref document: A1

ENP Entry into the national phase

Ref document number: 2012545575

Country of ref document: JP

Kind code of ref document: A

WWE Wipo information: entry into national phase

Ref document number: 13885495

Country of ref document: US

WWE Wipo information: entry into national phase

Ref document number: 2010859993

Country of ref document: EP

NENP Non-entry into the national phase

Ref country code: DE