DESC:FORM-2
THE PATENTS ACT, 1970
(39 of 1970)
&
THE PATENTS RULES, 2003
COMPLETE SPECIFICATION
(See section 10 and rule 13)

Title: METHOD FOR LINUX KERNEL SPACE BASED PHC CLOCK SYNCHRONIZATION FROM SATELLITE CLOCK WITH FPGA/HARDWARE SUPPORT

APPLICANT DETAILS:
(a) NAME: Bharat Electronics Limited
(b) NATIONALITY: Indian
(c) ADDRESS: Outer Ring Road, Nagavara, Bangalore - 560045 Karnataka, India

PREAMBLE TO THE DESCRIPTION:
The following specification (particularly) describes the nature of the invention (and the manner in which it is to be performed):
METHOD FOR LINUX KERNEL SPACE BASED PHC CLOCK SYNCHRONIZATION FROM SATELLITE CLOCK WITH FPGA/HARDWARE SUPPORT

FIELD OF INVENTION:
The present disclosure relates generally to time synchronization.

BACKGROUND OF THE INVENTION:
The following background discussion includes information that may be useful in understanding the present invention. It is not an admission that any of the information provided herein is prior art or relevant to the presently claimed invention, or that any publication expressly or implicitly
In the context of the Linux kernel, context refers to the state of execution of a process or thread at a specific point in time. There are three main types of contexts in the Linux kernel: user context, kernel context, and interrupt context.
User Context: This is the context in which regular user-space applications run. User context is characterized by code executing in user mode, where applications perform their tasks. User context is associated with processes or threads running in user space.
Kernel Context: When a process or thread transitions from user space to kernel space, it enters kernel context. Kernel context is characterized by code executing in kernel mode, where the operating system's kernel performs privileged operations. Kernel context is entered when a system call is made, or an exception occurs that requires kernel intervention.
Interrupt Context: Interrupt context is a special type of kernel context that is invoked in response to hardware or software interrupts. When an interrupt occurs, the processor interrupts the currently executing code to handle the interrupt. Interrupt context is more constrained than regular kernel context to ensure quick and efficient handling of the interrupt. It is crucial for interrupt handlers to execute quickly and avoid operations that might cause deadlocks or prolonged delays.
The differences between preemptive and non-preemptive (also known as cooperative or voluntary) kernels:
Preemptive Kernel: In a preemptive kernel, the kernel has the ability to preempt or forcibly interrupt a running task to allow another task to run. Preemption allows the operating system to switch between tasks even if the currently running task has not voluntarily given up control. Preemptive kernels are designed to handle multitasking more effectively, allowing the system to respond quickly to external events and prioritize tasks based on their priority levels.
Non-Preemptive Kernel: In a non-preemptive kernel, also known as a cooperative or voluntary kernel, a running task continues to execute until it explicitly relinquishes control or enters a state where it can be preempted. Task switches in a non-preemptive kernel rely on tasks yielding control voluntarily, such as through system calls, task sleep, or explicit yield operations. This model requires tasks to cooperate and not monopolize the CPU for long periods, as the kernel relies on their cooperation to switch between tasks.
In the Linux kernel, spinlocks are used for synchronization to protect critical sections of code from concurrent access by multiple processes or threads.
The three functions mentioned are spin_lock, spin_lock_irq, and spin_lock_irq_save are variations of spinlocks with different levels of interrupt handling.
"spin_lock" is used to protect a critical section without considering interrupt handling.
"spin_lock_irq" is used when, critical section can be preempted by interrupt handlers, and you want to disable local interrupts.
"spin_lock_irq_save" is used to disable local interrupts and save the current interrupt state, restoring it later after the critical section is executed.
Rubidium oscillators play a vital role in time synchronization systems due to their high long-term stability and accuracy.
Time synchronization is essential in various applications, such as navigation systems, telecommunications, and computer networks, where precise coordination of events is required. Rubidium oscillators contribute to time synchronization in following ways:
Stability and Accuracy: Rubidium oscillators provide excellent long-term stability, meaning they generate highly accurate frequency outputs for long periods. This stability is vital for maintaining accurate timekeeping in synchronization systems.
Primary Frequency Reference: In time synchronization systems, rubidium oscillators often serve as primary frequency references, across networked devices.
Clock Distribution: In PTP Grandmaster time synchronization architectures, rubidium oscillators once synced with a GNSS constellation act as master clocks, providing a stable time reference to synchronize other clocks in the system. The accurate timekeeping signal generated by the rubidium oscillator is distributed to various nodes within a network or system, serving as cost-effective and high-stability backup to cesium or GNSS references.
In IEEE paper namely “Time Synchronization Services for Low-Cost Fog Computing Applications (2017, international symposium on Rapid System prototyping)” is based on an accurate clock source (a GPS receiver) on, at least, one of the network nodes, the Precision Time Protocol for clock distribution, and a local daemon process that adjusts the system clock of the nodes. Such a synchronized time base allows for precise time triggered activation of tasks that are required in distributed, real-time embedded systems. The present disclosure describes a different approach, wherein modification to the fast Interrupt handler in the Linux Kernel is done, and a new clock handle is created. “NTP daemon synchronization” from GPIO-PPS to system clock is leveraged and (Seconds, nano seconds) are directly written in to the PHC clock of the Ethernet Chip.
In IEEE paper namely “Hardware Assisted CoTS IEEE 1588 solution for x86 Linux and its performance solution (2013, IEEE symposium on precision Clock Synchronization for measurement, control and communication, ISCPS)”. The 1PSS signal generated by GPS receiver/extender hardware is directly fed to “Software defined Pin” available in a specialized NIC card, the clock in such card is made “Master Clock”. However, the approach described herein involves the modification of the fast Interrupt handler code and copying seconds and nanoseconds information from GPS synchronized system clock to PHC clock registers of the PHY chip.
In patent namely “Display synchronization for time sensitive networking (US 2023/0262281 A1)”, the display network sync mechanisms synchronize multiple display systems via network. In each Display system, “Display clock” is tightly coupled with 1PPS from NIC card, all the time stamping of the frames exchanged between the systems is done by the PHC clock in the NIC card. “Vertical synchronization signal timer” connected to the Display Clock monitor circuitry is used to apply correction values to “Display clock”. In the present disclosure, the fundamental time source is a GNSS chip combined with an oscillator module. The Oscillator provides the 1PPS, where in NMEA is provided by the GNSS ship, i.e. routed to SoC. From thereon, modification to fast IRQ handler is done to achieve the synchronization between GNSS clock and PHC clock.

OBJECTIVES OF THE INVENTION:
The primary objective of the present invention is to overcome the problems stated in the prior art.
Another objective of the present invention is to provide a method for Linux Kernel Space based PHC clock synchronization from satellite clock with FPGA/hardware Support.

SUMMARY OF THE INVENTION:
The present invention provides a unique method for time stamping PTP Ethernet Packets in a SoC_FPGA hardware, while in operation, comprising steps of:
a) executing a mechanism in Linux Kernel that maintains the seconds/nano seconds to fill up in PTP packet;
b) maintaining time counters in the linux kernel, for the seconds counter and nano seconds fields;
c) updating seconds counter and resetting nanosecond counter, in to PHC clock of PHY hardware from Linux Kernel; and
d) time stamping the PTP packet, while transmitting/ receiving from PTP Ethernet Packets, to achieve both Rx/Tx Hardware Time stamping and Satellite Clock synchronization, at PHY hardware.
In an embodiment, the Hardware architecture specimen connecting GPIO driver interrupt handler with GPIO.
In an embodiment, the mechanism to modify GPIO- PPS driver comprising steps:
a. inserting code into “IRQ interrupt handler”, wherein modification is done inside the top half of the GPIO-PPS driver;
b. registering a clock handle inside the top half of the driver and start executing the critical section; and
c. retrieving Seconds and nanoseconds information from the, GPS synchronized system clock.
In an embodiment, the hardware mechanism facilitated via FPGA with GPIO pin to update PHC clock from RTC clock.
In an embodiment, the method of modifying Linux kernel to interpret 1PPS signal from FPGA hardware, on rising edge as indication to update Time counters in PHY chip and a mechanism to handle it in GPIO-PPS Hardware Interrupt handler.

DETAILED DESCRIPTION OF DRAWINGS:
To further clarify advantages and features of the present invention, a more particular description of the invention will be rendered by reference to specific embodiments thereof, which is illustrated in the appended drawings. It is appreciated that these drawings depict only typical embodiments of the invention and are therefore not to be considered limiting of their scope. The invention will be described and explained with additional specificity and detail with the accompanying drawings in which:
Fig. 1: illustrates FPGA- SoC architecture for Linux kernel based PHC time stamping.
Fig. 2: illustrates Linux-driver Top half/ Bottom half.
Fig. 3: illustrates a flow chart for flow of “GPIO-PPS-IRQ handler to PHC Clock Time stamping”.
Fig. 4: illustrates a flow chart for “GNSS clock to RTC clock synchronization.

DETAILED DESCRIPTION:
For the purpose of promoting an understanding of the principles of the invention, reference will now be made to the embodiment illustrated in the drawings and specific language will be used to describe the same. It will nevertheless be understood that no limitation of the scope of the invention is thereby intended, such alterations and further modifications in the illustrated system, and such further applications of the principles of the invention as illustrated therein being contemplated as would normally occur to one skilled in the art to which the invention relates.
It will be understood by those skilled in the art that the foregoing general description and the following detailed description are exemplary and explanatory of the invention and are not intended to be restrictive thereof.
The terms “comprises”, “comprising”, “includes”, or any other variations thereof, are intended to cover a non-exclusive inclusion, such that a setup, device or method that comprises a list of components or steps does not include only those components or steps but may include other components or steps not expressly listed or inherent to such setup or device or method. In other words, one or more elements in a system or apparatus proceeded by “comprises... a” does not, without more constraints, preclude the existence of other elements or additional elements in the system or method.
The present disclosure proposes a method, wherein “PHC clock” of the Ethernet Chip is synchronized with the satellite clock via kernel space. The method is implemented on a SOC-FPGA platform wherein, a GNSS module provides 1PPS and a NMEA to FPGA hardware of SOC. The Linux kernel, on ARM processor of SoC continuously monitors the 1PPS signal sent from FPGA hardware using interrupt handler and directly copies the “Time of the day” information to PHC clock of the Ethernet Chip, from interrupt context in kernel space directly. As PHC clock accuracy is directly proportional to PTP protocol accuracy, this leads to better implementation of PTP4L application using Linux OS on Zynq SoC.
In an embodiment, the present disclosure proposes to provide a system that can execute the algorithm in soft core processor and an FPGA hardware, from an external portable media.
In an embodiment, the present disclosure proposes to design and development of method for hardware time-stamping of PTP packets in Zynq SoC comprising of a) an FPGA for providing PPS signal from GNSS card to ARM core; and b) Arm core with Linux OS for setting PHY timestamp using PPS from FPGA.
In an embodiment, a method for maintaining Time counters in the Linux kernel, for the Seconds counter and nano seconds fields and updating seconds/nanoseconds counter in PHC clock of PHY hardware. A method to insert code into “IRQ interrupt handler”, wherein modification is done inside the top half of the GPIO-PPS driver. A method to register clock handles inside the top half of the PTP clock driver. The method to retrieve Seconds and nanoseconds information from the GPS synchronized system clock at rising edge of 1PPS signal from FPGA hardware and update Time counters in PHY chip.
In an embodiment, the present disclosure describes, FPGA-SoC architecture as illustrated in figure 1. The FPGA 1PPS and NMEA are coming as inputs into ARM SoC. These inputs are fed to different components of SoC, operating in both user space and kernel space. NTPD takes 1PPS and NMEA as inputs. GPIO-PPS driver interprets 1PPS as trigger and controls the PHC clock inside the PHY chip.
In an embodiment, GPIO-PPS diver modification: the present disclosure relates to the time synchronization, where in 1PPS signal, from FPGA is directly interpreted by PPS driver in the Linux kernel.
GPIO-PPS driver is modified in Linux kernel. As Linux is a monolithic kernel, the modification to driver is recompiled as a kernel patch. The PPS pulse interpretation is now done in the “Interrupt Context”, which is having the lowest level of latency as compared to the “Kernel Context” and “User Context”.
Interrupt handlers implementation is divided in to top half and bottom half. Top half is scheduled immediately by Linux kernel on CPU and bottom half can be scheduled as per logic of scheduling algorithm. The entire mechanism is explained in Diagram 2. The modification of code in this disclosure is in top half of the gps-ppio driver, where in “execution latency” of the code is minimal.
GPS-NTP-System clock synchronization: NTP server is installed on Linux to provide NTP services over Ethernet which is connected on PS side. GNSS chip module is used to receive NMEA data and 1 PPS.
From GNSS. Following steps are followed for time and PPS synchronization:
GNSS chip module provide 1 PPS out and NMEA data out (Serial Port);
GNSS chip 1 PPS given as input to FPGA is sent to ARM Via AXI_GPIO;
GNSS chip NMEA serial data is given as input to FPGA is sent to ARM Via AXI_UART;
NTP server installed on Linux is given NMEA and 1PPS input, which continuously synchronizes the system clock.
GPIO-PPS driver PHC clock (in Ethernet chip) time stamping: In top half of the driver, new “PTP clock handle” is registered for the PHC clock inside the Ethernet chip. From here on, all other operations are implemented as critical sections, as guarded by “Spin_lock” functions. While in the critical section, the processor can’t be pre-empted as Linux scheduler is temporarily switched off.
While in critical section, time from already synchronized GPS-NTP- system clock is retrieved, converted in to seconds and nano seconds format and written in to PHC clock of Ethernet. The above time stamping process is done for occurrence of rising edge of every pulse per second. PTP4l module can be configured as Master and is directed to use PHC clock, as shown in figure 1 and figure 3.
In an embodiment, the present disclosure proposes a method that allows the hardware time stamping in a unique way in SoC_FPGA hardware, while in operation to produce a PTP packet During execution, a mechanism in Linux Kernel that maintains the seconds/nano seconds and fill up in PTP packet.
The method of maintaining Time counters in the Linux kernel, for the Seconds counter and nano seconds fields.
The method of updating seconds counter and resetting nanosecond counter, in to PHC clock of PHY hardware.
The method of Time stamping the PTP packet, while transmitting/ receiving from PTP code, to achieve both Rx/Tx Hardware Time stamping and Satellite Clock synchronization, at PHY hardware.
In yet another embodiment, the present disclosure proposes, a hardware architecture specimen connecting GPIO driver interrupt handler with GPIO. During execution, a mechanism to modify GPIO- PPS driver.
The method to insert code into “IRQ interrupt handler”, wherein modification is done inside the top half of the GPIO-PPS driver.
The method is to register a clock handle inside the top half of the driver and start executing the critical section.
The method to retrieve Seconds and nanoseconds information from the, GPS synchronized system clock, is described herein below:
During execution, a hardware mechanism facilitated via FPGA with GPIO pin to update PHC clock from RTC clock.
A method of modifying Linux kernel to interpret 1PPS signal from FPGA hardware, on rising edge as indication to update Time counters in PHY chip and a mechanism to handle it in GPIO-PPS Hardware Interrupt handler.
The foregoing description of the invention has been set merely to illustrate the invention and is not intended to be limiting. Since modifications of the disclosed embodiments incorporating the substance of the invention may occur to person skilled in the art, the invention should be construed to include everything within the scope of the invention.
,CLAIMS:We Claim:

1. A method for hardware time-stamping in a SoC_FPGA hardware, while in operation to produce a PTP packet, comprising steps of:
a) executing a mechanism in Linux Kernel that maintains the seconds/nano seconds to fill up in PTP Ethernet packets;
b) maintaining time counters in the linux kernel, for the seconds counter and nano seconds fields;
c) updating seconds counter and resetting nanosecond counter, in to PHC clock of PHY hardware; and
d) time stamping the PTP packet, while transmitting/ receiving from PTP code, to achieve both Rx/Tx Hardware Time stamping and Satellite Clock synchronization, at PHY hardware.
2. The method for stamping hardware in a SoC_FPGA hardware as claimed in claim 1, comprises a Hardware architecture specimen connecting GPIO driver interrupt handler with GPIO.
3. The method for hardware time-stamping in a SoC_FPGA hardware as claimed in claim 1, comprises a mechanism to modify GPIO- PPS driver comprising steps:
a. inserting code into “IRQ interrupt handler”, wherein modification is done inside the top half of the GPIO-PPS driver;
b. registering a clock handle inside the top half of the driver and start executing critical section; and
c. retrieving Seconds and nanoseconds information from the, GPS synchronized system clock.
4. The method for hardware time-stamping in a SoC_FPGA hardware as claimed in claim 1, wherein a hardware mechanism facilitated via FPGA with GPIO pin to update PHC clock from RTC clock.

5. The method for hardware time-stamping in a SoC_FPGA hardware as claimed in claim 1, wherein a method of modifying Linux kernel to interpret 1PPS signal from FPGA hardware, on rising edge as indication to update Time counters in PHY chip and a mechanism to handle it in GPIO-PPS Hardware Interrupt handler.