Zynq-7000 AP SoC - Precision Timing with IEEE1588 v2 Protocol Tech Tip

Table of Contents

Document History

Summary

Implementation

Block Diagram

Step by Step Instructions

Expected Results

How to Expand

Appendix A: IEEE 1588v2 PTP Overview

Document History

The IEEE 1588 standard describes the protocol which synchronizes the system clocks of the different connected devices. Nanosecond level clock synchronization among connected devices is one of the primary requirements for many applications in automation, motion control, consumer electronics, Audio Video broadcasting (AVB) and telecommunications market segments. Achieving this timing requirement requires robust, responsive and error-free design and implementations in both software and hardware design.


Zynq-7000 AP SoC has inbuilt hardware support for the IEEE1588v2 Precision Time Protocol (PTP) time stamping for the Gigabit Ethernet MACs (GEM). The GEM in Zynq has support for detecting PTP messages, seconds’ counters, nanoseconds counters and registers for PTP specific configuration like the interrupts support for PTP messages etc. to meet all the hardware assisted time stamping requirements of the PTP. Zynq-7000 AP SoC has two hardened Time Stamping Units (TSUs) for both the GEMs in Processing System. These two TSUs will work independently to each other. Refer to sections 16.2.7 IEEE1588 Time stamping unit and 16.4 IEEE1588 Time stamping in Zynq Technical Reference Manual (TRM) for more details on the PTP TSUs in Zynq-7000 AP SoC.

This TechTip covers the following topics:

1. Details of IEEE1588 PTP Reference design using the Zynq-7000 AP SoC

2. Open Source Linux API support for PTP and kernel configuration

3. Linux implementation of IEEE1588 PTP (LinuxPTP)

4. Steps to create the Zynq-7000 AP SoC PS GEM with TSU design using the Vivado design tool

5. Creating the First Stage Boot Loader (FSBL), boot.bin files for the Zynq design created in above step

6. Linux kernel driver changes specific to this design and Using the SDK for building the LinuxPTP applications

7. Running the PTP time stamping & synchronization on two Zynq-7000 AP SoC boards: One is acting as PTP master and other will be acting as PTP slave

8. Expected results & How to expand the design

Implementation

Block Diagram

This Techtip explains the architecture and implementation details of the PTP solution using the Zynq AP SoC. The PTP uses the UDP/IP packet based time stamp message exchange mechanism to achieve the time synchronization among connected devices. The time stamp messaging can be achieved using the software timers and hardware assisted time stamping. Hardware timer assisted time stamping is more accurate than a software timer based solution. Zynq 7000 AP SoC has got the hardware time stamping units in GEMs to use for the PTP time stamping requirements. The Figure 1 highlights the interfaces and sub-systems of Zynq used in this techtip for demonstrating IEEE1588 PTP solution using the Zynq AP SoC.

This techtip design example uses the two Zynq boards to demonstrate the time synchronization:

1. One Zynq board will be acting as a PTP master device which will be referenced as a PTP master clock device, in PTP terms best master clock/Ordinary clock

2. The other Zynq board will be acting as PTP slave device which will be synchronizing its clock to reference master clock using the PTP event message exchanges.

The Figure 2 illustrates the basics PTP protocol messages flow chart:

Delay & offset are calculated based on:
Delay = [ (t2-t1) + (t4-t3) ] / 2;
Offset = [ (t2-t1) - (t4-t3) ] / 2;
PTP slave device will be adjusting its frequency and time based on offset calculated and will be in synchronous with the master device clock.
PTP slave and master time synchronization makes sure the TSU’s seconds counter and nano seconds counters/registers are in synch. If the application requires the system clocks to be at synchronization then TSU’s counters are to be synchronized to the system clock source like RTC etc. The following sections will explain in details how to achieve this.
The Figure 3 shows the software layers used in this techtip demo design

The Open source Linux kernel v3.10 onwards has updated inbuilt kernel level APIs support for the PTP in the form of PTP class driver for both software timers and hardware timer based time stamping. The Linux PTP framework uses the time stamping unit in Zynq GEMs through the Linux Ethernet GEM drivers. To support the time stamping in GEM the following APIs are implemented in the GEM kernel drivers.

1. ptp_adjfreq(): Adjust the frequency of the hardware clock with desired frequency offset from normal frequency in parts per billion (PPB).

2. ptp_adjtime(): Adjust the timer counter with desired change in nanoseconds

3. ptp_gettime(): Read the current time from the hardware clock

4. ptp_settime(): Sets the current time on the hardware clock

5. ptp_enable()

For more details on Linux PTP framework and implementation refer: http://linuxptp.sourceforge.net/


LinuxPTP provides the four user applications. The definition and usage of these applications

1. ptp4l application: It is an implementation of the Precision Time Protocol (PTP) according to IEEE standard 1588 for Linux. It implements Boundary Clock (BC) and Ordinary Clock (OC). This application is used to synchronize the TSUs in both master and slave Zynq devices at nanoseconds granularity.

2. phc2sys application: It is a program which synchronizes two clocks in the system i.e RTC etc. Typically, it is used to synchronize the system clock to a PTP hardware clock (PHC)/TSU time stamps, which itself is synchronized by the ptp4l program/application. Two synchronization modes are supported, one uses a pulse per second (PPS) signal provided by the source clock and the other mode reads time from the source clock directly. The PPS mode is usually preferred, because reading the PHC is slow and introduces an unknown error in the readings, but not all PHCs provide the PPS signal

3. hwstamp_ctl application: It is a program used to set the hardware time stamping policy at the network driver level with the SIOCSHWTSTAMP ioctl. The tx-type and rx-filter values are hints to the driver what it is expected to do. If the requested fine-grained filtering for incoming packets is not supported, the driver may time stamp more than just the requested types of packets. This program is a debugging tool. The ptp4l program does not need this program to function; it will set the policy automatically as appropriate

4. PMC (PTP Management Client) application: It is a program which implements a PTP management client according to IEEE standard 1588. The program reads from the standard input actions specified by name and management ID, sends them over the selected transport and prints any received replies. There are three actions supported: GET retrieves the specified information, SET updates the specified information and CMD (or COMMAND) initiates the specified event.

Step by Step Instructions

List all the steps to run the design. This includes hardware, software and tools needed.

1. Launch Vivado IDE Design Tool: Vivado 2013.4
   On Windows 7, select Start > All Programs > Xilinx Design Tools > Vivado 2013.4 > Vivado 2013.4
   On Linux, enter Vivado at the command prompt.
   

2. Select “Create New Project” in launch window as shown in Figure 4 and new Vivado project wizard will open

3. In the Project Name dialog box, type the project name (e.g. ZynqIEEE1588_PS_GEM) and location. Ensure that Create project subdirectory is checked, and then click Next.

4. In the Project Type dialog box, select RTL Project and ensure that Don’t specify the sources at this time is checked then click Next.

5. In the Default Part dialog box select Boards and choose ZYNQ-7 ZC702 Evaluation Board or ZYNQ-7 ZC706 Evaluation Board. Make sure that you have selected the proper Board Version to match your hardware because multiple versions of hardware are supported in the Vivado IDE. Click Next.

6. Review the project summary in the New Project Summary dialog box before clicking Finish to create the project. Project summary window similar to Figure 5 will be opened
   

7. In the Project Manager wizard under IP Integrator select Create Block Design, enter the design name or leave default (design_1) in the Please specify name of the block design pop-up window and select ok

8. In the desing_1 drawing view select Add IP as shown in Figure 6 and select Zynq7 Processing System in the next pop-up search window
   

9. Select Run Block Automation and /processing_system7_0 as shown in Figure 7
   

10. In next pop-up Run Block automation make sure that apply board preset is checked and select ok

11. In next window select and connect the clock inputs as shown in Figure 8
    

12. Click on Generate block design and generate in next pop-up under the Flow Navigator

13. Once generation is successful create the HDL wrapper as shown in Figure 9 and select the default option in next window pop-up
    

14. Similarly select the Export Hardware for SDK once the HDL Wrapper is created select the options shown in the Figure 10
    

15. SDK tool will be launched as shown in the Figure 11

Open

Figure 11: SDK launch window for the hardware design

1. Create a new application project to create the First stage boot loader (FSBL) as shown in the Figure 12

Open

Figure 12: Creating new SDK application project

1. Enter the project name in next window and select Next

2. In the Template wizard select Zynq FSBL and select Finish. Then SDK builds the Zynq FSBL if auto build is enabled

3. Next step is to create the boot.bin file. U-boot.elf file is also needed along with FSBL. Refer the Techtip on building u-boot or copy the u-boot.elf from the provided design files.

Open

Figure 13: Creating the Zynq boot image

1. After the selections done as shown in Figure 13, in Create Boot Image wizard enter the name for BIF file and browse the directory paths for Zynq_FSBL.elf and u-boot.elf files then select Create Image button. Rename the output.bin file to boot.bin. Use this bin file in both the SD cards.

2. Linux Image creation details: To run the demo with provided pre-build images skip to step 24 or Next few steps explain how to build the Linux with updated xilinx_emacps.c driver. Replace xilinx_emacps.c driver .c file provided in the design files to drivers/net/Ethernet/Xilinx/Xilinx_emacps.c in Xilinx kernel on Linux development PC

3. Enable the CONFIG_XILINX_PS_EMAC_HWTSTAMP configuration option in kernel config file

4. Make sure the MAC addresses of PTP master Zynq and PTP slave Zynq devices are different and this can be achieved by change the HW MAC in address in xemaccps_update_hwaddr function in xilinx_emacps.c driver and recompiling the kernel. Copy the two kernel images, device tree and boot.bin files to two separate SD cards

5. To run the demo with pre-build images or Images build in above steps 21 to 23: In SD_Image folder copy the content from SD1 folder contents to one SD card and SD2 folder contents to another SD card

6. Connect the power supplies, UART cables/PC to both Zynq boards. Connect the two Zynq boards back to back with the Ethernet cable. Insert the SD cards into the SD card slots of both the boards

7. Launch the GUI ‘ZynqIEEE1588DemoGUI.exe’ provided with the design files, GUI launch is as shown in Figure 14

Open

Figure 14: Zynq IEEE 1588 PTP Demo GUI

1. Power cycle both the boards and select the COM ports and baud rates(115200) for both Slave PTP device and Master PTP device on the GUI window as shown in Figure 15

Open

Figure 15: Starting the PTP master and PTP slave protocol

1. Select the “start master” button once it is highlighted/enabled.

2. Select the “start slave” button once it is highlighted/enabled

3. The two clocks in the GUI displays the path delay and master clock offset calculated in nanoseconds at slave PTP device for the PTP message transfers. Figure 16 shows the UART print messages from the PTP applications on both PTP master and PTP slave related to the delay, frequency and offset correction values. Slave device has to correct these settings on the TSU to be in sync with master time stamps

Open

Figure 16: PTP messages and offset, delay calculation on the slave PTP device

Expected Results

Show what the user should expect to see.

The offset delay between PTP Master Device and PTP Slave Device should be near to 9 nanoseconds as per the theoretical achievable granularity for this configuration. The current implementation is able to achieve the +/-500 ns granularity and will be optimized for the better granularity.

Following are the some of the application time synchronization requirements. These markets can be addressed with the Zynq-7000 AP SoC:

How to Expand

Show the user what they can do to alter or expand the design. An example is always good.

1. With the APU running at frequency 666.66 MHz, the TSU (111 MHz) in PS GEM time stamping granularity will be at 9 nanoseconds. If application needs time synchronization at much more granular time then TSU can be implemented in PL and can be run at higher frequencies than 111MHz to achieve more than 9 nanoseconds granularity

2. For better TSU synchronization, the software implementation can be explored with RTOS, lwIP UDP/IP stack and PTP protocol stack implementations.

Appendix A: IEEE 1588v2 PTP Overview

The IEEE 1588 PTP protocol defines the functionality, algorithms and guidelines for implementations of PTP for the two or more independent devices in the network to be on real time clock synchronization at less than a sub-micro/sub-nano seconds granularity. This is achieved through the exchange of the PTP event message between the nodes.

As Figure 17 shows an example of PTP message communication between a PTP master and PTP slave devices. Following are the event messages used in PTP between master and slave:

• Sync

• Follow Up

• Delay Request

• Delay Response

• Peer-to-Peer Transparent clock messages: pdelay_reg & pdelay_resp

There are two approaches for the time stamping used: One step and two step clock technique. Zync support the two step clock synchronization technique.
In One step approach there will not be a follow-up message so sync message has to use the most accurate time stamp with accurate estimate of the delays. Following figure 18 illustrate the Two Step Clock synchronization techniques for time exchange and measuring the delays and clock offset between master and slave devices:

Delay & offset are calculated based on:
Delay = [ (t2-t1) + (t4-t3) ] / 2;
Offset = [ (t2-t1) - (t4-t3) ] / 2;


More details on the IEEE1588 v2 protocol can be found at:
http://www.nist.gov/el/isd/ieee/ieee1588.cfm