Multi-core heterogeneous domain controller and inter-core time synchronization method thereof

Abstract

The invention provides a multi-core heterogeneous domain controller and an inter-core time synchronization method thereof, and the method comprises the steps: enabling a basic core to start and obtain a local timestamp of the timing of a real-time clock in a starting initialization stage of the domain controller, setting the local timestamp as the system initial time of the basic core, the local timestamp is sent to a data packet forwarding engine; the data packet forwarding engine carries out timing by taking the local timestamp as reference time; the non-basic core is started and obtains a current timestamp of timing of the data packet forwarding engine, and system initial time of the non-basic core is set according to the current timestamp, so that time synchronization between the non-basic core and the basic core in the starting initialization stage of the domain controller is achieved. According to the invention, the problems of high clock synchronization delay and poor consistency between different cores in the initialization process of the domain controller are solved.

Description

Technical Field

[0001] This application relates to the technical field of multi-core heterogeneous domain controllers, and particularly relates to a multi-core heterogeneous domain controller and an inter-core time synchronization method thereof. Background Art

[0002] A multi-core heterogeneous domain controller is an electronic control unit commonly used in automotive electronics, industrial automation, and other application fields that require high-performance computing and control. Exemplarily, a multi-core heterogeneous domain controller can be integrated with a multi-core architecture inside the domain in a way of a single or multiple A-cores (such as SOC) plus M-cores (such as MCU). Taking automotive electronics as an example, A-cores can be used to implement high-computing power, large storage, and low-coupling function requirements, such as in-vehicle big data, OTA clients, log information storage, light shows, etc. M-cores can be used to implement high-real-time vehicle control function requirements such as power control, mode management, body control, and power control; the functions of A-cores and M-cores are independent and interdependent, and data is exchanged through different transmission methods.

[0003] Currently, data exchange between the A-core and M-core of a multi-core heterogeneous domain controller can be carried out through an Ethernet switch, GPIO (General-Purpose Input / Output), SPI (Serial Peripheral Interface), UARI interface, and IPCF inter-core communication, etc. To ensure the accuracy of time synchronization within the domain, a time synchronization protocol based on GPTP (Generalized Precision Time Protocol) Ethernet data packets is generally adopted between the A-core and M-core, and time synchronization functions are realized through interaction with an external master clock source via a switch to ensure that the clock synchronization accuracy can reach the sub-microsecond level. However, this method can only ensure time synchronization consistency on the premise that the external master clock source and the domain controller are running normally and the Ethtsync protocol stack is started normally. It has the following problems:

[0004] (1) During the power-on initialization process of the domain controller, the clock synchronization delay between different cores is high and the consistency is poor;

[0005] (2) During the normal operation of the domain controller, the clock synchronization stability between different cores is insufficient;

[0006] The above problems will affect the time synchronization accuracy between different cores in the domain controller, thereby affecting the performance and reliability of the entire device system. Therefore, targeted measures need to be proposed to optimize and ensure the stability and accuracy of time synchronization between different cores of the domain controller. Summary of the Invention

[0007] The purpose of this application is to propose a multi-core heterogeneous domain controller, an inter-core time synchronization method, and a computer program product thereof to ensure the stability and accuracy of time synchronization between different cores of the multi-core heterogeneous domain controller.

[0008] To achieve the object of the present application, a first aspect of the present application provides an inter-core time synchronization method for a multi-core heterogeneous domain controller as described in the first aspect. The multi-core heterogeneous domain controller includes a base core, a packet forwarding engine, and at least one non-base core;

[0009] The method includes:

[0010] In the domain controller startup initialization phase, the base core starts and obtains the local timestamp measured by the real-time clock, sets the local timestamp as the system initial time of the base core, and sends the local timestamp to the packet forwarding engine;

[0011] The packet forwarding engine uses the local timestamp as the reference time for timing;

[0012] The non-base core starts and obtains the current timestamp measured by the packet forwarding engine, and sets the system initial time of the non-base core according to the current timestamp, so as to achieve time synchronization between the non-base core and the base core in the domain controller startup initialization phase.

[0013] As the same inventive concept, a second aspect of the present application provides a multi-core heterogeneous domain controller, including:

[0014] A real-time clock for measuring the local timestamp;

[0015] A base core for obtaining the local timestamp measured by the real-time clock in the domain controller startup initialization phase, setting the local timestamp as the system initial time of the base core, and sending the local timestamp to the packet forwarding engine;

[0016] A packet forwarding engine for packet forwarding and using the local timestamp as the reference time for timing;

[0017] At least one non-base core for obtaining the current timestamp measured by the packet forwarding engine in the domain controller startup initialization phase, and setting the system initial time of the non-base core according to the current timestamp, so as to achieve time synchronization between the non-base core and the base core in the domain controller startup initialization phase.

[0018] A third aspect of the present application provides a multi-core heterogeneous domain controller, including:

[0019] A memory for storing computer program instructions;

[0020] A processor for executing the computer program instructions to support the multi-core heterogeneous domain controller to implement the method according to the first aspect of the present application.

[0021] The fourth aspect of the present application provides a computer program product, including computer program instructions, and the computer program instructions direct a computer device to perform operations corresponding to the method described in the first aspect of the present application.

[0022] The above-mentioned multi-core heterogeneous domain controller, its inter-core time synchronization method, and computer program product have the following beneficial effects:

[0023] The multi-core heterogeneous domain controller uses a real-time clock to time local timestamps, ensuring that there is a reliable clock source even during the power-on initialization phase of the domain controller; during the startup initialization phase, the base core obtains the local timestamp of the real-time clock and sets it as the system initial time; the packet forwarding engine uses the local timestamp sent by the base core as the reference time and uses its own supported timing function to time to obtain the current timestamp of the packet forwarding engine, and all packets passing through the packet forwarding engine will carry timestamps. During the startup initialization phase, the non-base core requests the current timestamp from the packet forwarding engine and sets its own system initial time according to the current timestamp returned by the packet forwarding engine, thereby realizing time synchronization between the non-base core and the base core. Through the combination of the real-time clock and the packet forwarding engine, high-precision clock synchronization can be achieved during the initialization phase, effectively solving the problems of high clock synchronization delay and poor consistency between different cores during the domain controller initialization process. Description of the Drawings

[0024] In order to more clearly illustrate the technical solutions in the embodiments of the present application, the following will briefly introduce the drawings required in the embodiment descriptions. Obviously, the drawings in the following descriptions are only some embodiments of the present application. For those of ordinary skill in the art, without creative efforts, other drawings can be obtained based on these drawings.

[0025] Figure 1 It is a flowchart of an inter-core time synchronization method for a multi-core heterogeneous domain controller in an embodiment of the present application.

[0026] Figure 2 It is a schematic structural diagram of a multi-core heterogeneous domain controller in an embodiment of the present application.

[0027] Figure 3 It is a schematic diagram of the internal time synchronization logic link of a multi-core heterogeneous domain controller in an embodiment of the present application. Detailed Description of the Specific Embodiment

[0028] The detailed description of the drawings is intended to be an illustration of the current embodiments of the present application, rather than representing the only form in which the present application can be implemented. It should be understood that the same or equivalent functions can be completed by different embodiments intended to be included within the spirit and scope of the present application.

[0029] An embodiment of the present application provides an inter-core time synchronization method for a multi-core heterogeneous domain controller. The multi-core heterogeneous domain controller includes a basic core (M core), a packet forwarding engine (PFE, Packet Forwarding Engine), and at least one non-basic core (A core). The basic core (M core) and the at least one non-basic core (A core) both perform packet forwarding through the packet forwarding engine.

[0030] Refer to Figure 1 , the method of this embodiment includes the following steps:

[0031] Step S10, in the initialization stage when the domain controller starts up, the basic core starts and obtains the local timestamp counted by the real-time clock (RTC, Real-Time Clock), sets the local timestamp as the system initial time of the basic core, and sends the local timestamp to the packet forwarding engine.

[0032] Specifically, the real-time clock (RTC) is used to count the local timestamp; specifically, the real-time clock (RTC) is a special clock circuit that can still maintain the accuracy of time after power-off. The real-time clock can run independently of the main system clock and is usually powered by a battery to maintain its operation. Even if the system is powered off, it can continue to count time.

[0033] Specifically, when the domain controller is powered on or restarted, the basic core (M core) is first activated. After being activated, the basic core (M core) communicates with the real-time clock (RTC), reads the current local timestamp from the real-time clock (RTC), and synchronizes the local timestamp to the packet forwarding engine (PFE), and only synchronizes once during the startup process of the reference core, as the reference time of the packet forwarding engine (PFE).

[0034] Step S20, the packet forwarding engine counts time based on the local timestamp as the reference time.

[0035] Specifically, the Ethernet media access controller (EMAC, Ethernet Media Access Controller) in the packet forwarding engine (PFE) can accept the timestamp assignment function and cooperate with the PFE hardware crystal oscillator timing function to provide a feasible link scheme for the non-basic core to efficiently synchronize the basic core time strategy during the startup process. Compared with the method of performing in-domain time synchronization through IPCF inter-core communication during the startup stage, the second-level synchronization accuracy is improved to the millisecond level.

[0036] Step S30: The non-base core starts up and obtains the current timestamp of the packet forwarding engine's timing, and sets the system initial time of the non-base core according to the current timestamp, so as to achieve time synchronization between the non-base core and the base core during the startup initialization phase of the domain controller.

[0037] Specifically, after the non-base core starts up, it requests the packet forwarding engine (PFE) to obtain the current timestamp of its timing, so as to learn the current time, and sets the system initial time of the non-base core (A core) accordingly.

[0038] In summary, the method of this embodiment uses the real-time clock (RTC) to time the local timestamp, ensuring that there is a reliable clock source even during the power-on initialization phase of the domain controller; the base core (M core) obtains the local timestamp of the real-time clock (RTC) during the startup initialization phase and sets it as the system initial time; the packet forwarding engine (PFE) uses the local timestamp sent by the base core (M core) as the reference time and uses its own supported timing function to time to obtain the current timestamp of the packet forwarding engine (PFE), and all packets passing through the packet forwarding engine (PFE) will carry timestamps. The non-base core (A core) (M core) requests the current timestamp from the packet forwarding engine (PFE) during the startup initialization phase and sets its own system initial time according to the current timestamp returned by the packet forwarding engine (PFE), thereby achieving time synchronization between the non-base core (A core) (M core) and the base core (M core). Through the combination of the real-time clock (RTC) and the packet forwarding engine (PFE), it ensures that high-precision clock synchronization can be achieved during the initialization phase, effectively solving the problems of high clock synchronization delay and poor consistency between different cores during the initialization of the domain controller.

[0039] In some embodiments, the base core includes a real-time clock driver (RTCDrv), a time management module (TM, Time Manager), a system time base management module (STBM, System Time Base Manager), and a complex device driver (CDD, Complex Device Driver);

[0040] The step S10 includes:

[0041] Step S101: The time management module (TM, Time Manager) calls the real-time clock driver to obtain the local timestamp of the real-time clock timing and sends it to the system time base management module.

[0042] Specifically, the Real-Time Clock Driver (RTCDrv) is used to manage the Real-Time Clock (RTC), provide support for initializing the Real-Time Clock (RTC), configuring the parameters of the Real-Time Clock (RTC), operating the read-write interface of the Real-Time Clock (RTC), etc., and can also be used to record the device running time. The Time Management Module (TM) is a middleware software module in the embedded operating system, assisting in the time synchronization logic processing between the reference core (M core) and the non-reference core (A core), and providing a time information interface to the upper-layer applications.

[0043] Step S102, the System Time Base Management Module (STBM) sets the local timestamp as the system initial time of the base core.

[0044] Specifically, the System Time Base Management Module (STBM) maintains the system time base, is responsible for processing the time synchronization protocol to obtain NTP and GPTP protocol timestamps for updating, and provides a unified timestamp interface and the current time synchronization status interface, etc.

[0045] Step S103, the Complex Device Driver (CDD) calls the Real-Time Clock Driver (RTCDrv) to obtain the local timestamp of the Real-Time Clock (RTC) timing, and sends the local timestamp to the Packet Forwarding Engine.

[0046] Specifically, the Complex Device Driver (CDD) is used to implement actuator control through specific interrupts and complex microcontroller peripherals. In this embodiment, it mainly assigns timestamps by calling the corresponding interfaces through the hardware timestamp function supported by the Packet Forwarding Engine (PFE).

[0047] In some embodiments, the non-base core includes a System Clock API interface (Linux Posix Time API) and a System and Service Manager (Systemd); the non-base core (A core) runs the Linux system. In the Linux system, the System Clock API interface (Linux Posix Time API) provides a set of functions for obtaining and setting the system time of the Linux system and performing time-related operations.

[0048] The method further includes:

[0049] Step S40, during the startup initialization phase of the domain controller, the system and service manager obtains the current timestamp of the packet forwarding engine timing, determines the system initial time of the non-base core according to the current timestamp, and calls the system clock API interface to set the system initial time of the non-base core.

[0050] Specifically, the system and service manager (Systemd) is open-source software for Linux system initialization and management of system resources, services, and daemon processes. It runs as the PID1 process (i.e., the first process during startup), manages all other user-space processes, and can create and manage specific service units through the system and service manager (Systemd) to meet the requirements of specific applications or tasks.

[0051] In some embodiments, in step S40, the system and service manager obtains the current timestamp of the packet forwarding engine timing and determines the system initial time of the non-base core according to the current timestamp, including:

[0052] The system and service manager obtains the current timestamp of the packet forwarding engine timing every preset time, and determines the system initial time of the non-base core according to the current timestamps obtained for the preset number of times.

[0053] Specifically, the system and service manager (Systemd) is configured to obtain the current timestamp of the packet forwarding engine (PFE) every preset time interval (e.g., 10 ms). When each preset time interval arrives, the system and service manager (Systemd) will obtain the current timestamp from the PFE through a certain interface, and this process will be repeated for a preset number of times (e.g., 10 times) to collect sufficient data to improve the accuracy of time synchronization; the multiple timestamps collected are used to determine a reliable time value, and this time value will be used as the system initial time of the non-base core (A core).

[0054] Refer to Figure 2 , another embodiment of the present application provides a multi-core heterogeneous domain controller, including a real-time clock (RTC), a base core (M core), a packet forwarding engine (PFE), and at least one non-base core (A core). The base core (M core) and the at least one non-base core (A core) both perform packet forwarding through the packet forwarding engine.

[0055] The real-time clock (RTC) is used for timing the local timestamp; specifically, the real-time clock (RTC) is a special clock circuit that can maintain the accuracy of time even after a power outage. The real-time clock can run independently of the main system clock and is usually powered by a battery to maintain its operation. Even if the system loses power, it can continue to keep time.

[0056] The base core (M core) is used to obtain the local timestamp timed by the real-time clock during the startup initialization phase of the domain controller, set the local timestamp as the system initial time of the base core (M core), and send the local timestamp to the packet forwarding engine (PFE); specifically, when the domain controller is powered on or restarted, the base core (M core) is first activated. After being activated, the base core (M core) communicates with the real-time clock (RTC), reads the current local timestamp from the real-time clock (RTC), and synchronizes the local timestamp to the packet forwarding engine (PFE), and only synchronizes once during the startup process of the reference core, serving as the reference time for the packet forwarding engine (PFE).

[0057] The packet forwarding engine (PFE) is used for packet forwarding between various cores and between various cores and other external devices, and uses the local timestamp as the reference time to generate the current timestamp of the packet forwarding engine (PFE) through the clock oscillator supported by itself; specifically, the Ethernet Media Access Controller (EMAC) in the packet forwarding engine (PFE) can accept the timestamp assignment function and cooperate with the PFE hardware oscillator timing function to provide a feasible link solution for the high-efficiency synchronization of the base core time strategy during the non-base core startup process. Compared with the method of intra-domain time synchronization through IPCF inter-core communication during the startup phase, the second-level synchronization accuracy is improved to the millisecond level.

[0058] The non-base core (A core) is used to obtain the current timestamp of the packet forwarding engine (PFE) during the startup initialization phase of the domain controller, and set the system initial time of the non-base core (A core) according to the current timestamp, so as to achieve time synchronization between the non-base core (A core) and the base core (M core) during the startup initialization phase of the domain controller; specifically, after the non-base core starts up, it requests the packet forwarding engine (PFE) to obtain its current timestamp to learn the current time, and accordingly sets the system initial time of the non-base core (A core).

[0059] In summary, the multi-core heterogeneous domain controller of this embodiment uses a real-time clock (RTC) to time the local timestamp, ensuring that there is a reliable clock source even during the power-on initialization phase of the domain controller. During the startup initialization phase, the base core (M core) obtains the local timestamp of the real-time clock (RTC) and sets it as the system initial time. The packet forwarding engine (PFE) uses the local timestamp sent by the base core (M core) as the reference time and uses its own supported timing function to time and obtain the current timestamp of the packet forwarding engine (PFE). All packets passing through the packet forwarding engine (PFE) will carry timestamps. During the startup initialization phase, the non-base core (A core) (M core) requests the current timestamp from the packet forwarding engine (PFE) and sets its own system initial time according to the current timestamp returned by the packet forwarding engine (PFE), thus achieving time synchronization between the non-base core (A core) (M core) and the base core (M core). Through the combination of the real-time clock (RTC) and the packet forwarding engine (PFE), high-precision clock synchronization is ensured during the initialization phase, effectively solving the problems of high clock synchronization delay and poor consistency between different cores during the domain controller initialization process.

[0060] In some embodiments, the base core includes a real-time clock driver (RTCDrv), a time management module (TM, Time Manager), a system time base management module (STBM, System Time Base Manager), and a complex device driver (CDD, Complex Device Driver).

[0061] The real-time clock driver (RTCDrv) is used to manage the real-time clock (RTC), provide support for initializing the real-time clock (RTC), configuring the real-time clock (RTC) parameters, operating the read / write interface of the real-time clock (RTC), etc., and can also be used to record the device running time.

[0062] The time management module (TM) is used to call the real-time clock driver to obtain the local timestamp of the real-time clock timing and send it to the system time base management module (STBM). Specifically, the time management module (TM) is a middleware software module in the embedded operating system, assisting in the time synchronization logic processing between the reference core (M core) and the non-reference core (A core), and providing a time information interface to the upper-layer applications.

[0063] The system time base management module (STBM) is used to set the local timestamp as the system initial time of the base core; specifically, the system time base management module (STBM) maintains the system time reference, is responsible for processing the time synchronization protocol to obtain the NTP and GPTP protocol timestamps for update, and provides a unified timestamp interface and the current time synchronization status interface, etc.

[0064] The complex device driver (CDD) is used to implement actuator control through specific interrupts and complex microcontroller peripherals. In this embodiment, it is specifically used to call the clock driver (RTCDrv) to obtain the local timestamp of the real-time clock (RTC) timing, and send the local timestamp to the packet forwarding engine (PFE), that is, through the hardware timestamp function supported by the packet forwarding engine (PFE), call the corresponding interface to assign the timestamp.

[0065] In some embodiments, the non-base core includes a system clock API interface (Linux Posix Time API) and a system and service manager (Systemd).

[0066] The system clock API interface (Linux Posix Time API) is used to set the system initial time of the non-base core; specifically, the non-base core (A core) runs the Linux system. In the Linux system, the system clock API interface (Linux Posix Time API) provides a set of functions for obtaining and setting the system time of the Linux system, and performing time-related operations.

[0067] The system and service manager (Systemd) is used to obtain the current timestamp of the packet forwarding engine (PFE) during the startup initialization phase of the domain controller, determine the system initial time of the non-base core (A core) according to the current timestamp, and call the system clock API interface to set the system initial time of the non-base core (A core). Specifically, the system and service manager (Systemd) is an open-source software for initializing and managing system resources, services, and daemon processes in the Linux system. It runs as the PID1 process and manages all other user-space processes. Through the system and service manager (Systemd), specific service units can be created and managed to meet the requirements of specific applications or tasks.

[0068] In some embodiments, the system and service manager (Systemd) is specifically used to obtain the current timestamp of the packet forwarding engine (PFE) once every preset time, and determine the system initial time of the non-base core (A core) according to the current timestamps obtained for the preset number of times.

[0069] Specifically, the System and Service Manager (Systemd) is configured to obtain the current timestamp of the Packet Forwarding Engine (PFE) at every other preset time interval (e.g., 10 ms). When each preset time interval arrives, the System and Service Manager (Systemd) obtains the current timestamp from the PFE through a certain interface. This process is repeated a preset number of times (e.g., 10 times) to collect sufficient data to improve the accuracy of time synchronization; the multiple collected timestamps are used to determine a reliable time value, and this time value will be used as the system initial time of the non-base core (core A).

[0070] In some embodiments, the non-base core (core A) further includes a Network Time Protocol Client (NTPClient) and an In-Vehicle Ethernet Time Synchronization Master Module (EthTsyncMaster).

[0071] The Network Time Protocol Client (NTPClient) is used to establish communication with an external Network Time Protocol Server (NTPServer) during the normal operation stage of the domain controller, and periodically obtain Coordinated Universal Time (UTC) from the external Network Time Protocol Server (NTPServer) for in-vehicle time calibration. For example, it actively initiates a request every 10 minutes to obtain the Coordinated Universal Time (UTC) of the Network Time Protocol Server (NTPServer); based on the Coordinated Universal Time (UTC), the Network Time Protocol Client (NTPClient) calls the system clock API interface to calibrate the system time of the non-base core (core A); the Network Time Protocol Client (NTPClient) is also used to synchronize the Coordinated Universal Time (UTC) or the calibrated system time of the non-base core (core A) to the In-Vehicle Ethernet Time Synchronization Master Module (EthTsyncMaster); for a vehicle, a Network Time Protocol Server (NTPServer) can be deployed in the TBOX to obtain accurate Coordinated Universal Time (UTC) from GPS or an external NTP server network time synchronization, and the Network Time Protocol Client (NTPClient) communicates with the Network Time Protocol Server (NTPServer) through the NTP protocol.

[0072] The in-vehicle Ethernet time synchronization master module (EthTsyncMaster) is used to synchronize the Coordinated Universal Time (UTC) or the system time of the non-base core (Core A) after calibration to the packet forwarding engine (PFE); specifically, the in-vehicle Ethernet time synchronization master module (EthTsyncMaster) generates a data packet containing the Coordinated Universal Time (UTC) or the system time synchronization of the non-base core (Core A) after calibration based on the GPTP protocol, and sends it to the packet forwarding engine (PFE) through the Ethernet interface (Ethif, EthernetInterface) of the non-base core (Core A); the Ethernet interface (Ethif) is responsible for the initialization of Ethernet communication, the sending and receiving of data, and the management of the underlying Phy Link status. Through this interface, the software and hardware are decoupled, improving the portability and reusability of the software, as well as the reliability and scalability of the system.

[0073] The packet forwarding engine (PFE) is also used to forward the Coordinated Universal Time (UTC) or the system time of the non-base core (Core A) after calibration to the base core (Core M), so that the base core (Core M) updates its system time according to the Coordinated Universal Time (UTC) or the system time of the non-base core (Core A) after calibration; specifically, after receiving a data packet containing the Coordinated Universal Time (UTC) or the system time of the non-base core (Core A) after calibration, the packet forwarding engine (PFE) forwards the data packet to the base core (Core M), and the base core (Core M) parses the data packet to obtain the Coordinated Universal Time (UTC) or the system time of the non-base core (Core A) after calibration, and calibrates its system time, so that the base core (Core M) and the non-base core (Core A) are synchronized with the Coordinated Universal Time (UTC).

[0074] In some embodiments, the base core (Core M) further includes an in-vehicle Ethernet time synchronization slave module (EthTsyncSlave) and an Ethernet interface (Ethif, EthernetInterface);

[0075] The Ethernet interface (Ethif, EthernetInterface) receives the data packet containing the Coordinated Universal Time (UTC) or the system time of the non-base core (Core A) after calibration forwarded by the packet forwarding engine (PFE), and forwards it to the in-vehicle Ethernet time synchronization slave module (EthTsyncSlave) for processing.

[0076] The in-vehicle Ethernet time synchronization slave module (EthTsyncSlave) is used to parse the above data packet to obtain the Coordinated Universal Time (UTC) or the system time of the non-base core (Core A) after calibration, obtain a synchronization timestamp based on the Coordinated Universal Time (UTC) or the system time of the non-base core (Core A) after calibration, and send the synchronization timestamp to the system time base management module (STBM).

[0077] The system time base management module (STBM) is further used to calibrate and update the system time of the base core (Core M) according to the synchronization timestamp.

[0078] In some embodiments, the in-vehicle Ethernet time synchronization master module (EthTsyncMaster) is specifically used to generate a Sync message according to the Coordinated Universal Time (UTC) or the system time of the non-base core (Core A) after calibration, and send the Sync message to the data packet forwarding engine (PFE);

[0079] The data packet forwarding engine (PFE) is used to forward the Sync message to the in-vehicle Ethernet time synchronization slave module (EthTsyncSlave);

[0080] The in-vehicle Ethernet time synchronization master module (EthTsyncMaster) is further used to record the sending time of the Sync message, generate a Follow_Up message according to the sending time, and send the Follow_Up message to the data packet forwarding engine (PFE);

[0081] The data packet forwarding engine (PFE) is used to forward the Follow_Up message to the in-vehicle Ethernet time synchronization slave module (EthTsyncSlave);

[0082] The in-vehicle Ethernet time synchronization slave module (EthTsyncSlave) is used to parse the Sync message to obtain the Coordinated Universal Time (UTC) or the system time of the non-base core (Core A) after calibration, parse the Follow_Up message to obtain the sending time, and obtain the synchronization timestamp according to the Coordinated Universal Time (UTC) or the system time of the non-base core (Core A) after calibration and the sending time.

[0083] Specifically, the time when the in-vehicle Ethernet time synchronization master module (EthTsyncMaster) generates the Sync message is the Coordinated Universal Time (UTC) or the system time of the non-primary core (core A) after calibration (set as T1), while the actual transmission time of the Sync message is T2. T2 is informed to the primary core (core M) through the Follow_Up message. Therefore, (T2 - T1) is the delay time from the generation to the transmission of the Sync message. That is to say, when the in-vehicle Ethernet time synchronization master module (EthTsyncMaster) actually sends the Sync message, the Coordinated Universal Time (UTC) or the system time of the non-primary core (core A) after calibration should be T1+(T2 - T1). At this time, assuming that the system time of core M when receiving the Sync message is T3, and the network delay of the Sync message in the link transmission between the non-primary core (core A), the packet forwarding engine (PFE) and the primary core (core M) is T4, then the system time of the primary core (core M) can be calibrated based on T3, T4 and "T1+(T2 - T1)", so that the primary core (core M) and the non-primary core (core A) are synchronized with the Coordinated Universal Time (UTC).

[0084] In some embodiments, the system time base management module (STBM) is further configured to synchronize the updated system time of the primary core (core M) to the time management module (TM);

[0085] The time management module (TM) is further configured to call the real-time clock driver (RTCDrv) to modify the local time of the real-time clock according to the updated system time of the primary core (core M).

[0086] Specifically, the system time base management module (STBM) and the time management module (TM) work together to ensure the clock synchronization between the entire primary core system and the real-time clock (RTC), so that the local time of the real-time clock (RTC) is correctly updated.

[0087] In some embodiments, the system time base management module (STBM) is further configured to synchronize the current system time of the primary core (core M) to the time management module (TM) before the domain controller powers off and enters the sleep state;

[0088] The time management module (TM) is further configured to call the real-time clock driver (RTCDrv) to modify the local time of the real-time clock (RTC) according to the current system time of the primary core (core M).

[0089] Specifically, before the domain controller powers off, the local time of the real-time clock (RTC) is actively updated to the current system time of the base core (M core), so that when the domain controller powers on next time, the base core (M core) can directly obtain an accurate local timestamp from the real-time clock (RTC), without the need to correct the time through network synchronization or other time sources. This reduces the time synchronization waiting time after the system starts, enabling the system to resume normal operation more quickly.

[0090] In some embodiments, the packet forwarding engine (PFE) includes a first Ethernet media access controller interface (EMA0), a second Ethernet media access controller interface (EMA1), a first high-fidelity interface (Hif0), and a second high-fidelity interface (Hif1);

[0091] The first Ethernet media access controller interface (EMA0) is used to receive the local timestamp sent by the complex device driver (CDD);

[0092] The second Ethernet media access controller interface (EMA1) is used to receive the coordinated universal time (UTC) sent by the network time protocol server (NTPServer);

[0093] The first high-fidelity interface (Hif0) is used to respond to the request of the system and service manager (Systemd), send the current timestamp of the packet forwarding engine (PFE) to the system and service manager (Systemd), and communicate with the Ethernet interface (Ethif) of the base core (M core) to synchronize the coordinated universal time (UTC) or the calibrated system time of the non-base core (A core) to the in-vehicle Ethernet time synchronization slave module (EthTsyncSlave);

[0094] The second high-fidelity interface (Hif1) is used to communicate with the Ethernet interface (Ethif) of the non-base core (A core) and receive the coordinated universal time (UTC) or the calibrated system time of the non-base core (A core) sent by the in-vehicle Ethernet time synchronization master module (EthTsyncMaster).

[0095] Specifically, the time synchronization link between the non-base cores (A cores) of the base core (M core) in this embodiment is as Figure 3 shown and includes the following two stages:

[0096] In the domain controller startup initialization stage, the inter-core time synchronization is as shown in steps (1) to (7) of Figure 2 and is as follows:

[0097] During the normal operation phase of the domain controller, the inter-core time synchronization is as shown in steps (8) to (16) of Figure 2 and is shown in steps (8) to (16) of

[0098] Through the time synchronization link process of steps (1) to (7), during the normal operation phase of the domain controller, the non-reference core of core A serves as the master clock module of the heterogeneous multi-core, calibrating the external standard universal time (UTC) for the domain controller to ensure the accuracy of the domain controller time. And steps (8) to (16) perform time synchronization through the Gptp protocol cycle, ensuring precise time consistency within the domain controller.

[0099] In summary, for the problems of time synchronization delay in the startup initialization process stage and insufficient stability of the time synchronization link in the normal operation stage of the current domain controller's multi-core heterogeneous clock synchronization, the multi-core heterogeneous domain controller of this embodiment is based on different time synchronization logic strategies corresponding to different startup stages, uses the EMAC port and Hif port of the packet forwarding engine (PFE) to process the timestamp assignment of the startup timing and configure isolation for the GPTP protocol packets, combines the actual possible failure factors, constructs a multi-core heterogeneous time synchronization architecture and countermeasure solution within the domain, and provides a highly efficient, high-precision, and highly reliable time synchronization link between the basic core (M core) and the non-basic core (A core).

[0100] Another embodiment of the present application further provides a multi-core heterogeneous domain controller, including:

[0101] A memory for storing computer program instructions;

[0102] A processor for executing the computer program instructions to support the multi-core heterogeneous domain controller to implement the method according to the above embodiment.

[0103] In this embodiment, the memory mainly includes a program storage area and a data storage area. Among them, the program storage area can store operating devices, application programs required for at least one function, etc., and the data storage area can store related data, etc. In addition, the memory can be a high-speed random access memory, or a non-volatile memory, such as a plug-in hard disk, a smart media card (SMC), a secure digital (SD) card, a flash card, etc., or the memory can also be other volatile solid-state storage devices.

[0104] Another embodiment of the present application further provides a computer program product, including computer program instructions, and the computer program instructions direct a computer device to perform operations corresponding to the method described in the above embodiment.

[0105] Specifically, the computer program product includes a series of computer program instructions, which are codes written in the computer program and define how to perform specific operations. In this embodiment, these instructions are used to execute the methods of the above embodiments. These program instructions are designed to be loaded onto a computer device and guide the device to perform specific operations. In this way, the computer program product provides a complete software solution that can run on various computer devices and implement the methods of the above embodiments.

[0106] The embodiments of the present application have been described above. The above description is exemplary and not exhaustive, and is not limited to the disclosed embodiments. Many modifications and variations are obvious to those of ordinary skill in the art without departing from the scope and spirit of the described embodiments. The selection of the terms used herein is intended to best explain the principles of the embodiments, the practical application, or the improvement of the technology in the market, or to enable other ordinary skilled persons in the art to understand the disclosed embodiments.

Claims

1. A method for inter-core time synchronization of a multi-core heterogeneous domain controller, characterized in that: The multi-core heterogeneous domain controller includes a basic core, a packet forwarding engine and at least one non-basic core; The method comprises: In the domain controller startup initialization phase, the basic core starts and obtains a local timestamp of the real-time clock, sets the local timestamp as the system initial time of the basic core, and sends the local timestamp to the data packet forwarding engine; The data packet forwarding engine uses the local timestamp as a reference time for timing; The non-basic core starts and obtains the current timestamp of the data packet forwarding engine timing, and sets the system initial time of the non-basic core according to the current timestamp to achieve time synchronization between the non-basic core and the basic core during the domain controller startup initialization phase.

2. The method according to claim 1, characterized in that The basic core includes a real-time clock driver, a time management module, a system time base management module and a complex device driver; In the domain controller startup initialization phase, the basic core starts and obtains the local timestamp of the real-time clock, sets the local timestamp as the system initial time of the basic core, and sends the local timestamp to the data packet forwarding engine, including: The time management module calls the real-time clock driver to obtain the local timestamp of the real-time clock timing, and sends it to the system time base management module; The system time base management module sets the local timestamp as the system initial time of the basic core; The complex device driver calls the real-time clock driver to obtain a local timestamp of the real-time clock timing, and sends the local timestamp to the data packet forwarding engine.

3. The method according to claim 2, characterized in that The non-basic core includes a system clock API interface and a system and service manager; The method further comprises: During the domain controller startup initialization phase, the system and service manager obtains the current timestamp of the packet forwarding engine timing, determines the system initial time of the non-basic core based on the current timestamp, and calls the system clock API interface to set the system initial time of the non-basic core.

4. The method according to claim 3, characterized in that The system and service manager obtains a current timestamp of the data packet forwarding engine timing, and determines the system initial time of the non-basic core according to the current timestamp, including: The system and service manager obtains the current timestamp of the data packet forwarding engine at a preset time interval, and determines the system initial time of the non-basic core according to the current timestamps obtained the preset number of times.

5. A multi-core heterogeneous domain controller, characterized in that: include: Real-time clock, used for timing of local timestamps; The basic core is used to obtain the local timestamp of the real-time clock timing during the initialization phase of the domain controller startup, set the local timestamp as the system initial time of the basic core, and send the local timestamp to the data packet forwarding engine; A data packet forwarding engine, used for forwarding data packets and timing based on the local timestamp as a reference time; At least one non-basic core is used to obtain the current timestamp of the data packet forwarding engine timing during the initialization phase when the domain controller is started, and set the system initial time of the non-basic core according to the current timestamp to achieve time synchronization between the non-basic core and the basic core during the initialization phase when the domain controller is started.

6. The multi-core heterogeneous domain controller according to claim 5, characterized in that: The basic core includes: A real-time clock driver, used for managing the real-time clock; A time management module, used for calling the real-time clock driver to obtain the local timestamp of the real-time clock timing, and sending it to the system time base management module; A system time base management module, used to set the local timestamp to the system initial time of the basic core; The complex device driver is used to call the real-time clock driver to obtain the local timestamp of the real-time clock timing, and send the local timestamp to the data packet forwarding engine.

7. The multi-core heterogeneous domain controller according to claim 6, characterized in that: The non-basic cores include: System clock API interface, used to set the system initial time of the non-basic core; The system and service manager is used to obtain the current timestamp of the packet forwarding engine timing during the initialization phase of the domain controller startup, determine the system initial time of the non-basic core based on the current timestamp, and call the system clock API interface to set the system initial time of the non-basic core.

8. The multi-core heterogeneous domain controller according to claim 7, characterized in that: The system and service manager is used to obtain the current timestamp of the data packet forwarding engine timing every preset time, and determine the system initial time of the non-basic core according to the current timestamps obtained the preset number of times.

9. A multi-core heterogeneous domain controller, characterized in that: include: a memory for storing computer program instructions; A processor, configured to execute the computer program instructions to support the multi-core heterogeneous domain controller to implement the method according to any one of claims 1 to 4.

10. A computer program product, characterized in that The method comprises computer program instructions, wherein the computer program instructions instruct a computer device to execute operations corresponding to the method according to any one of claims 1 to 4.

Images