Embed Size (px)
Citation preview
SoCe
System-on-Chip engineering
Precise-Time-Basic (IEEE1588)Submicrosecond Synchronization using
FPGAs
SoCe
October 1, 2012
Doc: 120926
This page has been intentionally left blank
ii
Revision History
Rev. Date Author Description120711 11/07/12 ML First draft release120926 12/09/12 AA Revised
iii
Contents
I. Sub-microsecond Synchronization 1
1. Introduction to IEEE1588 - Precise Time Protocol 21.1. History and Standards . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21.2. Need for Synchronization . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.3. Origins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2. IEEE1588 Basics 42.1. Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42.2. Basics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.2.1. One-Step Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62.2.2. Two-Step Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3. Solutions. Hardware vs Software . . . . . . . . . . . . . . . . . . . . . . . 82.3.1. PTP Network Components . . . . . . . . . . . . . . . . . . . . . . 9
2.4. Implementing PTP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132.4.1. Software Implementation . . . . . . . . . . . . . . . . . . . . . . . 142.4.2. Hardware Support at the Ethernet Phyter . . . . . . . . . . . . . 142.4.3. Hardware Support at the Ethernet MAC IP in a FPGA . . . . . . 16
3. PTP Integration with Reliable Ethernet Protocols 17
II. System-on-Chip engineering solutions for IEEE1588-2008 V2 18
4. PreciseTimeBasic : An IEEE1588 V2 System-on-Programmable-Chip 194.1. General description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194.2. Hardware Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
5. Software Architecture 215.1. Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 225.2. Basic Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235.3. Resource utilization and accuracy . . . . . . . . . . . . . . . . . . . . . . 23
6. 1588Tiny : IEEE1588 V2 all-in-hardware IP Core 246.1. General description . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
iv
Contents
6.2. Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
v
Part I.
Sub-microsecond Synchronization
SoCe Doc: 120926 1 / 28
1. Introduction to IEEE1588 - PreciseTime Protocol
1.1. History and Standards
The idea of a Precision-Time-Protocol (PTP) was born in the late 90s in the U.S. in thefield of measuring technology. The principle of process developed was presented to theIEEE as a suggestion and created the basis for the IEEE1588 standard. In late 2002precision time protocol was approved as a standard under the name of ”1588TM - IEEEStandard for a protocol precision clock synchronization for networked measurement andcontrol systems.” Furthermore, PTP was also adopted as an IEC standard in May 2004and was published under the name of IEC 61588.
In response to new requirements the project P1588 arose. Its mail goal was to specifya version 2 of the protocol, which was approved in March 2008 under the title IEEE1588-2008, version 2. IEC has adopted this standard as well as IEC 61588 Edition 2. Thereis a small incompatibility between the two versions, clocks of the v1 and V2 can notsynchronize directly with each other because they use different message format. However,islands of different IEEE1588 flavors can interoperate by means of Boundary Clocksproviding different versions or different profiles over its ports.
The Precise time information has a great importance for distributed systems in au-tomation technology. Adopting PTP described in IEEE1588, it is possible to synchronizedistributed clocks with an accuracy of less than 1 microsecond via Ethernet networks.Are relatively lows the demands on the local clocks, of the network and the computingcapacity.
Depending on the Sector, synchronization needs differ. As an example, in powerdistribution systems, parameters such as currents and voltages are measured in dis-tributed sensors, connected centrally and evaluated. Thus, synchronization accuracy ismandatory in sample values. Turbine Controls use PTP protocol to install more effi-cient plants. And, for monitoring processes, de-central events detected are marked withprecise timestamps and transferred to the control station for recording and analysis. Intelecommunications, PTP is being considered for the timing of the supply network orradio base stations precise time pulses.
There is also an interest in time synchronization according to the IEEE1588 stan-dard in the field of safety systems, transportation, digital audio / video broadcasting,automotive technology or military applications.
SoCe Doc: 120926 2 / 28
1.2. Need for Synchronization
The need for accurate synchronization is increasing in several fields:
• Telecommunication networks: They are facing a rapidly migrating from circuitswitched to packet technologies.
• Key challenges: Highly accurate timing required in the packet networks anddistributed systems to enable existing and future applications.
• Several technologies exist to provide the precise frequency synchronizationneeded by these applications: Adaptive clock recovery (ACR), GPS-based syn-chronization, etc.
• Emerging IEEE1588 Precision Time Protocol (PTP) standard for a packet-based synchronization: higher level of performance and lower cost by leveragingthe existing infrastructure.
1.3. Origins
IEEE1588 was developed with the following goals:
• Accuracy to at least microsecond (us) and preferably nanosecond (ns) levels.
• Minimal network, computing and hardware resource requirements so that itcan be applied to low-end as well as high-end devices.
• Applicable with minimal or no administration to systems defined by a singlesubnet.
• Applicable to common and inexpensive data networks including but notlimited to Ethernet.
• Applicable to heterogeneous systems where clocks of different capabilities andqualities can synchronize to each other in a well ordered manner.
SoCe Doc: 120926 3 / 28
2. IEEE1588 Basics
2.1. Overview
The main features of IEEE1588 PTP protocol are summarized in the following points:
• It is able to synchronize networked clocks with an accuracy down to thenanosecond range.
• It provides high precision combined with easy installation compared withalternative synchronization mechanisms (NTP, GPS, IRIG, etc.).
• It allows Systems Synchronization and data transfer use the same standardnetwork.
• It is an Ethernet packet protocol for synchronizing clocks on a local areanetwork, LAN. Each clock is a 64 bit count with the LSB representing 1 ns. Themaster clock periodically, 1/4 to 64 second intervals, broadcasts its clock value toall of the slave clocks in the LAN.
• It is based on Packet Locked Loop (PLL) approach. Like any active synchronizedcircuit, the IEEE1588 clock is a servo and is usually implemented with a PIDalgorithm of some sort. The main problem with the IEEE1588 protocol is thatit implicitly assumes the packets will arrive at the destination reliably and withno delays.[1]
SoCe Doc: 120926 4 / 28
2.2. Basics
It is based on message exchange mechanism. These messages are regularly interchangedbetween master and slave in order to determine the offset and the message transitdelay through the network.
Masterclock
Slaveclock
t1
t2
t3
t4
Delay M-S
S-M Delay
sync
follow_up
delay_resp
delay_req
Offset Master
Offset
Figure 2.1.: Messages Exchange scheme
The slave clock requires four measured values t1, t2, t3, t4 to calculate delayand offset from master (Figure 2.1). These values are the send and receive times of theSync and the Delay-Req messages. The Follow-up and Delay-Resp messages transportthe values measured by the master down to the slave. A simple calculation delivers delayand offset:
Delay + Offset = t2 − t1 Delay =(t2 − t1) + (t4 − t3)
2
Delay −Offset = t4 − t3 Offset =(t2 − t1) − (t4 − t3)
2
The precision of the result depends on the precision of the timestamps[2].They should reflect the send and receive time as precise as possible. The slave’s offset
SoCe Doc: 120926 5 / 28
and delay calculation is based on the difference of timestamps taken at two differentplaces. Therefore, the two clocks should use the same scale, i.e. the same tic interval.This is achieved by drift compensation: the slave clock rate is accelerated or sloweddown by a control loop. A slightly different tic interval will degrade the result.
It is assumed that the message transit delay is the same for both directions. At afirst glance, this is the case in an Ethernet link.
In the long run, conditions may change due to reconfiguration (leading to a totallydifferent delay) or environmental conditions (temperature). How fast the clocks canreact depends on the frequency of sync and delay measurement and the dy-namic behavior of the servos controlling the slave clock.
To sum it up, performance depends on:
• The communication channel symmetry (i.e. same delay in both directions andconstant over a longer period of time).
• Drift compensated clocks (i.e. adjusted time base in master and slave clocks).
• timestamp accuracy.
• Sync interval.
• Clock stability.
• Clock control loop characteristics.
2.2.1. One-Step Clock
The one-step clock technique exchanges three packet-sized timing messages betweenmaster and slave: Sync, Delay- Req, and Delay-Resp. The master stamps the time (t1)on the Sync message that leaves the master. The slave receives the Sync message attime (t2) and sends a Delay-Req message at time (t3) to the master, which the masterreceives at t4. The master then sends a packet containing t4 to the slave. The slave nowhas all the information needed to calculate the slave offset:
SlaveT imeOffset =(t2 − t1) − (t4 − t3)
2
SoCe Doc: 120926 6 / 28
MasterTime
SlaveTime
t1
t2
t3
t4
sync
follow_up (t1 )
delay_resp (t4 )
delay_req
t2
t1
t2
t3
t1
t2
t3
t4
Timestampsknown by slave
Figure 2.2.: One-Step clock
2.2.2. Two-Step Clock
The two-step clock technique measures exactly when the Sync packet leaves the masterclock and places this timestamp in a Follow-Up message after it sends the Sync message.The Follow-Up message contains the true t1 value based on when the Sync message wasobserved to actually leave.
Mastertime
Slavetime
t1
t2
t3
t4
t-ms
t-sm
sync
follow_up
delay_resp
delay_req
t2
t1 t2
t1
t2
t3
t1
t2
t3
t4
Timestampsknown by slave
Figure 2.3.: Two-Step clock
The availability of the Follow-Up message on the heels of the Sync message is veryuseful.
SlaveT imeOffset =(t2 − t1) − (t4 − t3)
2
SoCe Doc: 120926 7 / 28
2.3. Solutions. Hardware vs Software
In order to obtain high levels of accuracy timestamps should be made as close as possibleto the wires. The PTP environment provides different possible points of timestamp, asseen in Figure 2.4.
PHY
MAC
NIC Driver
IP PTP Stack
UDP
PTP StackLargeunknown latency
Smallunknown latency
Smallknown latency
Only SW, Application LevelAcc.: 100usHuman Control
Driver LevelAcc.: 10us‐1usProcess/Motion Control
HW LevelAcc.: <50nsPrecision Control
Figure 2.4.: Possible timestamp points
For hardware assisted timestamping, timestamps can be taken at the communicationlink between the Ethernet Media Access Controller (MAC) and the Ethernet Phyter(PHY) (eg. MII). To acquire the frames directly on the wire, functions such as clockrecovery, line decoding, descrambling, and more features. It is essentially required forthe purpose of a PHY.
To collect the timestamps of transmitted and received PTP frames , the software onthe application layer requires an interface to the timestamping unit. Also needs an ad-ditional information to correlate timestamps with the corresponding messages [2].
Pure software solutions take timestamps in the Network Interface Card (NIC) driveror at the application layer. Timestamping at the application layer has the advantageof platform independence. A disadvantage is the relative large variation of the messagetransit delay through the protocol stack (also called jitter). The jitter depends onthe type of operating system, the mix of running applications, system hardware, theinterrupt system and other factors.
Timestamping at the driver level is the optimal software solution but requires a mod-ified network driver:
• Received frames can be stamped at the very beginning of the interrupt serviceroutine (ISR) serving the network interface.
SoCe Doc: 120926 8 / 28
• Transmitted frames are stamped at the very end of the send routine, i.e. at theplace, where the frame is passed to the hardware, the MAC controller.
To sum it up, in order to get better synchronization, the timestamp should be as nearas possible to the hardware layer, as shown in Figure 2.5.
PTP
UDP
IP
Driver
MAC
PHY
PTP
UDP
IP
Driver
MAC
PHYNetwork
possibletimestamp points
exchange ofPTP messages
MII
Master clock Slave clock
Figure 2.5.: PTP message exchange
2.3.1. PTP Network Components
• Best Master Clock Algorithm
The Best Master Clock (BMC) algorithm is central to the operation of PTP. Itspecifies the method by which each clock determines the best master clock in itssub-domain out of all clocks it can see, including itself. One node can only beSlave or Master/Slave. In case of being Master/Slave it can decide becoming Slavedepending on the BMC algorithm.
• Ordinary Clock
An ordinary clock is formally defined as a PTP clock with a single PTP port.It operates as a node within a PTP network, and can be selected as a masteror slave within a segment according to the BCM algorithm. Ordinary clocks arethe most populous device within a PTP network as they are generally used asthe end nodes within a network connected to devices needing synchronization.
• Boundary Clock
Boundary clocks are defined within a PTP system to sit in place of standard
SoCe Doc: 120926 9 / 28
PTP
UDP
IP
MAC
PHY
Boundary clock
Slave clockMaster clock
PTP
UDP
IP
MAC
PHY
PTP
UDP
IP
MAC
PHY
PTP
UDP
IP
MAC
PHY
Slave Master
Synchronization
Switching function
Message flow
network switches or routers. Boundary clocks are defined as PTP clocks withmore than a single PTP port, with each port providing access to a separatePTP communication path. The boundary clock acts as an interface betweenseparate PTP domains intercepting and processing all PTP messages and pass-ing all other network traffic. The BMC algorithm is used by the boundary clockto select the best clock any port can see. The chosen port is set as a slave and allother ports of the boundary clock are asserted as masters to their domain.
SoCe Doc: 120926 10 / 28
PTP
UDP
IP
MAC
PHY
PTP
UDP
IP
MAC
PHY
Master
Synchronization
Switching function
Message flow
Slave
TSU TSU
• Transparent Clock
Transparent clocks have been added to version 2 of the standard as an improvedmethod of forming cascaded topologies. Rather than acting as a multi-port ordi-nary clock as boundary clocks do, transparent clocks update a newly introducedtime-interval field within PTP event messages. This 64-bit time-interval correctionfield allows for switch delay compensation to a potential accuracy of less than apicosecond.
PTP
UDP
IP
PTP
UDP
IP
Master clock Slave clock
MAC
PHY
TSU
MAC
PHY
TSU
TRANSPARENT CLOCK
Slave Master
MAC
PHY
MAC
PHY
TSUTSU
Switching function
Time correction
There are two types of transparent clocks, End-to-End and Peer-to-Peer
SoCe Doc: 120926 11 / 28
I. End-To-End
End-to-End transparent clocks update the time interval field for the delayassociated with individual packet transfers. The slave measures the delayto the master with an end-to-end Delay-Request / Delay-Response messageexchange.
Master SlaveTransparentClock 1
TransparentClock 2
Synchronization(t1,c)
C:=C0
Synchronization(t1,c)
Synchronization(t1,c)
t t
∆s1
∆s2
Time stamping
Synchronization residence time
Correction Field
C:=C+∆s1
C:=C+∆s2
Master TC
TC
Slave
TC
TC Slave
Slave
Slave
end-to-end delay measurement
Synchronization
SoCe Doc: 120926 12 / 28
II. Peer-To-Peer
Peer-to-Peer transparent clocks measure the line delay associated with theingress transmission path and include this delay in the correction field also.TC‘s measure the link delay to all neighboring clocks with Pdelay-Req/Pdelay-Resp messages. Peer-to-peer transparent clocks can allow for faster reconfig-uration after network topology changes.
Master SlaveTransparentClock 1
TransparentClock 2
Synchronization(t1,c)
C:=C0
Synchronization(t1,c)
Synchronization(t1,c)
t t
∆s1
∆s2
Time stamping
∆s���� Synchronization residence time
Correction Field
C:=C+ ∆s1+∆L1
∆L1
∆L2
∆L3
C:=C+ s1+ L2
∆L���� uplink delay
C:=C+∆L3
Delay calculations
Master
Slave
Slave
Slave
Slave
peer-to-peer delay measurement
Synchronization
TC
TC TC
TC
2.4. Implementing PTP
The traditional form of time synchronization across Ethernet networks has been NetworkTime Protocol (NTP). Network Time Protocol time synchronization allows up to 100milliseconds. The IEEE1588 PTP is required to achieve greater synchronization.
As presented is Section 2.3, high accuracy requires hardware assistance for timestampgeneration and clock adjustment while the protocol is implemented in software. In PTPsoftware approaches, synchronization may reach los 100 microseconds. As shown inFigure 2.6, hardware-assisted timestamping is required to obtain a synchronization timein the region of nanoseconds.
SoCe Doc: 120926 13 / 28
100ms 100µs-10µs 100ns-50ns 10ns
Human control Process control Motion control Precision control
Standard MAC
S/W IEEE1588 Hardware assisted IEEE1588
NTP 1588 PTP 1588 PTP
TCP/IP/UDPTCP/IP/UDP
Standard MAC
Standard MACCuston FPGA or µControler
PHYTER
StandardEthernet
Precision PHYTER withH/w 1588 Timestamps + clock + GPIO
Figure 2.6.: Implementation Choices to obtain Better Time Synchronization
2.4.1. Software Implementation
All PTP functions are handled in software. It is the simplest implementation. PTPpacket travels through all layers from the wire, and incurs delays in software processing.
TS I/O PTPRJ-45
µC/ FPGA OSEthernetPHY
EthernetMAC
TS I/OPTPTimeStamp Precision Time Protocol software stack 1588 input/output 1588 clock
MII / RMII
PCI / Bus local
HARDWARE
SOFTWARE
Figure 2.7.: Software based timestamping
2.4.2. Hardware Support at the Ethernet Phyter
In this case, the PTP messages sniffing and timestamping is performed by an IEEE-1588-capable Ethernet Phyter. Figure 2.8 depicts this approach.
SoCe Doc: 120926 14 / 28
The Precision Phyter accesses to the PTP packets as soon as they are available fromthe wire. This is the key for reaching time synchronization of less than 10 nanoseconds.
PTPRJ-45µC/ FPGA OS
EthernetMAC
TS I/OPTPTimeStamp Precision Time Protocol software stack 1588 input/output 1588 clock
MII / RMII
PCI / Bus local
HARDWARE
SOFTWARE
TS I/O
Precision PHY
Figure 2.8.: IEEE1588 capable Phyter
SoCe Doc: 120926 15 / 28
2.4.3. Hardware Support at the Ethernet MAC IP in a FPGA
If this approach is used, the frames are captured at the link between the Ethernet Phyterand the MAC embedded in the FPGA. These frames can be decoded and modified (forexample, in order to implement a one-step clock). The required logic is located in anFPGA.
Every component that handles the PTP packets after they are received on the wire willincrease the synchronization error. Software adds the most error since both processorload and the delay associated with handling interrupts impact how quickly a synchro-nization request is processed. Fortunately, only certain PTP actions are time critical.The most time critical PTP actions are recording timestamps of PTP packets, adjustingand maintaining the synchronized local clock, and using synchronized I/Os.
In order to minimize the uncertainly, this critical operations are implemented on theFPGA as shown in Figure 2.9. Remaining high-level operations and applications canrun in a embedded microprocessor or an external one.
PTPRJ-45µC/ FPGA OSEthernet
PHY
EthernetMAC
TS I/OPTPTimeStamp Precision Time Protocol software stack 1588 input/output 1588 clock
MII / RMII
PCI / Bus local
HARDWARE
SOFTWARE
FPGA
I/O
TS
Figure 2.9.: FPGA based timestamping
SoCe Doc: 120926 16 / 28
3. PTP Integration with ReliableEthernet Protocols
PTP FPGA based implementations offer high level of flexibility thanks to Reconfig-urable Technology. FPGA are the best candidates to combine the newest Ethernetbased protocols that are arising for Industrial Network with high-accuracy synchroniza-tion mechanisms. Modular design of IP cores makes easy to include them in systemswith other communication features as high availability or redundancy. In this area, isspecially significative the interest on the combination of Reliable Ethernet protocols likeParallel Redundancy Protocol (PRP) or High-availability Seamless Redundancy (HSR)[8] by using mixtures of RedBoxes, Boundary Clocks and Transparent Clocks[9]. PRPand HSR are detailed in IEC 62439-3, standard for Automation Networks and bothprotocols offer zero recovery time.
Protocols like PRP and HSR can also be implemented on software and hardware. How-ever, the low latency times required for HSR applications make software applicationsonly valid for functional verification and testing.
Approaches that combines PTP with Reliable Ethernet implemented in a single FPGA,offering hardware timestaming and dedicated switch arquitecturas, can provide high ac-curacy synchronization together with a high performance in reliable communications.
NOTE: SoCe White Paper for FPGA based Reliable Ethernet implementations offersmore details about these protocols.
SoCe Doc: 120926 17 / 28
Part II.
System-on-Chip engineering solutionsfor IEEE1588-2008 V2
SoCe Doc: 120926 18 / 28
4. PreciseTimeBasic : An IEEE1588V2 System-on-Programmable-Chip
4.1. General description
PreciseTimeBasic is a IEEE1588-2008 compliant clock synchronization System-on-Programmable-Chip (SoPC) for FPGA devices. It combines in a single device all theIPs, software stack and Operating System necessary to implement most of IEEE1588Network Components. PreciseTimeBasic maintains the clock and it is in charge oftimestamping and frame analysis. Multiple Ethernet connections can share the sametimer or different Ethernet connections may have their individual timer. Standard ver-sions are available for PLB and AXI4 on-chip buses and thanks to its SoPC architecturecan easily integrate other typical CPU functionalities.
4.2. Hardware Architecture
PreciseTimeBasic SoPC has been integrated on Xilinx Platform Studio tools. Thereare version compatible with PLB an AXI on-chip buses. As and example of thisintegration Figure 4.1 depicts a typical SoPC architecture for a IEEE1588 compat-ible node based on PreciseTimeBasic . It combines an embedded microprocessor[4](e.g.MicroBlaze), an embedded Ethernet controller, IEEE1588 timer core, two times-tamping cores and other peripherals needed by the embedded Operating System (Linux)and software stacks timers, DDR controller, UART, etc.).
SoCe Doc: 120926 19 / 28
PHY TX PHY RX
Timer
Capture
Capture
EthernetMac
Otherperipherals
MicroBlaze
PLB/AXI
Figure 4.1.: Hardware layout
SoCe Doc: 120926 20 / 28
5. Software Architecture
A SoPC solution combines in a single chip hardware and software modules.PreciseTimeBasic hardware layout allows different software and stacks alternatives.There are many software stacks that provide all the algorithms (BMC, PID control, etc.)to perform the clock synchronization proposed in IEEE1588. However, they relay in theaccuracy of the timestamps [[5][6]].
PreciseTimeBasic supports two Open Source and the Third-Party IXXAT PTP stacks.These stacks manage the accurate timestamps provided by the capture cores throughthe appropriate driver. In slave mode, the stack is be able to modify timer core’s valueand frequency, once again, using a driver.
In PreciseTimeBasic standard version, the Operating System embedded in the SoPCPetalinux (embedded Linux distribution optimized for Xilinx FPGAs)[7]. The softwareand hardware interaction in the SoPC is depicted in Figure 5.1.
PTPstack
Petalinux
MicroBlaceFPGA
IP Cores
Driver
Driver
Timer
Capture
Figure 5.1.: H3-SW hierarchy
SoCe Doc: 120926 21 / 28
5.1. Applications
By its implementation modularity, PreciseTimeBasic may be used in a wide range ofapplications. Furthermore, it does not need any specific hard module inside the FPGA,so it can be implemented seamless in low-cost or high-end FPGA families. Among othersectors where PreciseTimeBasic can be directly used, highlight:
• Energy and Power Electronics
• Industrial Ethernet communications
• Wireless base stations synchronization
• Wired Networks synchronization
• Home Automation
• Military and Software-Defined Radio
SoCe Doc: 120926 22 / 28
5.2. Basic Package
PreciseTimeBasic basic package includes the following items:
• IP core netlist ready for seamless integration in XPS
• Software driver for easy integration with different PTP software stacks
• Reference design for SP605 Spartan-6 Evaluation Board
• Training seminar
PreciseTimeBasic is supported by several PTP software stacks:
• IXXAT PTP software stack
• GPL SourceForge PTPd stack
• GPL OpenPTP
SoCe offers the following engineering services related to this product:
• FPGA custom design (SoPC Microblaze based solution)
• Software and OS (Linux) integration
• Combination with other IPs or networking solutions
• Custom board design
5.3. Resource utilization and accuracy
PreciseTimeBasic has been described using VHDL language to facilitate the imple-mentation in different FPGA families and devices. The core is wrapped to be PLBcompatible or AXI4 although can be customized for other on-chip Bus.
• A complete PLB implementation for one Ethernet interface (1 timer and 2 times-tamping units RX/TX) needs approximately 1000 Spartan-6 Slices.
• Nanosecond timer counter grain, frequency and offset can be configured to achievesub microsecond synchronization. Frequency can be fine tuned down to nanosec-onds per second.
• Messages are timestamped with nanosecond accuracy close to the physical layerto minimize unpredictable latencies.
SoCe Doc: 120926 23 / 28
6. 1588Tiny : IEEE1588 V2all-in-hardware IP Core
6.1. General description
This IP Core is a compact, high-optimized solution to implement Ordinary-Clock capa-bilities in equipments with IEEE1588 Slave-Only requirements. 1588Tiny does not re-quire any SoPC architecture (it is a single IP) and it includes a custom Ethernet MAC. Itmanages Announce, Sync and Delay-Resp messages and generates Delay-Req messages.This IP also synchronizes internal counter (64bit with LSB representing nanoseconds)and in the standard version generates a PPS signal based in the internal counter asdepicted in Figure 6.1. This IP also allows the use of Ethernet MAC different fromthe internal one. In these cases, packet sniffing and timestamping is performed insidethe FPGA and between the Ethernet Phyter and the internal Ethernet MAC IP. Theinterface distribution for this last option is represented in Figure 6.1.
1588 TinyMII
PPS Signal
64 bit Time (ns)
MII
Figure 6.1.: 1588Tiny core interfaces
SoCe Doc: 120926 24 / 28
1588Tiny main features are:
• 1588Tiny is the simplest and smallest solution toadd IEEE1588 V2 functionality to any equipment
• It is a single IP core that comprises IEEE1588 V2Slave Only Functionalities and a basic EthernetPort to process PTP frames
• It offers high accuracy clock synchronized with aIEEE1588 Master connected to Ethernet net withthe minimum FPGA resources
• It is a fully hardware solution. Software PTP stackis not required, nor soft embedded Microprocessor
• Excellent trade-off between clock accuracy and re-sources. For extra clock accuracy, see Precise-TimeBasic IP core
• Standard versions are available for low-cost XilinxFPGAs
FPGA
1588TinyIP Core
TinyETHERNET
PORT
Figure 6.2.: 1588Tiny
6.2. Applications
1588Tiny may be used in a wide range of applications. Thanks to its optimized archi-tecture it can be implemented on the most affordable FPGAs available in the market.Among other sectors where 1588Tiny can be directly used, highlight:
• Equipments for Energy Market
• Industrial Ethernet communications
• Human-Machine-Interfaces
• Vending
• Motor encoder reconstruction and broadcasting
1588Tiny basic package includes the following items:
SoCe Doc: 120926 25 / 28
• Wired Networks synchronization
• Home Automation
• Military and Aerospace
• IP core netlist ready for seamless integration in ISEdesing flow
• Reference design for AVNET Spartan-6 FPGA LX9Microboard
• Available profiles: Power, IEC 51850 and Telecom
• Training seminar
SoCe Doc: 120926 26 / 28
Bibliography
[1] IEEE1588 - 2008, “Standard for a Precision Clock Synchronization Protocol forNetworked Measurement and Control Systems”, February 2009.
[2] Weibel, Hans; Bechaz, Dominic: “IEEE1588 Implementation and Performance oftimestamping Techniques ”, 2004 Conference on IEEE1588, 2004.
[3] D. B. Sullivan, D. W. Allan, D. A. Howe, and F. Walls, “Characterization of clocksand Oscillators,” NIST, Technical Note 1337, 1990.
[4] Fletcher, Bryan H. : “FPGA Embedded Processors: Revealing True System Perfor-mance”, Embedded Systems Conference, San Francisco, California, 2005
[5] PTP daemon (ptpd) in SourceForge.
[6] IXXAT Automation IEEE1588 protocol stack.
[7] Petalinux Embedded Linux by Petalogix.
[8] IEC 62439, “Industrial communication networks: high availability automation net-works”, February 2010.
[9] Meier, Sven; Weibel, Hans: “IEEE1588 applied in the environment of high availabil-ity LANs”, International IEEE Symposium on Precision Clock Synchronization forMeasurement, Control and Communication, 2007.
SoCe Doc: 120926 27 / 28
System-on-Chip engineering
Zitek Bilbao (ETSI)
Alameda Urquijo s/n
48013 Bilbao SPAIN
Tlf: +34 944420700
SoCe Doc: 120926 28 / 28
