JP2011237929A - Multi-core processor - Google Patents

Abstract

PROBLEM TO BE SOLVED: To provide a multi-core processor capable of reliably arbitrating accesses to a shared access object.SOLUTION: A multi-core processor is configured such that a message queue for defining the descriptions and order of accesses to a specific shared access object is set in a memory that can be read from or written to by a plurality of processor cores. The plurality of processor cores exclusively write job information into the message queue according to a predetermined write control on the message queue, where the job information is related to a process including the access to the specific shared access object, from among processes included in tasks to be executed by the processor cores. At least one processor core, among the plurality of processor cores intended for executing the access to the specific object, carries out processes including the access to the specific shared access object in accordance with the job information written in the message queue.

Description

  The present invention relates to a multi-core processor in which a plurality of processor cores can perform processing independently.

  Conventionally, a multicore processor having a plurality of processor cores (CPU cores) in one package has been put into practical use. In a multi-core processor, each core can independently perform arithmetic processing and the like. Therefore, high-speed processing can be realized particularly when applied to a device that executes a plurality of tasks simultaneously, such as an in-vehicle control device in which a plurality of functions are integrated.

  An invention relating to a control device for a multi-core CPU for a moving body related to this is disclosed (for example, see Patent Document 1). In this control device, an abnormality detection unit that detects that an abnormality that reduces processing capacity has occurred, a processing priority storage unit that stores priority of processing assigned to a plurality of CPU cores, and a plurality of CPU cores A processing capacity adjusting means for adjusting each processing capacity, and when an abnormality is detected by the abnormality detecting means, the process having the highest priority stored in the processing priority storing means is assigned. Control is performed to reduce the processing capacity of CPU cores other than the CPU core.

  By the way, in a multi-core processor, there is usually a shared access target such as a nonvolatile memory. For this reason, it is necessary to control so that a plurality of processor cores do not access such a shared access target at the same time.

  The multi-core processor described in Patent Document 2 includes a plurality of reconfigurable devices that can dynamically reconfigure a circuit configuration based on circuit information, and one of the plurality of processor cores uses the reconfigurable device. In this case, exclusive control is performed by storing in the memory lock information indicating that the reconfigurable device is locked to one of the processor cores.

JP 2008-097280 A JP 2010-045578 A

  However, when exclusive control like the multi-core processor described in the above-mentioned conventional patent document 2 is performed on a shared access target, each processor core must refer to the lock information, and there is a possibility that the processing is delayed. Further, it is necessary to perform exclusive control with respect to access to the memory storing the lock information.

  Furthermore, as a result of one of the processor cores occupying the shared access target, the throughput between the processor cores may be biased.

  The present invention has been made to solve such problems, and a main object of the present invention is to provide a multi-core processor capable of reliably performing arbitration related to access to a shared access target.

In order to achieve the above object, one embodiment of the present invention provides:
A multi-core processor in which a plurality of processor cores can perform processing independently,
A message queue for defining the content and order of access to a specific shared access target is set on the memory accessible by the plurality of processor cores,
The plurality of processor cores exclusively write job information related to access to the specific shared access target in the message queue according to predetermined write control on the message queue,
At least one specific target access execution processor core among the plurality of processor cores executes processing including access to the specific shared access target in accordance with job information written in the message queue.
It is a multi-core processor.

  According to this aspect of the present invention, a plurality of processor cores exclusively write job information related to access to a specific shared access target in a message queue in accordance with predetermined write control, and the specific target access execution processor core Since access to a specific shared access target is executed on behalf of the processor core that has written the job information in accordance with the job information written in the message queue, arbitration relating to access to the shared access target can be performed reliably.

In one embodiment of the present invention,
The job information includes information on processing priority,
It is preferable that the specific target access execution processor core changes the order of performing the processing based on information on processing priority included in the job information.

  In this way, the processing included in the job information can be executed in the processing order corresponding to the priority.

In one embodiment of the present invention,
Predetermined write control for the message queue is performed sequentially according to a predetermined order from a processor core that has finished writing job information to the message queue to a processor core that next writes job information to the message queue. Thus, exclusive control may be realized.

In one embodiment of the present invention,
The predetermined write control for the message queue is sequentially written from the write control processor core to each processor core according to a predetermined order held in at least one of the plurality of processor cores. Exclusive control may be realized by performing a notification of possible.

In one embodiment of the present invention,
The writable notification may be performed by a software interrupt, or by designating a processor core to which job information is written next in the message queue on a memory accessible by the plurality of processor cores. It may be a thing.

One embodiment of the present invention includes
The processor cores mounted on a vehicle may perform processing for vehicle control.

  ADVANTAGE OF THE INVENTION According to this invention, the multi-core processor which can perform the arbitration regarding access to a shared access object reliably can be provided.

1 is a system configuration example of a multi-core processor 1 according to a first embodiment of the present invention. It is a conceptual diagram which shows the concept of the message queue 42 with the state of the job stored, and the change of a process main body. It is a figure which shows the data structure of the message information input from the request | requirement reception part, and the job information which gave job ID to this and was stored in the message queue. It is a figure which shows the structure of the queue buffer which can implement | achieve the message queue 42 concerning a present Example. FIG. 5 is a diagram illustrating a result of job sorting unit 36 rearranging job information from the state illustrated in FIG. 4. It is a timing chart which shows the flow of a process when message information is written in the message queue by the request reception part of each processor core. It is a flowchart which shows the flow of the request reception process which the request reception part of each processor core performs. 4 is a flowchart showing a flow of initialization processing executed when the multi-core processor 1 is started up or recovered from an error. 4 is a flowchart showing a flow of job execution processing executed by a job execution unit 37. This flow is repeatedly executed, for example, periodically. 7 is a flowchart showing a flow of job start processing executed by a job execution unit 37. 7 is a flowchart showing a flow of job end processing executed by a job execution unit 37. In the conventional multi-core processor, it is a figure which shows a mode that interference arises when a some processor core accesses a specific shared access object simultaneously. It is a figure which shows a mode that generation | occurrence | production of interference is avoided in the multi-core processor 1 of 1st Example. It is a sequence diagram which shows a mode that the control with respect to the message queue 42 is performed between each core. 3 is a flowchart showing a flow of resource access wait processing executed by a scheduler 12 of a processor core 10. 4 is a flowchart showing a flow of resource access distribution processing executed by a scheduler 12 of the processor core 10. 4 is a flowchart showing a flow of resource occupation start processing executed by schedulers 22 and 32 of processor cores 20 and 30. 4 is a flowchart showing a flow of resource occupation end processing executed by schedulers 22 and 32 of processor cores 20 and 30. 4 is a flowchart showing a flow of resource access end processing executed by a scheduler 12 of the processor core 10. It is a partial block diagram which can be added as an additional function to 1st Example and 2nd Example. It is a timing chart which shows the flow of a process when each processor core accesses an I / O port. It is a partial block diagram which can be added as an additional function to 1st Example and 2nd Example.

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

<First embodiment>
A multi-core processor according to a first embodiment of the present invention will be described below with reference to the drawings. The multi-core processor of this embodiment is capable of processing independently by a plurality of processor cores, and executes a plurality of tasks at the same time, such as an in-vehicle controller integrated with a plurality of functions. It is suitably applied to the device.

[Constitution]
FIG. 1 is a system configuration example of a multi-core processor 1 according to the first embodiment of the present invention. The multi-core processor 1 is an example of a plurality of processor cores (the number is not particularly limited, but three in this specification) 10, 20, and 30, a shared memory 40, and a specific shared access target. Non-volatile memory 50. The nonvolatile memory 50 is, for example, an EEPROM (Electrically Erasable and Programmable Read Only Memory) or a flash memory.

  Each processor core fetches an instruction sequence stored in a program memory (not shown) and temporarily stores it, an instruction decoder that decodes the instruction sequence stored in the instruction sequence, and is decoded by the instruction decoder An arithmetic unit for executing an instruction, a register for storing an operation result by the arithmetic unit, a primary cache memory, and the like are included, and each executes processing related to a specific task.

  In the present embodiment, the processor core 10 includes a timing generation unit 11, a scheduler 12, functional modules 13 and 14, and a request reception unit 15 as functional blocks that function by executing instructions as described above. Here, the functional module is a processing unit constituting various tasks that the multi-core processor 1 should originally execute.

  Further, the processor core 20 includes a scheduler 22, functional modules 23 and 24, and a request receiving unit 25 as functional blocks.

  The processor core 30 includes a scheduler 32, functional modules 33 and 34, a request receiving unit 35, a job sorting unit 36, a job execution unit 37, and a memory driver 38 as functional blocks.

  The shared memory 40 is, for example, a RAM (Random Access Memory), and can be read and written by each processor core. In the shared memory 40, for example, a work area and an area indicating a job status indicating the processing status of the functional module are set for each functional module. In FIG. 1, the work areas of the function modules 13, 23, and 33 are not shown.

  In the shared memory 40, a message queue 42 for defining the content and order of access to a specific shared access target (nonvolatile memory 50 in this embodiment) is set.

  FIG. 2 is a conceptual diagram showing the concept of the message queue 42 together with changes in the status of the stored job and the processing subject. As shown in the figure, the message queue 42 stores a plurality of pieces of job information in the order of input or processing.

  The job status is from "Waiting for registration" before being stored as job information, to "Waiting for execution" after being stored as job information, and "In execution" after the order of execution has reached the top of the queue. The status changes in the order of “completed” after the processing is completed. The “Waiting for registration” state is a state inputted from any of the request accepting units. In the “Waiting for execution” state, the job sort unit 36 performs sorting. In the “running” state, the job execution unit 37 executes the process.

  FIG. 3 is a diagram illustrating the data structure of the message information input from the request receiving unit and the job information stored in the message queue 42 with the job ID assigned thereto. The job information in this embodiment is obtained by adding a job ID to message information input from any request receiving unit.

  The message queue 42 is realized by a queue buffer, for example. FIG. 4 is a diagram illustrating the structure of a queue buffer capable of realizing the message queue 42 according to the present embodiment. As shown in the figure, in the queue buffer, an array index is assigned to matrix data including message information including job IC and priority, and the head and tail of the queue are designated by pointers 44A and 44B, respectively. The pointers 44A and 44B are configured to move in accordance with job execution. FIG. 4 shows a state after the job stored in the array index [3] is completed. The next job to be executed is the job ID “01” stored in the array index [4]. It is a job. When the execution of the job stored in the array index [4] is completed, the pointer 44A moves down one level.

  The job sort unit 36 sorts the job information stored in the message queue 42 according to the priority included in the job information, for example. FIG. 5 is a diagram showing the result of job sorting unit 36 rearranging job information from the state shown in FIG.

  As described above, the job whose job information is stored in the message queue 42 is executed by the job execution unit 37 of the processor core 30. For example, when executing a job for reading data from a predetermined address of the nonvolatile memory 50 written by the request receiving unit 15 of the processor core 10, the job execution unit 37 of the processor core 30 starts from a predetermined address of the nonvolatile memory 50. The data is read and stored in the work area for the corresponding functional module of the processor core 10 in the shared memory 40. The processor core 30 includes a memory driver 38 as a function for accessing the nonvolatile memory 50.

  As described above, in the multi-core processor 1 according to the present embodiment, the processing related to the access to the nonvolatile memory 50 is performed by the processor core 30, so that a plurality of processor cores are simultaneously stored in the nonvolatile memory 50. Interference caused by access can be reliably avoided.

[Control of writing to message queue 42]
FIG. 6 is a timing chart showing the flow of processing when message information is written to the message queue 42 by the request receiving unit of each processor core. The timing generation unit 11 of the processor core 10 performs reference timing notification for request reception start at every predetermined period. For example, the predetermined period is set to a time that has a sufficient margin than the total processing time when all the functional modules of each processor core access the nonvolatile memory 50.

  When the scheduler 12 of the processor core 10 detects the reference timing notification, it sends a request reception permission notification to the request reception unit 15 (time t1). The request receiving unit 15 writes job information in the message queue 42 when the message queue 42 is empty (time t1 to t2). When the output of the message information is completed, the scheduler 12 sends a request acceptance permission notification to the scheduler 22 of the processor core 20 (time t3). Here, the request acceptance permission notification is performed by, for example, software / hardware interruption, but may be performed by the scheduler 12 setting a flag or the like in the shared memory 40 and the scheduler 22 polling. The same applies to other schedulers.

  When the scheduler 22 of the processor core 20 detects the request reception permission notification, it outputs an activation signal to the request reception unit 25 (time t3). The request receiving unit 25 writes job information in the message queue 42 when the message queue 42 is empty (time t3 to t4). When the output of the message information is completed, the scheduler 22 sends a request reception permission notification to the scheduler 32 of the processor core 30 (time t5).

  When the scheduler 32 of the processor core 30 detects the request reception permission notification, it outputs an activation signal to the request reception unit 35 (time t5). The request receiving unit 35 writes job information in the message queue 42 when the message queue 42 is empty (time t5 to t6). When the output of the message information is completed, the scheduler 32 instructs the job sorting unit 36 to rearrange the job information (time t7). When the job sorting unit 36 finishes rearranging the job information, the job execution unit 37 executes the job based on the job information stored in the message queue 42 (time t8).

  As described above, the start signal is output by the timing generation unit 11 of the processor core 10, and the request reception unit of each processor core is controlled to sequentially output the message information in response to the start signal. As a result, it is possible to avoid interference between processor cores regarding the writing of job information.

[Various processing flows]
Hereinafter, the operation of each functional block will be described with reference to flowcharts.

  FIG. 7 is a flowchart showing a flow of request reception processing executed by the request reception unit of each processor core. This flow is executed for each functional module being executed in the processor core when the request acceptance permission notification is detected as described above.

  First, the request receiving unit writes “waiting for registration” in the storage area indicating the job status corresponding to the processing in the shared memory 40 (S100).

  Next, the request reception unit determines whether or not there is a space in the message queue 42 (S102). This determination is performed, for example, by referring to the positions (start and end positions) of the pointers 44A and 44B held as external variables. If there is no vacancy in the message queue 42, this flow ends.

  If there is an empty space in the message queue 42, the position of the pointer 44B is incremented by 1 and the end position of the queue is decremented (S104), and the job ID is added to the message information to be registered this time and registered at the end of the queue. (S106).

  Then, “waiting for execution” is written in the storage area indicating the job status corresponding to the processing in the shared memory 40 (S108), and this flow is ended.

  FIG. 8 is a flowchart showing a flow of initialization processing executed when the multi-core processor 1 is started up or recovered from an error. This flow is executed by an OS (Operating System) (not shown) of the multi-core processor 1.

  In the initialization process, the execution state held as an external variable is set to the idle state (S200), and the positions of the pointers 44A and 44B are set to the zero position (S202 and S204). Here, the “execution state” is data indicating the execution state of the access process to the nonvolatile memory 50 by the memory driver 38.

  FIG. 9 is a flowchart showing the flow of job execution processing executed by the job execution unit 37. This flow is repeatedly executed, for example, periodically.

  First, the job execution unit 37 determines whether or not the execution state held as an external variable is an idle state (S300).

  If the execution state is the idle state, it is determined whether or not there is job information waiting for execution in the message queue 42 (S302). This determination can be made by referring to the positions of the pointers 44A and 44B, for example. If there is no job information waiting to be executed in the message queue 42, one routine of this flow is terminated.

  If there is job information waiting for execution in the message queue 42, the job start process shown in FIG. 10 is executed (S304).

  On the other hand, if the execution state is not the idle state, it is determined whether or not the memory driver 38 is in the idle state (S306). If the memory driver 38 is not in the idle state, one routine of this flow is terminated. It is determined that the memory driver 38 is not in the idle state when the execution state and the memory driver 38 are not in the idle state, that is, when access to the nonvolatile memory 50 is being executed.

  If the memory driver 38 is in the idle state, the job end process shown in FIG. 11 is executed (S308).

  FIG. 10 is a flowchart showing the flow of job start processing executed by the job execution unit 37.

  First, the job execution unit 37 extracts message information from the job information at the head of the queue (S400). Then, an access instruction is issued to the memory driver 38 according to each data included in the message information (S402).

  Next, it is assumed that the execution state is being executed (S404), and “executing” is written in the storage area of the shared memory 40 indicating the job state corresponding to the processing (S406). As described above, this storage area is included in the message information input from the request receiving unit.

  Then, the position of the pointer 44A is incremented by 1, and the head position of the queue is lowered (S408), and this flow is finished.

  FIG. 11 is a flowchart showing the flow of job end processing executed by the job execution unit 37.

  In the job end process, the job execution unit 37 sets the execution state to the idle state (S500), and then writes “complete” in the storage area of the shared memory 40 indicating the job state corresponding to the process. (S502) This flow is ended.

[Summary]
According to the multi-core processor 1 of the present embodiment described above, the processing related to access to the nonvolatile memory 50 is executed by the processor core 30 so that a plurality of processor cores can simultaneously execute the nonvolatile memory 50. It is possible to reliably avoid the occurrence of interference by accessing the.

  Further, the timing generation unit 11 of the processor core 10 notifies the reference timing, and in response to this, the request reception unit of each processor core is controlled to sequentially output message information. Interference between cores can be avoided.

  FIG. 12 is a diagram illustrating a state in which interference occurs when a plurality of processor cores simultaneously access a specific shared access target in a conventional multi-core processor. On the other hand, FIG. 13 is a diagram showing how interference is avoided in the multi-core processor 1 of this embodiment.

<Second embodiment>
A multi-core processor according to a second embodiment of the present invention will be described below with reference to the drawings. The multi-core processor of this embodiment is capable of processing independently by a plurality of processor cores, and executes a plurality of tasks at the same time, such as an in-vehicle controller integrated with a plurality of functions. It is suitably applied to the device.

[Constitution]
Since the multi-core processor 2 of this embodiment is the same as that of the first embodiment in the configuration and the basic functions of each component, it will be referred to FIG. The description will focus on the differences from the first embodiment.

  Also in the multi-core processor 2 according to the present embodiment, the processing related to access to the nonvolatile memory 50 is performed by the processor core 30 so that a plurality of processor cores access the nonvolatile memory 50 at the same time. Thus, it is possible to reliably avoid the occurrence of interference.

[Control of writing to message queue 42, various processing flows]
The flow of processing when message information is written to the message queue 42 by the request receiving unit of each processor core is also the same as in the first embodiment, and FIG. 6 is used.

  However, in this embodiment, in the control of writing to the message queue 42, the notification flow between schedulers is different from that in the first embodiment.

  FIG. 14 is a sequence diagram illustrating a state in which writing control for the message queue 42 is performed between the cores.

  First, the processor core 10 executes a resource access wait process as shown in FIG. 15 (S600). Note that “resource” in this figure refers to the shared memory 40.

  When the resource access waiting process ends, the processor core 10 executes the request reception process described in FIG. 7 in the first embodiment for each of the functional modules 13 and 14 (S602 and S604).

  When the request acceptance process ends, the processor core 10 executes a resource distribution process as shown in FIG. 16 (S606). Here, the target core is the processor core 20.

  When a request acceptance permission notification is sent from the processor core 10 to the processor 20 in the resource allocation process, the processor 20 executes a resource occupation start process as shown in FIG. 17 (S610).

  When the resource access wait process ends, the processor core 20 executes the request reception process described in FIG. 7 in the first embodiment for each of the functional modules 23 and 24 (S612 and S614).

  When the request acceptance process ends, the processor core 20 executes a resource occupation end process as shown in FIG. 18 (S616).

  When a resource occupation end notification is sent from the processor core 20 to the processor 10 in the resource occupation end process, the processor 10 executes a resource allocation process as shown in FIG. 16 (S618). Here, the target core is the processor core 30.

  When a request acceptance permission notification is sent from the processor core 10 to the processor 30 in the resource allocation process, the processor 30 executes a resource occupation start process as shown in FIG. 17 (S620).

  When the resource access waiting process ends, the processor core 30 executes the request reception process described in FIG. 7 in the first embodiment for each of the functional modules 33 and 34 (S622, S624).

  When the request acceptance process is completed, the job sort unit 36 executes job sort (S626), and the job execution unit 37 executes the job (S628).

  Then, the scheduler 32 of the processor core 30 executes a resource occupation end process as shown in FIG. 18 (S630).

  When a resource occupation end notification is sent from the processor core 30 to the processor 10 in the resource occupation end process, the processor 10 executes a resource access end process as shown in FIG. 19 (S640).

  FIG. 15 is a flowchart showing the flow of the resource access wait process executed by the scheduler 12 of the processor core 10.

  First, the scheduler 12 waits until a reference timing notification is made by the timing generator 11 (S700).

  When the reference timing notification is made, it is determined whether the resource access is in an end state (S702). If the resource access is not finished, error processing is performed (S704), and the process returns to S700.

  If the resource access is in the end state, the resource access is set in the start state (S706).

  FIG. 16 is a flowchart showing a flow of resource access distribution processing executed by the scheduler 12 of the processor core 10.

  In the resource access distribution process, the scheduler 12 sends a request acceptance permission notification to the target processor core according to a schedule (in the present embodiment, specified as processor core 10 → processor core 20 → processor core 30) (S800). ).

  FIG. 17 is a flowchart showing the flow of resource occupation start processing executed by the schedulers 22 and 32 of the processor cores 20 and 30.

  In the resource occupation start process, the schedulers 22 and 32 of the processor cores 20 and 30 wake up the accelerator task of the own core (S900).

  FIG. 18 is a flowchart showing the flow of the resource occupation end processing executed by the schedulers 22 and 32 of the processor cores 20 and 30.

  In the resource occupation end process, the schedulers 22 and 32 of the processor cores 20 and 30 notify the processor core 10 of the occupation end of the own core (S1000), and terminate the access task of the own core (S1002).

  FIG. 19 is a flowchart showing the flow of resource access end processing executed by the scheduler 12 of the processor core 10.

  In the resource access distribution process, the scheduler 12 ends the resource access (S1100).

  As described above, the start signal is output by the timing generation unit 11 of the processor core 10, and the request reception unit of each processor core is controlled to sequentially output the message information in response to the start signal. As a result, it is possible to avoid interference between processor cores regarding the writing of job information.

[Summary]
According to the multi-core processor 2 of the present embodiment described above, the processing related to access to the nonvolatile memory 50 is performed by the processor core 30 so that a plurality of processor cores can simultaneously execute the nonvolatile memory 50. It is possible to reliably avoid the occurrence of interference by accessing the.

  Further, the timing generation unit 11 of the processor core 20 notifies the reference timing, and in response to this, the request reception unit of each processor core is controlled to sequentially output message information. Interference between cores can be avoided.

  The best mode for carrying out the present invention has been described above with reference to the embodiments. However, the present invention is not limited to these embodiments, and various modifications can be made without departing from the scope of the present invention. And substitutions can be added.

  For example, the nonvolatile memory 50 is given as an example of a specific shared access target. However, the present invention is not limited to this, and other devices such as a soak timer IC may correspond to the specific shared access target. The soak timer IC has a function of measuring the time during which the key is turned off in the in-vehicle control device or turning on the power of the in-vehicle control device at a predetermined time during the key-off.

  Further, each processor core has a function corresponding to a request reception unit, but may be held as a common function between processors.

  In addition, each processor core may independently access a shared access target other than a specific shared access target. FIG. 20 is a partial configuration diagram that can be added as an additional function to the first embodiment and the second embodiment. As shown in the figure, for a short latency device such as an external I / O port, each processor core may be provided with a driver and independently accessible. FIG. 21 is a timing chart showing the flow of processing when each processor core accesses an I / O port. This modification is the same for the standby RAM. FIG. 22 is a partial configuration diagram that can be added as an additional function to the first embodiment and the second embodiment.

1, 2, Multi-core processor 10, 20, 30 Processor core 11 Timing generator 12, 22, 32 Scheduler 13, 14, 23, 24, 33, 34 Functional module 15, 25, 35 Request receiver 40 Shared memory 50 Non-volatile memory

Claims (7)

A multi-core processor in which a plurality of processor cores can perform processing independently,
A message queue for defining the content and order of access to a specific shared access target is set on the memory that can be read and written by the plurality of processor cores,
The plurality of processor cores exclusively write job information related to access to the specific shared access target in the message queue according to predetermined write control on the message queue,
At least one specific target access execution processor core among the plurality of processor cores executes access to the specific shared access target according to job information written in the message queue.
Multi-core processor. The multi-core processor according to claim 1, comprising:
The job information includes information on processing priority,
The specific target access execution processor core changes the order of performing the processing based on information on processing priority included in the job information.
Multi-core processor. A multi-core processor according to claim 1 or 2,
Predetermined write control for the message queue is performed sequentially according to a predetermined order from a processor core that has finished writing job information to the message queue to a processor core that next writes job information to the message queue. Realized by
Multi-core processor. A multi-core processor according to claim 1 or 2,
The predetermined write control for the message queue is sequentially written from the write control processor core to each processor core according to a predetermined order held in at least one of the plurality of processor cores. Realized by making possible notifications, A multi-core processor according to claim 3 or 4,
The writable notification is performed by a software interrupt.
Multi-core processor. A multi-core processor according to claim 3 or 4,
The writable notification is performed by designating a processor core to which job information is to be written next in the message queue on a memory accessible by the plurality of processor cores.
Multi-core processor.   The multi-core processor according to claim 1, wherein the multi-core processor is mounted on a vehicle, and each of the processor cores performs processing for vehicle control.

Images