Time synchronization method and device based on heterogeneous multi-core system and system on chip

Abstract

The invention provides a time synchronization method and device based on a heterogeneous multi-core system and a system on chip, the heterogeneous multi-core system comprises a first kernel serving as a master node and a second kernel serving as a slave node, the method is executed by the second kernel, and the method comprises the following steps: determining a local hardware timestamp when an event to be synchronized occurs; obtaining a synchronization time parameter through bidirectional message interaction based on a hardware timestamp between the first kernel and the second kernel; and converting the local hardware timestamp into a corresponding global timestamp based on the synchronization time parameter. A two-way measurement mechanism of a precision time protocol (PTP) is transplanted to inter-core communication in a chip, and hardware-level timestamp capture is combined, so that software jitter and communication delay uncertainty are systematically eliminated, and therefore, sub-microsecond synchronization precision which can only be achieved by depending on external hardware connection in the past is realized on the pure software level, and the precision of the chip is improved. And meanwhile, the hardware cost and the integration complexity are obviously reduced.

Description

Technical Field

[0001] This disclosure relates to the fields of chip and automotive electronics technology, and in particular to a sub-microsecond high-precision time synchronization method, device and system-on-chip based on heterogeneous multi-core system-on-chip (SoC) suitable for scenarios such as intelligent driving domain controllers. Background Technology

[0002] With the rapid development of intelligent connected vehicle technology, automotive electronic and electrical architecture is evolving from traditional distributed architecture to domain-centralized and centrally computed architecture. The intelligent driving domain controller, as the core computing unit, typically adopts a heterogeneous multi-core system-on-a-chip architecture. This architecture usually includes two types of processing cores: one is a high-performance computing core, which typically runs complex operating systems such as Linux or QNX, used for perception fusion and path planning of high-bandwidth data from LiDAR, cameras, etc.; the other is a real-time control core, which typically runs an AUTOSAR CP or RTOS real-time operating system, used for vehicle chassis control, millimeter-wave radar data acquisition, and functional safety monitoring.

[0003] In autonomous driving systems, multi-sensor fusion is crucial for perceiving the environment. Because different sensors have different data acquisition frequencies and transmission paths, the system must ensure that all sensor data is based on the same high-precision global time reference. Therefore, achieving high-precision time synchronization between different cores within a heterogeneous SoC becomes the technological foundation for ensuring the accuracy and safety of autonomous driving decisions.

[0004] 1. Existing technical solution 1 (periodic update method based on shared memory)

[0005] A commonly used soft synchronization solution in the industry is periodic calibration based on shared memory. In this solution, a high-performance core running Linux operates the IEEE 802.1AS protocol stack via an Ethernet interface, acting as the master clock node to obtain the external global time. The Linux kernel sets up a periodic task to call system functions to obtain the current system time and write this time value to the shared memory area inside the SoC. The real-time core running the AUTOSAR system reads the time value in this shared memory through polling or interrupts and uses it to overwrite or update the local system time.

[0006] Existing limitations: While this method is simple to implement, it suffers from severe accuracy deficiencies and cannot meet the microsecond-level synchronization requirements of Level 3 and above autonomous driving. (1) Uncertain synchronization path delay: From the Linux kernel reading the time and writing it to memory, to the AUTOSAR kernel reading memory and updating the local clock, multiple stages such as operating system scheduling, bus arbitration, and memory read and write are involved. The time consumption of these stages is dynamic, resulting in an unpredictable time difference between the "write time" and the "effective time".

[0007] (2) Large software jitter: When the Linux kernel is under high load, the scheduling of synchronization tasks may be blocked or delayed; similarly, if the AUTOSAR kernel is processing a high-priority interrupt, the operation of reading shared memory will also be delayed. This software-level jitter is usually on the order of hundreds of microseconds or even milliseconds, resulting in extremely large synchronization errors.

[0008] (3) Lack of frequency compensation: This method usually only makes a one-time "hard adjustment" to the time point, without taking into account the frequency drift of the hardware crystal oscillators used by the two cores. During the interval between the two synchronization cycles, the local clock will deviate rapidly from the real time.

[0009] 2. Existing technical solution two (triggering method based on external hardware signals)

[0010] Another common approach is to introduce an external hardware signal for synchronization, often referred to as PPS hardwired synchronization. This approach utilizes an external high-precision time synchronization module to generate a physical pulse signal. The pin of this signal is connected to both the Linux core GPIO pin of the SoC and the capture pin of the AUTOSAR core. When the pulse arrives, both cores simultaneously trigger interrupts, recording their respective local timestamps, and then calculating the difference between them for alignment.

[0011] Existing limitations: Although this method has high accuracy, it has the following limitations in actual mass production implementation: (1) High hardware cost: Additional wiring is required on the PCB board, and even a dedicated FPGA or CPLD chip is required to distribute the synchronization signal, which increases the bill of materials cost.

[0012] (2) Pin resource occupation: The pin resources of SoC chips are usually very tight, and it is difficult to allocate pins for time synchronization in many highly integrated designs.

[0013] (3) Internal signals are not reachable: As the integration of SoC becomes higher and higher, many heterogeneous cores are packaged inside the chip and there are no independent external pins that can directly trigger the interrupts of all cores, which makes this solution impossible to implement on some new chips.

[0014] In summary, existing technologies present the following contradictions: while software solutions based on shared memory are low-cost and easy to implement, their synchronization accuracy cannot meet the requirements of high-level autonomous driving; and while solutions based on external hardware signals offer higher accuracy, they are costly, difficult to integrate, and their applicability is limited as SoC integration density increases. Therefore, there is an urgent need for a technical solution that can achieve high-precision time synchronization within heterogeneous multi-core SoCs, while simultaneously balancing implementation cost and integration convenience. Summary of the Invention

[0015] This disclosure provides a sub-microsecond time synchronization method, apparatus, and system-on-a-chip based on a heterogeneous multi-core system.

[0016] This disclosure provides a time synchronization method based on a heterogeneous multi-core system. The heterogeneous multi-core system includes a first kernel as a master node and a second kernel as a slave node. The method is executed by the second kernel and includes: determining a local hardware timestamp when the event to be synchronized occurs, the local hardware timestamp having sub-microsecond raw time precision; obtaining synchronization time parameters through bidirectional message interaction between the first kernel and the second kernel based on the hardware timestamp; and converting the local hardware timestamp into a corresponding global timestamp based on the synchronization time parameters, thereby achieving sub-microsecond time synchronization between the second kernel and the first kernel.

[0017] As in this embodiment of the invention, the synchronization time parameters include: basic time deviation, reference synchronization timestamp, and its corresponding reference base time; Synchronization time parameters are obtained through bidirectional message interaction between the first kernel and the second kernel based on hardware timestamps, including: recording a second local hardware timestamp of the moment when the first kernel sends a first synchronization message to it, and a first follow-up message of the first kernel sending the first synchronization message to it, wherein the first follow-up message carries the first local hardware timestamp of the moment when the first kernel sends the first synchronization message to it; recording a third local hardware timestamp of the moment when the first delay request message is sent to the first kernel, and a first delay response message of the first kernel responding to the first delay request message, wherein the first delay response message carries a fourth local hardware timestamp recorded by the first kernel when receiving the first delay request message; determining the inter-core path delay based on the first local hardware timestamp, the second local hardware timestamp, the third local hardware timestamp, and the fourth local hardware timestamp, and determining the base time deviation based on the inter-core path delay; using the local hardware timestamp of the moment when the first kernel sends a reference synchronization message as a reference base time, and using the local hardware timestamp of the moment when the first kernel receives the reference synchronization message as a reference synchronization timestamp.

[0018] As in this embodiment of the invention, the synchronization time parameter further includes: frequency ratio; The synchronization time parameters are obtained through bidirectional message interaction based on hardware timestamps between the first kernel and the second kernel. The method also includes: calculating the frequency ratio between the hardware clocks of the first kernel and the second kernel based on the local hardware timestamps of multiple sets of bidirectional message interactions between the first kernel and the second kernel.

[0019] As in this embodiment of the invention, the inter-core path delay is determined by combining the message transmission time from the first core to the second core and the message transmission time from the second core to the first core, and calculating the bidirectional average delay value used to offset the uncertainty of one-way transmission, which is then used as the inter-core path delay.

[0020] In this embodiment of the invention, the determination of the basic time deviation is achieved by deducting the inter-core path delay from the total message transmission time from the first core to the second core.

[0021] As in this embodiment of the invention, the step of converting the local hardware timestamp into a corresponding global timestamp based on the synchronization time parameter includes: establishing a time conversion relationship based on the reference base time and the reference synchronization timestamp; using the frequency ratio to perform frequency normalization correction on the time interval of the local hardware timestamp relative to the reference synchronization timestamp; combining the corrected time interval with the reference base time, and applying the basic time deviation for final alignment to generate the global timestamp.

[0022] As in this embodiment of the invention, the process of obtaining synchronization time parameters is achieved by applying the bidirectional message exchange and timestamp recording method defined in the Precision Time Protocol or the Generalized Precision Time Protocol, which is used to measure path delay between network devices, to the inter-core communication process between the first kernel and the second kernel.

[0023] In one embodiment of the present invention, the first kernel runs a first operating system and synchronizes with an external master clock via an Ethernet interface to obtain a global reference time; the second kernel runs a real-time operating system.

[0024] As in this embodiment of the invention, the first synchronization message, the first follow message, the first delay request message, and the first delay response message are transmitted through shared memory, hardware mailboxes, message queues, or remote processor message mechanisms within the heterogeneous multi-core system.

[0025] As in this embodiment of the invention, determining the local hardware timestamp when the event to be synchronized occurs includes: when sensor data controlled by the second kernel arrives and triggers a hardware interrupt, directly reading the local hardware counter value of the second kernel in the interrupt service routine, and determining the local hardware timestamp when the event to be synchronized occurs based on the local hardware counter value.

[0026] As in this embodiment of the invention, all local hardware timestamps are obtained by directly reading the underlying shared hardware counter of the heterogeneous multi-core system or the high-precision timer private to each kernel.

[0027] According to one aspect of the embodiments of this application, a time synchronization device is disclosed, the device comprising: The event capture module determines the local hardware timestamp when the event to be synchronized occurs; The parameter acquisition module is configured to acquire synchronization time parameters through bidirectional message interaction between the first kernel and the second kernel based on hardware timestamps. The timestamp conversion module is configured to convert the local hardware timestamp into a corresponding global timestamp based on the synchronization time parameter, thereby achieving sub-microsecond time synchronization between the second kernel and the first kernel.

[0028] As in this embodiment of the invention, the synchronization time parameters include: basic time deviation, reference synchronization timestamp, and its corresponding reference base time; The parameter acquisition module is configured to record a second local hardware timestamp of the time when the first kernel sends a first synchronization message to it, and a first follow-up message of the first kernel sending the first synchronization message to it, wherein the first follow-up message carries the first local hardware timestamp of the time when the first kernel sends the first synchronization message to it; record a third local hardware timestamp of the time when the first delay request message is sent to the first kernel, and a first delay response message of the first kernel responding to the first delay request message, wherein the first delay response message carries a fourth local hardware timestamp recorded by the first kernel when receiving the first delay request message; determine the inter-core path delay based on the first local hardware timestamp, the second local hardware timestamp, the third local hardware timestamp, and the fourth local hardware timestamp, and determine the base time deviation based on the inter-core path delay; use the local hardware timestamp of the time when the first kernel sends a reference synchronization message as a reference base time, and use the local hardware timestamp of the time when the first kernel receives the reference synchronization message as a reference synchronization timestamp.

[0029] As in this embodiment of the invention, the synchronization time parameter further includes: frequency ratio; The parameter acquisition module is configured to calculate the frequency ratio between the hardware clocks of the first kernel and the second kernel based on the local hardware timestamps of multiple sets of bidirectional message exchanges between the first kernel and the second kernel.

[0030] As in this embodiment of the invention, the parameter acquisition module is configured to combine the message transmission time from the first kernel to the second kernel and the message transmission time from the second kernel to the first kernel to calculate a bidirectional average delay value used to offset the uncertainty of one-way transmission, which is used as the inter-core path delay.

[0031] As in this embodiment of the invention, the parameter acquisition module is configured to deduct the inter-core path delay from the total transmission time of the message from the first kernel to the second kernel.

[0032] In this embodiment of the invention, the timestamp conversion module is configured to establish a time conversion relationship based on the reference base time and the reference synchronization timestamp; use the frequency ratio to perform frequency normalization correction on the time interval of the local hardware timestamp relative to the reference synchronization timestamp; combine the corrected time interval with the reference base time, and apply the basic time deviation for final alignment to generate the global timestamp.

[0033] As in this embodiment of the invention, the parameter acquisition module is configured to apply a bidirectional message exchange and timestamp recording method defined in the Precision Time Protocol or the Generalized Precision Time Protocol, which is used to measure path delay between network devices, to the inter-core communication process between the first kernel and the second kernel.

[0034] In one embodiment of the present invention, the first kernel runs a first operating system and synchronizes with an external master clock via an Ethernet interface to obtain a global reference time; the second kernel runs a real-time operating system.

[0035] As in this embodiment of the invention, the first synchronization message, the first follow message, the first delay request message, and the first delay response message are transmitted through shared memory, hardware mailboxes, message queues, or remote processor message mechanisms within the heterogeneous multi-core system.

[0036] In this embodiment of the invention, the event capture module is configured to directly read the local hardware counter value of the second kernel in the interrupt service routine when sensor data controlled by the second kernel arrives and triggers a hardware interrupt, and determine the local hardware timestamp when the event to be synchronized occurs based on the local hardware counter value.

[0037] As in this embodiment of the invention, all local hardware timestamps are obtained by directly reading the underlying shared hardware counter of the heterogeneous multi-core system or the high-precision timer private to each kernel.

[0038] According to one aspect of the embodiments of this application, a heterogeneous multi-core system-on-a-chip is disclosed, including: a first kernel as a master node configured to run a first operating system; and a second kernel as a slave node configured to run a real-time operating system and capable of executing any of the aforementioned methods.

[0039] According to one aspect of the embodiments of this application, a vehicle is disclosed, including the above-described heterogeneous multi-core system-on-a-chip.

[0040] According to one aspect of the embodiments of this application, an electronic device is disclosed, including: one or more processors; and a storage device for storing one or more programs, which, when executed by the one or more processors, cause the electronic device to implement the methods provided in the various optional implementations described above.

[0041] In this embodiment of the invention, a local hardware timestamp is determined when the event to be synchronized occurs; synchronization time parameters are obtained through bidirectional message interaction between the first kernel and the second kernel based on the hardware timestamp; based on the synchronization time parameters, the local hardware timestamp is converted into a corresponding global timestamp, thereby achieving sub-microsecond-level time synchronization between the second kernel and the first kernel. By porting the bidirectional measurement mechanism of the Precision Time Protocol (PTP) to the inter-core communication within the chip and combining it with hardware-level timestamp capture, software jitter and communication latency uncertainties are systematically eliminated, thereby achieving sub-microsecond-level synchronization accuracy at the pure software level, which previously relied on external hardware connections, while significantly reducing hardware costs and integration complexity.

[0042] In this embodiment of the invention, the core mechanism of the precision time protocol is creatively transplanted to the heterogeneous inter-core communication link. The hardware counter is used to directly read the event timestamp to ensure the original sub-microsecond accuracy. The uncertainty of inter-core communication delay is precisely eliminated through bidirectional message interaction and four-time measurement. Finally, a dynamic time conversion relationship is established to achieve continuous high-precision time synchronization.

[0043] Compared to traditional shared memory solutions, this invention improves synchronization accuracy from milliseconds to sub-microseconds, completely eliminating microsecond-level jitter caused by operating system scheduling. Compared to external hardware synchronization solutions, it achieves the same level of accuracy without increasing hardware costs or wiring complexity, and is perfectly compatible with highly integrated SoC architectures. This innovation provides a reliable sub-microsecond time reference for multi-sensor fusion in intelligent driving domain controllers, solving the core requirement of time consistency for heterogeneous computing units in L3 and above autonomous driving systems, and has significant technological advancement and industrial application value.

[0044] Other features and advantages of this application will become apparent from the following detailed description, or may be learned in part from practice of this application.

[0045] It should be understood that the above general description and the following detailed description are merely exemplary and do not limit this application. Attached Figure Description

[0046] The accompanying drawings, which are incorporated in and form part of this specification, illustrate embodiments consistent with this disclosure and, together with the description, serve to explain the principles of this disclosure. It is obvious that the drawings described below are merely some embodiments of this disclosure, and those skilled in the art can obtain other drawings based on these drawings without any inventive effort.

[0047] Figure 1 A flowchart of the time synchronization method based on heterogeneous multi-core systems provided in this application is shown.

[0048] Figure 2 A flowchart of the method for obtaining synchronization time parameters provided in this application is shown.

[0049] Figure 3 A block diagram of the time synchronization device provided in this application is shown.

[0050] Figure 4 A block diagram of the electronic device provided in this application is shown. Detailed Implementation

[0051] Exemplary embodiments will now be described more fully with reference to the accompanying drawings. However, these exemplary embodiments can be implemented in many forms and should not be construed as limited to the examples set forth herein; rather, they are provided so that this disclosure will be more comprehensive and complete, and will fully convey the concept of the exemplary embodiments to those skilled in the art. The described features, structures, or characteristics may be combined in any suitable manner in one or more embodiments.

[0052] Furthermore, the accompanying drawings are merely illustrative of this disclosure, and the same reference numerals in the drawings denote the same or similar parts, thus repeated descriptions of them will be omitted. Some block diagrams shown in the drawings are functional entities and do not necessarily correspond to physically or logically independent entities. These functional entities may be implemented in software, in one or more hardware modules or integrated circuits, or in different network and / or processor devices and / or microcontroller devices.

[0053] In this disclosure, at least one item can be described as one item or multiple items, and multiple items can be two, three, four, or more items, without limitation. The " / " sign can indicate that the related objects are in an "or" relationship; for example, A / B can represent A or B. "And / or" can be used to describe three relationships between related objects; for example, A and / or B can represent: A alone, A and B simultaneously, and B alone, where A and B can be singular or plural. For ease of description of the technical solutions of this disclosure, terms such as "first," "second," "A," or "B" can be used to distinguish technical features with the same or similar functions. These terms do not limit the quantity or execution order. Furthermore, the terms "first," "second," "A," or "B" are not necessarily different. The words “exemplary” or “for example” are used to indicate examples, illustrations, or explanations. Any design described as “exemplary” or “for example” should not be construed as being superior or more advantageous than other design options. The use of words such as “exemplary” or “for example” is intended to present the relevant concepts in a concrete manner to facilitate understanding.

[0054] The time synchronization method based on a heterogeneous multi-core system proposed in this invention will be described in detail below with reference to specific embodiments. The heterogeneous multi-core system includes a first core as the master node and a second core as the slave node. The execution entity of this method is the second core, which can be any processor core with computing capabilities. The specific implementation methods of this disclosure will be described in detail with reference to the accompanying drawings.

[0055] Figure 1 The flowchart illustrates the time synchronization method based on a heterogeneous multi-core system provided in this application. The execution entity of this method is a second kernel, such as... Figure 1 As shown, the method may include, but is not limited to, the following steps: Step S110: Determine the local hardware timestamp when the event to be synchronized occurs.

[0056] The implementation environment of this invention can be a typical intelligent driving domain controller, the core of which is a heterogeneous multi-core system-on-a-chip (SoC). This SoC includes at least: 1. First kernel (master node): It uses an ARM Cortex-A72 core and runs the Linux operating system (Kernel 5.10). This kernel integrates a Gigabit Ethernet controller (MAC) and runs the open-source Linux PTP protocol stack to support the IEEE 802.1AS (gPTP) protocol.

[0057] 2. Second kernel (slave node): Employs an ARM Cortex-R52 core and runs a real-time operating system compliant with the AUTOSAR ClassicPlatform (CP) R20-11 specification. This kernel is responsible for processing millimeter-wave radar data from the CAN bus and vehicle chassis control signals.

[0058] 3. Shared hardware resources: The SoC provides the following: Shared memory region: A 128KB on-chip SRAM is configured as a non-cacheable region accessible to both cores for inter-core data exchange.

[0059] System Counter: A free-running hardware counter with a frequency of 200MHz, driven by an internal PLL of the SoC. This counter is 64-bit wide, provides a unified physical time base, and its current value can be directly read by both cores through a memory-mapped register.

[0060] Inter-core interrupt controller: Supports sending software-triggered interrupts from the first core to the second core, and from the second core to the first core.

[0061] In this embodiment of the invention, the first kernel can be set to a Linux kernel, and the second kernel can be set to an AUTOSAR kernel. However, the invention is not limited to this; for example, the first kernel can also be set to an AUTOSAR kernel, and the second kernel to a Linux kernel. The first kernel can be set as the master node, and the second kernel can be set as the slave node. If the AUTOSAR kernel is connected to an Ethernet network and running the Generalized Precision Time Protocol (GPTP), the AUTOSAR kernel can also be configured as the master node, and the Linux kernel as the slave node.

[0062] It should also be noted that if the heterogeneous multi-core on-chip system includes a third core (such as System Manager), then both the first and second cores can be configured as slave nodes, with the third core acting as the master node for synchronization. The third core synchronizes with an external master clock via an Ethernet interface to obtain a global reference time. Subsequently, it performs bidirectional message exchanges based on hardware timestamps with the first and second cores respectively, obtaining their respective independent synchronization time parameters. This exchange process includes recording the local hardware timestamps of the sending and receiving times of the first synchronization message, the first follow message, the first delay request message, and the first delay response message, and based on these, determining the inter-core path delay, base time deviation, reference time, and corresponding parameters between the third and second cores. The first and second cores respectively use their obtained synchronization time parameters to convert their local hardware timestamps into corresponding global timestamps, thereby achieving sub-microsecond indirect time synchronization between the two based on the same master node.

[0063] In this embodiment of the invention, the first kernel runs a GPTP protocol stack through its integrated Ethernet interface to receive PTP (Precision Time Protocol) messages from the vehicle's master clock. The protocol stack calculates the offset between the first kernel's system time and the external UTC time. ext and the frequency ratio of its hardware clock to the external master clock (RateRatio) ext This process synchronizes the first kernel to a high-precision UTC time domain, making its system time a reliable global reference time. This lays the foundation for the absolute time reference for subsequent bidirectional message exchanges between the first and second kernels based on hardware timestamps to obtain synchronization time parameters.

[0064] The first core of the heterogeneous multi-core system-on-a-chip is configured with an Ethernet controller and its media access control layer. Within the first operating system (such as Linux) running on this first core, a generalized precision time protocol stack conforming to the IEEE 802.1AS standard is integrated and runs. The first core connects to the vehicle-mounted time-sensitive network via its Ethernet interface. On the network, a vehicle-level master clock (typically a high-precision GNSS timing module) serves as the time source, periodically sending precision time protocol messages. The first core's GPTP protocol stack receives and processes PTP messages from the vehicle-level master clock. Through message interaction, the protocol stack accurately calculates the instantaneous time deviation (denoted as Offset) between the first core's current system time and an external UTC time reference. ext ), and the frequency ratio between the first core hardware clock and the external master clock (denoted as RateRatio). extThis frequency ratio represents how many units the first kernel's timeline actually increases by for every unit increase in the second kernel's local counter per unit time. If RateRatio ext A value > 1 indicates that the second kernel is running slowly; if RateRatio ext A value less than 1 indicates that the second core is moving faster. By introducing a frequency ratio (Ratio) for linear compensation, the accumulated error caused by the crystal oscillator frequency drift between the two heterogeneous cores can be effectively eliminated. Even when the interval between inter-core synchronization messages is large (e.g., 1 second), using this frequency ratio for prediction can still ensure that the stamping accuracy at any time during the synchronization interval remains at the sub-microsecond level.

[0065] Based on the calculated Offset ext and RateRatio ext The GPTP protocol stack continuously adjusts the system clock of the first kernel through the operating system or hardware mechanisms. After this process is completed, the system time of the first kernel has been synchronized to the high-precision UTC time domain, becoming a reliable and absolute time reference source within the entire on-chip system. At this point, the first kernel has completed the acquisition and synchronization of the external time base, providing an accurate global time source for subsequent inter-core synchronization.

[0066] Compared to existing technologies that rely on external PPS hardware connections, which require dedicated FPGA / GPS module pins connected to the GPIO of each core, increasing PCB routing complexity and BOM costs, this invention is entirely based on existing communication mechanisms within the SoC (such as Shared Memory), representing a purely software-level innovation. It achieves near-hardware interconnect synchronization without requiring any additional chips, pins, or wiring, significantly reducing mass production costs.

[0067] In this embodiment of the invention, when data from the vehicle-mounted sensor (e.g., millimeter-wave radar) reaches the second core via the CAN bus or LIN bus, a hardware interrupt is triggered. The second core then responds to the interrupt and immediately reads the current local hardware counter value in its interrupt service routine. Based on this local hardware counter value, it obtains the local hardware timestamp C at the time the event to be synchronized occurs. event The local hardware timestamp C is obtained by directly reading the local hardware counter at the hardware interrupt service routine entry point. eventThis achieves triple sub-microsecond precision assurance: First, it completely avoids the non-deterministic delay of tens to hundreds of microseconds that may be introduced by the operating system's task scheduling, raising the determinism of timestamp capture to the nanosecond-level hardware response level; second, it establishes a tight coupling between the physical occurrence time of sensor events and the counter reading time, ensuring that the original time material has sub-microsecond-level event representation accuracy; finally, based on the highest priority mechanism of hardware interrupts, it ensures the absolute determinism and stability of timestamp acquisition under high system load conditions, thus providing the entire synchronization system with a reliable and accurate sub-microsecond-level time source that is not affected by software interference.

[0068] In this embodiment of the invention, when the second kernel receives sensor data, it does not directly use the current system time, but instead reads the hardware counter in real time and dynamically calculates the UTC timestamp of the data, i.e., the local hardware timestamp C, by combining the Delay and Offset parameters calculated in the previous steps. event This enables precise alignment of source data.

[0069] Step S120: Obtain synchronization time parameters through bidirectional message interaction between the first kernel and the second kernel based on hardware timestamps.

[0070] In this embodiment of the invention, the synchronization time parameters may include: a base time offset, a reference synchronization timestamp, and its corresponding reference base time. When acquiring the synchronization time parameters, the first kernel sends a first synchronization message to the second kernel and sends a first follow-up message to the first synchronization message. The second kernel records a second local hardware timestamp t2 at the time of receiving the first synchronization message sent by the first kernel, and receives a first follow-up message carrying a first local hardware timestamp t1 at the time of sending the first synchronization message sent by the first kernel. The second kernel sends a first delay request to the first kernel, and the first kernel sends a first delay response message to the second kernel for the first delay request. The second kernel records a third local hardware timestamp t3 at the time of sending the first delay request message to the first kernel, and receives a first delay response message from the first kernel in response to the first delay request message. The first delay response message carries a fourth local hardware timestamp t4 recorded by the first kernel when receiving the first delay request message. Then, the inter-core path delay is determined based on the first local hardware timestamp t1, the second local hardware timestamp t2, the third local hardware timestamp t3, and the fourth local hardware timestamp t4. Based on inter-core path delay Determine the base time deviation The local hardware timestamp of the time when the first kernel sends the reference synchronization message is used as the reference base time T. baseThe local hardware timestamp of the time when the reference synchronization message sent by the first kernel is received is used as the reference synchronization timestamp t. ref It should be noted that, since the first kernel runs the gPTP master protocol stack, its periodic transmissions carry the reference base time T. base The message indicates that the second kernel is able to obtain the reference time T. base .

[0071] It should be noted that the reference synchronization message can also be the first synchronization message, in which case the reference synchronization timestamp is the second local hardware timestamp t2, and the reference base time T. base That is, the first local hardware timestamp t1, which is the time when the first kernel sends the first synchronization message, can be carried in the first follow-up message of the first synchronization message sent by the first kernel to the second kernel.

[0072] In this embodiment of the invention, the synchronization time parameter may further include the frequency ratio. When obtaining the frequency ratio, the frequency ratio between the hardware clocks of the first kernel and the second kernel can be calculated based on the local hardware timestamps of multiple sets of bidirectional message exchanges between the first kernel and the second kernel.

[0073] It should be noted that, in this embodiment of the invention, all local hardware timestamps can be obtained by reading the underlying shared hardware counter of the heterogeneous multi-core system or the high-precision timer private to each kernel.

[0074] Existing technologies typically read the operating system's system time. When the Linux kernel is under high load, the overhead of system calls increases; when the AUTOSAR kernel has high-priority tasks, the read operation is postponed. This invention employs a "hardware counter snapshot" technique. Timestamp acquisition is completed directly at the driver or hardware layer, without going through the operating system scheduling layer. Regardless of whether the Linux kernel is running deep learning algorithms or the AUTOSAR kernel is handling emergency braking, the value of the underlying hardware counter increases linearly and remains undisturbed, thus ensuring synchronization stability under extreme conditions.

[0075] It should also be noted that the first synchronization message, the first follow message, the first delay request message, and the first delay response message in the embodiments of the present invention are transmitted through the shared memory, hardware mailbox, message queue, or remote processor message mechanism within the heterogeneous multi-core system.

[0076] In this embodiment, "shared memory" is used as the IPC channel. Alternatively, RPMSG (Remote Processor Messaging), Mailbox, Spinlock, or a hardware FIFO queue proprietary to the SoC vendor can be used to transmit synchronization messages (Sync / Delay_Req, etc.). As long as bidirectional data interaction can be achieved and interrupt stamping is triggered, it is within the scope of protection of this patent.

[0077] It should be noted that the second kernel saves the synchronization time parameter after obtaining it. If it is necessary to convert the global timestamp based on the synchronization time parameter later, it can directly call the synchronization time parameter for calculation.

[0078] Step S130: Based on the synchronization time parameter, the local hardware timestamp C is... event Convert to the corresponding global timestamp T utc This enables sub-microsecond time synchronization between the second kernel and the first kernel.

[0079] The second kernel will use the local hardware timestamp C event Convert to global timestamp T utc The process is crucial for achieving sub-microsecond synchronization. The second kernel acquires the synchronization time parameters (including the base time offset) measured through bidirectional message interaction. base Reference time T base Reference synchronization timestamp t ref Then, a dynamic time mapping model is established: first, using the reference time T... base Synchronize with reference timestamp t ref Using the established time anchor as a reference, the local hardware timestamp C to be converted event Synchronize with reference timestamp t ref The difference is calculated to obtain the original time interval; then this original time interval is compared with the reference time T. base Superimpose and apply the base time offset. base After fine-tuning, a global timestamp T that is strictly aligned with the first kernel time domain is output. utc .

[0080] T utc =T base +(C event -t ref ) +Offset base

[0081] In the above formula, T utc Represents a global timestamp, C event Indicates the local hardware timestamp to be converted, Offsetbase T represents the base time deviation. base and t ref They appear in pairs, t ref This represents the reference synchronization timestamp, specifically the local hardware timestamp recorded by the second kernel at the moment of receiving the reference synchronization message sent by the first kernel. T base It is represented as the reference base time, which is the local hardware timestamp of the time when the first kernel sends the reference synchronization message.

[0082] The entire conversion process is based on hardware time parameter calculations, avoiding operating system scheduling intervention. This enables the second kernel to generate global time identifiers with sub-microsecond precision for any local event in real time, ultimately achieving continuous and stable sub-microsecond time synchronization between the two kernels.

[0083] When the synchronization time parameter also includes the frequency ratio, the reference time T is used first. base Synchronize with reference timestamp t ref Using the constructed time anchor as a reference, the local hardware timestamp C to be converted is... event Synchronize with reference timestamp t ref After obtaining the original time interval by subtraction, it is necessary to correct the original time interval based on the frequency ratio (Ratio), and then compare the corrected time interval with the reference time T. base Superimpose and apply the base time offset. base After fine-tuning, a global timestamp T that is strictly aligned with the first kernel time domain is output. utc .

[0084] T utc =T base +(C event -t ref )×Ratio +Offset base

[0085] In the above formula, T utc Represents a global timestamp, C event Indicates the local hardware timestamp to be converted, Offset base T represents the base time deviation. base and t ref They appear in pairs, t ref This represents the reference synchronization timestamp, specifically the local hardware timestamp recorded by the second kernel at the moment of receiving the reference synchronization message sent by the first kernel. T base It is represented as the reference base time, which is the local hardware timestamp of the moment when the first kernel sends the reference synchronization message. Ratio represents the frequency ratio.

[0086] The frequency ratio is a core parameter for correcting the frequency differences between heterogeneous multi-core processors. Because the master and slave cores use independent hardware clock sources, their actual frequencies have inherent deviations and drift with temperature, causing errors to accumulate rapidly even after synchronization due to their different clock speeds. The frequency ratio quantifies this rate difference by measuring the ratio of the growth of the hardware counters of the two cores within a continuous synchronization cycle. In the time conversion formula, it represents the local hardware timestamp interval (C) of the second core. event -t ref The time interval is scaled proportionally to match the UTC time base of the first core, thereby dynamically offsetting the accumulated error caused by frequency drift and ensuring that sub-microsecond accuracy can still be maintained within the synchronization interval.

[0087] The above embodiments of the present invention achieve high-precision time synchronization between heterogeneous multi-core systems: First, the slave node directly reads the hardware counter when the event to be synchronized (such as a sensor interrupt) occurs to obtain the local hardware timestamp, thus obtaining a jitter-free time reference point from the lowest-level hardware; second, through bidirectional message interaction with the master node (first core) based on the hardware timestamp, the synchronization time parameters are accurately measured, effectively eliminating the uncertain delays caused by operating system scheduling and interrupt response; finally, these synchronization time parameters are used to convert the slave node's local hardware timestamp into a global timestamp in real time and accurately. The core technical effect of this method is that by porting the bidirectional measurement mechanism of the Precision Time Protocol (PTP) to the inter-core communication inside the chip and combining it with hardware-level timestamp capture, software jitter and communication delay uncertainties are systematically eliminated, thereby achieving sub-microsecond-level synchronization accuracy at the pure software level, which previously relied on external hardware connections, while significantly reducing hardware costs and integration complexity.

[0088] Especially in the field of data fusion of LiDAR (Linux side) and millimeter-wave radar (AUTOSAR side) in autonomous driving systems, if the time reference is inconsistent, the target position calculation of a vehicle moving at high speed will be greatly deviated (for example, at a vehicle speed of 100km / h, a 10ms error is equal to a position error of 28cm). The embodiments of the present invention ensure that all sensor data on the heterogeneous core are based on the same high-precision UTC time axis, eliminating time alignment errors and effectively improving the accuracy and safety of autonomous driving perception algorithms.

[0089] The following is combined Figure 2 The method for obtaining synchronization time parameters in the embodiments of the present invention will be described in more detail. Figure 2 A flowchart illustrating the method for obtaining synchronization time parameters provided in this application is shown. This method can be executed by a second kernel, such as... Figure 2 As shown, the method may include, but is not limited to, the following steps: Step S201: Record the second local hardware timestamp t2 of the time when the first kernel sends the first synchronization message to it, and the first follow-up message of the first kernel sends the first synchronization message to it, wherein the first follow-up message carries the first local hardware timestamp t1 of the time when the first kernel sends the first synchronization message to it.

[0090] It should be noted that when the first kernel sends a first synchronization message SYNC to the second kernel, the hardware or driver layer captures the current counter value, i.e., the first local hardware timestamp t1, the moment the first SYNC leaves the first kernel communication interface. The second kernel receives the first SYNC and records the second local hardware timestamp t2 at the moment of receiving the first SYNC sent by the first kernel. After capturing the first local hardware timestamp t1, the first kernel can send a first follow message Follow Up carrying the first local hardware timestamp t1 to the second kernel, or it can include the first local hardware timestamp t1 in the first SYNC data payload, thereby realizing the transmission of the first local hardware timestamp t1 to the second kernel.

[0091] Step S202: Record the third local hardware timestamp t3 of the time when the first delay request message is sent to the first kernel, and receive the first delay response message sent by the first kernel in response to the first delay request message. The first delay response message carries the fourth local hardware timestamp t4 recorded by the first kernel when receiving the first delay request message.

[0092] It should be noted that the second kernel sends a first delay request (Delay Req) to the first kernel. At the instant the first delay request is sent, the second kernel captures a local counter value, i.e., the third local hardware timestamp t3. The first kernel receives the first delay request (Delay Req) and, at the instant of receipt, captures the current counter value, i.e., the fourth local hardware timestamp t4. The first kernel then passes t4 to the second kernel via a first delay response (DELAY RESP).

[0093] Step S203: Determine the inter-core path delay Delay based on the first local hardware timestamp t1, the second local hardware timestamp t2, the third local hardware timestamp t3, and the fourth local hardware timestamp t4. ipc And based on inter-core path delay Delay ipc Determine the base time deviation Offset base .

[0094] After obtaining the first local hardware timestamp t1, the second local hardware timestamp t2, the third local hardware timestamp t3, and the fourth local hardware timestamp t4, the second kernel uses the bidirectional symmetry assumption to eliminate the average latency on the communication path to calculate the inter-core path delay. :

[0095] Existing technologies typically ignore the time consumed by inter-core communication (IPC). In heterogeneous systems, the process of sending data from one core to receiving it from another involves bus arbitration, interrupt response latency, and memory copy time. These delays are typically between 10 μs and several hundred μs and are jittery. In this embodiment of the invention, a bidirectional measurement mechanism (Pdelay) using the aforementioned four timestamps is introduced to mathematically cancel out the physical delays on the round-trip path. The method described above for calculating inter-core path delays can accurately isolate the communication time, ensuring that the calculated clock offset no longer includes transmission delay errors, thereby improving synchronization accuracy from milliseconds (ms) to sub-microseconds (<1 μs).

[0096] The above calculation of inter-core path delay The method, compared to relying solely on one-way message transmission time (such as using only...), The calculation method described in this invention has fundamental advantages. One-way calculations directly introduce all dynamic delays and jitter along the communication path into the clock offset, causing significant errors. However, this invention, through the assumption of bidirectional symmetry, averages the transmission time of the round-trip path. This cleverly cancels out the random delay components (such as bus arbitration fluctuations and interrupt response queuing) that exist in opposite directions but with similar amplitudes in the outbound and return paths, thus eliminating the inherent, stable physical propagation time of the communication link. This not only eliminates the path uncertainties that cannot be distinguished in one-way measurements but also ensures that the calculated clock offset reflects only the inherent differences between the two core clock sources, providing a crucial guarantee for achieving sub-microsecond synchronization accuracy.

[0097] After calculating the inter-core path delay Then, the basic time deviation can be calculated using the following formula. :

[0098] It should be noted that the above embodiments use a "hardware counter" as a benchmark to determine the local hardware timestamp. Alternatively, if the SoC supports this, each core's private high-precision timer can also be used to determine the local hardware timestamp. In this case, a "frequency normalization" step needs to be added to the algorithm, i.e., first calculating the frequency ratio of the two private timers, and then performing the offset calculation. Although this increases computational complexity, the underlying logic remains the same and is within the scope of this invention.

[0099] Step S204: Use the local hardware timestamp of the time when the first kernel sends the reference synchronization message as the reference base time T.base， The local hardware timestamp of the time when the reference synchronization message sent by the first kernel is received is used as the reference synchronization timestamp t. ref .

[0100] It should be noted that the reference synchronization message is a message sent by the first kernel to the second kernel as an anchor point. It can be the most recently sent message at the time the synchronization was determined, or it can be the first synchronization message. In this case, the reference synchronization timestamp is the second local hardware timestamp t2, and the reference base time T is used. base This refers to the first local hardware timestamp t1 at the time the first kernel sends the first synchronization message. For ease of description, the following description uses the first synchronization message sent by the first kernel to the second kernel as an example to obtain the reference base time T. base It can include: When the first kernel sends the follow-up message, it directly uses the calculated T... base Value (i.e.) The message field is filled in and sent to the second kernel; the second kernel uses the second local hardware timestamp captured when it previously received the first synchronization message. As t ref Combined with the received T base That is, to obtain the complete anchor pair (t) ref , T base ).

[0101] Step S205: Based on the local hardware timestamps of multiple sets of bidirectional message exchanges between the first kernel and the second kernel, calculate the frequency ratio between the hardware clocks of the first kernel and the second kernel.

[0102] It should be noted that the synchronization time parameter can also include the frequency ratio. Since the frequency ratio measures the relative timekeeping rate difference between the two core clock sources, this rate difference must be indirectly estimated by observing the ratio of the growth of the hardware counters of the two cores within the same physical time interval. A single synchronization cycle can only provide an instantaneous phase offset at a given point in time, and cannot reflect the rate characteristic of "accumulation over time." Only by obtaining the local hardware timestamps from the hardware counter values ​​of the master and slave cores at two specific moments through two consecutive synchronizations can the number of increments of the two core counters during the actual physical time interval be calculated. The ratio of these two increments directly reveals the relative relationship between the crystal oscillator frequencies of the two cores, enabling the system to predict and compensate for the time error that accumulates due to frequency drift within the synchronization interval. This is crucial for achieving long-term stable sub-microsecond synchronization. This invention provides a method for calculating the frequency ratio based on a bidirectional hybrid method using complete data from two consecutive cycles: ; Wherein, the first synchronization period (period n): : Represents the local hardware timestamp of the moment when the first kernel sends the SYNC message; : Indicates the local hardware timestamp of the second kernel receiving the SYNC time; : Represents the local hardware timestamp at the moment when the second kernel sends DELAY_REQ; : Indicates the local hardware timestamp at the time when the first kernel receives DELAY_REQ; Second synchronization period (period n+1): : Represents the local hardware timestamp of the moment when the first kernel sends the SYNC message; : Indicates the local hardware timestamp of the second kernel receiving the SYNC time; : Represents the local hardware timestamp at the moment when the second kernel sends DELAY_REQ; : Indicates the local hardware timestamp at the time when the first kernel receives DELAY_REQ.

[0103] After calculating the frequency ratio, the local hardware timestamp can be converted to the corresponding global timestamp based on the frequency ratio. Compared to only correcting the instantaneous phase offset of the clock, this overcomes the "different running speed" problem caused by the inherent difference in the independent crystal oscillator frequencies of the two cores and the temperature drift effect, preventing the continuous accumulation of errors within the synchronization interval, which severely restricts synchronization accuracy and stability. By calculating the frequency ratio, the system can quantify and dynamically compensate for this relative rate deviation, ensuring that even within a long synchronization period, the local clock of the slave core can accurately track the time reference of the master core, effectively suppressing the time accumulation effect of errors. This mechanism not only significantly reduces the dependence on the synchronization frequency and reduces system overhead, but also fundamentally ensures that the heterogeneous multi-core system maintains sub-microsecond synchronization accuracy for a long time under various operating conditions and temperature environments, providing a reliable time reference guarantee for high-precision sensor data fusion.

[0104] According to some embodiments, by using multiple consecutive synchronization messages, the frequency drift ratio of the hardware clock sources of the first core and the second core is calculated and used for local time interpolation calculation, which can further eliminate the cumulative error caused by crystal oscillator temperature drift.

[0105] Figure 3 A block diagram of the time synchronization device provided in this application is shown, the device comprising: Event capture module 310 is configured to determine the local hardware timestamp when the event to be synchronized occurs; The parameter acquisition module 320 is configured to acquire synchronization time parameters through bidirectional message interaction between the first kernel and the second kernel based on hardware timestamps. The timestamp conversion module 330 is configured to convert the local hardware timestamp into a corresponding global timestamp based on the synchronization time parameter, thereby achieving sub-microsecond time synchronization between the second kernel and the first kernel.

[0106] In this embodiment of the invention, the synchronization time parameters include: basic time deviation, reference synchronization timestamp, and its corresponding reference base time; The parameter acquisition module 320 is configured to record a second local hardware timestamp at the time of receiving the first synchronization message sent by the first kernel, and a first follow-up message at the time of receiving the first synchronization message sent by the first kernel, wherein the first follow-up message carries the first local hardware timestamp at the time of sending the first synchronization message sent by the first kernel; record a third local hardware timestamp at the time of sending the first delay request message to the first kernel, and a first delay response message at the time of receiving the first delay request message sent by the first kernel, wherein the first delay response message carries a fourth local hardware timestamp recorded by the first kernel when receiving the first delay request message; determine the inter-core path delay and the basic time deviation based on the first local hardware timestamp, the second local hardware timestamp, the third local hardware timestamp, and the fourth local hardware timestamp; use the local hardware timestamp at the time of sending the reference synchronization message sent by the first kernel as the reference base time, and use the local hardware timestamp at the time of receiving the reference synchronization message sent by the first kernel as the reference synchronization timestamp.

[0107] In this embodiment of the invention, the synchronization time parameter further includes: frequency ratio; The parameter acquisition module 320 is configured to calculate the frequency ratio between the hardware clocks of the first kernel and the second kernel based on the local hardware timestamps of multiple sets of bidirectional message exchanges between the first kernel and the second kernel.

[0108] In this embodiment of the invention, the parameter acquisition module 320 is configured to combine the message transmission time from the first kernel to the second kernel and the message transmission time from the second kernel to the first kernel to calculate a bidirectional average delay value used to offset the uncertainty of one-way transmission, which is used as the inter-core path delay.

[0109] In this embodiment of the invention, the parameter acquisition module 320 is configured to deduct the inter-core path delay from the total transmission time of the message from the first kernel to the second kernel.

[0110] In this embodiment of the invention, the timestamp conversion module 330 is configured to establish a time conversion relationship based on the reference base time and the reference synchronization timestamp; use the frequency ratio to perform frequency normalization correction on the time interval of the local hardware timestamp relative to the reference synchronization timestamp; combine the corrected time interval with the reference base time, and apply the basic time deviation for final alignment to generate the global timestamp.

[0111] In this embodiment of the invention, the parameter acquisition module 320 is configured to apply a bidirectional message exchange and timestamp recording method defined in the Precision Time Protocol or the Generalized Precision Time Protocol, which is used to measure path delay between network devices, to the inter-core communication process between the first kernel and the second kernel.

[0112] In this embodiment of the invention, the first kernel runs a first operating system (e.g., a non-real-time operating system) and synchronizes with an external master clock via an Ethernet interface to obtain a global reference time; the second kernel runs a real-time operating system.

[0113] In this embodiment of the invention, the first synchronization message, the first follow message, the first delay request message, and the first delay response message are transmitted through shared memory, hardware mailboxes, message queues, or remote processor message mechanisms within the heterogeneous multi-core system.

[0114] In this embodiment of the invention, the event capture module 310 is configured to directly read the local hardware counter value of the second kernel in the interrupt service routine when sensor data controlled by the second kernel arrives and triggers a hardware interrupt, and determine the local hardware timestamp when the event to be synchronized occurs based on the local hardware counter value.

[0115] In this embodiment of the invention, all local hardware timestamps are obtained by directly reading the underlying shared hardware counter of the heterogeneous multi-core system or the high-precision timer private to each kernel.

[0116] The above embodiments of the present invention achieve high-precision time synchronization between heterogeneous multi-core systems: First, the slave node directly reads the hardware counter when the event to be synchronized (such as a sensor interrupt) occurs, obtaining a jitter-free time reference point from the lowest-level hardware; second, through bidirectional message interaction with the master node (first core) based on hardware timestamps, synchronization parameters such as inter-core communication path delay and clock deviation are accurately measured, effectively eliminating the uncertain delays caused by operating system scheduling and interrupt response; finally, these parameters are used to convert the local hardware counter value of the slave node into a global timestamp in real time and accurately. The core technical effect of this method is that by transplanting the bidirectional measurement mechanism of the Precision Time Protocol (PTP) to the inter-core communication inside the chip and combining it with hardware-level timestamp capture, software jitter and communication delay uncertainty are systematically eliminated, thereby achieving sub-microsecond-level synchronization accuracy at the pure software level, which previously relied on external hardware connections, while significantly reducing hardware costs and integration complexity.

[0117] This invention also discloses a heterogeneous multi-core on-chip system, comprising: As the primary kernel of the master node, it is configured to run the primary operating system; As a second kernel of a slave node, it is configured to run a real-time operating system and can execute methods according to embodiments of the present invention.

[0118] This invention also discloses a vehicle that includes a heterogeneous multi-core system-on-a-chip as described in the above embodiments.

[0119] The following is for reference. Figure 4 To describe the electronic device 40 according to an embodiment of this application. Figure 4 A block diagram of the electronic device provided in this application is shown. Figure 4 The electronic device 40 shown is merely an example and should not impose any limitations on the functionality and scope of use of the embodiments of this application.

[0120] like Figure 4 As shown, the electronic device 40 is manifested in the form of a general-purpose computing device. The components of the electronic device 40 may include, but are not limited to: at least one processing unit 410, at least one storage unit 420, and a bus 340 connecting different system components (including storage unit 420 and processing unit 410).

[0121] The storage unit stores program code that can be executed by the processing unit 410, causing the processing unit 410 to perform the steps described in the exemplary method description section of this specification according to various exemplary embodiments of the present invention. For example, the processing unit 410 can perform actions such as... Figure 1 and Figure 2 The steps shown are as follows.

[0122] Storage unit 420 may include a readable medium in the form of a volatile storage unit, such as random access memory (RAM) 4201 and / or cache memory 4202, and may further include a read-only memory (ROM) 4203.

[0123] Storage unit 420 may also include a program / utility 4204 having a set (at least one) program module 4205, such program module 4205 including but not limited to: operating system, one or more application programs, other program modules and program data, each or some combination of these examples may include an implementation of a network environment.

[0124] Bus 430 can represent one or more of several types of bus structures, including a memory cell bus or memory cell controller, a peripheral bus, a graphics acceleration port, a processing unit, or a local bus using any of the various bus structures.

[0125] Electronic device 40 can also communicate with one or more external devices 500 (e.g., keyboard, pointing device, Bluetooth device, etc.), and with one or more devices that enable a user to interact with electronic device 40, and / or with any device that enables electronic device 40 to communicate with one or more other computing devices (e.g., router, modem, etc.). This communication can be performed via input / output (I / O) interface 450. Input / output (I / O) interface 450 is connected to display unit 440. Furthermore, electronic device 40 can also communicate with one or more networks (e.g., local area network (LAN), wide area network (WAN), and / or public networks, such as the Internet) via network adapter 460. As shown, network adapter 460 communicates with other modules of electronic device 40 via bus 430. It should be understood that, although not shown in the figures, other hardware and / or software modules can be used in conjunction with electronic device 40, including but not limited to: microcode, device drivers, redundant processing units, external disk drive arrays, RAID systems, tape drives, and data backup storage systems.

[0126] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, terminal device, or network device, etc.) to execute the methods according to the embodiments of this application.

[0127] In an exemplary embodiment of this application, a computer-readable storage medium is also provided, on which computer-readable instructions are stored, which, when executed by a computer's processor, cause the computer to perform the methods described in the above method embodiments.

[0128] According to one embodiment of this application, a program product for implementing the methods in the above-described method embodiments is also provided. This product may employ a portable compact disc read-only memory (CD-ROM) and include program code, and may run on a terminal device, such as a personal computer. However, the program product of this invention is not limited thereto. In this document, a readable storage medium may be any tangible medium containing or storing a program that may be used by or in conjunction with an instruction execution system, apparatus, or device.

[0129] The program product may employ any combination of one or more readable media. A readable medium may be a readable signal medium or a readable storage medium. A readable storage medium may be, for example, but not limited to, an electrical, magnetic, optical, electromagnetic, infrared, or semiconductor system, apparatus, or device, or any combination thereof. More specific examples of readable storage media (a non-exhaustive list) include: an electrical connection having one or more wires, a portable disk, a hard disk, random access memory (RAM), read-only memory (ROM), erasable programmable read-only memory (EPROM or flash memory), optical fiber, portable compact disk read-only memory (CD-ROM), optical storage devices, magnetic storage devices, or any suitable combination thereof.

[0130] Computer-readable signal media may include data signals propagated in baseband or as part of a carrier wave, carrying readable program code. Such propagated data signals may take various forms, including but not limited to electromagnetic signals, optical signals, or any suitable combination thereof. A readable signal medium may also be any readable medium other than a readable storage medium, capable of sending, propagating, or transmitting programs for use by or in conjunction with an instruction execution system, apparatus, or device.

[0131] The program code contained on the readable medium may be transmitted using any suitable medium, including but not limited to wireless, wired, optical fiber, RF, etc., or any suitable combination thereof.

[0132] Program code for performing the operations of this invention can be written in any combination of one or more programming languages, including object-oriented programming languages ​​such as JAVA and C++, and conventional procedural programming languages ​​such as C or similar languages. The program code can execute entirely on the user's computing device, partially on the user's device, as a standalone software package, partially on the user's computing device and partially on a remote computing device, or entirely on a remote computing device or server. In cases involving remote computing devices, the remote computing device can be connected to the user's computing device via any type of network, including a local area network (LAN) or a wide area network (WAN), or it can be connected to an external computing device (e.g., via the Internet using an Internet service provider).

[0133] It should be noted that although several modules or units for the device used to perform actions have been mentioned in the detailed description above, this division is not mandatory. In fact, according to the embodiments of this application, the features and functions of two or more modules or units described above can be embodied in one module or unit. Conversely, the features and functions of one module or unit described above can be further divided and embodied by multiple modules or units.

[0134] Furthermore, although the steps of the method in this application are described in a specific order in the accompanying drawings, this does not require or imply that the steps must be performed in that specific order, or that all the steps shown must be performed to achieve the desired result. Additional or alternative steps may be omitted, multiple steps may be combined into one step, and / or a step may be broken down into multiple steps.

[0135] Through the above description of the embodiments, those skilled in the art will readily understand that the exemplary embodiments described herein can be implemented by software or by combining software with necessary hardware. Therefore, the technical solutions according to the embodiments of this application can be embodied in the form of a software product, which can be stored in a non-volatile storage medium (such as a CD-ROM, USB flash drive, external hard drive, etc.) or on a network, including several instructions to cause a computing device (such as a personal computer, server, mobile terminal, or network device, etc.) to execute the methods according to the embodiments of this application.

[0136] Other embodiments of this application will readily occur to those skilled in the art upon consideration of the specification and practice of the invention disclosed herein. This application is intended to cover any variations, uses, or adaptations of this application that follow the general principles of this application and include common knowledge or customary techniques in the art not disclosed herein. The specification and examples are to be considered exemplary only, and the true scope and spirit of this application are indicated by the appended claims.

Claims

1. A time synchronization method based on a heterogeneous multi-core system, characterized in that, The heterogeneous multi-core system includes a first kernel as a master node and a second kernel as a slave node. The method is executed by the second kernel, and the method includes: Determine the local hardware timestamp when the event to be synchronized occurred; Synchronization time parameters are obtained through bidirectional message exchange between the first kernel and the second kernel based on hardware timestamps. Based on the synchronization time parameters, the local hardware timestamp is converted into a corresponding global timestamp, thereby achieving sub-microsecond time synchronization between the second kernel and the first kernel.

2. The method according to claim 1, characterized in that, The synchronization time parameters include: basic time deviation, reference synchronization timestamp, and its corresponding reference base time; Synchronization time parameters are obtained through bidirectional message exchange based on hardware timestamps between the first kernel and the second kernel, including: Record a second local hardware timestamp of the time when the first synchronization message is received from the first kernel, and a first follow-up message of the first synchronization message is received from the first kernel. The first follow-up message carries the first local hardware timestamp of the time when the first kernel sends the first synchronization message to it. Record a third local hardware timestamp of the time when the first delay request message is sent to the first kernel, and receive a first delay response message sent by the first kernel in response to the first delay request message. The first delay response message carries a fourth local hardware timestamp recorded by the first kernel when it receives the first delay request message. The inter-core path delay is determined based on the first local hardware timestamp, the second local hardware timestamp, the third local hardware timestamp, and the fourth local hardware timestamp, and the base time deviation is determined based on the inter-core path delay. The local hardware timestamp at the time when the first kernel sends the reference synchronization message is used as the reference base time, and the local hardware timestamp at the time when the first kernel receives the reference synchronization message is used as the reference synchronization timestamp.

3. The method according to claim 2, characterized in that, The synchronization time parameter also includes: frequency ratio; The synchronization time parameters are obtained through bidirectional message exchange based on hardware timestamps between the first kernel and the second kernel, and the method further includes: Based on the local hardware timestamps of multiple sets of bidirectional message exchanges between the first kernel and the second kernel, the frequency ratio between the hardware clocks of the first kernel and the second kernel is calculated.

4. The method according to claim 2, characterized in that, The inter-core path delay is determined in the following way: By combining the message transmission time from the first core to the second core and the message transmission time from the second core to the first core, a bidirectional average delay value is calculated to offset the uncertainty of one-way transmission, which is used as the inter-core path delay.

5. The method according to claim 4, characterized in that, The basic time deviation is determined in the following way: The inter-core path delay is deducted from the total message transmission time from the first kernel to the second kernel.

6. The method according to claim 3, characterized in that, The step of converting the local hardware timestamp into a corresponding global timestamp based on the synchronization time parameter includes: Establish a time conversion relationship based on the aforementioned reference base time and reference synchronization timestamp; Using the frequency ratio, the time interval between the local hardware timestamp and the reference synchronization timestamp is corrected for frequency normalization. The corrected time interval is combined with the reference time, and the base time deviation is applied for final alignment to generate the global timestamp.

7. The method according to claim 2, characterized in that, The step of converting the local hardware timestamp into a corresponding global timestamp based on the synchronization time parameter includes: A time conversion relationship is established based on the reference base time and the reference synchronization timestamp, and the basic time deviation is applied for final alignment to generate the global timestamp.

8. The method according to any one of claims 1-7, characterized in that, The first kernel runs a first operating system and synchronizes with an external master clock via an Ethernet interface to obtain a global reference time; the second kernel runs a real-time operating system.

9. The method according to claim 1, characterized in that, Determine the local hardware timestamp when the event to be synchronized occurred, including: When sensor data controlled by the second kernel arrives and triggers a hardware interrupt, the local hardware counter value of the second kernel is directly read in the interrupt service routine, and the local hardware timestamp when the event to be synchronized occurs is determined based on the local hardware counter value.

10. A heterogeneous multi-core on-chip system, characterized in that, include: As the primary kernel of the master node, it is configured to run the primary operating system; As a second kernel of the slave node, it is configured to run a real-time operating system and execute the method according to any one of claims 1-9.

11. A vehicle, characterized in that, Including the heterogeneous multicore on-chip system according to claim 10.

Images