Vehicle control unit

Abstract

To share an accelerator among applications mounted on SoC.SOLUTION: In a vehicle control unit having multiple semiconductor chips each having at least one application and at least one accelerator connected to the multiple semiconductor chips, each of the multiple semiconductor chips includes an accelerator access section for controlling access to the accelerators, and a time slot information storage section for storing time slot information showing propriety of access to the accelerators from the application in each time slot. The application can output a usage request to the accelerators via the accelerator access section, and the accelerator access section determines whether the usage request is transmitted to the accelerators on the basis of information on propriety of the access in a time slot corresponding to current time for the usage request.SELECTED DRAWING: Figure 6

Description

[Technical field]

[0001] The present invention relates to a vehicle control device. [Background technology]

[0002] As vehicle control becomes more sophisticated and complex due to the advancement of autonomous driving, the amount of processing required for autonomous driving vehicle control devices is increasing. To meet this demand, vehicle control devices equipped with multiple systems on chips (SoCs) are being adopted. In addition, in order to improve the processing performance of each SoC, the processing speed of the central processing unit (CPU) installed inside the SoC has been increased and it has become multi- and many-core. However, due to the heat generation and reduced power efficiency of the SoC, the processing speed is already reaching its limit, and even if the number of cores is increased by multi- and many-core, the expected processing performance may not be achieved because of the bottleneck of processing that cannot be parallelized. Therefore, the installation of accelerators is progressing. Accelerators make it possible to execute specific processing, such as image processing and inference in machine learning, at lower power consumption and higher speed than a CPU. Accelerators are installed inside or outside the SoC. In order to balance the performance and cost of vehicle control devices, it is important to efficiently utilize hardware resources, and it is required to share accelerators between multiple applications.

[0003] A technology related to sharing an accelerator among multiple applications is described in Patent Document 1. Patent Document 1 discloses a vehicle control device including a shared storage shared by multiple applications, and an access right management unit that divides one time slot to include a static area corresponding to a time-triggered access request from the applications and a dynamic area corresponding to an event-triggered access request from the applications, and assigns an access right from the applications to the shared storage to either the static area or the dynamic area.

[0004] Patent Document 2 also discloses the following computer system. That is, the access path to the shared resource is a single I / F, and a contention control module that integrates the access I / F from each subsystem to the shared resource is provided independently. The contention control module serializes the access requests from each subsystem to the shared resource. If the period required to complete access to the shared resource is one time slot, the access period of the subsystem is set to "number of subsystems x time slots". As a result, the number of accesses to the shared resource during any access period does not exceed the number of subsystems, and access from the subsystems to the shared resource appears to be a fixed cycle, making it possible to simply configure the bus control circuit in this computer system. [Prior art documents] [Patent documents]

[0005] [Patent Document 1] JP 2022-053096 A [Patent Document 2] JP 2013-174934 A Summary of the Invention [Problem to be solved by the invention]

[0006] Although Patent Document 1 does not refer to an accelerator, it is applicable if storage is replaced with accelerator and Electronic Control Unit (ECU) is replaced with SoC. That is, the accelerator can be shared between applications mounted on different SoCs. This document is based on the premise that the accelerator (shared storage in this document) exists inside a certain SoC (integrated ECU in the document), and a mechanism for managing access to the accelerator (called shared storage in the document) is installed in the SoC (called integrated ECU in the document) to mediate access from each application to the accelerator (called shared storage in the document) so as not to conflict. On the other hand, if this technology is applied to a vehicle control device having an accelerator outside the SoC, in order to access the accelerator from a SoC that does not have a management mechanism, it is necessary to bypass the SoC that has the management mechanism, and latency will worsen. This can negate the effect of accelerating processing by the accelerator.

[0007] According to Patent Document 2, access from an application (called a subsystem in the document) to an accelerator (called a shared resource in the document) is fixed to a cycle of "number of applications x time slot", which simplifies the design of a bus control circuit. However, this method is inefficient when there are many applications using the accelerator and the frequency of access to the accelerator differs between the applications, because the application with the higher frequency of access must wait until the time when the time slot assigned to that application starts.

[0008] In light of the above, the present invention is particularly aimed at accelerators mounted outside the SoC, and aims to efficiently share the accelerator among multiple applications mounted on different SoCs, with the objective of enabling each SoC to directly access the accelerator without causing access contention. [Means for solving the problem]

[0009] A representative example of the invention disclosed in the present application is as follows: A vehicle control device including a plurality of semiconductor chips each having one or more applications and one or more accelerators connected to the plurality of semiconductor chips, wherein each of the plurality of semiconductor chips has an accelerator access unit that controls access to the accelerator and a time slot information storage unit that stores time slot information indicating whether or not the application can access the accelerator in each time slot, the application can output a use request to the accelerator via the accelerator access unit, and the accelerator access unit determines whether or not to transfer the use request from the application to the accelerator based on the access availability information for the time slot corresponding to the current time. Effect of the Invention

[0010] According to one aspect of the present invention, the time for each SoC to use each accelerator is divided in advance, so that contention does not occur. Problems, configurations, and effects other than those described above will become apparent from the description of the embodiment of the invention described below. [Brief description of the drawings]

[0011] [Figure 1] 1 is a diagram illustrating a hardware configuration of a vehicle control device according to a first embodiment. [Figure 2A] FIG. 2 is a diagram showing a software configuration in an SoC before the present invention is applied. [Figure 2B] FIG. 2 is a diagram showing a software configuration in an SoC before the present invention is applied. [Diagram 3] FIG. 11 is a diagram illustrating an access contention that occurs when no measures such as those in the first embodiment are taken. [Figure 4] FIG. 11 is a diagram showing a state of detouring access that occurs when a centralized management mechanism is provided in the first embodiment; [Diagram 5]FIG. 13 is a diagram illustrating the latency from the control application of the SoC to the start of access to the accelerator during a detour access. [Figure 6] FIG. 1 is a diagram illustrating an overview of a first embodiment. [Figure 7] FIG. 7 is a diagram illustrating the latency from the control application of the SoC until the start of access to the accelerator in the case of FIG. 6. [Figure 8] FIG. 2 is a diagram showing an overview of time slot allocation in the first embodiment. [Figure 9] FIG. 9 is a diagram illustrating the latency from the control application of the SoC until the start of access to the accelerator in the case of FIG. 8. [Figure 10] FIG. 13 is a diagram illustrating an overview of a third embodiment. [Figure 11] 13 is a diagram showing information on used spare time slots managed internally by an update unit. FIG. [Figure 12] FIG. 13 is a diagram illustrating an example of the flow of processing performed between SoCs when updating a time slot in the third embodiment. [Figure 13] FIG. 13 is a diagram illustrating an overview of a fourth embodiment. [Figure 14] FIG. 13 is a diagram illustrating an overview of a fifth embodiment. [Figure 15] FIG. 13 is a diagram illustrating an overview of a sixth embodiment. [Figure 16] FIG. 13 is a diagram showing a new access prohibition section at the beginning of an accessible time slot. [Figure 17] 13 is a diagram showing a new access prohibition section at the end of an accessible time slot. DETAILED DESCRIPTION OF THE PREFERRED EMBODIMENTS

[0012] The following describes the embodiments for carrying out the invention using a plurality of examples. These examples will be described as being related to a vehicle control device. In these examples, for simplicity, an example of a vehicle control device having a System on Chip (SoC) formed on two semiconductor chips and two accelerators will be used for the description. However, the number of SoCs may be three or more, and the number of accelerators may be one or three or more.

Example

[0013] <Hardware Configuration> <Vehicle Control Device 0> FIG. 1 is a diagram showing the hardware configuration of the vehicle control device 0 in the first embodiment. The hardware configuration of the vehicle control device 0 according to the present invention will be described with reference to FIG. 1. The vehicle control device 0 includes a first SoC, SoC1, a second SoC, SoC2, a first accelerator, accelerator 3, and a second accelerator, accelerator 4, which are connected to each other via a communication bus 5. The communication method in the communication bus 5 is not limited. For the purpose of description in this embodiment, it is assumed that this communication method is Peripheral Component Interconnect Express (PCIe), which is one of the communication methods generally used between an SoC and an accelerator existing outside the SoC. At this time, SoC1 and SoC2 are designated as hosts in PCIe, and accelerator 3 and accelerator 4 are designated as devices in PCIe, and they may be connected to each other by a known technology such as a PCIe fabric.

[0014] <Hardware Configuration of SoC1 and SoC2> An example of the hardware configuration of SoC1 and SoC2 according to the present invention will be described with reference to FIG. 1. Each SoC is equipped with a processor 6, a memory 7, an external communication port 8, and an internal bus 29. The processor 6 may include a Central Processing Unit (CPU) core 61 for performing arithmetic processing, and a cache memory 62 for temporarily storing data. The memory 7 is a main memory including a Read Only Memory (ROM) and a Random Access Memory (RAM). The external communication port 8 is a port for performing communication using the communication bus 5, and in this embodiment, since external communication is performed by PCIe, a port defined by PCIe is applicable. The processor 6, the memory 7, and the external communication port 8 are connected to each other by the internal bus 29 and transmit information.

[0015] <Hardware configuration of Accelerator 3 and Accelerator 4> A hardware configuration example of the accelerator 3 and the accelerator 4 according to the present embodiment will be described with reference to FIG. 1. Each accelerator is equipped with an external communication port 8 and a memory 7, similar to the SoC. Each accelerator also includes a register 9, a Direct Memory Access Controller (DMAC) 10, and a specific processing calculation unit 11. Data transmitted from the SoC1 or SoC2 and received at the external communication port 8 of the accelerator 3 or accelerator 4 can be automatically transferred to the memory 7 or the register 9 by the DMAC 10, and the specific processing calculation unit 11 can be started. The specific processing calculation unit 11 calculates a specific process to be processed on behalf of the CPU core 61 in the SoC, stores the calculation result in the memory 7, and requests the DMAC 10 to transfer the stored calculation result. The specific process to be processed on behalf of the CPU core 61 specifically corresponds to, for example, image processing or inference processing in machine learning. When the DMAC 10 receives a transfer instruction from the specific processing operation unit 11, it transfers the processing result stored in the memory 7 to the external communication port 8, and the processing result is transmitted to the SoC1 or SoC2.

[0016] <Software configuration> 2A and 2B are diagrams showing the software configurations of SoC1 and SoC2 before the present invention is applied. The software configurations of SoC1 and SoC2 before the present invention is applied will be described with reference to Figs. 2A and 2B.

[0017] SoC1 and SoC2 may have a scheduler 12, an accelerator driver 13 which is a first accelerator driver, an accelerator driver 14 which is a second accelerator driver, and one or more control applications 15. The control application 15 may be, for example, an application that detects a driving lane from an image acquired from a camera attached to the front of the vehicle, or an application that detects vehicles and pedestrians from the same image. The scheduler 12 starts each control application 15 at a time (which may be a period) that is preset for the control application 15.

[0018] The accelerator driver 13 is called by the control application 15, and receives data to be transferred to the accelerator 3 from the control application 15 as an access request to the accelerator 3, i.e., a use request. Next, the accelerator driver 13 transmits data from the external communication port 8 of the SoC1 or SoC2 to which the accelerator driver 13 belongs to, via the communication bus 5, to the external communication port 8 of the accelerator 3. This means that the control application 15 can output a use request to the accelerator 3 via the accelerator driver 13. In addition, the accelerator driver 13 receives a processing result from the accelerator 3, and stores the processing result in the memory 7 of the SoC1 or SoC2 to which the accelerator driver 13 belongs. In this embodiment, since the communication bus 5 is PCIe, specifically, the accelerator driver 13 generates and transmits a Transaction Layer Packet (TLP) defined by PCIe. Since it is difficult to store all the transfer data in one TLP, when the control application 15 calls the accelerator driver 13 once, the accelerator driver 13 usually generates multiple TLPs.

[0019] The accelerator driver 14 is called by the control application 15, and receives data to be transferred to the accelerator 4 from the control application 15 as an access request to the accelerator 4, i.e., a use request. Next, the accelerator driver 14 transmits data from the external communication port 8 of the SoC1 or SoC2 to which the accelerator driver 14 belongs to the accelerator 4 via the communication bus 5 to the external communication port 8 of the accelerator 4. This means that the control application 15 can output a use request to the accelerator 4 via the accelerator driver 14. The accelerator driver 14 also receives a processing result from the accelerator 4 and stores the processing result in the memory 7 of the SoC1 or SoC2 to which the accelerator driver 14 belongs. In this embodiment, since the communication bus 5 is PCIe, specifically, the accelerator driver 14 generates and transmits a TLP defined by PCIe. Since it is difficult to store all the transfer data in one TLP, when the control application 15 calls the accelerator driver 14 once, the accelerator driver 14 usually generates multiple TLPs.

[0020] <Access contention occurs> 3 is a diagram showing the state of access contention that occurs when no measures such as those in this embodiment are taken. This access contention will be explained using FIG.

[0021] In the example shown in FIG. 3, the control application 15 mounted on SoC1 calls the accelerator driver 13 mounted on SoC1, and sequentially transfers data to an area of ​​addresses 0x1000 to 0x2000 in the memory 7 mounted on the accelerator 3. At the same time, the control application 15 mounted on SoC2 calls the accelerator driver 13 mounted on SoC2, and sequentially transfers data to an area of ​​addresses 0x1500 to 0x3000 in the memory 7 mounted on the accelerator 3. These data transfers are performed using a plurality of packets. At this time, data from the control application 15 of SoC1 is written to addresses 0x1000 to 0x1500 in the memory 7 of the accelerator 3, and data from the control application 15 of SoC2 is written to addresses 0x2000 to 0x3000. However, for 0x1500 to 0x2000, data from control application 15 of SoC1 or control application 15 of SoC2 will be written according to the arrival order of the packets, and the data will be undefined. This is the occurrence of access contention. In this case, accelerator 3 cannot obtain a correct calculation result. Therefore, it is necessary to ensure that the same accelerator is not accessed simultaneously between those SoCs.

[0022] <Latency degradation due to detouring access> 4 is a diagram showing a state of a detouring access that occurs when a centralized management mechanism is provided in this embodiment. This detouring access will be explained with reference to FIG.

[0023] As shown in Fig. 4, when the access centralized manager 17 is provided in the SoC1, all accesses to the accelerator 3 and the accelerator 4 are made via the access centralized manager 17 of the SoC1. Since all accesses to the accelerator 3 are made by the access centralized manager 17, the access centralized manager 17 can determine that the accelerator 3 is in use from the time data is transferred to the accelerator 3 until a calculation result is received from the accelerator 3, and can determine that the accelerator 3 is not in use (is in an unused state) otherwise. When the control application 15 mounted on the SoC1 tries to access the accelerator 3, it calls the access centralized manager 17 instead of calling the accelerator driver 13, and passes the data to be passed to the accelerator 3 to the access centralized manager 17 once. When the control application 15 mounted on the SoC2 tries to access the accelerator 3, it does not call the accelerator driver 13 mounted on the SoC2, but uses the inter-SoC communication unit 16 mounted on the SoC2 to transmit the data to be transferred to the SoC1, and when the inter-SoC communication unit 16 in the SoC1 receives the data, it passes the data to the access general manager 17. When the access general manager 17 receives the data, it checks the state of the accelerator 3, and if the accelerator 3 is not in use, it calls the accelerator driver 13 to start using the accelerator 3. However, if not, it stores the data in a queue in the access general manager 17, and when the accelerator 3 becomes free, it takes the data from the queue and calls the accelerator driver 13. This prevents the access contention as shown in FIG. 3 from occurring, and the accelerator 3 can be shared and used between the control applications 15 mounted on the SoC1 and SoC2. In this embodiment, the inter-SoC communication method is a serial peripheral interface (SPI), but is not limited to SPI and may be any method that allows communication between SoCs, such as a controller area network (CAN) or Ethernet.

[0024] 5 is a diagram showing the latency from the control applications 15 of SoC1 and SoC2 to the start of access to the accelerator 3 during detouring access. The deterioration of latency will be described with reference to FIG.

[0025] In this embodiment, each process is assumed to be started periodically. Specifically, for example, the control application 15 and the inter-SoC communication unit 16 are started by the scheduler 12 at a period of 50 ms, and the access general management unit 17 is started at a period of 25 ms. In FIG. 5, the lightning-like mark indicates the timing of starting by the scheduler 12. The access general management unit 17 is mounted on the SoC1. In this case, when the control application 15 mounted on the SoC1 requests access to the accelerator 3, the access to the accelerator 3 is started at the timing when the access general management unit 17 is started for the first time after the timing when the control application 15 is started (in FIG. 5, the time of the control application 15 (SoC1) is indicated by a black lightning-like mark). If the accelerator 3 is not being used by another application, the time from when the control application 15 requests access to when the access to the accelerator 3 is actually started, i.e., the latency, can be estimated to be about 30 ms.

[0026] On the other hand, when the control application 15 mounted on the SoC2 requests access to the accelerator 3, data transfer from the SoC2 to the SoC1 is started when the inter-SoC communication unit 16 of the SoC2 is started for the first time after the control application 15 is started, and the data is passed to the access centralized management unit 17 when the inter-SoC communication unit 16 of the SoC1 is started for the first time after the transfer is completed. Then, when the access centralized management unit 17 is started (if the accelerator 3 is not being used by another application), access to the accelerator 3 is started. Therefore, the time from when the control application 15 requests access to when access to the accelerator 3 is actually started, that is, the latency, can be estimated to be about 90 ms. Therefore, if a mechanism for centralized management of access to the accelerator is provided in one SoC to prevent access contention, the latency when an accelerator is accessed from an SoC that does not have the mechanism is larger than the latency when an accelerator is accessed from an SoC that has the mechanism.

[0027] It is possible to reduce latency by making some of the processing an interrupt type, but this affects other periodically activated tasks, making verification difficult. Even if the processing is changed to an interrupt type, access from an SoC that does not have a centralized management mechanism still requires time due to the need for data transfer using inter-SoC communication. If access requires time, the effect of accelerating inference processing, which is the purpose of using the accelerator in this embodiment, cannot be obtained.

[0028] <Time-sharing access management> Fig. 6 is a diagram showing an overview of the vehicle control device in this embodiment. The overview of the vehicle control device in this embodiment will be described with reference to Fig. 6. In Fig. 6, the accelerator 4 and the second accelerator driver 14 are omitted from the illustration.

[0029] In FIG. 6, a time synchronization unit 18 that synchronizes the time between SoC1 and SoC2 is provided in each SoC. Also, each SoC has an accelerator access unit 19 that performs time-division access based on the synchronized time, and an available time slot information storage unit 20 that stores information on whether each accelerator can be accessed in each time slot. A time slot is generally, for example, a periodic time interval that is recognized and defined as being different from each other, and is a division of the right to use resources by time. Here, a time slot may be a periodic definition of whether or not access to one or more accelerators is allowed for at least one of a plurality of SoCs for a plurality of time periods. A time slot has a certain time width, and in this embodiment, the length of the time width of a time slot is 10 ms. In the table stored in the available time slot information storage unit 20, ◯ indicates that access is allowed, and × indicates that access is not allowed. The contents of the information stored in the available time slot information storage unit 20 in SoC1 and the information stored in the available time slot information storage unit 20 in SoC2 are determined in advance so that access from both SoCs does not overlap with the same accelerator. In the case of FIG. 6, SoC1 can access accelerator 3 and accelerator 4 in odd-numbered time slots (1-3). At this time, SoC2 cannot access accelerator 3 and accelerator 4. SoC2 can access accelerator 3 and accelerator 4 in even-numbered time slots (2-4). At this time, SoC1 cannot access accelerator 3 and accelerator 4.

[0030] In FIG. 6, four time slots are shown, and these time slots return to time slot 1 when time slot 4 ends. The time synchronization unit 18 has a function of synchronizing the time between each SoC. That is, the time count is started with time 0 being the time when the vehicle control device 0 is started and time synchronization by the time synchronization unit 18 is completed, and the time is counted up to less than 10 ms, time slot 1 is 10 ms or more and less than 20 ms, time slot 3 is 20 ms or more and less than 30 ms, time slot 4 is 30 ms or more and less than 40 ms, and time slot 1 is 40 ms or more and less than 50 ms. In this way, each time while the vehicle control device 0 is started is uniquely assigned to one of the time slots. When the accelerator access unit 19 receives an access request to the accelerator 3 from the control application 15 in the SoC in which it is mounted, it checks the current time with the time synchronization unit 18 and determines the time slot of the time period corresponding to the current time (this time slot is called the "current time slot"). FIG. 6 shows a state where the current time slot is the second time slot, and indicates that SOC2 can access the accelerator 3, and that SOC1 cannot access it. The accelerator access unit 19 further refers to the available time slot information storage unit 20 to determine whether the accelerator 3 is available in the current time slot, and if it is available and the accelerator 3 is not being used by another control application of the SOC in which the accelerator access unit 19 is installed, transfers data to the accelerator 3. If the accelerator is being used by another application, the accelerator access unit 19 puts the data in a queue, and when the use of the other application ends, takes out the data from the queue and transfers it. In this way, the accelerator access unit 19 determines whether to transfer a use request to the accelerator 3 from the control application 15 based on information on whether the time slot in the time period corresponding to the current time can be accessed. In this embodiment, each SoC has a time synchronization unit 18, and the case where the time between each SoC is synchronized has been described. However, if the time is synchronized between the SoCs, the time synchronization unit 18 is not necessary.For example, this may involve initially booting each SoC simultaneously to synchronize the time of each SoC.

[0031] Fig. 7 is a diagram showing the latency from the control applications 15 of SoC1 and SoC2 to the start of access to the accelerator 3 in the case of Fig. 6. This latency will be described with reference to Fig. 7.

[0032] In Fig. 7, the time slots in which SoC1 can access accelerator 1 and the time slots in which SoC2 can access accelerator 1 are arranged from the left as time slot 1, time slot 2, and so on, and for each time slot, a circle indicates an accessible time slot and a cross indicates an inaccessible time slot. The lightning marks indicate the timing at which control application 15 is started by scheduler 12. As in Fig. 5, in this embodiment, control application 15 is executed at 50 ms intervals, so the lightning marks appear every 50 ms. In this embodiment, the time width of the time slot is 10 ms, so there are five time slots between the lightning marks.

[0033] As shown in FIG. 7, when the scheduler 12 activates the control applications 15 of SоC1 and SоC2 at a 50 ms cycle, the current time slot when the control application 15 is activated is either an odd-numbered time slot or an even-numbered time slot. At the time of the lightning-like mark on the left side of FIG. 7, the current time slot is an odd-numbered time slot, so SоC1 can use the accelerator, and SоC2 cannot. After 10 ms has elapsed, the current time slot becomes an even-numbered time slot, and SоC2 can use the accelerator. Therefore, the latency from when the control application 15 of SоC2 requests access to the accelerator until it becomes available is about 10 ms, which is one-ninth of the approximately 90 ms in FIG. 5. Also, at the time of the lightning-like mark on the right side of FIG. 7, the current time slot is an even-numbered time slot, so SоC1 cannot use the accelerator, and SоC2 can use it. Therefore, the control application 15 of SOC2 can use the accelerator immediately, with almost zero latency.

[0034] According to this embodiment, access to the accelerator from each SoC is time-shared in advance, so that even if each SoC directly accesses each accelerator, no access contention occurs between the SoCs, and this has the effect of enabling efficient sharing of the accelerator between the SoCs. EXAMPLES

[0035] A second embodiment of a vehicle control device according to the present invention will be described with reference to Figs. 8 and 9. The second embodiment is different from the first embodiment in that each control application 15 calls the accelerator access unit 19 without being aware of whether to use the accelerator 3 or the accelerator 4. Note that the same components as those in the first embodiment are denoted by the same reference numerals and their description will be omitted.

[0036] <Time-sharing access management> FIG. 8 is a diagram showing an outline of time slot allocation in this embodiment. In the case of FIG. 8, SoC1 can access accelerator 3 in time slot 1, accelerator 4 in time slot 2, and accelerator 3 and accelerator 4 in time slot 3. Also, SoC2 can access accelerator 4 in time slot 1, accelerator 3 in time slot 2, and accelerator 3 and accelerator 4 in time slot 4. When accelerator access unit 19 receives an access request from control application 15 in the SoC in which it is mounted, accelerator access unit 19 checks the current time with time synchronization unit 18 and determines the time slot corresponding to the current time (current time slot). Accelerator access unit 19 further refers to available time slot information storage unit 20 to identify an accelerator available in the current time slot, and if any of the identified accelerators is not being used by another application, transfers data to that accelerator. If all accelerators are being used by other applications, the data is put into a queue, and when the other applications finish using the data, the data is taken out of the queue and transferred.

[0037] FIG. 9 is a diagram showing the latency until the control applications 15 of the SoC1 and SoC2 start accessing the accelerators 3 and 4 in the case of FIG.

[0038] In FIG. 9, the control application 15 does not specify in advance which accelerator to access. Instead, the accelerator access unit 19 finds an accelerator available in the current time slot or the time slot closest to the current time slot, and transfers data to either the accelerator 3 or the accelerator 4 found. This eliminates the need for the control application 15 to consider the time division of the accelerator. In the case of this embodiment, the activation period of the control application 15 is 50 ms, and the period of the time division of the accelerator (i.e., the number of time slots in the table stored in the available time slot information storage unit 20 * 10 ms) is 40 ms, so the time slot in which the control application 15 is activated is not fixed. Therefore, as shown in FIG. 9, sometimes the control application 15 is activated in the first time slot, and sometimes the control application 15 is activated in the second time slot, etc. In such a case, if the control application 15 side decides which accelerator to use, it is necessary to distinguish between cases for each time slot to be activated, which makes scheduling complicated. Therefore, the accelerator selection is left to the accelerator access unit 19. As described above, accelerator access unit 19 searches for an accelerator that is available in the current time slot or the time slot closest to the current time slot, and transfers data to that accelerator. Therefore, in the case of the timing of the lightning-like mark on the left side of Fig. 9, i.e., when control application 15 of SoC2 starts up in time slot 1, data is transferred to accelerator 4, and in the case of the timing of the lightning-like mark on the right side of Fig. 9, i.e., when control application 15 of SoC2 starts up in time slot 2, data is transferred to accelerator 3.

[0039] According to this embodiment, it is possible to dynamically change the selection of the accelerator so as to minimize the latency while avoiding the complicated scheduling that occurs when the accelerator time division period and the control application startup period are not an integer multiple. EXAMPLES

[0040] A third embodiment of a vehicle control device according to the present invention will be described with reference to Figures 10 to 12. The third embodiment differs from the second embodiment in that the information stored in the available time slot information storage unit 20 is updated. Note that the same components as those in the first or second embodiment are denoted by the same reference numerals and their description will be omitted.

[0041] <Time-sharing access management> Fig. 10 is a diagram showing an overview of a vehicle control device in this embodiment. In Fig. 10, SoC1 and SoC2 have an inter-SoC communication unit 16 and a time slot information update unit 21. The time slot information update unit 21 has a function of updating the time slot information stored in the time slot information storage unit.

[0042] The information stored in the available time slot information storage unit 20 of SoC1 and SoC2 indicates that neither SoC accesses any accelerator in the third time slot and the fourth time slot, that is, access is not possible. Hereinafter, such a time slot is called a spare time slot. The spare time slot is a time slot in which access to at least one specific accelerator among the accelerators is not possible for any SoC. The spare time slot is a time slot that is kept free as a spare, and can be assigned to SoC1 and SoC2 as necessary. The time slot information update unit 21 has a function of updating the information stored in the available time slot information storage unit 20. In this embodiment, SoC2 newly has an additional control application 22. The additional control application 22 is a control application that was not previously installed and was added with the update of the vehicle control. The additional control application 22 uses the accelerator like the control application 15. Therefore, the addition of the additional control application 22 increases the frequency with which SoC2 uses the accelerator. Therefore, time slot information update unit 21 can update time slot 3, which is a spare time slot, so that SoC2 can use accelerator 3. At this time, if the information stored in available time slot information storage unit 20 of SoC2 is updated and the information is not transmitted to SoC1, additional control application 22 may be mounted on SoC1 later and time slot information update unit 21 of SoC1 may update time slot 3 to make accelerator 3 accessible, resulting in overlapping and failure of time-division access. In other words, when updating the information stored in available time slot information storage unit 20, this problem can be addressed by transmitting an instruction to update the information to time slot information update unit 21 mounted on each SoC.

[0043] FIG. 11 is a diagram showing spare time slot used information 211 managed internally by time slot information update unit 21. In FIG. 11, when time slot information update unit 21 receives information on the use of a spare time slot from time slot information update unit 21 of another SoC via inter-SoC communication unit 16, it records the time slot in spare time slot used information 211 as an inaccessible time slot. In this embodiment, SoC2 enables SoC2 to access accelerator 3 in time slot 3, which is a spare time slot, for additional control application 22. Therefore, the using SoC is recorded as SoC2, the time slot number is recorded as 3, and the accelerator is recorded as accelerator 3 in spare time slot used information 211 of time slot information update unit 21 of SoC1. By referring to this information, SoC1 can prevent future use of a spare time slot already in use by SoC2. Note that spare time slot used information 211 is not an essential component in this embodiment. Even if the spare time slot used information 211 is not present, if there is no overlapping use of accelerators between each SoC, the effects of this embodiment can be achieved as long as the other necessary components are present, even if the spare time slot used information 211 is not present.

[0044] FIG. 12 is a diagram illustrating the flow of processing performed between SoC2 and SoC1 when SoC2 updates a timeslot in this embodiment.

[0045] In step S1, SoC2 determines a new time slot and accelerator to be used. Hereinafter, this is referred to as a desired time slot. The desired time slot can be determined by referring to the information stored in available time slot information storage unit 20 and used spare time slot information 211. In this embodiment, by referring to available time slot information storage unit 20, it is found that time slot 3 and time slot 4 are free time slots, and since no information is stored in used spare time slot information 211, it is found that time slot 3 and time slot 4 are not used by other SoCs. Therefore, SoC2 desires to use accelerator 3 in time slot 3. At this point, SoC2 cannot yet access accelerator 3 in time slot 3. In step S2, the information of the desired time slot determined in step S1 is transmitted to all other SoCs (SoC1 in this embodiment) by using inter-SoC communication unit 16 to notify them. This is a request by the time slot information update unit 21 of one SoC, SoC2, to update one spare time slot of SoC2 to a time slot that allows SoC2 to access the accelerator 3, to the time slot information update unit 21 belonging to another SoC. When SoC1 receives the information of the time slot desired to be used, the process proceeds to step S3. In step S3, SoC1 writes data to the spare time slot used information 211 of the time slot information update unit 21 mounted on SoC1 as shown in FIG. 11. When this writing is completed, the process proceeds to step S4, and notifies SoC2 that the request for use has been accepted, using inter-SoC communication. When SoC2 proceeds to step S5, and receives an acceptance notification from all other SoCs (only SoC1 in this embodiment), the process updates the information stored in the available time slot information storage unit 20, and updates the access to the accelerator 3 in the third time slot from unavailable (x) to available (o). From this point on, SoC2 is able to access the accelerator 3 in the third time slot.

[0046] When an additional control application 22 is added to the aforementioned SoC2, the process of updating the spare time slot to make it usable, i.e., accessible, may be performed by notifying a time slot information update unit belonging to another SoC when the computational load of the accelerator 3 accessed by the SoC2 exceeds or has exceeded a predetermined load.

[0047] According to this embodiment, when the processing load of each SoC fluctuates due to an update of a control application or the like and the frequency with which each SoC uses the accelerator changes, the time division between the SoCs is maintained while dynamically changing the time division to allocate more time slots to the SoC that has increased the frequency with which it accesses the accelerator, thereby achieving the effect of enabling the accelerator to be used efficiently even after the processing load fluctuates. EXAMPLES

[0048] A fourth embodiment of the vehicle control device according to the present invention will be described. The fourth embodiment is different from the third embodiment in that an accelerator temperature measurement unit is provided instead of the additional control application. Note that the same components as those in the third embodiment are denoted by the same reference numerals and will not be described.

[0049] <Dynamic allocation change for heat dissipation> 13 is a diagram showing an outline of the invention in the fourth embodiment. The fourth embodiment will be described with reference to FIG.

[0050] SoC1 and SoC2 each have a temperature measurement unit 23. Each temperature measurement unit 23 measures the temperature of accelerator 3 and accelerator 4, and when the temperature of an accelerator exceeds a certain threshold, notifies the time slot information update unit 21 of information on the accelerator that has exceeded the threshold. The time slot information update unit 21 stops using an accelerator whose temperature has exceeded a preset threshold, and transfers the time slot that had been accessing the accelerator to another accelerator. This other accelerator to be transferred can be an accelerator whose temperature does not exceed the preset threshold. For example, in the case of FIG. 13, when the temperature of accelerator 3 exceeds the preset threshold, the time slot information update unit 21 transfers the time slot that had been using accelerator 3 to accelerator 4. When it is SoC1 that changes the time slot, the time slot that SoC1 used accelerator 3 in is the first time slot. Therefore, the time slot information update unit 21 of SoC1 changes this time slot to unusable, i.e., inaccessible (x), and requests the use of accelerator 4 in time slot 3, which is a spare time slot. The change of time slot 1 and time slot 3 may be updated in the same procedure as shown in the third embodiment. That is, the time slot information update unit 21 of SoC1 notifies the time slot information update unit 21 belonging to another SoC of a request to update time slot 3, which is a spare time slot of SoC1, to a time slot in which the control application 15 of SoC1 can access the accelerator 4, and this can be processed. Similarly, in the case of SoC2, the accelerator 3 used by SoC2 is time slot 2. Therefore, the time slot information update unit 21 changes this time slot to unusable, i.e., inaccessible (x), and requests the use of accelerator 4 in time slot 4, which is a spare time slot. The change of time slot 2 and time slot 4 may be updated in the same procedure as shown in the third embodiment.That is, this can be processed by the time slot information update unit 21 of SoC2 notifying the time slot information update unit 21 belonging to another SoC of a request to update the fourth time slot, which is a spare time slot of SoC2, to a time slot in which the control application 15 of SoC2 can access the accelerator 4. Here, in order to deal with the case where the accelerator becomes unusable due to a failure or the like, a failure detection unit may be provided instead of the temperature measurement unit 23.

[0051] According to this embodiment, if one of the accelerators becomes unusable due to overheating, failure, or the like, the time-division access is changed to use another available accelerator, thereby improving the availability of vehicle control. EXAMPLES

[0052] A fifth embodiment of the vehicle control device according to the present invention, that is, a fifth embodiment, will be described with reference to Fig. 14. The fifth embodiment differs from the third embodiment in that, instead of accepting a time slot allocation update between each SoC, updated available time slot information is directly received from an external source, such as a server, and updated. Note that the same reference numerals are used for the same configuration as in the third embodiment, and the description thereof will be omitted.

[0053] <Vehicle control device 0> Fig. 14 is a diagram showing an overview of the fifth embodiment. In Fig. 14, the vehicle control device 0 includes a vehicle 24 and a server 25. The vehicle 24 includes an SoC1, an SoC2, an accelerator 3, an accelerator 4, and a communication bus 5. The server 25 transmits updated available time slot information to the time slot information update unit 21 of each SoC.

[0054] <Server 25> The server 25 transmits to each SoC information on available time slots that are allocated so as not to overlap with each other. Here, each SoC may communicate with the server 25 directly, or may communicate with the server 25 via a gateway for external communication installed in the vehicle.

[0055] <Time slot information update unit 21> In this embodiment, time slot information update unit 21 stores the available time slot information received from the server as is in available time slot information storage unit 20. Since time slot allocation is determined so as not to overlap in server 25, the procedure shown in Fig. 12 of inquiring and accepting a use request using inter-SoC communication is not necessary.

[0056] According to this embodiment, there is an effect that it is possible to update available time slot information without requiring communication between SoCs. In this embodiment, an example is shown in which the updated available time slot information is received from a server and updated. However, this is not limited to a server, and it is sufficient if it is something that updates the time slot information stored in the time slot information storage unit based on information on whether or not a time slot can be accessed, which is received from outside the vehicle in which the vehicle control device is installed. For example, a mobile terminal or the like may be used instead of the server described above. EXAMPLES

[0057] 15 is a diagram showing an overview of a sixth embodiment of a vehicle control device according to the present invention, which is a sixth embodiment of the present invention. The sixth embodiment will be described with reference to FIG.

[0058] The sixth embodiment differs from the first embodiment in that the access unit considers the priority between the control applications. The same components in the sixth embodiment as those in the first embodiment are denoted by the same reference numerals and the description thereof is omitted. In FIG. 15, the components of the SoC 2 other than the time synchronization unit 18 are omitted from the illustration.

[0059] <Time-sharing access management> The accelerator access units 19 of SoC1 and SoC2 each have a queue 191, a priority order storage unit 192, and a call unit 193. The control application 15 is made up of a high priority control application 151 whose priority is set high by the priority order storage unit 192, and a low priority control application 152 whose priority is set low. That is, for a plurality of applications, priorities are set for requests to access the accelerator, i.e., requests to use the accelerator. When the accelerator access unit 19 receives a request to access the accelerator from the high priority control application 151 or the low priority control application 152 during the time period when the current time corresponds to the fourth time slot, it stores the request in the queue 191. When the current time reaches the first time slot, call unit 193 checks queue 191 and priority order storage unit 192, and if access requests have been received from both high priority control application 151 and low priority control application 152, it processes the access request from high priority control application 151 first, and processes the access request from low priority control application 152 after accelerator 3 has completed processing the access request from high priority control application 151. This means that when an access request to an accelerator is received from an application in a time slot in which the accelerator is not accessible, the accelerator access unit may output the received use requests to the first accelerator in descending order of priority at the timing of switching from the time slot in which the accelerator is not accessible to the time slot in which the accelerator is accessible.

[0060] When an access request is received from only one of the high priority control application 151 and the low priority control application 152, that access request is processed. The example described here is related to the case where there are two priorities, high and low, but there may be two or more priorities. Similarly, when there are two or more priorities for a control application, the application with the highest priority is processed preferentially according to the priority. The processing of an access request from a control application 15 such as the high priority control application 151 and the low priority control application 152 may be such that the corresponding accelerator access unit determines whether or not to output an access request, i.e., a usage request, to the accelerator to be accessed, i.e., to be used.

[0061] According to this embodiment, when a plurality of control applications are to use an accelerator, it is possible to provide an effect of making it possible to use the accelerator so as to shorten the latency of a control application with a high priority. EXAMPLES

[0062] A seventh embodiment of the vehicle control device according to the present invention, that is, a seventh embodiment of the vehicle control device, will be described with reference to Fig. 15. The seventh embodiment differs from the sixth embodiment in that when a high priority control application issues an access request to the accelerator, the use of the accelerator by a low priority control application is stopped. Note that the same components in the seventh embodiment as those in the sixth embodiment are denoted by the same reference numerals and description thereof will be omitted.

[0063] <Time-sharing access management> Consider the same case as in FIG. 15. Assume that the accelerator access unit 19 of SoC1 receives an access request to the accelerator from the low priority control application 152 during the time slot corresponding to the current time of the fourth time slot, but has not received an access request from the high priority control application 151. When the current time of the first time slot is reached, the call unit 193 takes out the access request from the low priority control application 152 from the queue 191 and starts using the accelerator 3. Immediately after that, the accelerator access unit 19 of SoC1 receives an access request from the high priority control application 151. At this time, the call unit 193 of the accelerator access unit 19 of SoC1 uses the accelerator driver 13 to instruct the accelerator 3 to stop processing, and transfers the access request from the high priority control application 151 to the accelerator 3. The access request from the low priority control application 152 is temporarily canceled and stored in the queue 191 again. After the high priority control application 151 finishes using the accelerator 3, an access request from the low priority control application 152 is processed. Here, the instruction to the accelerator 3 to stop the processing may be output to the accelerator 3 as a processing interruption instruction.

[0064] According to this embodiment, it is possible to eliminate the priority inversion caused by the occupation of the accelerator by a control application with a low priority, and it is possible for a control application with a high priority to use the accelerator with low latency. EXAMPLES

[0065] An eighth embodiment of the vehicle control device according to the present invention, that is, an eighth embodiment, will be described with reference to Fig. 16. The eighth embodiment differs from the first embodiment in that the accelerator driver is not called at the beginning of the available time slot. Note that the same reference numerals are used to designate the same components in the eighth embodiment as those in the first embodiment, and the description thereof will be omitted.

[0066] <New access prohibited area> Fig. 16 is a diagram explaining the necessity of a new access prohibition section at the beginning of an accessible time slot. In Fig. 16, there are two graphs, one above the other, showing the time and the accessibility to the accelerator. The upper graph is for the second accelerator of SoC1, and the lower graph is for the second accelerator of SoC2.

[0067] In general, since different SoCs have different clock sources, it is difficult to always perform precise time synchronization between multiple SoCs. That is, there is a certain range of error in the time between multiple SoCs. In this embodiment, the maximum value of this error is 3 ms. As shown in FIG. 16, it is assumed that the time of SoC2 is 3 ms behind the time of SoC1. In this case, the time of 10 ms in SoC2 is 13 ms in SoC1. Here, when SoC1 starts accessing the accelerator 4 from its own time of 10 ms, the time of 7 ms in SoC2 means that SoC2 may still be using the accelerator 4, and access contention may occur. Therefore, when switching from an access-prohibited time slot to an accessible time slot, access to the accelerator, i.e., a use request is not made for the first 3 ms. The above explanation has been given for the case where the time of SoC2 is behind the time of SoC1, but the same applies when the time of SoC1 is behind the time of SoC2, i.e., when the time of SoC2 is ahead of the time of SoC1. 16 shows an example in which an access prohibition time period is set in time slot 4 of SoC2 according to the rule that when switching from an access prohibition time slot to an accessible time slot, no access to the accelerator is made for a period of time equivalent to the time error at the beginning of the accessible time slot. This access prohibition time period set in time slot 4 of SoC2 is effective when the time on SoC2 is ahead of the time on SoC1.

[0068] According to this embodiment, when an error exists in the time synchronization between SoCs, an effect of preventing contention for access to the accelerator is achieved. EXAMPLES

[0069] A ninth embodiment of the vehicle control device according to the present invention, that is, a ninth embodiment, will be described with reference to Fig. 17. The ninth embodiment differs from the eighth embodiment in that the accelerator driver is not accessed at the end of the available time slot. The same components in the ninth embodiment as those in the eighth embodiment are denoted by the same reference numerals and the description thereof will be omitted.

[0070] <New access prohibited area> Fig. 17 is a diagram explaining the necessity of a new access prohibition section at the end of an accessible timeslot. In Fig. 17, there are two graphs, one above the other, showing the time and the accessibility to the accelerators. The upper graph is for the second accelerator of SoC1, and the lower graph is for the second accelerator of SoC2.

[0071] In this embodiment, the control application uses the accelerator for a maximum of 5 ms. As shown in FIG. 17, when the control application 15 of SoC1 starts using the accelerator 4 at time 27 ms, the use may end at time 32 ms. This may cause an access contention because it becomes an accessible time slot of SoC2 as shown in FIG. 17. Therefore, when switching from an accessible time slot to an inaccessible time slot, new access to the accelerator is not performed for 5 ms going back from the end of the accessible time slot. This time during which new access to the accelerator is not performed can be called an access prohibition time. That is, the accelerator access unit can be configured not to start outputting the use request during the access prohibition time going back from the end of the accessible time slot in the case of switching from an accessible time slot to an inaccessible time slot in the access permission information of the time slot. The access prohibition time corresponds to the length of time the application uses the accelerator, and can be, for example, the maximum time during which the application is expected to use the accelerator. This access prohibition time may be set to the time slot in the access permission information of the time slot. Moreover, this process of not making new access to the accelerator is the same for any accelerator in any SoC.

[0072] According to this embodiment, it is possible to prevent each control application from using the accelerator in excess of the available time slots.

[0073] The present invention is not limited to the above-described embodiments, and includes various modified examples and equivalent configurations within the spirit of the appended claims. For example, the above-described embodiments have been described in detail to clearly explain the present invention, and the present invention is not necessarily limited to having all of the configurations described. Furthermore, a part of the configuration of one embodiment may be replaced with a configuration of another embodiment. Furthermore, a configuration of another embodiment may be added to a configuration of one embodiment. Furthermore, a part of the configuration of each embodiment may be added, deleted, or replaced with another configuration.

[0074] In addition, each of the above-mentioned configurations, functions, processing units, processing means, etc. may be realized in hardware, for example by designing some or all of them as an integrated circuit, or may be realized in software by a processor interpreting and executing a program that realizes each function.

[0075] Information such as programs, tables, and files that realize each function can be stored in a storage device such as a memory, a hard disk, or an SSD (Solid State Drive), or in a recording medium such as an IC card, an SD card, or a DVD.

[0076] In addition, the control lines and information lines shown are those considered necessary for the explanation, and do not necessarily show all the control lines and information lines necessary for implementation. In reality, it can be considered that almost all components are connected to each other. [Explanation of symbols]

[0077] 0 Vehicle control device 1. The First SoC 2. Second SoC 3. The First Accelerator 4. The second accelerator 5. Communication Bus 6 processors 7. Memory 8 External communication ports 9 Registers 10 DMAC 11 Specific processing calculation unit 12 Scheduler 13 Driver for the first accelerator 14 Driver for the second accelerator 15 Control App 16 Inter-SoC communication section 17 Access Management Department 18 Time Synchronization Unit 19 Access Section 20 Available time slot information storage section 21 Update section 22 Additional Control Apps 23 Temperature measurement section 24 vehicles 25 Server 29 Internal Bus 61 CPU cores 62 Cache Memory 151 High Priority Control App 152 Low priority control application 191 Queue 192 Priority storage section 193 Cole Department 211 Spare time slot used information

Claims

1. A vehicle control device including a plurality of semiconductor chips each having one or more applications, and one or more accelerators connected to the plurality of semiconductor chips, Each of the plurality of semiconductor chips includes an accelerator access unit that controls access to the accelerator; a time slot information storage unit that stores time slot information indicating whether or not the application can access the accelerator in each time slot, the application is capable of outputting a use request to the accelerator via the accelerator access unit, A vehicle control device characterized in that the accelerator access unit determines whether or not to transfer the use request from the application to the accelerator based on the access availability information for the time slot corresponding to the current time.

2. The vehicle control device according to claim 1, The vehicle control device according to claim 1, wherein the plurality of semiconductor chips further include a time slot information update unit that updates the time slot information stored in the time slot information storage unit.

3. The vehicle control device according to claim 2, the time slot information includes a spare time slot during which none of the semiconductor chips can access the accelerator; The time slot information update unit Transmitting a request to update the spare time slot to a time slot that allows access to the accelerator from the semiconductor chip to which the time slot information update unit belongs, to a time slot information update unit of another semiconductor chip; When permission for the update is received from all other time slot information update units, update the spare time slot to an accessible time slot; A vehicle control device comprising: a vehicle control unit that, when receiving a request to update the spare time slot to a time slot that allows access to the accelerator, updates the requested spare time slot to an inaccessible time slot.

4. A vehicle control device according to claim 3, The vehicle control device is characterized in that, when the computational load of the accelerator accessed by the semiconductor chip to which the time slot information update unit belongs exceeds a predetermined threshold, the time slot information update unit sends a request to a time slot information update unit belonging to another semiconductor chip to update one of the time slots to a time slot that allows access to the accelerator.

5. A vehicle control device according to claim 3, a time slot information update unit that updates at least one of the spare time slots to a time slot that enables the semiconductor chip to which the time slot information update unit belongs to access another of the accelerators when the temperature of the accelerator being accessed by the semiconductor chip to which the time slot information update unit belongs exceeds a predetermined threshold.

6. The vehicle control device according to claim 2, A vehicle control device characterized in that the time slot information update unit updates the time slot information stored in the time slot information storage unit based on time slot information received from outside the vehicle in which the vehicle control device is installed.

7. The vehicle control device according to claim 1, A priority for the usage request is set for the application; The vehicle control device according to claim 1, wherein the accelerator access unit, when receiving the use request from the application, determines whether to output the use request to the accelerator in accordance with the priority.

8. The vehicle control device according to claim 7, a first accelerator access unit that, after transferring a first use request to a first accelerator, receives a second use request having a higher priority than the first use request, and outputs to the first accelerator an instruction to interrupt processing due to the first use request.

9. The vehicle control device according to claim 7, a vehicle control device characterized in that, when the accelerator access unit receives a use request for the first accelerator from the application during a time slot in which access to the first accelerator is not possible, the accelerator access unit outputs the received use request to the first accelerator in order of highest priority.

10. The vehicle control device according to claim 1, the plurality of semiconductor chips each have a time synchronization unit that synchronizes time between the semiconductor chips; the time slots in the time slot information are set based on the synchronized time, an access prohibition time corresponding to an allowable time error in time synchronization between the semiconductor chips is set in the time slot; The vehicle control device according to claim 1, wherein the accelerator access unit does not start outputting the use request during the access prohibition time.

11. The vehicle control device according to claim 1, an access prohibition time is set in the time slot according to a length of time for which the application uses the accelerator; The vehicle control device according to claim 1, wherein the accelerator access unit does not start outputting the use request during the access prohibition time.

Images