JP2018013843A - Multi-core arithmetic unit - Google Patents

Abstract

PROBLEM TO BE SOLVED: To appropriately perform distributed processing in a multi-core arithmetic unit having a plurality of CPU cores.SOLUTION: A multi-core arithmetic unit 10 includes a first core 1, a second core 2 operating independently of the first core 1, and a shared memory 4; and both the cores communicate with each other via the shared memory 4. The first core 1 executes a behavior schedule application for determining a behavior schedule that indicates the order of the behavior changes of a vehicle drive transmission device 100 as a control target. The second core 2 executes an actuator control application that controls an actuator 120 for operating the vehicle drive transmission device 100, and a sensing application that obtains and provides physical information.SELECTED DRAWING: Figure 6

Description

  The present invention relates to a multi-core arithmetic device including a plurality of CPU cores.

  A multi-core arithmetic device having a plurality of CPU cores is known. US Patent Application Publication No. 2012/0246650 A1 (Patent Document 1) discloses a multi-core arithmetic device (multi-core microcontroller (5)) having a plurality of CPU cores (processor cores (6, 7, 13, 14)). (In the background art, the reference numerals in parentheses are those of Patent Document 1). A sensor element (1) and an actuator (3) are connected to the multi-core microcontroller (5). For example, one processor core (6) reads the sensor value of the sensor element (1) and detects a physical phenomenon. Another processor core (7) determines parameters for controlling the actuator (3) and outputs them to the actuator (3). That is, the control of the actuator (3) based on the detection result of the sensor element (1) is distributed by the plurality of processor cores (6).

  In general, by performing distributed processing using a plurality of processor cores in this way, it is possible to distribute the calculation load of the entire microcontroller and improve the calculation capability. However, even if the calculation by one processor core is simply changed to the calculation by two processor cores, for example, the processing speed is not halved or the processing amount is not doubled. For example, in distributed processing, processing for managing distributed processing, such as synchronization of distributed operations and adjustment of mutual calculation timing, so-called overhead processing occurs, and the total amount of calculation increases by this overhead processing. . In addition, the processor core often performs operations while using peripheral function blocks such as a memory, a communication controller, and an A / D converter. However, a plurality of processor cores may use the same peripheral function block. For example, when one processor core uses such a peripheral function block, other processor cores must wait until the peripheral device block becomes available, resulting in a computation waiting time. There is also.

US Patent Application Publication No. 2012 / 0246650A1

  In view of the above background, it is desirable to appropriately perform distributed processing in a multi-core arithmetic device having a plurality of CPU cores.

As one aspect, at least two independent CPU cores, a first core and a second core that operates independently of the first core, a shared memory that is used in common by the plurality of CPU cores, A multi-core computing device equipped with
A plurality of the CPU cores communicate via the shared memory,
A behavior schedule application that is software for determining a behavior schedule indicating the order of behavior change of the vehicle drive transmission device to be controlled;
An actuator control application that is software for controlling an actuator that operates the vehicle drive transmission device according to the determined behavior schedule;
At least physical information for determining the behavior schedule is acquired, and at least a sensing application that is software that provides the physical information to the behavior schedule application is executed.
The first core executes the behavior schedule application;
The second core executes the actuator control application and the sensing application.

  For example, the behavior of a vehicle drive transmission device is defined by the selection of mechanical components such as gears. Also, the connection (coupling) of the selected gears is often realized via a control component. Here, the calculation related to the behavior of the machine component and the calculation related to the behavior of the control component may be executed using different hardware resources. However, when the control target is a vehicle drive transmission device, etc., as described above, the behavioral change between the mechanical component and the control component has order dependency. For this reason, if these two controls are executed using different hardware resources, an unnecessary waiting time may be generated and the calculation efficiency may be reduced. According to this configuration, since the behavior schedule indicating the order of behavior change of the vehicle drive transmission device is calculated by one CPU core, it is possible to suppress such a decrease in the calculation efficiency.

  In a vehicle drive transmission device, an actuator is generally required to actually realize the connection of gears and the like. Since the actuator is naturally provided outside the multi-core arithmetic device, control signals and data are transmitted via the interface function block of the multi-core arithmetic device. In addition, a sensor for detecting physical information indicating the operating state of the vehicle drive transmission device is also provided outside the multi-core arithmetic device. Therefore, the detection information by such a sensor is also transmitted through the interface function block of the multi-core arithmetic device. For example, if the actuator control application and the sensing application are executed by different CPU cores, the actuator and the sensor may try to use the same interface function block at the same time, and a waiting time may occur in one CPU core. . Since such a waiting time may occur in any CPU core, the calculation efficiency may decrease as a whole. According to this configuration, since the actuator control application and the sensing application are executed by the same CPU core, it is possible to suppress such a decrease in the calculation efficiency.

  Further features and advantages of the multi-core arithmetic device will become clear from the following description of embodiments described with reference to the drawings.

Schematic block diagram of a vehicle drive transmission device including a multi-core arithmetic device The figure which shows typically the load of the control processing of the drive transmission device for vehicles The figure which shows typically the flow of the control processing of the drive transmission device for vehicles Schematic block diagram showing the configuration of a multi-core arithmetic unit The figure which shows typically the load of the control processing of the drive transmission device for vehicles by distributed processing Schematic block diagram showing the relationship between each CPU core and functional blocks Plan view showing an example of input / output terminals State transition diagram showing an example of exclusive processing State transition diagram showing an example of exclusive processing and reservation processing

  Hereinafter, embodiments of a multi-core processor (Multi Core Processor) will be described with reference to the drawings. In the present embodiment, the multi-core arithmetic device is a semiconductor large-scale integrated circuit (system LSI) whose control target is a vehicle drive transmission device. Here, the vehicle drive transmission device is a device that transmits the driving force of the driving force source to the wheels of the vehicle. The vehicle drive transmission device includes at least an input member that receives a driving force from the driving force source side and an output member that provides the driving force to the wheel side, and the input member and the output member have A transmission member for transmitting the driving force is included. That is, the input member and the output member are drivingly connected via one or more transmission members. The drive connection refers to a state in which two rotating elements are connected so as to be able to transmit a driving force, and the two rotating elements are connected so as to rotate integrally, or the two rotating elements are connected to each other. It includes a state in which a driving force is transmitted through one or more transmission members.

  The driving force source is a rotating electrical machine, an internal combustion engine, a hybrid drive engine that combines these, and the like. Further, in the present embodiment, the mechanism for transmitting the driving force is a torque converter type automatic transmission provided with a torque converter and a planetary gear mechanism, an automatic clutch type provided with a spur gear mechanism and a mechanism for automatically performing clutch operation. For example, a step changer such as an automatic transmission or a continuously variable transmission (CVT) that continuously changes a belt or chain around a pulley with a variable diameter. The transmission member described above includes various members that transmit rotation at the same speed or with a variable speed. For example, a shaft, a gear mechanism, a belt, a chain, and the like included in these transmissions are included in the transmission member. The transmission member also includes an engagement device that selectively transmits rotation and driving force, such as a friction engagement device (brake, clutch), a meshing engagement device, and the like.

  Further, as is well known, in these transmissions, switching of the engagement state of the friction engagement device and the meshing engagement device, changing the diameter of the pulley, and the like are performed by hydraulic control via a hydraulic circuit. Done. In the present embodiment, such a hydraulic circuit is included in the vehicle drive transmission device to be controlled by the multi-core arithmetic device.

  FIG. 1 is a schematic block diagram of a vehicle drive control device 200 that controls a vehicle drive transmission device 100 using a multi-core arithmetic device 10. In the present embodiment, as shown in FIG. 1, the vehicle drive transmission device 100 controls an automatic transmission 101 (A / T: Automatic Transmission), a hydraulic circuit 102 (H / C: Hydraulic Circuit), and a hydraulic circuit 102. Actuators such as solenoids (ACT-1, ACT-2, ..., ACT-n), sensors and switches (S-1, S-2, ..., Sn) for detecting physical phenomena in the automatic transmission 101 and the hydraulic circuit 102 ). For example, a shift position switch, a shift position sensor, a hydraulic pressure sensor, an oil temperature sensor, a rotation sensor, and the like. A plurality of actuators, sensors, and switches are provided. In this embodiment, the actuators are exemplified as a hydraulic control actuator group 120 (HCA) and a sensor group 130 (SEN / SW: Sensors / Switches). The hydraulic control actuator group 120 and the sensor group 130 correspond to peripheral devices provided outside the multi-core arithmetic device 10.

  In this embodiment, the multi-core arithmetic device 10 is commonly used by two independent CPU cores 3 of the first core 1 (CPU 1) and the second core 2 (CPU 2) and a plurality of CPU cores 3. A shared memory 4 (Global RAM), a DMA controller 6 (DMAC: Direct Memory Access Controller), an external communication interface 7 (PI: Peripheral Interface), and a CAN transceiver 8 (CANT: CAN Transceiver) are provided. In the present embodiment, the multi-core arithmetic device 10 exemplifies a dual-core configuration having two CPU cores 3, but may naturally have three or more CPU cores 3. Note that the DMA controller 6 and the external communication interface 7 can be used in common by a plurality of CPU cores 3 due to the structure of the multi-core arithmetic device 10 (see FIG. 4). However, in the present embodiment, the DMA controller 6 and the external communication interface 7 are used only by the second core 2, and the first core 1 does not use them. That is, in this embodiment, the DMA controller 6 and the external communication interface 7 are used only by the single CPU core 3 (second core 2). Therefore, it is not necessary to perform arbitration (for example, exclusive processing) between the plurality of CPU cores 3, and applications using these functional units can be executed in a timely manner under the management of the second core 2.

  The multi-core arithmetic device 10 is connected to the hydraulic control actuator group 120 and the sensor group 130 of the vehicle drive transmission device 100 via the external communication interface 7. Further, the multi-core arithmetic device 10 is connected to an in-vehicle network 300 (C / N: Car Network; see FIG. 2 and the like) of the vehicle via the CAN transceiver 8, and various in-vehicle systems and CAN (Controller Area Network) standards. Communicate with. In the present embodiment, as an in-vehicle system, an antilock brake system 301 (ABS: Antilock Brake System), an electric power steering 302 (EPS), a failure diagnosis system 303 (DIAG: Diagnosis), etc. are illustrated. ing.

  FIG. 2 schematically shows a control processing load on the vehicle drive transmission device 100. FIG. 2 illustrates the processing load when the vehicle drive transmission device 100 is controlled without performing parallel processing. The control process for the vehicle drive transmission device 100 is executed by combining a plurality of applications (software). Applications related to the automatic transmission 101 and the hydraulic circuit 102 are a transmission control application AP1 (behavior schedule application) and a fail-safe application AP4. An application related to the in-vehicle network 300 is a communication application AP5. An application related to the sensor group 130 is a sensing application AP3. An application related to the hydraulic control actuator group 120 is an actuator control application AP2.

  As shown in FIG. 2, the transmission control application AP1 includes a shift control application AP1a that is an application particularly related to the automatic transmission device 101, and a hydraulic control application AP1b that is an application particularly related to the hydraulic circuit 102. is there. The shift control application AP1a is an application that determines a combination of gears according to a gear ratio. The hydraulic control application AP1b controls the hydraulic pressure for controlling the engagement devices such as the clutch and the brake of the automatic transmission 101, that is, the hydraulic pressure at various points in the hydraulic circuit 102, according to the gear combination determined by the shift control application AP1a. decide.

  Since the shift control application AP1a and the hydraulic control application AP1b have such order dependency, they are collectively referred to as a transmission control application AP1. The transmission control application AP1 can also be referred to as a behavior schedule application because it can also be referred to as an application that determines a behavior schedule of gears, clutches, and the like in the vehicle drive transmission device 100. The fail-safe application AP4 determines whether or not the target clutch or brake has operated normally according to the oil pressure determined by the oil pressure control application AP1b. It is an application to perform. Accordingly, it can be said that the fail-safe application AP4 also has order dependency on the shift control application AP1a and the hydraulic control application AP1b. Therefore, the fail safe application AP4 can also be included in the behavior schedule application.

  FIG. 3 schematically shows the flow of control processing when these applications are serially processed without parallel processing. The priority of processing is higher in the upper application in FIG. 3 than in the lower application. That is, the application with the highest priority is the actuator control application AP2, followed by the sensing application AP3 and the communication application AP5. The transmission control application AP1 and the failsafe application AP4 which are behavior schedule applications have the lowest priority. However, the behavior schedule application is executed as a main application in the vehicle drive transmission device 100.

  That is, as the main application, the shift control application AP1a, the hydraulic control application AP1b, and the failsafe application AP4 are executed in order, and are periodically repeated one cycle at a time. While the process of a certain cycle is being executed, the actuator control application AP2 is executed so as to satisfy the hydraulic pressure determined in the previous cycle. Similarly, while processing of a certain cycle is being executed, the sensing application AP3 is executed, and detection results from various sensors and switches are acquired. That is, during execution of the main process, an interrupt process for executing the actuator control application AP2 and the sensing application AP3 is executed. Similarly, when the execution of the communication application AP5 is requested, the interrupt process is executed. In FIG. 3, a white circle indicates that an interrupt has occurred, and a dashed arrow indicates that interrupt processing is being executed for the main processing.

  In general, such interrupt processing reduces the overall calculation speed. For example, when these applications are serially processed without parallel processing, the calculation load reaches about 90% of the maximum calculation capacity as shown in FIG. In order to stably operate the computer system, it is preferable to suppress the calculation load to about 70% or less. In the present embodiment, by implementing parallel processing using the multi-core arithmetic device 10, interrupt processing is also reduced, and the arithmetic load is reduced. However, when a process is divided, a new process may occur due to the division. Such new processing is called overhead processing. For this reason, when a plurality of applications are simply distributed to a plurality of CPU cores 3, overhead processing increases, and the effect of reducing the computation load may be limited. In the present embodiment, the hardware configuration of the multi-core arithmetic device 10 is also taken into consideration, and such overhead processing is suppressed to appropriately realize distributed processing.

  The block diagram of FIG. 4 schematically shows the configuration of the multi-core arithmetic device 10. FIG. 5 is a diagram corresponding to FIG. 2 and schematically shows a load when control processing for the vehicle drive transmission device 100 is distributed. FIG. 6 is a block diagram corresponding to FIG. 1, and shows the relationship between each application and the hardware configuration of the multi-core arithmetic device 10 when the control processing for the vehicle drive transmission device 100 is distributed.

  As described above with reference to FIG. 1, the multi-core arithmetic device 10 includes two independent CPU cores 3, that is, a first core 1 and a second core 2. As shown in FIG. 4, in the present embodiment, the first core 1 and the second core 2 are CPU cores 3 having different configurations, but the first core 1 and the second core 2 have the same configuration. The CPU core 3 may be used. In the present embodiment, the first core 1 includes a first microprocessor 11 (MPU: Micro Processing Unit), a first interrupt controller 12 (INTC: Interrupt Controller), and a floating point arithmetic unit 13 (FPU) as the core of the CPU core 3. : Floating-point Processing Unit). In addition to the shared memory 4 (Global RAM), a first dedicated memory 19 (Local RAM) occupied by the first core 1 is connected to the first core 1. The access speed from the first core 1 to the first dedicated memory 19 is higher than the access speed from the first core 1 to the shared memory 4.

  The second core 2 has a second microprocessor 21 (MPU) and a second interrupt controller 22 (INTC). Similar to the first core 1, a second dedicated memory 29 (Local RAM) occupied by the second core 2 is also connected to the second core 2. The access speed from the second core 2 to the second dedicated memory 29 is also higher than the access speed from the second core 2 to the shared memory 4.

  A code flash memory 9 (PGM FRASH) storing an application (program code) is connected to the first core 1 and the second core 2 via a flash memory interface 90 (FRASH I / F). The first core 1, the second core 2, and the flash memory interface 90 are connected to a connection bus 20 (I-BUS: System Interconnect Bus) that connects functional blocks (systems) serving as the core of the multi-core arithmetic device 10. . The shared bus 4 (Global RAM) and the DMA controller 6 (DMAC) described above with reference to FIG. 1 are also connected to the connection bus 20.

  Since the shared memory 4 is used by both the first core 1 and the second core 2, there is a risk of contention. For this reason, an exclusive control register 41 (MEVR: Mutual Exclusion Value Register) is provided as a functional block for managing the right (access right) to use the shared memory 4. The exclusive control register 41 manages a mutual exclusion value described later between the first core 1 and the second core 2. Details of management will be described later. In the present embodiment, the first core 1 and the second core 2 are different in configuration, and complex operations such as using a large amount of temporary storage areas or using floating point are more difficult than the second core 2. The first core 1 is more suitable. For this reason, the shared memory 4 is also directly connected to the first core 1, but is connected to the second core 2 via the connection bus 20.

  The exclusive control register 41 is a shared resource management function block allocated to the shared memory 4 that is one of the shared resources 5. In this embodiment, the internal core interrupt control register 47 (ICIR: Internal Core Interrupt) is used as a shared resource management function block for the first core 1 and the second core 2 to request interrupt processing from the other CPU core 3. Control Resister) is also provided. For example, the first core 1 may be used by the second core 2, and similarly, the second core 2 may be used by the first core 1. In such a case, the first core 1 and the second core 2 can be shared resources 5 with each other.

  As one aspect, the first dedicated memory 19 may be available from the second core 2 via the connection bus 20 and the first core 1. When the second core 2 uses the first dedicated memory 19, it is not preferable that the first core 1 uses the first dedicated memory 19 at the same time. Therefore, it is preferable to perform exclusive processing (exclusive control). In such a case, the internal core interrupt control register 47 can perform exclusive processing. Similarly, the second dedicated memory 29 may also be available from the first core 1 via the connection bus 20 and the second core 2. Of course, only one of the first dedicated memory 19 and the second dedicated memory 29 can be shared, and the other cannot be shared.

  The first core 1 and the second core 2 are also connected to a processor bus 30 (P-BUS: Processor Bus) that is an internal bus of the multi-core arithmetic device 10. In addition, a connection bus 20 is also connected to the processor bus 30. In addition to the above-described external communication interface 7 and CAN transceiver 8 (CANT), the processor bus 30 includes an AD converter 31 (ADC: Analogue Digital Converter), an input / output register 32 (I / O: Input / Output Terminal Register), and a reset. Functional blocks such as a controller 33 (RSTC: Reset Controller) and a data flash memory 34 (DATA FLASH) are connected. The input / output register 32 holds data output from the multi-core arithmetic unit 10 and outputs the data from the input / output terminal 10t (see FIG. 7) functioning as an output terminal, and from the input / output terminal 10t functioning as an input terminal. It is a functional block that holds data input to the device 10 and provides it to the functional blocks of the multi-core arithmetic device 10. The reset controller 33 is a functional block that resets a functional block including the CPU core 3. The data flash memory 34 is a rewritable and rewritable nonvolatile memory, and can store data that needs to be retained even after the power supply to the multi-core arithmetic device 10 is interrupted.

  Hereinafter, an embodiment in which the control software (application) of the vehicle drive transmission device 100 is distributed by the multi-core arithmetic device 10 will be described. FIG. 5 shows the assignment of applications to the first core 1 (CPU 1) and the second core 2 (CPU 2) and the processing load. FIG. 6 shows the relationship between the CPU cores 3 and the functional blocks that are strongly related to the applications executed by the CPU cores 3 among the functional blocks of the multi-core arithmetic device 10.

  As shown in FIG. 5, the first core 1 (CPU1) executes the transmission control application AP1 (behavior schedule application) and the failsafe application AP4, and the second core 2 (CPU2) performs the actuator control application AP2 and sensing. The application AP3 is executed. As will be described later, the first core 1 also executes the communication application AP5. However, even if the first core 1 has a relatively high processing load, the load is within 70% of the maximum calculation load. From the viewpoint of load distribution, appropriate distributed processing can be realized.

  Specifically, as described above, the transmission control application AP1 and the failsafe application AP4 having high order dependency are integrated into one CPU core 3 (the first core 1 in the present embodiment). When processing with high order dependency is divided into a plurality of hardware, the time required for overhead processing such as waiting time and synchronization processing time tends to increase. As in this embodiment, by consolidating applications with high order dependency on one piece of hardware (CPU core 3), occurrence of such overhead processing is suppressed, and increase in processing time due to distributed processing is suppressed. be able to.

  In the present embodiment, the form in which the communication application AP5 is executed by the first core 1 is illustrated, but the communication application AP5 may be executed by any of the CPU cores 3 of the first core 1 and the second core 2. Good. The CPU core 3 that executes the application may be selected in consideration of the ease of generating the program code, the ease of debugging, the load balance of the plurality of CPU cores 3, and the like. For example, since CAN is a general-purpose communication standard, an automatic tool that automatically generates a basic program code by setting a connection form, a communication speed, and the like has been put into practical use. When the first core 1 and the second core 2 have different hardware structures and computer architectures such as an operating system, the communication application is applied to the CPU core 3 having a computer architecture that can use such an automatic tool. It is preferable to assign AP5.

  As described above with reference to FIG. 5, the actuator control application AP2 and the sensing application AP3 are executed by the second core 2 (CPU 2). In the actuator control application AP2, for example, the hydraulic control actuator group 120 is controlled by outputting a modulation pattern set in advance in a memory in the multi-core arithmetic unit 10 by DMA transfer, and a status signal from the hydraulic control actuator group 120 is output. The data is taken into the multicore arithmetic device 10 by serial communication. In the sensing application AP3, for example, the detection result of the sensor group 130 is taken into the memory in the multi-core arithmetic device 10 by DMA transfer, and the control of the sensor group 130 is performed by serial communication.

  As shown in FIG. 6, the first core 1 writes a behavior schedule, which is a calculation result by execution of the transmission control application AP <b> 1 (behavior schedule application), to the shared memory 4. The second core 2 reads the behavior schedule stored in the shared memory 4 from the shared memory 4 and executes the actuator control application AP2 based on the behavior schedule. A calculation result obtained by executing the actuator control application AP2 is DMA-transferred to the external communication interface 7 by the DMA controller 6 that has received a command from the second core 2, and is provided to the hydraulic control actuator group 120 via the external communication interface 7. . Further, the second core 2 causes the external communication interface 7 to receive physical information from the sensor group 130 by executing the sensing application AP3. The physical information received from the sensor group 130 by the external communication interface 7 is DMA-transferred from the external communication interface 7 to the shared memory 4 by the DMA controller 6 that has received a command from the second core 2, and stored in the shared memory 4.

  Thus, in the actuator control application AP2 and the sensing application AP3, the DMA controller 6 and the external communication interface 7 are used intermittently. On the other hand, the transmission controller application AP1 and the failsafe application AP4 do not use the DMA controller 6 or the external communication interface 7. Since the DMA controller 6 and the external communication interface 7 are shared resources 5 like the shared memory 4, arbitration is necessary for different applications to use the same shared resources 5. Here, if these different applications are executed by different CPU cores 3, arbitration is required between the different CPU cores 3, so overhead time such as communication time and waiting time increases.

  In particular, in the configuration in which the first core 1 and the second core 2 are highly independent as in the present embodiment and communication is performed via the connection bus 20 (I-BUS) without being directly connected to each other, arbitration is performed. The overhead time due to tends to be long. Furthermore, as shown in FIG. 3, the actuator control application AP2 and the sensing application AP3 use the DMA controller 6 and the external communication interface 7 intermittently at high frequency because one control cycle is relatively short. For this reason, there is a tendency for the overhead time due to arbitration to increase. In the present embodiment, the actuator control application AP2 and the sensing application AP3 are executed by one CPU core 3 (here, the second core 2) without being distributed to different CPU cores 3. Therefore, generation of overhead due to distributed processing is suppressed, and appropriate distributed processing is realized.

  Note that the transmission control application AP1 may also receive a shift command or the like via the in-vehicle network 300. That is, the transmission control application AP1 may also use the CAN transceiver 8. In the present embodiment, a communication application AP5 that is an application that mainly uses the CAN transceiver 8 is executed by the first core 1 together with the transmission control application AP1. Therefore, it can be said that the allocation of the communication application AP5 to the first core 1 is also appropriate from the viewpoint of not distributing applications that use the same shared resource 5 to different CPU cores 3.

  As described above, the AD converter 31, the input / output register 32, and the data flash memory 34 connected to the processor bus 30 can also be considered as one of the shared resources 5. The input / output terminal 10t (see FIG. 7) connected to the input / output register 32 is also one of the shared resources 5. Depending on the type of the input / output terminal 10 t, the attribute can be changed by software executed in the multi-core arithmetic device 10. However, in the case where a plurality of software (applications) are executed in parallel by a plurality of CPU cores 3, arbitration is required as in the DMA controller 6 and the like. Therefore, it is preferable that the first and second cores 1 and 2 are assigned with the occupied input / output terminals 10t.

  FIG. 7 is a schematic external view of an envelope 10p that houses a plurality of CPU cores 3 and a shared memory 4 and includes a plurality of input / output terminals 10t. In the present embodiment, a BGA (Ball Grid Array) type semiconductor package is illustrated. For example, as shown in FIG. 7, it is preferable that the first terminal group 1t occupied by the first core 1 and the second terminal group 2t occupied by the second core 2 are assigned in advance. Note that such terminal assignment may be fixedly assigned due to the hardware structure, or may be assigned by software such as setting by a register (not shown) in the multi-core arithmetic device 10. .

  As described above, appropriate distributed processing can be realized by assigning an application to each CPU core 3 so that different CPU cores 3 can use the same shared resource 5 as much as possible. However, it is not realistic to occupy each shared resource 5 so that all the shared resources 5 are used by a single CPU core 3. For example, since the shared memory 4 is also used to mediate communication between the first core 1 and the second core 2, it cannot be occupied by either the first core 1 or the second core 2. Therefore, an arbitration process is necessary when using the shared memory 4.

  In the present embodiment, exclusive processing is performed using the exclusive control register 41 (MEVR). Here, the exclusive process is the same as that performed by another CPU core 3 while one CPU core 3 is accessing the shared resource 5 (for example, a specific data group (DATA Gr.) In the shared memory 4). This is processing for restricting access to the shared resource 5. The exclusive control register 41 is one of shared resource management function blocks that manage an access right (lock number described later) that is a right to use the shared resource 5. In other words, the shared resource 5 to be managed and the lock number of the exclusive control register 41 are associated (associated) with each other.

  In the present embodiment, a common storage area (data group (DATA Gr.)) In which both the first core 1 and the second core 2 refer to data is set in the shared memory 4. A plurality of such data groups can be set. Here, one data group is assumed to be “[a, b, c]” by data [a], data [b], and data [c]. Data [a], data [b], and data [c] are different data, and are written (updated) at different timings. However, these data need to be used in a state where the timing at which the data is acquired (updated timing) is consistent. For example, if these three data are data acquired by the sensing application AP3, it is required that all the data is acquired and stored in the same control cycle (for example, the first cycle T1) in FIG. . A state in which data acquired in different control cycles, for example, data acquired in the first cycle T1 and data acquired in the second cycle T2 are mixed is a state having no consistency. .

Hereinafter, an example will be described with reference to FIG.
[a, b, c] = [a1, b1, c1]: Consistent (acquired at the same control cycle (T1))
[a, b, c] = [a2, b1, c1]: no consistency (acquired at different control cycles (T1, T2))

  For example, when the CPU core 3 is single and an application is executed by serial processing as shown in FIG. 3, there is only one program counter and instructions are executed one by one in order. Therefore, in the above example, after acquiring data [a1], data [b1], and data [c1], before acquiring data [a2], data group [a, b, c] If the command to be used is executed, data consistency is maintained. Here, what is a problem is so-called “interrupt processing”, which can be avoided by performing “interrupt disabled” processing.

  However, when a plurality of applications are processed in parallel by a plurality of CPU cores 3 as in this embodiment, the data consistency as described above cannot be maintained in such “interrupt disable” processing. There is. A program counter exists for each CPU core 3, and the interrupt prohibition process is effective only for each CPU core 3. For example, when the second core 2 updates the data group [a, b, c] and the first core 1 and the second core 2 refer to the data group [a, b, c], the second core 2 has the data Even if it is controlled so as to maintain the consistency, it may occur that the first core 1 refers to the data group [a, b, c] in a state where the consistency is not achieved. Specifically, in the state where the second core 2 updates the data and “[a, b, c] = [a2, b1, c1]”, the first core 1 has the data group [a, b , c], control using inconsistent data is executed.

  In order to avoid such an event, an access right called a lock number is assigned to each of a plurality of data groups, and exclusive control is performed so that the target data group cannot be referred to unless the lock number is acquired. . The exclusive control register 41 (shared resource management function block) is a functional unit that manages such an access right (lock number). In the present embodiment, the exclusive control register 41 is a register having a plurality of bits. Since the lock number for one data group is one bit as described later, the exclusive control register 41 can perform exclusive control for a plurality of data groups. A lock number is assigned to each data group that is updated and referred to by performing exclusive control.

  That is, in the present embodiment, at least one data group that is a set of a plurality of data used in a state in which the consistency of the plurality of data is ensured is set in the shared memory 4, and the multi-core arithmetic device 10 has , An exclusive control register 41 (shared resource management function block) that manages an access right (lock number) that is a right to use the shared resource 5 including the data group is provided. As will be described in detail below, the shared resource 5 can be used by the CPU core 3 having the access right. Each of the CPU cores 3 acquires the access right to the shared resource 5, uses the shared resource 5, and releases the access right after the use is finished. The exclusive control register 41 (shared resource management function block), when one CPU core 3 acquires an access right to a specific shared resource 5, uses the specific shared resource 5 by all other CPU cores 3. Execute exclusive processing to be prohibited.

  FIG. 8 shows an example of exclusive processing. First, in order for the first core 1 (CPU 1) to use the data group [a, b, c] in the shared memory 4, the exclusive control register 41 (MEVR) is requested to obtain an access right (# 11r). ). Since the access right may be referred to as a lock number, a command (access right request command) for making this request is represented as “LOCK_REQ” in the drawing. The exclusive control register 41 that has received the access right request command uses the register value of the exclusive control register 41 corresponding to the access right when the access right assigned to the data group [a, b, c] is empty. A mutual exclusion value (MEV: Mutual Exclusion Value) is changed from “0” to “1”, and a response notifying that an access right is given is sent (# 11a). When the mutual exclusion value is “0”, it indicates that the access right is free, and when it is “1”, the access right is in use, and the response for notifying successful access right acquisition is It is expressed as “ACK (success)”. The first core 1 that has acquired the access right uses the data group [a, b, c] of the shared memory 4 (Global RAM). For example, the first core 1 refers to the data stored in the data group [a, b, c].

  When the first core 1 finishes using the shared memory 4, it releases the access right. In this embodiment, an access right release request command (UNLOCK_REQ) is transmitted to the exclusive control register 41 (# 12r). The exclusive control register 41 that has received the command changes the mutual exclusion value from “1” to “0”. At this time, the exclusive control register 41 may or may not respond to the first core 1 as shown in # 12a.

  When the second core 2 transmits an access right request command (LOCK_REQ) to the exclusive control register 41 while the first core 1 has acquired the access right (# 21r), the exclusive control register 41 has the access right. A response notifying that it is in use is sent (# 21a). As illustrated in FIG. 8, the exclusive control register 41 transmits a response “ACK (fail)” notifying the failure of access right acquisition to the second core 2.

  The exclusive control register 41 receives the access right from the second core 2 after the mutual exclusion value becomes “0” based on the transmission (# 12r) of the access right release request command (UNLOCK_REQ) from the first core 1. When the request command (LOCK_REQ) is received (# 22r), the mutual exclusion value is changed to “1”, and a successful access right acquisition “ACK (success)” is notified (# 22a). The second core 2 that has acquired the access right uses the data group [a, b, c] of the shared memory 4 (Global RAM). For example, the second core 2 updates the data of the data group [a, b, c]. Here, when data [a], data [b], and data [c] are updated at different timings, the second core 2 holds the access right until the update of all data is completed. Preferably it is. As described above, the exclusive control register 41 manages the access right to the data group [a, b, c] of the shared memory 4 so that the data group [a, b, c] can be used by a plurality of CPU cores 3.

  When the use of the data group [a, b, c] is finished, the second core 2 releases the access right (# 23r). Upon receiving the access right release request command (UNLOCK_REQ), the exclusive control register 41 changes the mutual exclusion value to “0”. Here, when the second core 2 transmits the access right request command (LOCK_REQ) again (# 24r), the exclusive control register 41 notifies the access right acquisition success “ACK (success)” (# 24a). The second core 2 continues to acquire the access right and uses the shared memory 4 (Global RAM) again.

  When the second core 2 finishes using the second data group [a, b, c], it releases the access right (# 25r). Upon receiving the access right release request command (UNLOCK_REQ), the exclusive control register 41 changes the mutual exclusion value to “0”. Here, when the second core 2 further transmits an access right request command (LOCK_REQ) (# 26r), the exclusive control register 41 notifies an access right acquisition success “ACK (success)” (# 26a). The second core 2 obtains the access right three times in succession and uses the data group [a, b, c].

  The first core 1 tries to acquire the access right multiple times after the second core 2 first acquires the access right of the shared memory 4 (# 13r, # 14r, # 15r, # 16r), but all fail. (# 13a, # 14a, # 15a, # 16a). During this time, the first core 1 is in a so-called deadlock state and cannot execute an operation using the data group [a, b, c]. For this reason, the first core 1 may prolong the processing time, or may be reset while the processing has not been completed because the specified timeout time has been reached.

  Therefore, as shown in FIG. 9, it is preferable to further provide reservation flags (RSV_CPU1, RSV_CPU2) so that the access reservation right can be set. The reservation flag (access reservation right) is set as a variable. A reservation flag of each CPU core 3 is set for each lock number. In the present embodiment, the reservation flag of the first core 1 is the first reservation flag 43 (RSV_CPU1), and the reservation flag of the second core 2 is the second reservation flag 45 (RSV_CPU2). Each CPU core 3 confirms a reservation flag of another CPU core 3 corresponding to the target access right before attempting to acquire the access right ("CHK" described later). If the reservation flag of the other CPU core 3 is not the reservation state (“1”), the acquisition of the lock number (access right) is requested. The other CPU cores 3 may have acquired the lock number without enabling the reservation flag. In this case, since the acquisition of the lock number will fail, the reservation flag is set so that its own reservation flag becomes valid (reserved state). That is, when the exclusive control register 41 (shared resource management function block) executes an exclusive process by giving a lock number (access right) to a specific shared resource 5 to one CPU core 3, the other CPU core 3 Sets an access reservation right, which is a right to acquire the next lock number after the lock number is released, as a reservation flag in the exclusive control register 41.

  A specific example will be described below with reference to FIG. In exclusive control that also uses a reservation flag, the first core 1 first checks the reservation flags of the other CPU cores 3. In the present embodiment, the first core 1 checks the state of the reservation flag (second reservation flag 45) of the second core 2 which is the other of the two CPU cores 3 (# 11c). The value of the second reservation flag 45 is “0” indicating an invalid state (a state in which no reservation right is set), and the first core 1 can access the data group [a, b, c]. Judgment that it exists is shown (Judge (success): # 11j). When it is confirmed that there is no reservation by the second core 2, as in FIG. 8, the first core 1 requests acquisition of an access right (# 11r), and the exclusive control register 41 sets the mutual exclusion value to “1”. "And at the same time, the access right is notified (# 11a).

  Here, consider a case where the second core 2 tries to acquire an access right. Prior to requesting the access right, the second core 2 checks the state of the reservation flag (first reservation flag 43) of the first core 1 (# 21c). Since the reservation right by the first core 1 is not set, it is determined that the data group [a, b, c] can be accessed by the second core 2 (Judge (success): # 21j ). The second core 2 requests acquisition of the access right based on the determination result (# 21r). However, the confirmation of the reservation flag is merely confirmation of the setting state of the access reservation right. In this case, since the access right has already been given to the first core 1, the exclusive control register 41 transmits a response “ACK (fail)” notifying the failure of access right acquisition to the second core 2 (#). 21a). The second core 2 notified of the failure to acquire the access right sets the value of the reservation flag (second reservation flag 45) of the second core 2 to “1” indicating a valid state (a state in which the reservation right is set). (RSV_SET: # 21s). After setting the access reservation right, the second core 2 requests acquisition of the access right again (# 27r), but the first core 1 has not released the access right and fails to acquire the access right again. Is sent to the second core 2 (# 27a).

  On the other hand, the exclusive control register 41 sets the mutual exclusion value to “0” based on the transmission of the access right release request command “UNLOCK_REQ” from the first core 1 (# 12r), and sets the access right release request command “UNLOCK_REQ”. Is accepted to the first core 1 (# 12a). The first core 1 checks the state of the reservation flag (second reservation flag 45) of the second core 2 in order to continue using the data group [a, b, c] (# 17c). The value of the second reservation flag 45 is “1” as described above, and the reservation right is set. Therefore, it is determined that access to the data group [a, b, c] by the first core 1 is impossible (Judge (fail): # 17j). The first core 1 confirms the state of the second reservation flag 45 again (# 18c), but since the state has not changed, it is again determined that access is not possible (Judge (fail): # 18j). If the acquisition of the lock number is hindered by the state of the reservation flag of another CPU core 3, it is preferable not to set its own reservation flag to the valid state. This is to prevent any CPU core 3 from acquiring a lock number in a mutual reservation state.

  The second core 2 that has set its own reservation flag (second reservation flag 45) to the valid state requests access right without checking the state of the reservation flag (first reservation flag 43) of the first core 1. The command “LOCK_REQ” is transmitted (# 28r). As described above, since the second reservation flag 45 is “1”, the access right (lock number) is released without being acquired by the first core 1. Accordingly, the exclusive control register 41 changes the mutual exclusion value to “1” and notifies the success of access right acquisition “ACK (success)” (# 28a). Further, by acquiring the lock number, the second core 2 changes the value of its own reservation flag (second reservation flag 45) to “0” in an invalid state (non-reserved state) (RSV_Release: # 28s).

  Here, when the first core 1 confirms the state of the reservation flag (second reservation flag 45) of the second core 2 (# 19c), since the reservation right by the second core 2 is released, the first core 1 1 indicates that access to the data group [a, b, c] is possible (Judge (success): # 19j). The first core 1 requests acquisition of the access right based on the determination result (# 19r), but since the access right has already been given to the second core 2, the exclusive control register 41 acquires the access right. (ACK (fail): # 19a). The first core 1 notified of the failure to acquire the access right sets the value of the reservation flag (first reservation flag 43) of the first core 1 to “1” indicating a valid state (a state in which the reservation right is set). (RSV_SET: # 19s).

  As described above with reference to FIG. 9, the exclusive control register 41 (shared resource management function block) is provided with a reservation flag, and each CPU core 3 performs an access reservation process, thereby suppressing the occurrence of a deadlock. can do.

  By the way, the cause of the occurrence of the deadlock is not limited to the form illustrated in FIG. In the case where the CPU core 3 uses a plurality of shared resources 5 at the same time, if the plurality of CPU cores 3 acquire the access rights of some of the shared resources 5, they cannot execute the processes. The busy state may continue. In this case, since none of the CPU cores 3 can complete the processing, the shared resource 5 is not released and all the CPU cores 3 may time out. Including such an event, a deadlock may occur even if it is designed to suppress the occurrence of a deadlock. By grasping that a deadlock has occurred and analyzing the cause, it is possible to change the program and try to improve the application.

  For example, when a deadlock occurs in which the CPU core 3 waits for the access right to be released and the execution of arithmetic processing by the CPU core 3 is stopped, and a predetermined timeout time elapses, at least the deadlock The processing (reset processing) for returning the arithmetic processing by the CPU core 3 in which the occurrence of the error occurred to the initial state is executed by the management function block that manages the CPU core 3 or the plurality of CPU cores 3 in an integrated manner. This management function block is, for example, the reset controller 33. When the reset process is executed, fail information including at least the number of times access right acquisition has failed is recorded in a recording area in the multi-core arithmetic unit 10. For example, reset to the storage area of the memory (shared memory 4, data flash memory 34) included in the shared resource 5 or the memory (first dedicated memory 19 and second dedicated memory 29) occupied by each CPU core 3 A recording area that is not in an initial state is set by processing. The recording area may be set to a nonvolatile memory such as the data flash memory 34, which preferably holds data even when power is not supplied. Note that the fail information may be reset information including the number of times the reset process has been executed.

[Outline of Embodiment]
The outline of the multi-core arithmetic device (10) described above will be briefly described below.

As one aspect, at least two independent CPU cores (3), a first core (1) and a second core (2) that operates independently of the first core (1), A multi-core arithmetic device (10) having a shared memory (4) that is commonly used by the CPU core (3),
A plurality of CPU cores (3) communicate via the shared memory (4);
A behavior schedule application (AP1) which is software for determining a behavior schedule indicating the order of behavior change of the vehicle drive transmission device (100) to be controlled;
An actuator control application (AP2) which is software for controlling the actuator (120) for operating the vehicle drive transmission device (100) according to the determined behavior schedule;
At least physical information for determining the behavior schedule is acquired, and at least a sensing application (AP3) that is software that provides the physical information to the behavior schedule application (AP2) is executed.
The first core (1) executes the behavior schedule application (AP1);
The second core (2) executes the actuator control application (AP2) and the sensing application (AP3).

  For example, the behavior of the vehicle drive transmission device (100) is defined by the selection of a mechanical component (101) such as a gear. Further, the connection (coupling) of the selected gears is often realized through the control component (102). Here, the calculation related to the behavior of the machine component (101) and the calculation related to the behavior of the control component (102) may be executed using different hardware resources. However, when the control target is the vehicle drive transmission device (100), etc., as described above, the behavior change between the mechanical component (101) and the control component (102) has order dependency. For this reason, if these two controls are executed using different hardware resources, an unnecessary waiting time may be generated and the calculation efficiency may be reduced. According to this configuration, since the behavior schedule indicating the order of behavior change of the vehicle drive transmission device (100) is computed by one CPU core (3 (1)), the computation efficiency is reduced as such. Is suppressed.

  In the vehicle drive transmission device (100), an actuator (120) is generally required to actually realize the connection of gears and the like. Since the actuator (120) is naturally provided outside the multi-core arithmetic device (10), control signals and data are transmitted via the interface function blocks (6, 7) of the multi-core arithmetic device (10). . In addition, a sensor (130) for detecting physical information indicating an operation state of the vehicle drive transmission device (100) is also provided outside the multi-core arithmetic device (100). Therefore, information detected by such a sensor (130) is also transmitted via the interface function blocks (6, 7) of the multi-core arithmetic unit (10). For example, when the actuator control application (AP2) and the sensing application (AP3) are executed by different CPU cores (3), the actuator (120) and the sensor (130) have the same interface function block (6 , 7), a waiting time may occur in one of the CPU cores (3). Since such a waiting time may occur in any CPU core (3), the calculation efficiency may decrease as a whole. According to this configuration, since the actuator control application (AP2) and the sensing application (AP3) are executed by the same CPU core (3 (2)), it is possible to suppress such a decrease in calculation efficiency.

  Here, the vehicle drive transmission device (100) has a transmission (101) capable of changing a transmission gear ratio, and the behavior schedule application (AP1) has a fluid pressure supplied to the transmission (101). It is preferable to determine the change as the behavior schedule.

  For example, the behavior of the vehicle drive transmission device (100) is defined by the selection of a combination of gears and the setting of the diameter of a pulley with a variable diameter in the transmission (101), which is a mechanical component. Further, the behavior of the mechanical component such as the combination of the selected gears and the change of the diameter of the pulley is often realized through a fluid pressure circuit (102) as an example of a control component. As described above, the calculation related to the behavior of the mechanical component (transmission (101)) and the calculation related to the behavior of the control component (fluid pressure circuit (102)) are executed using different hardware resources. Also good. However, when the vehicle drive transmission device (100) is a control target, the behavior change between the mechanical component (transmission device (101)) and the control component (fluid pressure circuit (102)) has order dependency. For this reason, as described above, the calculation efficiency may be reduced. By executing the behavior schedule application (AP1), the change in the fluid pressure that realizes the behavior of the transmission (101) is determined as the behavior schedule, so that the vehicle drive transmission device ( 100) can be controlled.

  The vehicle drive transmission device (100) preferably includes a hydraulic control actuator (120), and the actuator control application (AP2) preferably controls the hydraulic control actuator (120) by outputting a modulation pattern. It is.

  As described above, the control component of the vehicle drive transmission device (100) is often realized, for example, via the fluid pressure circuit (102). The fluid pressure circuit (102) is generally provided with a hydraulic control actuator (120). The operation amount of the hydraulic control actuator (120) can be controlled by various methods. For example, control using pulse width modulation according to the command value or modulation such as amplitude modulation has good responsiveness, preferable. Therefore, it is preferable that the actuator control application (AP2) controls the hydraulic control actuator (120) by outputting the modulation pattern.

  The vehicle drive transmission device (100) includes at least a sensor (130) that detects the physical information for determining the behavior schedule, and the sensing application (AP3) is controlled by the sensor (130). It is preferable to acquire the detected physical information.

  In determining the behavior schedule by the first core (1), it is important to detect physical phenomena in the automatic transmission (101) and the hydraulic circuit (102). For this reason, in many cases, the vehicle drive transmission device (100) is provided with sensors for detecting a shift position, hydraulic pressure, oil temperature, and the like. When physical information detected by such a sensor (130) is acquired by a sensing application (AP3) executed by a second core (2) different from the first core (1), the behavior schedule is calculated. Appropriate physical information can be obtained without any influence.

The multi-core arithmetic device (10) further includes an external communication interface (7) for communicating with the actuator (120) and a peripheral device including the sensor (130) for detecting the physical information, and at least the external communication interface. (7) and a DMA controller (6) for performing DMA transfer to the shared memory (4),
The external communication interface (7) and the DMA controller (6) are used only by applications executed by the second core (2) among the first core (1) and the second core (2). ,
The first core (1) writes the behavior schedule which is a calculation result by the execution of the behavior schedule application (AP1) to the shared memory (4),
The second core (2) reads the behavior schedule stored in the shared memory (4) from the shared memory (4), executes the actuator control application (AP2) based on the behavior schedule, A calculation result by execution of the actuator control application (AP2) is provided to the actuator (120) via the external communication interface (7) by DMA transfer,
Further, the second core (2) is configured to transfer the physical information received from the sensor (130) by the external communication interface (7) by the DMA transfer by executing the sensing application (AP3). 7) to the shared memory (4).

  In many cases, the functional units such as the DMA controller (6) and the external communication interface (7) can use a plurality of CPU cores (3) included in the multi-core arithmetic device (10). However, when these function units are used by a plurality of CPU cores (3), arbitration such as exclusive processing is required between the plurality of CPU cores (3). As described above, when only the single CPU core (3) (second core (2)) uses the DMA controller (6) and the external communication interface (7), there is no need to perform such arbitration. An application using these functional units can be executed in a timely manner under the control of two cores (2). As a result, overhead time such as communication time and waiting time can be suppressed, and the calculation efficiency of the multi-core arithmetic device (10) is improved.

  The envelope (10p) that houses the plurality of CPU cores (3) and the shared memory (4) includes a plurality of input / output terminals (10t), and includes the first core (1) and the second core (1). Preferably, the core (2) is assigned with the input / output terminals (10t) that it occupies.

  When the input / output terminal (10t) is shared among the plurality of CPU cores (3), a waiting time may occur in the calculation. However, when the occupied input / output terminal (10t) is assigned to the first core (1) and the second core (2), the vehicle drive transmission device ( 100) can be controlled.

  As one aspect, when an abnormality occurs in the vehicle drive transmission device (100), the multi-core arithmetic device (10) further executes a fail-safe application (AP4) that is software for coping with the abnormality. The fail-safe application (AP4) is preferably executed by the first core (1).

  When an abnormality occurs in the vehicle drive transmission device (100), it is desirable to quickly reflect it in the overall behavior schedule of the vehicle drive transmission device (100). Therefore, it is preferable that the fail-safe application (AP4) is executed by the first core (1) on which the behavior schedule application (AP1) is executed.

  In the shared memory (4), at least one data group that is a set of a plurality of data used in a state in which the consistency of the plurality of data is ensured is set, and the multi-core arithmetic device (10) A shared resource management function block (41, 43) for managing an access right that is a right to use the shared resource (5) including the data group, wherein the shared resource (5) includes the CPU core having the access right; (3) can be used, and each of the CPU cores (3) uses the shared resource (5) after acquiring the access right to the shared resource (5), and after using the shared resource (5), The access right is released, and the shared resource management function block (41, 43) is configured such that one CPU core (3) accesses the specific shared resource (5). When acquiring the right, it is preferable to perform the exclusive process which prohibits the use of the specific of the shared resource by all other of said CPU core (3) (5).

  For example, if the shared resource (5) is a data group of the shared memory (4) and the exclusion process is not executed, the CPU core (3) may execute the application using data whose consistency is not ensured. And the reliability of control decreases. Such an event may occur not only in the data group of the shared memory (4) but also in other shared resources such as an input / output register for setting data of the input / output terminal (10t). By performing the exclusive process, it becomes possible to maintain the consistency of the shared resource (5), and to ensure the stability of the calculation.

  Here, when the shared resource management function block (41, 43) gives the access right to the specific shared resource (5) to one CPU core (3) and executes the exclusive processing, It is preferable that the other CPU core (3) sets an access reservation right, which is a right to acquire the next access right after the access right is released, in the shared resource management function block (41, 43). It is.

  If the CPU core (3) having the access right acquires the access right immediately after releasing the access right, the other CPU core (3) still cannot acquire the access right due to the exclusion process. If the access right acquisition failure continues at such timing, the other CPU core (3) is in a so-called deadlock state and cannot execute the operation using the shared resource (5). The processing time may be prolonged, or the specified timeout time may be reached and the processing may be incomplete. As described above, when the access reservation right is set, the occurrence of deadlock can be suppressed.

As one aspect, the CPU core (3) waits for the release of the access right, and a deadlock that is a state in which execution of arithmetic processing by the CPU core (3) stops occurs, and a predetermined timeout time When the process has passed, at least the reset process, which is a process for returning the arithmetic processing by the CPU core (3) in which the deadlock has occurred, to the initial state is integrated with the CPU core (3) or the plurality of CPU cores. Executed by the management function block (33) to manage,
In the storage area of the memory (4, 34) included in the shared resource (5) or the memory (19, 29) occupied by each of the CPU cores (3), there is a recording area that is not in the initial state by the reset process. Set,
It is preferable that reset information including at least the number of times the acquisition of the access right is failed is recorded in the recording area when the reset process is executed.

  If the deadlock state is not resolved, reset processing is executed. By recording information indicating that access right acquisition has failed in the recording area, it is possible to grasp the frequency of deadlock occurrence and to generate the CPU core (3) when debugging the multi-core arithmetic device (10). Can be identified. And based on these information, improvement of the application (program, software) which controls the drive transmission device for vehicles (100), improvement of exclusive processing and reservation processing by the shared resource management function block (41, 43), etc. It can be carried out.

1: 1st core 2: 2nd core 3: CPU core 4: Shared memory 5: Shared resource 6: DMA controller 7: External communication interface 10: Multi-core arithmetic unit 10p: Envelope 10t: Input / output terminal 33: Reset controller (Management function block)
34: Data flash memory 41: Exclusive control register (shared resource management function block)
41r: reserved register (shared resource management function block)
43: Internal core interrupt control register (shared resource management function block)
DESCRIPTION OF SYMBOLS 100: Vehicle drive transmission device 101: Automatic transmission 102: Hydraulic circuit 120: Hydraulic control actuator group (hydraulic control actuator)
130: Sensor group (sensor)
200: Vehicle drive control device AP1: Transmission control application AP1a: Shift control application AP1b: Hydraulic control application AP2: Actuator control application AP3: Sensing application AP4: Fail-safe application

Claims (10)

At least two independent CPU cores, a first core and a second core that operates independently of the first core;
A shared memory shared by a plurality of CPU cores;
A multi-core arithmetic device comprising:
A plurality of the CPU cores communicate via the shared memory,
A behavior schedule application that is software for determining a behavior schedule indicating the order of behavior change of the vehicle drive transmission device to be controlled;
An actuator control application that is software for controlling an actuator that operates the vehicle drive transmission device according to the determined behavior schedule;
At least physical information for determining the behavior schedule is acquired, and at least a sensing application that is software that provides the physical information to the behavior schedule application is executed.
The first core executes the behavior schedule application;
The multi-core arithmetic device, wherein the second core executes the actuator control application and the sensing application.   The said vehicle drive transmission apparatus has a transmission which can change a gear ratio, and the said behavior schedule application determines the change of the fluid pressure supplied to the said transmission as the said behavior schedule. Multi-core arithmetic unit.   The multi-core arithmetic device according to claim 1, wherein the vehicle drive transmission device includes a hydraulic control actuator, and the actuator control application controls the hydraulic control actuator by outputting a modulation pattern.   The vehicle drive transmission device includes at least a sensor that detects the physical information for determining the behavior schedule, and the sensing application acquires the physical information detected by the sensor. 4. The multi-core arithmetic device according to any one of 3. Furthermore, an external communication interface that communicates with the actuator and a peripheral device including a sensor that detects the physical information, and a DMA controller that performs DMA transfer to at least the external communication interface and the shared memory,
The external communication interface and the DMA controller are used only by applications executed by the second core out of the first core and the second core,
The first core writes the behavior schedule, which is a calculation result by execution of the behavior schedule application, to the shared memory,
The second core reads the behavior schedule stored in the shared memory from the shared memory, executes the actuator control application based on the behavior schedule, and calculates a calculation result by the execution of the actuator control application as a DMA. Providing to the actuator via the external communication interface by transfer,
Further, the second core causes the external communication interface to store the physical information received from the sensor by the DMA application from the external communication interface in the shared memory by executing the sensing application. The multi-core arithmetic device according to any one of the above. The envelope that houses the plurality of CPU cores and the shared memory includes a plurality of input / output terminals,
The multi-core arithmetic device according to any one of claims 1 to 5, wherein the input / output terminals to be occupied are assigned to the first core and the second core, respectively. Furthermore, when an abnormality occurs in the vehicle drive transmission device, a fail-safe application that executes software for dealing with the abnormality is executed.
The multi-core arithmetic device according to claim 1, wherein the fail-safe application is executed by the first core. In the shared memory, at least one data group that is a set of a plurality of data used in a state in which the consistency of the plurality of data is ensured is set,
A shared resource management function block for managing an access right that is a right to use a shared resource including the data group;
The shared resource can be used by the CPU core having the access right,
Each of the CPU cores uses the shared resource after acquiring the access right to the shared resource, and releases the access right after the use ends.
The shared resource management function block is an exclusive process for prohibiting use of the specific shared resource by all other CPU cores when one CPU core acquires the access right to the specific shared resource. The multi-core arithmetic device according to any one of claims 1 to 7, wherein: When the shared resource management functional block gives the access right to a specific shared resource to one CPU core, and executes the exclusive processing,
The multi-core operation according to claim 8, wherein the other CPU core sets an access reservation right, which is a right to acquire the next access right after the access right is released, in the shared resource management function block. apparatus. If the CPU core waits for the release of the access right and a deadlock occurs in which execution of arithmetic processing by the CPU core is stopped, and a predetermined timeout period elapses, at least the deadlock A reset process, which is a process for returning the arithmetic processing by the CPU core in which the error occurred to an initial state, is executed by the management function block that manages the CPU core or a plurality of the CPU cores,
In a memory area included in the shared resource or a memory area occupied by each CPU core, a recording area that is not in an initial state by the reset process is set,
The multi-core arithmetic device according to claim 8 or 9, wherein at the time of executing the reset process, fail information including at least the number of times the access right acquisition has failed is recorded in the recording area.

Images