JP2013084218A - Core monitoring device and information processor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a core monitoring device capable of determining a core causing an abnormality while suppressing an increase in software load in a multi-core icon.SOLUTION: A core monitoring device 17 accepts notifications from a plurality of cores at a common cycle and comprises: core identification numeric value generation means 31 that generates a core-specific core identification numeric value (for example, a counter value×ID) for each core when receiving notifications from the cores; total value calculation means 32 that calculates a total value of the core identification numeric values of the plurality of cores; total value storage means 36 that stores the last calculated total value; first difference calculation means 33 that calculates a first difference which is the difference between the total value calculated by the total value calculation means and the total value stored by the total value storage means; first difference storage means 37 that stores the first difference; and second difference calculation means 34 that calculates a second difference which is the difference between the first difference calculated by the first difference calculation means and the first difference stored by the first difference storage means.

Description

  The present invention relates to a core monitoring apparatus that monitors operating states of a plurality of cores.

  In order to improve fuel efficiency, reduce driver's burden, and improve safety, vehicles are equipped with many electronic control devices that apply microcomputers. Since these controls are lost when a microcomputer breaks down, measures are taken to ensure the operation of the microcomputer by monitoring the operation state of the microcomputer. As such a countermeasure, for example, a watchdog timer that confirms that a task is normally executed by a periodic timer reset is known.

  By the way, a multi-core type processor including a plurality of cores has been mounted on a microcomputer (hereinafter referred to as a multi-core microcomputer). As a technique for monitoring the operating state of each core in a multi-core microcomputer, it is conceivable to prepare a watchdog timer for each core. However, if a watchdog timer for each core is arranged, the number and wiring of watchdog timers increase, resulting in an increase in cost.

  Therefore, a technique for monitoring a plurality of cores with a single watchdog timer has been proposed (see, for example, Patent Document 1). In Patent Document 1, the update area of each core secured in each RAM by each core is updated so that each update history can be determined at regular intervals, and at least one core determines the RAM update history. An electronic control device that performs output processing to a monitoring unit is disclosed. In this electronic control device, if even one of the plurality of cores does not update the RAM normally, the core is specified based on the update area, so that only one core with an abnormality can be reset with one watchdog timer.

  In addition to the watchdog timer, a technique for monitoring each other between cores has also been proposed (see, for example, Patent Document 2). Patent Document 2 discloses a monitoring method in which a monitoring unit gives an example to a monitored CPU and monitors the arithmetic function of the CPU based on an answer to the example.

JP 2010-033475 A JP 2010-128627 A

  However, the electronic control device disclosed in Patent Document 1 has a problem that the software load increases because it is necessary to monitor the update area of the RAM and identify an abnormal core in software. That is, conventionally, the process of resetting the watchdog timer has been performed in a software manner. However, if one watchdog timer is used, an extra software load is generated.

  Further, as in Patent Document 2, when a certain core monitors other cores, there is a problem that it is impossible to detect which core has an abnormality between monitored cores. For example, in a multi-core including three cores, it is assumed that the core 1 and the core 2 monitor each other, and the core 1 and the core 3 monitor each other. When the core 1 detects the abnormality of the core 2, the core 1 must notify the core 3 of the abnormality of the core 2 in order for the core 3 to detect the abnormality of the core 2. For this reason, a soft load is generated in order for cores to detect an abnormal core.

  In view of the above problems, an object of the present invention is to provide a core monitoring apparatus capable of discriminating an abnormal core while suppressing a software load increase in a multi-core microcomputer.

  The present invention is a core monitoring device that receives notifications from a plurality of cores in a common cycle, and when receiving notifications from the cores, a core identification value generation unit that generates a core identification value unique to each core for each core; A total value calculating means for calculating a total value obtained by summing the core identification values of a plurality of cores, a total value storing means for storing the last calculated total value, and a total value calculated by the total value calculating means First difference calculation means for calculating a first difference that is a difference from the total value stored in the total value storage means, and first difference storage means for storing the first difference calculated last. And a second difference calculation for calculating a second difference which is a difference between the first difference calculated by the first difference calculation means and the first difference stored in the first difference storage means. Means.

  In a multi-core microcomputer, it is possible to provide a core monitoring device capable of discriminating an abnormal core while suppressing a software load increase.

It is an example of the figure explaining the general | schematic characteristic of a microcomputer. It is an example of the hardware block diagram of the microcomputer mounted in a vehicle. It is an example of the figure which illustrates typically the relation between the task of cores 1-n, and a counter history part. It is a figure which shows an example of a structural example of a counter log | history part. It is a figure which shows an example of a structural example of a counter log | history part. It is a figure explaining an example of transition of a counter value, an integrated value, a total value, the 1st difference, and the 2nd difference. It is a figure explaining an example of transition of a counter value, a total value, a total value, the 1st difference, and the 2nd difference in case of four cores. It is a figure explaining an example of transition of a counter value, integrated value, total value, the 1st difference, and the 2nd difference in case ID is discontinuous. It is a figure explaining an example of transition of a counter value, a total value, a total value, the 1st difference, and the 2nd difference when a plurality of cores run away simultaneously. It is a figure which shows an example of a structural example of a counter log | history part. It is a figure which shows an example of a structural example of a counter log | history part.

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

FIG. 1 is an example of a diagram illustrating schematic features of the microcomputer according to the present embodiment. First, as a premise, in a multi-core microcomputer having a plurality of cores, each core is assigned a unique ID so that the OS (Operating System) and the cores identify each other.
(i) Each of the three cores 1 to 3 has a counter mounted in software, and each counts up independently in the same cycle. The counted value is called a counter value.
(ii) The cores 1 to 3 calculate “counter value × ID”. Since the ID is different, the calculation result is different for each core even if the counter value is the same.
(iii) A circuit that replaces the watchdog timer (a counter history section described later) performs the following calculation.
-Calculate the total value of the calculation results notified from the cores 1 to 3.
Calculate the first difference that is the difference between the previous and current total values.
Calculate the second difference, which is the difference between the first difference and the previous difference.

As shown in FIG. 1A, when no core is running out of control, “6” is always obtained for the first difference and “0” is always obtained for the second difference.
(iv) For example, when the core 2 runs out of control, the core 2 cannot update “counter value × ID”, so the calculation result of the core 2 in the above circuit remains “4”.
(v) Therefore, the total value becomes smaller than the normal value due to the runaway of the core 2. The first difference is also reduced because the core 2 does not update “counter value × ID”. Here, the decrease in the first difference is equal to the ID of the core 2. For this reason, as shown in FIG. 1B, the ID of the core that has runaway in the second difference is obtained.

  Thus, since the runaway core does not update “counter value × ID”, the total value becomes small, and the core ID of the runaway core 2 appears in the second difference, which is the decrease of the first difference. If each core refers to this second difference, each core can detect the runaway core.

[Configuration example]
FIG. 2 is an example of a hardware configuration diagram of a microcomputer mounted on the vehicle. The microcomputer 100 is assumed to be mounted on an ECU (Electronic Control Unit), but its application is not limited to a vehicle. There are various types of ECUs mounted on the vehicle, such as an engine ECU, a brake ECU, a body ECU, a navigation ECU (AV / information processing ECU), and a gateway ECU, depending on main functions. The microcomputer 100 of the present embodiment can be mounted without being affected by the difference in ECU functions. Further, the microcomputer 100 may be mounted on an ECU in which a plurality of functions are integrated into one.

  The microcomputer 100 includes a processor 11, a ROM 12, an INTC 13, a RAM 14, a DMAC 15, and an I / O bridge 16 connected to the main bus 21. The counter history unit 17 is connected to the I / O bridge 16 via the peripheral bus 22. An ADC (Analog to Digital Converter) 18 and a CAN controller 19 are connected.

  The processor 11 has at least two or more cores 1 to n, and each of the cores 1 to n has a general arithmetic function (for example, an arithmetic device such as an ALU, an instruction buffer, an instruction decoder, a register set, etc.). Yes.

  The ROM 12 is a nonvolatile memory such as a flash memory, and stores a program 30 executed by the processor 11, initial values, parameters, and the like.

  The INTC 13 arbitrates based on the priority of the peripheral device and notifies the processor 11 of the interrupt request input from the peripheral device via the IRQ or other interrupt terminal. As a result, the processor 11 reads an instruction at an address determined according to the interrupted peripheral device from the ROM 12 and executes the process.

  The RAM 14 is a work area for the processor 11 to execute the program 30. The processor 11 reads the program 30 from the ROM 12, and reads the data from the RAM 14 via the data bus if necessary and executes the program 30. The DMAC 15 transmits data from the RAM 14 to the peripheral device via the I / O bridge 16 according to an instruction from the processor 11. In response to an instruction from the processor 11 interrupted by the peripheral device, data is received from the peripheral device via the I / O bridge 16 and written to the RAM 14.

  The I / O bridge 16 is a multiplexer, a bridge circuit, or the like, and is connected to the counter history unit 17, the ADC 18, and the CAN controller 19 for each channel, and transmits / receives data to / from these peripheral devices. The counter history unit 17 acquires “counter value × ID” (or counter value) of the cores 1 to n and calculates the total value, the first difference, and the second difference. Details will be described later.

  The ADC 18 converts analog signals detected by various sensors into digital signals. The ADC 18 notifies the end of conversion to the processor 11 via the INTC 13. The CAN controller 19 is a communication device for communicating with other ECUs connected via an in-vehicle network. When receiving a communication data transmission request from the processor 11, the CAN controller 19 stores the CAN ID and data in each field of the frame and outputs them to the CAN bus. In addition, when the CAN controller 19 detects the communication data of the CAN ID to be received, the CAN controller 19 captures the data and interrupts it to the processor 11 via the INTC 13 to notify it.

  As the watchdog timer, the counter history unit 17 may be mounted in the same microcomputer. However, the counter history unit 17 may be mounted in another microcomputer or another ECU connected via an in-vehicle LAN such as a CAN (Controller Area Network). In this case, the counter history unit 17 can be shared by a plurality of microcomputers.

[Processing such as counting up the counter value]
Each of the cores 1 to n performs processing for controlling a dedicated in-vehicle device. This process or a program that executes this process is called a main task. In anomaly monitoring using a general watchdog timer, the cores 1 to n periodically reset the watchdog timer so that the watchdog timer does not overflow. This reset is often performed in a task called an idle task. In the present embodiment, instead of the core executing the idle task and resetting the watchdog timer, a process of notifying “counter value × ID” (or counter value) is performed.

  FIG. 3 is an example of a diagram for schematically explaining the relationship between the tasks of the cores 1 to n and the counter history unit 17. As shown in FIG. 3, the counter history unit 17 may or may not have multipliers 1 to n.

  Non-overlapping IDs are assigned to the cores 1 to n. The ID is registered in the core ID register 40 of each of the cores 1 to n by the OS or the program 30 as an initial process when the microcomputer 100 is activated. The ID is fixed for each core, but may be different for each initial process. Moreover, it is not necessary to be a serial number as shown.

  The timer 41 periodically interrupts the processor 11 at predetermined time intervals (for example, several milliseconds). Each core 1 to n executes the main task by interruption. When the cores 1 to n finish executing the main task, the cores 1 to n subsequently execute the idle task. Since the main task performed by each core has different processing contents, the execution completion timing may be different even if the main task is executed in the same cycle. However, the frequency with which the main task and the idle task are executed is common to the cores 1 to n.

  Therefore, each of the cores 1 to n executes an idle task with a common period. That is, even if the main tasks executed by the cores 1 to n are different, the frequency with which the idle task counts up the counter value is common.

  The idle task performs a process of counting up the counter value by a predetermined value instead of the process of resetting the watchdog timer. Since the count up of the counter value is common to each core, the counter values 1 to n are equal in the cores 1 to n if the core does not run away. The number of count-ups per time may be any number as long as it is a natural number common to each core, but is assumed to be “1” here. Therefore, the counter value increases by one every time the idle task is called.

  The idle task notifies the counter history unit 17 of its own “counter value × ID”. Alternatively, the idle task notifies the counter history unit 17 of the counter value together with its own ID. As described above, the “counter value × ID” process is a process for identifying each of the cores 1 to n, but either the core or the counter history unit 17 may perform the process. Details will be described later.

  The idle task stores the counter value in the local RAMs and registers of the cores 1 to n, and thereafter, if there is no other processing, the cores 1 to n end the idle task. Next time, when the main task is activated by a periodic interrupt, the idle task reads the last stored counter value and performs the process of counting up again.

  The access from the cores 1 to n to the counter history unit 17 is in the order of the main bus 21, the I / O bridge 16, the peripheral bus 22, and the counter history unit 17. Conversely, when the counter history unit 17 accesses the processor 11, the INTC 13 and the processor 11 are in this order.

  In addition, the idle task is not necessarily called from the main task and executed, and the counter value may be accumulated in the main task. Further, the idle task may be directly activated by a periodic interrupt.

[Configuration Example 1 of Counter History Section]
FIG. 4 is a diagram illustrating an example of a configuration example of the counter history unit 17. The configuration of FIG. 4 is a configuration when the counter history unit 17 calculates “counter value × ID”.

  The counter history unit 17 includes a multiplier 31 (referred to as multipliers 1 to n when distinguished), an adder 32, a subtractor 33, a total value storage unit 36, a first difference storage unit 37, a second difference storage unit 38, A comparator 35 and a core ID disclosure register 39 are included. Note that the multiplier 31, the adder 32, and the subtractors 33 and 34 are illustrated separately for convenience of explanation, and may be configured by an integrated arithmetic unit capable of addition, subtraction, and multiplication.

  The counter values sent from the cores 1 to n and the IDs 1 to n of the cores 1 to n are supplied to the multipliers 1 to n. The multipliers 1 to n multiply the core counter value and the core ID for each core, and supply each to the adder 32.

  The adder 32 adds the multiplication results of all the multipliers 1 to n. This addition result is the total value. The adder 32 supplies the latest total value to the subtracter 33.

Next, the subtractor 33 performs the following processing.
Read the previous total value from the total value storage unit 36.
The latest total value acquired from the adder 32 is stored in the total value storage unit 36.
-Subtract the previous total from the latest total.
This subtraction result is the first difference. The subtractor 33 supplies the latest first difference to the subtracter 34.

Next, the subtractor 34 performs the following processing.
Reads the previous first difference from the first difference storage unit 37.
The latest first difference acquired from the subtracter 34 is stored in the first difference storage unit 37.
-The absolute value is obtained by subtracting the previous first difference from the latest first difference.
This subtraction result is the second difference.

  Next, the comparator 35 determines whether or not the second difference is zero. In the case of zero, there is no runaway core in cores 1 to n, and each core 1 to n is normally counting up the counter value. Therefore, the counter history unit 17 does not need to do anything, but in the figure, the second difference is stored in the second difference storage unit 38 for comparison.

  When the second difference is not zero, the cores 1 to n have runaway cores. For this reason, the comparator 35 stores the second difference in the core ID disclosure register 39. The core ID disclosure register 39 is a storage means (for example, a register) that each core refers to. When the second difference is other than zero, the second difference becomes the core ID of the runaway core, so that each of the cores 1 to n can easily determine which core has runaway.

Similarly to the watchdog timer, the counter history unit 17 performs the following process when the second difference is not zero.
(A) An interrupt signal is output to the processor 11. As a result, each of the cores 1 to n of the processor 11 reads out the second difference (core ID) from the core ID disclosure register 39 as a process corresponding to the interrupt, and identifies the runaway core. Also, fail-safe processing (distributing processing to another core, switching masters, etc.) according to the runaway core can be performed.
(B) Notifying another ECU via the CAN controller 19.
(C) Shut off the power supply. Reset the runaway core (internal reset that resets only the core).

  In this way, the core in which each of the cores 1 to n runs out of control without increasing the software processing load almost simply by causing the idle task to perform the process of counting the counter value instead of resetting the watchdog timer. Can be identified. Any number of cores may be used as long as there is one counter history unit 17.

[Configuration Example 2 of Counter History Section]
FIG. 5 is a diagram illustrating an example of a configuration example of the counter history unit 17. The configuration of FIG. 5 is a configuration when the idle task of each core calculates “counter value × ID”. For this reason, the counter history unit 17 in FIG. 5 does not have the multipliers 1 to n. The other configuration is the same as that of FIG.

  The adder 32 is supplied with the calculation result of “counter value × ID” sent from the cores 1 to n. The adder 32 adds the calculation results of “counter value × ID” of all the cores 1 to n. This addition result is the total value. The adder 32 supplies the latest total value to the subtracter 33.

  Subsequent processing, that is, processing by the subtractor 33, subtractor 34, and comparator 35 is the same as that in FIG.

  Comparing FIG. 5 and FIG. 4, since n multipliers 1 to n are unnecessary in FIG. 5, the circuit scale of the counter history unit 17 can be reduced. Therefore, when the number of cores is large and the multipliers 1 to n cannot be aggregated, the aspect of FIG. 5 is more effective.

[Transition of counter value, etc.]
FIG. 6 is a diagram for explaining an example of the transition of the counter value, the integrated value, the total value, the first difference, and the second difference. The left figure shows the transition when normal, and the right figure shows the transition when the core 2 runs away. Note that whether each core 1 to n transmits “counter value × ID” or “counter value” does not affect the transition of the counter value.

  A counter value, an integrated value, a total value, a first difference, and a second difference are illustrated for each time t0 to t4. Times t0 to t4 represent the elapse of an interval (for example, several milliseconds) at which the timer 41 periodically interrupts each of the cores 1 to n. The counter value “1, 2, 3, 4, 5” increases by one each time. Although there is only one counter value, each of the cores 1 to n is actually synchronized by a periodic interrupt, so that each idle task counts the counter value.

  Since the core 1 or the multiplier 1 periodically calculates “ID: 1 × counter value”, the calculation result is “1, 2, 3, 4, 5”.

  Since the core 2 or the multiplier 2 periodically calculates “ID: 2 × counter value”, the calculation result is “2, 4, 6, 8, 10”.

  Since the core 3 or the multiplier 3 periodically calculates “ID: 3 × counter value”, the calculation result is “3, 6, 9, 12, 15”.

  Further, since the total value is the sum of the integrated values at times t0 to t4, it becomes an equality series (first term 6, tolerance 6) that increases by “6”, such as “6, 12, 18, 24, 30”. . Therefore, the first difference is “6, 6, 6, 6, 6” in which the tolerance “6” always appears. For this reason, the second difference is always “0”, but it is not calculated because there is no first difference to be calculated at time t0. Therefore, “−, 0, 0, 0, 0” is obtained.

  Thus, if the core does not run away, the first difference is always the tolerance “6”, so the second difference is “0”, and the counter history unit 17 can confirm that the core is not running away.

  Next, a case where any one of the cores 1 to n runs away will be described. Here, it is assumed that the core 2 runs away from time t2 to t3. The counter values of the cores 1 and 3 are as described in the left diagram of FIG. On the other hand, since the core 2 has run away, the idle task cannot count up the counter value, and the counter value of the core 2 becomes “1, 2, 3, 3, 3” (not shown). Further, if the core 2 runs away, the counter history unit 17 cannot be notified of the counter value (or ID: 2 × counter value). Therefore, after the runaway of the core 2, “6” is supplied to the adder 32 regardless of the passage of time.

  Therefore, the total value is “6, 12, 18, 22, 26”, and the tolerance after time t3 is 4. The reason why the tolerance decreases from “6” to “4” is because “ID: 2 × counter value” of the core 2 is not updated.

  Since the total value has decreased at time t3, the first difference between times t3 and t4 is also reduced to “6, 6, 6, 4, 4”. As a result, the second difference is “−, 0, 0, 2, 0”. “2” appears in the second difference only at time t3 immediately after the core 2 runs away. This “2” is nothing but the ID of the core 2 (= 2).

  Therefore, the counter history unit 17 can specify the runaway timing of the core based on the time when the second difference becomes other than “0”, and can identify the core that has runaway based on the value of the second difference. Since the counter history unit 17 stores the value of the second difference in the core ID disclosure register 39, it is possible to detect the core 2 in which the other non-runaway cores 1 and 3 have runaway.

  FIG. 7 is a diagram for explaining an example of the transition of the counter value, integrated value, total value, first difference, and second difference when there are four cores 1 to n. The left figure shows the transition when normal, and the right figure shows the transition when the core 4 runs away.

Since the transition when the cores 1 to n do not run away is the same as the left diagram of FIG.
The total value is an arithmetic series (first term 10, tolerance 10) that increases by “10”, such as “10, 20, 30, 40, 50”. Therefore, the tolerance “10” always appears in the first difference as “10, 10, 10, 10, 10”. Therefore, the second difference is “−, 0, 0, 0, 0”.

  Next, it is assumed that the core 4 has runaway between times t1 and t2. The counter values of the cores 1 to 3 are as described in the left diagram of FIG. On the other hand, since the core 4 has runaway, the idle task cannot count up the counter value, and the counter value of the core 4 becomes “1, 2, 2, 2, 2” (not shown). If the core 4 runs away, the counter history unit 17 cannot be notified of the counter value (or ID = 4 × counter value). Therefore, “8” is supplied to the adder 32 regardless of the passage of time.

  Therefore, the total value is “10, 20, 26, 32, 38”, and the tolerance after time t2 is 6. The reason why the tolerance decreases from “10” to “6” is because the integrated value of the core 4 is not updated.

  Since the total value decreased at time t2, the first difference between times t2, t3, and t4 is also reduced to “10, 10, 6, 6, 6”. As a result, the second difference is “−, 0, 4, 0, 0”. “4” appears in the second difference only at time t2 immediately after the core 4 runs away. This “4” is nothing but the ID of the core 4 (= 4). Therefore, it can be seen that the runaway core and its timing can be specified regardless of the number of cores.

  FIG. 8 is a diagram for explaining an example of the transition of the counter value, the integrated value, the total value, the first difference, and the second difference when the ID is discontinuous. The left figure shows the transition when normal, and the right figure shows the transition when the core 2 runs away. A description of the transition in the normal state is omitted.

  In the figure, the IDs of the cores 1 to 3 are 6, 11, and 101, respectively. When the core 2 runs away between times t2 and t3, the counter value of the core 2 becomes “11, 22, 33, 33, 33” because the core 2 has runaway and cannot count up. Therefore, “33” is supplied to the adder 32 regardless of the passage of time.

  Therefore, the total value is “118, 236, 354, 461, 568”, and the tolerance after time t3 is “107”. The reason why the tolerance decreases from “118” to “107” is because the integrated value of the core 2 is not updated.

  Since the total value decreased at time t3, the first difference between times t3 and t4 is also reduced to “118, 118, 118, 107, 107”. As a result, the second difference is “−, 0, 0, 11, 0”. “11” appears in the second difference only at time t2 immediately after the core 2 runs away. This “11” is nothing but the ID 2 of the core 2. Therefore, if the IDs given to the cores 1 to n are unique, the runaway core and its timing can be identified regardless of the value of the ID.

  FIG. 9 is a diagram for explaining an example of the transition of the counter value, integrated value, total value, first difference, and second difference when a plurality of cores run away simultaneously. In FIG. 9, both the left diagram and the right diagram show transitions when the cores 1 and 2 run away.

  In the left figure, the IDs of the cores 1 to 3 are ID = 1, 2, and 3, respectively. Assume that both cores 1 and 2 run away between times t3 and t4. As described above, the ID of the core that has runaway due to the runaway of the core appears in the second difference, but when multiple cores run away at the same time, the total of the IDs of the multiple runaway cores appears in the second difference . For this reason, the second difference at time t3 is “3”.

  However, since the ID of the core 3 is “3”, the core 3 may erroneously detect that the core 3 has run away. Such false detection can be avoided by adjusting the IDs of the cores 1 to n by a developer or the like.

  In the right diagram of FIG. 9, the IDs of the cores 1 to 3 are ID = 1, 2, and 4, respectively. Similarly, if the cores 1 and 2 run out of control between times t3 and t4, the second difference at time t3 is “3”. Since there is no core whose ID is “3”, the core 3 can detect that two cores (cores 1 and 2) whose total ID is “3” have runaway. There are only “1” and “2” combinations of IDs for which the total ID is “3”. Therefore, the core 3 can detect that the cores 1 and 2 have run away.

Similarly, multiple cores that have runaway at the same time can be identified.
・ When cores 1 and 3 runaway, the second difference is “5”, but there is no core with ID = 5, and the combination of IDs where the total ID is “5” is only “1” and “4” Absent. Therefore, the core 2 can detect that the cores 1 and 3 have run away.
・ When cores 2 and 3 run away, the second difference is “6”, but there is no core with ID = 6, and the combination of IDs with a total ID of “6” is only “2” and “4” Absent. Therefore, the core 1 can detect that the cores 2 and 3 have run away.

  Thus, it is possible to cope with the runaway of a plurality of cores by appropriately setting the IDs of the cores 1 to n. Specifically, the developer or the like sets the IDs of the cores 1 to n so that the sum of the IDs of any two sets of cores does not match the IDs of the other cores. Even when three or more cores run away at the same time, the ID of each core may be set so that the sum of the IDs of any three sets of cores does not match the IDs of other cores.

  Since the counter value is incremented by one, ID appears in the second difference, but the counter value may be incremented by two. In this case, the ID × 2 of the runaway core appears in the second difference. Therefore, if each core 1 to n is divided by “2”, the ID of the runaway core can be obtained. As described above, if the increment value is constant and known, the count value for one count-up may not be “1”.

[Switching between master and slave]
The multi-core microcomputer 100 may employ a configuration in which one of a plurality of cores is set as a master and the rest are set as slaves, and the master monitors the slaves. In this case, if the master goes out of control, there is a possibility that inconveniences such as the absence of the core monitoring the slave and the monitoring of the core are not performed.

  In general, each of the cores 1 to n determines a master core as follows. For example, each of the cores 1 to n refers to (exchanges) the IDs of other cores at the time of activation, and the smallest core takes over the master. Therefore, if there is a core with core ID = 1 (referred to as core 1), core 1 with ID = 1 takes over the master. The core 1 stores its own ID in a register that stores the master core ID, and notifies the other cores 2 to n of the ID (= 1) of the master core 1. Each of the cores 2 to n stores ID = 1 of the core 1 in a register that stores the core ID of the core that is the master.

  When the core 1 runs out of control, the other cores 2 to n detect that the core 1 has gone out of control with reference to the core ID disclosure register 39. The runaway core 1 is powered off or reset. When the core 1 is reset, it is considered that the core 1 also returns. However, since the core that has once runaway may run away again, it is preferable that another core 2 to n takes over the master.

  Therefore, the other cores 2 to n that have detected the runaway of the core 1 run away from the master core 1 stored in the register, and therefore determine the next master core with reference to the ID of the other core. . In this case, the core 2 having the smallest ID takes over the master.

  The core 2 stores its own ID in a register that stores the core ID of the master, and notifies the other cores 3 to n of ID = 2. Each core 3-n stores the ID 2 of the core 2 in a register that stores the core ID of the master core.

  In this way, since the cores in which the cores 1 to n have runaway can be identified, if the runaway core is the master, other cores can autonomously switch from the slave to the master.

  The core 2 that has become the master executes tasks necessary for the master. For example, a process of resetting the microcomputer itself, a process of disconnecting or starting the core, a process of setting a clock frequency, and the like can be performed as necessary.

  As described above, the microcomputer 100 according to the present embodiment can obtain the “counter value × ID” for each core, add them up, and specify the runaway core only by performing subtraction twice. Since the idle task only needs to be counted up or multiplied by an integer after counting up, the software load is hardly increased.

  In the first embodiment, the cores 1 to n count up at least the counter value in software, but in this embodiment, the microcomputer 100 in which the counter history unit 17 counts up the counter value will be described.

[Counter history section where counter circuits 1 to n count up by the same amount]
FIG. 10 is a diagram illustrating an example of a configuration example of the counter history unit 17. In the first embodiment, the idle task counts up the counter value, but in the present embodiment, the counter history unit 17 counts up. For this reason, the counter history unit 17 in FIG. 10 includes a counter circuit 42 (hereinafter, when distinguished, the counter circuits 1 to n).

  The idle tasks of the cores 1 to n periodically notify the counter history unit 17 using a periodic interrupt by a timer. The counter history unit 17 discriminates the notification source cores 1 to n and causes the counter circuits 1 to n corresponding to the cores 1 to n to count up the counter value. Each of the counter circuits 1 to n counts up the counter value by the same amount (for example, one by one). The IDs of the cores 1 to n are included in the periodic notification. Therefore, the idle task only needs to perform a simple process of notifying the core ID.

  The multipliers 1 to n are supplied with the counter values sent from the counter circuits 1 to n and the IDs 1 to n of the cores 1 to n. As a process for identifying each core, the multipliers 1 to n multiply the counter value and the core ID for each core, and supply each to the adder 32. The subsequent processing is the same as in the first embodiment, and the adder 32 calculates the total value of “counter value × ID” acquired from the multipliers 1 to n. The subtractor 33 calculates a first difference that is the difference between the newest total value and the previous total value, and stores the first difference in the first difference storage unit 37. The subtractor 34 calculates a second difference, which is the difference between the newest first difference and the previous first difference, and stores it in the second difference storage unit 38.

  When the core runs away, the idle task executed by the core cannot notify the counter history unit 17 of the core ID, and the counter circuit 40 corresponding to the core does not count up. That is, the same situation as the case where the runaway core in Example 1 does not count up occurs. For this reason, the ID of the core that has runaway appears in the second difference, and other cores that have not runaway can identify the core that has runaway by the core ID disclosure register 39.

  Therefore, by disposing the counter circuits 1 to n corresponding to the cores 1 to n in the counter history unit 17, the idle task only needs to perform a simple process similar to the reset of the conventional watchdog timer, Cost increase can be suppressed.

[Counter history section in which counter circuits 1 to n increment different values]
Further, in the same configuration, the multiplier 31 can be omitted.
FIG. 11 is a diagram illustrating an example of a configuration example of the counter history unit 17. In FIG. 11, the counter circuits 1 to n perform processing for identifying each core. Specifically, the counter circuits 1 to n count up different values from each other.

  The idle tasks of the cores 1 to n periodically notify the counter history unit 17 using a periodic interrupt by a timer. The counter history unit 17 discriminates the notification source core and causes the counter circuit corresponding to the core to count up the counter value.

  Each of the counter circuits 1 to n counts up the counter value by a different value. For example, the counter circuit 1 counts up by “1”, the counter circuit 2 counts up by “2”, and the counter circuit n counts up by “n”. By such count-up, a process for identifying each core can be realized as in “counter value × ID”.

  The counter value sent from the counter circuits 1 to n is supplied to the adder 32. The adder 32 adds up the counter values of the counter circuits 1 to n and stores the total value in the total value storage unit 36.

  The subsequent processing is the same as in the first embodiment, and the subtractor 33 calculates a first difference that is the difference between the newest total value and the previous total value, and stores the first difference in the first difference storage unit 37. The subtractor 34 calculates a second difference, which is the difference between the newest first difference and the previous first difference, and stores it in the second difference storage unit 38.

  When the core runs away, the counter circuit corresponding to the core does not count up. Therefore, the second difference shows the count-up amount of the counter circuit 42 corresponding to the runaway core. Since the count-up amount is fixed (unique) for each core, other cores that have not runaway can identify the runaway core.

  Accordingly, even if the idle task does not count up, the counter history unit 17 having the counter circuit 42 can identify the runaway core.

11 processor 17 counter history unit 30 program 31 multiplier 32 adder 33, 34 subtractor 35 comparator 36 total value storage unit 37 first difference storage unit 38 second difference storage unit 39 core ID disclosure register 40 core ID register 41 Timer 42 Counter circuit 100 Microcomputer

Claims (8)

A core monitoring device that receives notifications from a plurality of cores in a common cycle,
When receiving a notification from the core, core identification value generation means for generating a core identification value unique to each core for each core;
A total value calculating means for calculating a total value obtained by totaling the core identification values of a plurality of cores;
Total value storage means for storing the finally calculated total value;
First difference calculating means for calculating a first difference which is a difference between the total value calculated by the total value calculating means and the total value stored in the total value storing means;
First difference storage means for storing the first difference calculated last;
A second difference calculating means for calculating a second difference which is a difference between the first difference calculated by the first difference calculating means and the first difference stored in the first difference storing means; ,
A core monitoring device.   The core identification numerical value generation means acquires a counter value that is periodically counted up by the core together with core identification information, and generates the core identification numerical value using the core identification information and the counter value. Item 2. The core monitoring apparatus according to Item 1.   The core monitoring apparatus according to claim 1, wherein the core identification numerical value generation unit acquires the core identification numerical value generated by using a counter value counted by each core periodically and core identification information. The core identification numerical value generating means has a count circuit that counts the number of notifications of core identification information periodically notified for each core,
The core identification value for each core is generated from the counter value of the count circuit and the core identification information.
The core monitoring apparatus according to claim 1.   5. The core monitoring apparatus according to claim 2, wherein the core identification value is a multiplication value obtained by multiplying a counter value and core identification information.   The core identification value generation means is a count circuit that counts the number of periodic notifications of core identification information by converting it into different increments for each core, and counts the counter value of the count circuit for the core identification value of each core The core monitoring apparatus according to claim 1, wherein:   7. The apparatus according to claim 1, further comprising: a second difference disclosure unit that determines whether or not the second difference is zero and discloses the second difference when the second difference is not zero. The core monitoring device described. A core monitoring device according to any one of claims 1 to 7,
A processor having a plurality of cores;
Means for storing a program executed by the core;
An information processing apparatus.

Images