AN 739: Altera 1588 System Solution

Download PDF
ID 683410
Date 1/28/2016
Public
Document Table of Contents
Document Table of Contents x
1. Altera 1588 System Solution
1. Altera 1588 System Solution x
1.1. Altera 1588 System Level Overview 1.2. Precision Time Protocol (PTP) Concept in A 1588 System 1.3. Reference Design Walk-through 1.4. System Architecture 1.5. Altera 1588 System Solution Document Revision History
1.2. Precision Time Protocol (PTP) Concept in A 1588 System x
1.2.1. Understanding the Different PTP Clocks 1.2.2. Precision Time Protocol (PTP) Synchronization Process 1.2.3. Functional Flow For A 1588 Ordinary Clock Master/Slave Mode System 1.2.4. Functional Flow For A 1588 Transparent Clock Master/Slave Mode System 1.2.5. Functional Flow for A 1588 Boundary Clock Mode System 1.2.6. Timestamp Packet Functional Flow in Linux Driver
1.3. Reference Design Walk-through x
1.3.1. System Requirements 1.3.2. Reference Design User Guide
1.3.2. Reference Design User Guide x
1.3.2.1. Hardware Setup 1.3.2.2. Executing The Reference Design 1.3.2.3. Replacing RBF File
1.3.2.1. Hardware Setup x
1.3.2.1.1. Loading the Boot Image into SD Card 1.3.2.1.2. Setting Up Development Kit 1.3.2.1.3. Booting Up The Reference Design
1.4. System Architecture x
1.4.1. System Modules 1.4.2. Clocking and Reset Scheme 1.4.3. System Parameters 1.4.4. System Register Map 1.4.5. Interface Signals
1.4.1. System Modules x
1.4.1.1. MAC 1.4.1.2. Time of Day (ToD) 1.4.1.3. Packet Parser 1.4.1.4. The Central Processing Unit (CPU) 1.4.1.5. FIFO
1.4.4. System Register Map x
1.4.4.1. MAC Registers 1.4.4.2. Transceiver Registers 1.4.4.3. PTP Control Registers 1.4.4.4. 1588 ToD Clock Registers
1.4.5. Interface Signals x
1.4.5.1. Clock and Reset Signals 1.4.5.2. PHY Interface Signals 1.4.5.3. HPS Signals
1. Altera 1588 System Solution

1.2.3. Functional Flow For A 1588 Ordinary Clock Master/Slave Mode System

The following figure illustrates the functional flow for Altera 1588 reference design system with Altera’s Ethernet 1588 configured as ordinary clock (OC) master and slave clocks. In this flow, the CPU refers to the Linux PTP software stack and the PTP driver interacting with the stack.
Figure 5. Functional Flow For 1588 Ordinary Clock in Master & Slave Mode
  1. The CPU acting as an OC-master sends a Sync packet to the network via its user logic.
  2. The packet parser block extracts the fingerprint (an ID for the PTP packet) after decoding the PTP packet and sends the fingerprint to MAC Tx along with the packet.
  3. For 1-step mechanism, the 1588 logic generates a timestamp T1 for the Sync packet before sending it to the PHY. This reference design provides the option to enable timestamping for every packet to integrate with LinuxPTP. However, the design can be changed to only timestamp PTP packets.
  4. For 2-step mechanism, the transmitting MAC generates the timestamp T1 before sending the Sync packet to the PHY and stores the timestamp T1 along with its fingerprint in the FIFO. 1
  5. The OC-master checks if there is a valid entry in the FIFO via interrupt or polling mechanism. It then reads the entry from the FIFO to collect the timestamp T1 and the fingerprint. The dotted arrows in OC-master indicate the blocks involved in 2-step mechanism. 1
  6. The CPU then sends a Follow-up message with timestamp T1, which refers to the Sync packet sent in step 1.1
  7. The FPGA hosting the OC-slave clock receives the Sync packet and the receiving MAC generates the timestamp T2.
  8. The packet parser stores the corresponding timestamp T2 and the fingerprint in the FIFO. You can design a packet parser which can validates the incoming packet as a PTP packet and stores the timestamp T2 along with its fingerprint in the RX FIFO, ignoring the timestamps for the non-PTP packets.
  9. The CPU receives the Sync packet via user logic and collects timestamp T1 from the received packet.2
  10. In 2-step mechanism, the CPU acting as the OC-slave collects timestamp T1 from the Follow-up message sent in step 6.
  11. The CPU then reads the FIFO to collect the fingerprint and the timestamp T2.
  12. The CPU acting as the OC-slave sends Delay_Req packet via its user logic.
  13. The packet parser block after decoding the PTP packet extracts the fingerprint and sends it to the MAC block along with the packet.
  14. The MAC Tx of the OC-slave clock generates timestamp T3 before sending the packet to the PHY and stores the timestamp along with its fingerprint in the FIFO.
  15. The CPU acting as the OC-slave reads the FIFO to obtain the timestamp T3.
  16. The FPGA hosting the OC-master clock receives the Delay_Req packet and the receiving MAC generates the timestamp T4.
  17. The packet parser stores the corresponding timestamp T4 and the fingerprint in the FIFO.
  18. The CPU acting as the OC-master receives the PTP packet via user logic and reads the FIFO to collect the fingerprint and timestamp T4.
  19. Next, the CPU sends a Delay_Response packet containing timestamp T4 via its user logic.
  20. The MAC Tx of the OC-master timestamps the Delay_Response packet but the software stack will ignore the timestamp. You can design a packet parser to instruct the MAC to not generate a timestamp for the Delay_Response packet, which already contain the timestamp T4, after decoding the PTP packet.
  21. The MAC Tx of the OC-master sends the Delay_Response packet as it is.
  22. The FPGA hosting the OC-slave clock receives the Delay_Response packet.
  23. The receiving MAC timestamps the Delay_Response packet and stores it in the FIFO. The CPU reads the FIFO but the timestamp collected through the FIFO read is ignored by the software stack. You can design a packet parser block which able to identify Delay_Response packet type and sends the packet further to the user logic ignoring its timestamp.
  24. The CPU receives Delay_Response packet via user logic and collects the timestamp T4 from the packet.
  25. At this point, the stack in the OC-slave has all the timestamps T1, T2, T3, & T4 from which the mean path delay (MPD) is calculated.
  26. The OC-slave collects the timestamps T5 & T6 after receiving the next Sync packet, and calculates the ToD offset as described in Precision Time Protocol (PTP) Synchronization Process.
  27. Next, with the time difference between two successive Sync packets, the stack in the OC-slave calculates the frequency offset as described in Precision Time Protocol (PTP) Synchronization Process.
  28. The stack residing in the OC-slave CPU supplies the calculated ToD offset and frequency offset to Servo algorithm, which can either adjust the PLL settings supplying the PTP clock to the ToD or program the registers in the 1588 IP to synchronize the slave’s ToD with master’s ToD.
  29. Step 1 to step 24 is repeated continuously to adjust the settings for slave’s ToD with the calculated ToD and frequency offset.
  30. The PPS pulse outputs from the OC-master and the OC-slave can be observed in an oscilloscope to appreciate the efficacy of synchronization process.

The correction field in the PTP header may be updated in any of the above mentioned PTP packets for any fractional arithmetic residue or asymmetry.

1 This flow is only applicable in a 2-step mechanism.
2 This flow is only applicable in a 1-step mechanism.
Level Two Title