PCM4L

PCM4L RENESAS | Alldatasheet

Document overview

• Manufacturer or author: Renesas Electronics Corporation
• PDF pages: 38

Technical content

Datasheet sections

• 1.1 Simplified Synchronization Model
• 1.2 Clock Recovery Techniques
• 1.2.1 Assisted Clock Recovery
• 2.1 Reference Trackers (RTs)
• 2.1.1 Write Phase Reference Tracker
• 2.1.2 Adaptive Time Reference Tracker
• 2.1.3 Assisted Time Reference Tracker
• 2.1.4 Adaptive Frequency Reference Tracker
• 2.1.5 Programmable Loop Filter
• 2.2 Reference Tracker Supervisor (RTS)
• 2.2.1 Hitless Reference Switching
• 2.2.2 Phase Slope Limit and Instant Reference Switching
• 2.2.3 Reference Switching Thresholds
• 2.3 APTS Supervisor
• 2.4 Local Oscillator State Machine (LOSM)
• 2.4.1 Operational States
• 2.4.2 Lock Acquisition Qualification Timeout
• 3.1 The JavaScript Object Notation (JSON)
• 3.1.1 JSON Configuration File
• 3.2 General Configuration Parameters
• 4.1 Management APIs
• 4.2 Management CLI Utility
• 5.1 Noise Generation
• 5.2 PDV Tolerance

Features

▪ Filters the effects of high Packet Delay Variation (PDV) per G.8273.4 or G.8263 ▪ Calibrates for asymmetry when an external local time reference is available per G.8273.4 APTS ▪ Software provided as clear C code, ready for Linux distributions

• Runs on Linux kernel v3.0 and higher, using the PTP Hardware Clock Infrastructure for clock control
• Dramatically simplifies software integration and debugging ▪ Support for IEEE1588-2019 Slave Event Monitoring channel to allow for a timestamp interface to an external PTP stack ▪ Full PTP clock state machine per ITU-T G.8275.1 Appendix V and G.8275.2 Appendix IV

Applications

▪ Wireless infrastructure for 4.5G and 5G network equipment ▪ Phase/time synchronization with full timing support from the network per ITU-T G.8275.1

• Telecom Boundary Clocks (T-BCs) and Telecom Time Slave Clocks (T-TSCs) according to ITU-T G.8273.2 for Full Timing Support (FTS) networks ▪ Phase/time synchronization with assisted or partial timing support from the network per ITU-T G.8275.2
• Telecom Boundary Clocks (T-BCs) and Telecom Time Slave Clocks (T-TSCs) according to ITU-T G.8273.4 for Assisted Partial Timing Support (APTS) or Partial Timing Support (PTS) networks pcm4l PTP Clock Manager for Linux

R31DS0087EU0101 Rev.1.01 Page 2 Sep.28.21 pcm4l Datasheet Simplified Diagram

R31DS0087EU0101 Rev.1.01 Page 3 Sep.28.21 pcm4l Datasheet Block Diagram

of Profiles. With a properly designed network, sub-nanosecond time transfer accuracy can be achieved. Telecom, these industry agreed architectures come from the ITU-T.

1.1 Simplified Synchronization Model

between the master clock to the slave clock and the return path are symmetric. Figure 1. Basic PTP Timing Message Exchange (from IEEE 1588-2019)

1. Offset From Master, or <offsetFromMaster>
2. Using delay request-response mechanism (used by all ITU-T Telecom Profiles).

1. Mean Path Delay, or <meanPathDelay>[2]

from master, offsetFromMaster. Figure 2. Example Synchronization Using the IEEE 1588 Timing Message Exchange of under 1 microsecond and frequency accuracy of under 16 parts-per-billion (ppb). also run on the external processor. support for all three ITU-T Telecom profiles and added support for external filter/servos, such a pcm4l.

1. If using peer-to-peer delay mechanism, then this would be Mean Link Delay, or <meanLinkDelay>.

R31DS0087EU0101 Rev.1.01 Page 7 Sep.28.21 pcm4l Datasheet

1.2 Clock Recovery Techniques

For network clock synchronization, equipment clock systems predominantly rely on a linear-based clock recovery suppresses high-frequency noise, or jitter. The ITU-T has many equipment clock recommendations for TDM, legacy or non-packet network types (e.g., ITU-T G.813 for SDH/SONET networks and ITU-T G.8262 for Ethernet networks). However, with the transition to packet-switched networks, more advanced techniques may be required as Ethernet is built based on an asynchronous physical layer clock (some Telecom networks have been transitioned to Synchronous Ethernet, per ITU-T G.8262; however, there are still many networks that are based solely on IEEE 802.3). There are typically two ways to recover a clock when sent over a packet-based network: adaptive and differential. Per ITU-T G.8260, adaptive clock recovery is a technique that does not require the support of a network-wide synchronization signal to regenerate the timing. In this case, the timing recovery process is based on the (inter-) arrival time of the packets using timestamps. The information carried by the packets could be used to support this operation, depending on the packet delay variation (PDV) each timing packet experiences. Either two-way or one- way protocols can be used, which is why IEEE 1588 is a good protocol choice. Differential clock recovery is another technique, typically used for Circuit Emulation Services (CES), to recover clocks based on the difference between (inter-)arrival time of the packets using a traceable clock at both the sending end and the receiving end. This ensures the recovered clock is not affected by the packet delay variation (PDV) each timing packet experiences. However, a traceable clock may not be supported [or available] at the receiving end, so adaptive clock recovery must be used. More details on differential methods can be found in section 8.2 of ITU-T G.8261. The Renesas pcm4l software supports both adaptive and linear clock recovery techniques, with the linear clock recovery being offloaded to the Renesas network synchronization devices, such a ClockMatrix device.

1.2.1 Assisted Clock Recovery

The ITU-T has proposed an architecture that uses GNSS as the primary local time source, with PTP acting as a backup – primarily to maintain a time holdover on the loss of GNSS. This is described in G.8273.4 as Assisted Partial Time Support (APTS). Two methods can be used to implement APTS: 1. Select the local time source as the best clock for local PTP clock (i.e., ITU-T virtual PTP port), and monitor the PTP T-GM using ITU-T alternate master. 2. Maintain two independent clock channels (GNSS and PTP) and correct for asymmetry on the active PTP T-GM The latter works best for T-BC-A implementations, to maintain PTP clock traceability to the T-GM. The former can work well for either T-BC-A or T-TSC-A, but the PTP stack must support the G.8275.2 alternate master to allow the PTP T-GM’s to be monitored and corrected for asymmetry prior to GNSS failure. 2. Software Architecture Overview The Renesas software is provided under a no-fee license. The terms of that license can be found and agreed to here: pcm4l Software (Note: user login is required). The Renesas PCM software solution covers network clock tracking, filtering, and a clock state machine. It is meant to interface an IEEE 1588 compliant PTP stack, such as Linux PTP (ptp4l). The PCM for Linux (pcm4l) software package has already been integrated to Linux, and can run on any Linux Distribution v3.0 or later. The software runs on an external processor running the Linux OS and interfaces the clock and timestamper unit(s) (TSU) through the PTP Clock Manage (PHC) Infrastructure. The raw PTP timestamps are provided by the IEEE 1588-2019 Slave Event Monitoring channel and either filtered by Renesas’ patented PDV noise filtering algorithm or by hardware using Renesas’ network synchronization PLLs, such as ClockMatrix. The PCM has a local oscillator state machine (LOSM) that supports the ITU-T PTP clock operating modes.

R31DS0087EU0101 Rev.1.01 Page 8 Sep.28.21 pcm4l Datasheet The PCM supports various means to stabilize the frequency and/or time of the local PTP clock. This can be by local GNSS assistance as used by the G.8275.2 Profile for APTS (and optionally being consider with G.8275.1 Profile as well). The Renesas software simplifies the complex process of integrating packet-based timing for network synchronization into a larger system. Separating the 1588 protocol from the clock recovery allows the user to use readily available PTP stacks for the protocol, to use the existing Linux kernel socket options and PTP clock infrastructure for time stamp and clock correction routing within the kernel, and to use different vendors (and drivers) for each of the 1588 system components. An example of such a PTP stack is Linux PTP, or ptp4l. The ptp4l software already implements the IEEE 1588- 2008 standard, including supporting some industry 1588 Profiles, and uses the Linux kernel PTP infrastructure to access hardware for retrieving local hardware (HW) timestamps and clock control. Many CPU/SoC vendors already provide kernel driver support for the HW-based PTP timestamper, and may even provide a driver for the PTP Hardware Clock (PHC) to control its PTP clock. The ptp4l software also supports a simple Proportional- Integral (PI) filter along with a servo and stage machine. However, this PI-filter was not designed to support the much more sophisticated adaptive algorithm would be needed to do packet selection and filtering. This is where the Renesas PCM fits in. As of LinuxPTP v3.0, a new Slave Event Monitoring channel, per IEEE 1588-2019, was added to ptp4l to allow for an external filter/servo to take control of the PTP clock. The Renesas pcm4l software also supports the Slave Event Monitoring channel as part of its PTP Stack Adaptor, and is discussed further in the following sections. Looking at the pcm4l directory structure in Figure 3, the core software (idtCore\\) comprises four component modules: Reference Tracker(s), Reference Tracker Supervisor, APTS Supervisor, and Local PTP Clock State Machine. Customers are not expected to modify the core software component modules. The PCM software communicates to the PTP stack via the PTP Stack Adaptor (ptpStack\\). The following sections provide more details. The system software component (idtSystem) contains all the adaptors and adaption code. This should not be modified, as they have already been updated for Linux.

Figure 3. Directory Structure Once a grandmaster (GM) connection has been established, the pcm4l will assign a reference tracker for that GM. The reference tracker supervisor will manage all reference trackers and maintain the local clock state machine. The following sections provide more details about each of these blocks.

2.1 Reference Trackers (RTs)

granted by the reference tracker supervisor. adaptive clock recover (both for frequency and time); more information is located in Appendix I of ITU-T G.8260.

R31DS0087EU0101 Rev.1.01 Page 10 Sep.28.21 pcm4l Datasheet Depending on the target equipment clock recommendation, one of the four reference tracker operating modes are selected: Write Phase, Adaptive Time, Assisted Time, or Adaptive Frequency, and are described in this section. The determination of which tracker mode to use will depend on the target equipment clock recommendation. For frequency synchronization using the ITU-T G.8265.1 Profile, the Adaptive Frequency Reference Tracker would be used. This is designed to meet ITU-T G.8263 (PEC-S-F) for the limits defined for case 3 in clause 7.2.2 of ITU-T G.8261.1 of <16ppb. Additionally, the Adaptive Time Reference Tracker would be used for the limits defined for case 1 or 2 in clause 7.2.2 of G.8263. For phase/time synchronization using the ITU-T G.8275.1 Profile, the Write Phase Reference Tracker would be used. This will use the PTP Hardware Clock (PHC) adjust phase control and the Renesas network timing device’s hardware filter to meet ITU-T G.8273.2 for telecom boundary clocks and telecom time slave clocks. Frequency assistance would come from the co-located EEC1/eSEC, which is again supported by the Renesas network timing device using our patented Combo mode, which provides the band-pass filtered noise transfer as defined in For phase/time synchronization using the ITU-T G.8275.2 Profile, either the Adaptive Time Reference Tracker or Assisted Time Reference Tracker would be used. These are designed to meet ITU-T G.8273.4 for telecom boundary clocks and telecom time slave clocks for use with partial timing support or assisted partial timing support from the network.

2.1.1 Write Phase Reference Tracker

A Write Phase Reference Tracker is used to track a master in a 1588-aware network, where the packet delay variation (PDV) is small. A Write Phase Reference Tracker uses the Renesas hardware digital loop filter. A software outlier filter is implemented to improve the reference tracking performance. The update rate to the hardware loop filter is based on the Sync update rate (e.g., per the ITU-T G.8275.1 Profile, this is 16 packets-per-second (pps)). The hardware loop filter must be set to a bandwidth in the range of 0.05Hz and 0.1Hz, per ITU-T G.8273.2. For other profiles, the bandwidth should be set to about 1/50th of the Sync packet rate (e.g., for the IEEE 1588 Default profile at 1pps, it would be 0.02Hz, or lower). The outlier filter is implemented in software to improve the Write Phase Reference Tracker performance. If a detected phase offset is off the mean value by the minimum outlier threshold, minOutlierThresholdNanoseconds for consecutive outlier count threshold, minOutlierCountThreshold, the detected phase offset is declared as an outlier and will not be written the DCO device. The phase offset statistics, the mean, and the standard deviation, are updated by the Write Phase Reference Tracker on every transaction. The Write Phase Reference Tracker has four stages when it starts tracking a master clock or after it has been reset by the RTS: ▪ Stage 1: Snapping Stage. Upon entering this first tracking stage, the Write Phase Reference Tracker estimates the local clock initial time offset and requests a phase snap if the offset is bigger than a threshold. After this phase snap, the local clock will be close to the master clock. The reference tracker then switches to use the PTP Hardware Clock (PHC) adjphase API. ▪ Stage 2: Converging Stage. Starting from this stage until the last stage, the Write Phase Reference Tracker writes the phase offset to the adjphase API when a forward link or reverse link time stamp pair is received. This stage takes about one minute to allow the local clock to converge to the master clock. ▪ Stage 3: Statistics Collecting Stage. At this stage, the tracker performs: collecting PDV statistics for outlier filter; writing phase offset to adjphase API; detecting and reporting locked/un-locked states to reference tracker supervisor. This stage takes 1 minute in 16 pps or higher packet rate. It will take longer time if the packet rate is lower than 16 pps. ▪ Stage 4: Tracking Stage. At this stage, the tracker updates the PDV statistics and checks for outliers. For time stamp pairs that are not outliers, the tracker writes the phase offset to the adjphase API and updates the state (locked/unlocked) to reference tracker supervisor. The Write Phase Reference Tracker remains in this stage until it is reset by the reference tracker supervisor.

R31DS0087EU0101 Rev.1.01 Page 11 Sep.28.21 pcm4l Datasheet

2.1.2 Adaptive Time Reference Tracker

An Adaptive Time Reference Tracker is designed to be used in a network where the PDV is large. It periodically analyzes the PDV statistics, and based on the PDV analysis, the Adaptive Time Reference Tracker determines the required time to collect the time stamps to achieve the target frequency or time estimation accuracy. After collecting enough time stamps, the Adaptive Time Reference Tracker will select a frequency estimation algorithm and/or a time estimation algorithm based on the PDV analysis. The frequency and/or a time offset are then estimated and local oscillator correction requests will be sent to the reference tracker supervisor. Similar to the Write Phase Reference Tracker, an outlier filter is implemented in software. When the reference tracker collects the time stamps, the outlier filter analyzes the time stamps and drops the time stamps that are far away from the average ones. The Adaptive Time Reference Tracker has three stages when it starts tracking a master clock or after it has been reset by the RTS: ▪ Stage 1: Rough Time And Frequency Correction Stage. This stage takes 10 seconds or less depending on the configuration. In this stage, the Adaptive Time reference Tracker makes a rough time estimation and sends a phase correction request to the reference tracker supervisor. If a frequency correction is configured, a rough frequency estimation is performed and a frequency correction request will be sent to the supervisor as well. Then, the Adaptive Time Reference Tracker enters the second stage. ▪ Stage 2: High Precision Frequency Correction Stage. This stage takes roughly one minute to several minutes depending on the configuration and PDV condition. The maximum time spent in this stage is determined by highPrecisionFrequencyCorrectionTimeMinutes. If the PDV is very small, this stage will take about one minute. If the PDV is not very small, the tracker will analyze the PDV and either determine how long it will need to collect time stamps or will take the configured highPrecisionFrequencyCorrectionTimeMinutes duration time to collect time stamps, depending on the lesser of the two time periods. After collecting the required time stamps, the reference tracker will perform a high-precision frequency and time estimation. Frequency and time correction requests will be sent to the reference tracker supervisor. After these corrections, the local clock should be very closely synchronized with the master clock. The tracker then transfers to the next stage. ▪ Stage 3: ToD Correction Stage. In this stage, the Adaptive Time Reference Tracker runs like an adaptive PLL. It analyzes PDV statistics, collects enough time stamps, makes a ToD offset estimation, and requests a frequency correction. The reference tracker will stay in this stage until it is reset by the reference tracker supervisor, or a large frequency or ToD offset is detected. If one of these events happens, the Adaptive Time Reference Tracker will signal the reference tracker supervisor that the lock state is lost and will then transfer to the Stage 2 - High Precision Frequency Correction Stage.

2.1.3 Assisted Time Reference Tracker

The Assisted Time Reference Tracker is designed to be used in a network where PTP will be a backup to a local time reference, such as GNSS. It performs all the functions of the Adaptive Time Reference Tracker in addition to calibrating for asymmetries using information from the local time reference (via the APTS Supervisor).The frequency and/or a time offset are then estimated and local oscillator correction requests will be sent to the reference tracker supervisor. The Assisted Time Reference Tracker has four stages when it starts tracking a master clock or after it has been reset by the APTS Supervisor: ▪ Stage 1: Idle Stage. In this stage, the Assisted Time reference Tracker is waiting for a PTP clock source. If the PTP source is available prior to a local time reference being available, phase and frequency corrections may occur in this stage for initial frequency and phase snapping (equivalent to stages 1 and 2 for Adaptive Time Reference Tracker). ▪ Stage 2: PTP Out of Specification Stage. This stage is entered when there is only a PTP clock source (no local time reference). Any previous asymmetry compensation will be disabled and the Assisted Time tracker will provide phase and frequency corrections (equivalent to stage 3 for Adaptive Time Reference Tracker). The

R31DS0087EU0101 Rev.1.01 Page 12 Sep.28.21 pcm4l Datasheet reference tracker will stay in this stage until it is reset by the reference tracker supervisor, or a large frequency or ToD offset is detected. If one of these events happens, the Assisted Time Reference Tracker will signal the reference tracker supervisor that the lock state is lost and will then transfer to the “Stage 1: Idle Stage.” ▪ Stage 3: PTP Calibration Stage. In this stage, the Assisted Time Reference Tracker is in calibration mode, and PTP corrections are disabled. The APTS supervisor is locked to the local time reference source and provides phase and frequency corrections. A calibration engine collects information from the APTS supervisor to remove any asymmetry to the PTP clock source. ▪ Stage 4: PTP Assisted Holdover Stage. In this stage, the Assisted Time Reference Tracker runs like an adaptive PLL with asymmetry compensation enabled. It analyzes PDV statistics, compensates for asymmetry, collects enough time stamps, makes a ToD offset estimation, and requests a frequency correction. The reference tracker will stay in this stage until:

• The local time reference is re-qualified and locked. If this event happens, the Assisted Time Reference Tracker will then return to the “Stage 3: PTP Calibration Stage” once lock is achieved.
• The calibration timer expires, or a reroute is detected. If one of these events happens, the Assisted Time Reference Tracker will then transfer to “Stage 2: PTP Out of Specification Stage.”
• It is reset by reference tracker supervisor, or a large frequency or ToD offset is detected. If one of these events happens, the Assisted Time Reference Tracker will signal the reference tracker supervisor that the lock state is lost and will then transfer to “Stage 1 - Idle Stage.”

2.1.4 Adaptive Frequency Reference Tracker

The Adaptive Frequency Reference Tracker is designed to be used in networks where the PDV is large and the main goal is to synchronize the frequency between the master and the slave. Similar to the Adaptive Time Reference Tracker, it periodically analyzes the PDV statistics, and based on the PDV analysis results, the tracker calculates the required time to collect the timestamps in order to achieve the target frequency synchronizing accuracy. After collecting the timestamps, the Adaptive Frequency Reference Tracker selects a frequency estimation algorithm based on the PDV analysis. The frequency offset is then estimated and the local oscillator correction requests will be sent to the reference tracker supervisor to apply the frequency corrections. The same outlier filter as Adaptive Time Reference Tracker is used. The Adaptive Frequency Reference Tracker has three stages when it starts tracking a master clock or after it has been reset by the RTS: ▪ Stage 1: Rough Time And Frequency Correction Stage. This stage takes 10 seconds or less depending on the configuration setting. In this stage, the Adaptive Frequency reference Tracker makes a rough time estimation and sends a phase correction request to the reference tracker supervisor. If a frequency correction is configured, a rough frequency estimation is performed and a frequency correction request will be sent to the supervisor as well. Then, the Adaptive Frequency Reference Tracker enters Stage 2. ▪ Stage 2: High Precision Frequency Correction Stage. This stage takes roughly one minute to several minutes to do a frequency correction, depending on the PDV statistics. The maximum time spent in this stage is determined by highPrecisionFrequencyCorrectionTimeMinutes. The tracker analyzes the PDV and determines how long it needs to collect the time stamps. After collecting the required time stamps, the reference tracker will perform a high precision frequency estimation. A frequency correction request will be sent to the reference tracker supervisor. After this correction, the local clock should be synchronized in frequency with the master clock. The Adaptive Frequency Reference Tracker then transfers to Stage 3. ▪ Stage 3: Frequency Correction Stage. In this stage, the Adaptive Frequency Reference Tracker continues periodically analyzing PDV statistics, collects enough time stamps, makes a frequency offset estimation, and requests a frequency correction to the reference tracker supervisor. The reference tracker will stay in this stage until it is reset by the reference tracker supervisor, or a large frequency offset is detected. If one of these events occurs, the Adaptive Frequency Reference Tracker will signal the reference tracker supervisor lost lock state and will then transfer to the Stage 2 - High Precision Frequency Correction Stage.

R31DS0087EU0101 Rev.1.01 Page 13 Sep.28.21 pcm4l Datasheet

2.1.5 Programmable Loop Filter

Each ReferenceTacker has a programmable Proportional + Integrator (PI) loop filter that is used with the Adaptive Time and Adaptive Frequency modes. It provides access to the Minimum Response Time, Maximum FFO Correction, Integral Branch Gain, and Bandwidth Scalar. Generally, these should be left at their defaults because they are optimized for G.8261 and G.8271.2 networks when using the Adaptive Reference Tracker(s). ▪ Minimum Response Time Seconds, dcoLoopFilter.minResponseTimeSeconds, is the target duration (in seconds) for the DCO filter to bring the Time of Day offset back to zero, if the PDV conditions permit. ▪ Maximum FFO Correction, dcoLoopFilter.maxFfoCorrection, is the absolute value of the maximum allowed FFO (fractional frequency offset) correction that the proportional branch of the loop filter can apply to the DCO. It can also be equated to a phase slope limit (PSL) in ns/s. ▪ Integral Branch Gain, dcoLoopFilter.integralBranchGain, is the gain of the integral branch of the loop filter relative to the proportional branch. ▪ Bandwidth Scalar, dcoLoopFilter.bandwidthScalar, is the DCO loop filter bandwidth scalar value. For more information on usage, please contact Renesas.

2.2 Reference Tracker Supervisor (RTS)

The RTS manages the switching between RTs. This includes concepts like hitless switching, revertive and non- revertive switching, and phase slope limiting. The use of multiple RTs is generally for Profiles that support multiple GM instances to run in parallel, such as ITU-T G.8265.1 Profile, or that support alternate master monitoring, such as ITU-T G.8275.2 Profile. When using with a PTP stack that supports multiple OC instances, a Master Selection Algorithm (MSA) is available to take advantage of additional G.8265 features, such as Wait-to-Restore and Master Lock-out.

2.2.1 Hitless Reference Switching

The hitless reference switching feature is configured in the JSON configuration file. Setting the value of “ptpPacketReferenceSwitch.referenceSwitchType” to “Hitless” will enable this feature. When a reference switch between RTs is triggered, the time offset of the selected/target master against the slave is measured. The servo then automatically compensates for this offset, so the phase transient at the clock outputs can be minimized when servo switches to another RT. In order for hitless reference switching to work, the following conditions must be met: ▪ The slave time offset to the target master must be within the time lock threshold, timeLockThresholdNanoseconds (i.e., in the time locked state). ▪ The slave frequency offset to target master must be within frequency lock threshold, frequencyLockThresholdPpb (i.e., in the frequency locked state). When all three conditions are satisfied, the servo will estimate the offset to the target master at the time of the reference switch, and this offset will be compensated at the clock output. The compensated offset, if any, at the original RT will be automatically cleared when the servo switches away from it. An option to clear any absorbed phase offset can be triggered by calling the management API mngApi_HitlessSwitchTieReset. When this API function is called, the servo will remove any phase offset compensation and start to track the master at zero phase offset.

R31DS0087EU0101 Rev.1.01 Page 14 Sep.28.21 pcm4l Datasheet

2.2.2 Phase Slope Limit and Instant Reference Switching

The phase slope limiting feature can be configured to limit the rate of output phase movement when the servo switches from one RT to another. The following parameters in “ptpPacketReferenceSwitch” configuration are used for phase slope limiting: ▪ “referenceSwitchType” – Set type to “PhaseSlopeLimit” to select reference switch type as phase slope limited switch. ▪ “phaseSlopeLimit” – The limit of output phase movement rate in the unit of nanosecond per second. If “referenceSwitchType” is set to “PhaseSlopLimit” and the slave is time locked to the target master, the value of “phaseSlopeLimit” will be applied when there is a switch between RTs. If “referenceSwitchType” is set to “PhaseSlopeLimit” and the slave is frequency locked to the target master, the frequency lock threshold will be applied when the reference switch occurs. If “referenceSwitchType” is set to “Instant”, no phase slope limit will be applied if the slave ToD offset to the target master is larger than 10 microseconds, or 1 ppm per second phase slope limit will be applied if the offset is less than 10 microseconds.

2.2.3 Reference Switching Thresholds

These thresholds take effect only if the reference switch type is hitless or phase slope limited. If the reference switch type is hitless and the absolute value of the ToD offset is within the thresholds, then apply a hitless switch; otherwise, apply a phase slope limit. If the reference switch type is phase slope limited and the absolute value of the ToD offset is within the thresholds, then apply PSL; otherwise, apply a hitless switch. The reference switch thresholds are configured by the JSON parameters lowerTodThresholdNanoseconds and upperTodThresholdNanoseconds. 2.2.4 Revertive/Non-revertive Switching (G.8265) Revertive switching is the default behavior for switching between masters. When the best master, as selected by the telecom master selection algorithm, is registered or restored due to loss of signal, etc, the servo will switch from the master it is currently tracking to the new best master. When revertive switching is disabled, master switching is non-revertive (i.e., servo will only switch to different master if the current master is disqualified due to loss of signal, etc.). One exception is when the new master that comes up is a better master than the current master the servo is tracking and the servo has not achieved frequency lock with the current master yet; in this case, the servo will switch to the new master. 2.2.5 Wait-to-Restore (G.8265) When configured, wait-to-restore ensures the previously disqualified RT (due to signal failure, etc.) is only again considered for the best master selection when it is fault-free for the time period specified by the wait to restore time. The wait to restore time can be configured globally for all masters using the configuration parameter “masterWaitToRestoreTimeoutValue”, or individually using the management API function mngApi_SetWaitToRestoreTimeout(). The following management API functions can be used to monitor/query wait to restore time for each individual master: ▪ mngApi_GetWaitToRestoreTimeout – Returns the current value of wait to restore time ▪ mngApi_IsWaitToRestoreTimerRunning – Checks whether wait to restore timer is running ▪ mngApi_ClearWaitToRestoreTimer – Clears the running wait to restore timer The unit for wait to restore time is in seconds to allow for configuration flexibility.

2.3 APTS Supervisor

PTP ToD from the PTP channel. Once the initial ToD is retrieved, it will enter the Locked state. phase/time synchronized to the local time reference.

2.4 Local Oscillator State Machine (LOSM)

fields. The following table provides a mapping of the LOSM state and the ITU-T clock mode. Table 1. ITU-T Clock Mode Mapping

Figure 4. State Machine Diagram

2.4.1 Operational States

state and enters on expiration of unqualified timer, unqualifiedTimeoutSeconds, when in the Holdover state. ▪ Lock Acquisition – At least one qualified reference is present prior to reaching the frequency locked state. threshold, timeLockThresholdNanoseconds.

2.4.2 Lock Acquisition Qualification Timeout

frequency lock can be achieved then this master will be considered unusable and will be locked out.

instance number and lockoutEnable set to E_osFalse. The lock acquisition timer is configured by the JSON parameter qualificationTimeoutSeconds.

1. Start-up System Configuration

configuration parameters themselves.

3.1 The JavaScript Object Notation (JSON)

provides the user with the flexibility to configure the operation of their 1588 implementation. The JSON Configuration file and associated scripts, files and tools can be found in the idtBuild\\idtConfig\\ directory.

3.1.1 JSON Configuration File

▪ The JSON array starts with ‘[‘ (left bracket) and ends with ‘]’ (right bracket). ends with ‘}’ (right brace). ▪ Each name is separated from its value by a ‘:’ (colon) and the name/value pairs are separated by a ‘,’ (comma). number, another JSON object, a JSON array or a true, false or null keyword. ▪ The JSON object name “_description_” is used for comments and the value is not used.

3.2 General Configuration Parameters

populated for any configuration item not present in the JSON configuration file. Table 2. Top-Level Configuration Parameters versionId “4.0” Identifies the version of software that the configuration file is compatible with. configuration file from one version of software to another. testModeEnable 0 Test mode. When test mode is enabled, data validation errors are ignored. 0 = Disabled, errors flagged and application exits. 1 = Enabled, errors flagged and application continues. ▪ “AdaptiveFrequency”: See Assisted Time Reference Tracker. ▪ “AdaptiveTime”: See Adaptive Time Reference Tracker. mgmtIpAddress “127.0.0.1” IPv4 address used by the application management interface.

15 A periodic timer is started when the LOSM enters unqualified state and is

Valid values: A non-negative 32-bit integer (seconds). remoteUdsAddress “/var/run/ptp4l” Identifies the PTP stack UDS address. localUdsAddress “/var/run/pcm4l” Identifies the local UDS address. deviceConfig N/A See Table 5. profileConfig N/A See Table 6. loggerConfig N/A See Table 7. instanceConfig N/A See Table 11. Table 3. PHC Configuration Parameters control (i.e., Renesas timing device). phaseSnapDelaySecond 2 This indicates the time to wait for a time adjustment to be reflected at the PHC. syncdConfig N/A See Table 4. Table 4. Syncd Configuration Parameters syncdPeriodSecond 1 This is the interval to run the timestamper ToD synchronization. Table 5. Device Configuration Parameters Table 2. Top-Level Configuration Parameters (Cont.)

qualificationTimeoutSeconds 900 Timeout value for the qualification timer. servo decides how to transition the DCO on loss of all PTP references. user defined FFO when entering out-of-spec. Table 6. Profile Configuration Parameters can be used to determine the IEEE 1588 frequency traceable flag. suitability of the physical PLL clock as reference. 5 = Do Not Use (i.e. not to be used as reference).

1 Specifies the clock category threshold to trigger the restoration of the physical

changed during run-time externally by management API. This parameter sets the restoration delay. Valid values: {0 - 100} In seconds. 0 means no delay. 0 Configures whether a correction is phase slope limited when in locked state. 0 = Do not apply phase slope limit in locked state. 1 = Apply phase slope limit when in locked state.

Table 7. Logger Configuration Parameters timestamp format: System time or PTP time. logFileN N/A “N” represents a log instance. See Table 9. Table 8. STDOUT Log Configuration Parameters selectionMask N/A 16-bit string bitfield to indicate type of messages to display. Table 9. Log File Configuration Parameters enable 1 This parameter is used to enable/disable this log instance. fileName N/A The name of the log file as a string of characters. Valid values: Maximum of 179 characters file name. purge 1 This boolean indicates whether the log history should be deleted or not. 0 = Append log messages to existing file. maxFileSize 1000000 Maximum File Size is the maximum size in number of bytes for this log file. Valid values: Number of bytes before log file is archived. (Max. 16 gigabytes).

Table 10. Sys Log File Configuration Parameters ipAddress “10.64.10.45” Destination IPv4 address. udpPort 514 UDP port number. Table 11. Reference Tracker Instance Configuration Parameters trackerConfig N/A See Table 12. Table 12. Reference Tracker Configuration Parameters implementation, faster lock times can be achieved.

0 Provides the option to use the initial FFO estimation to correct local oscillator

0.12 Sets the minimal proportion of the exponentially distributed component required

for PDV minimal value tracking. servo decides whether the PDV is stationary or not. maxNumberOfPhaseSnap 1 Sets the maximum number of phase snaps after initial acquisition is finished. 600 The threshold in nanoseconds to start an open-loop pull-in for phase correction. accuracy of the timestamper’s adjphase for relative time adjustment.

0.000002 This threshold is used to detect floor delay changes in the network. Valid values: A positive value expressed in seconds.

20 This threshold in nanoseconds per second is used to detect fast variations of

Valid values: A positive value expressed in nanoseconds per second.

6 This parameter specifies the duration in minutes needed for high precision

variance exceeds the PDV threshold, PTSF unusable is set. log variance must cross below the PDV Threshold minus this group’s value. snapTransitionTimestamps 4 Number of time stamps that are not usable after a phase (ToD) snap. filter can apply to the DCO. relative to the proportional branch. Bandwidth Scalar is the DCO loop filter bandwidth scalar value. desiredPrecisionSeconds 0.0000001 Sets the target precision of the ToD offset estimation. Frequency Lock is achieved. It is expressed in parts-per-billion.

1000 This is the absolute value of the ToD offset threshold below which the Time Lock

is achieved. It is expressed in nanoseconds.

0 This can be used to avoid snap collisions after a time adjustment has been

Table 12. Reference Tracker Configuration Parameters (Cont.)

1. PTP Clock Manager Management

4.1 Management APIs

“Servo Management API” of the PCM4L Reference Manual. JSON parameter: mgmtIpAddress.

4.2 Management CLI Utility

100 Any offset from master calculation determined to be greater than this in

nanoseconds will be identified as an outlier. minOutlierCountThreshold 16 Number of sequential outliers before discarding phase offset adjustments.

1. ITU-T Equipment Clock Compliances

with Paragon-NEO, unless otherwise stated.

5.1 Noise Generation

Table 13. Noise Generation[1]

1. Measured on Xilinx ZCU111 + ClockMatrix 8A34001E FMC running pcm4l v4.1 and ptp4l v3.0.
2. Measured under constant temperature (within ±1 K) and using a first-order low-pass measurement filter with a bandwidth of 0.1Hz for a
3. Using an ITU-T G.8263 compliant oscillator.See AN-807 Recommended Crystal Oscillators for Network Synchronization
4. Still for further study at ITU-T.
5. Locked to local time reference source (GNSS).
6. Provisional G.8273.2 Class D.

Figure 11. T-BC-A/T-TSC-A Dynamic Time Error Noise Generation (dTEL)

5.2 PDV Tolerance

network limits at the output (max|TE|L < 1350ns) with maximum noise at the input. The pattern is then normalized so that the peak-to-peak pktSelected2wayTE is <1100 ns. The following figures show the TE performance at the output for the two reference models. Figure 12. Reference Model 1 (652nspp)

Figure 13. Reference Model 2 (1211nspp)

reference source. The PDV models used are the same as PTS. The pattern is then normalized so that the |pktSelected2wayTE| is < 1100ns. The following figures shows the TE performance at the output for the two reference models. Figure 14. Reference Model 1 (7.5nspp)

Figure 15. Reference Model 2 (6.75nspp)

measured to the G.8261 option 1 limit. Figure 16. Test Case 12b (MTIE = 161ns)

Figure 17. Test Case 13b (MTIE = 295ns)

Figure 18. Test Case 14b (MTIE = 303ns)

Figure 19. APTS Holdover with PTP

R31DS0087EU0101 Rev.1.01 Page 37 Sep.28.21 pcm4l Datasheet 6. Glossary 7. Revision History Abbreviation Description 1PPS A 1Hz synchronization signal (one pulse per second) FCW Frequency control word Revision Date Description 1.01 Sep 28, 2021 ▪ Updated to add Assisted Partial Time Support (APTS) feature, as introduced in v4.1.0 ▪ Updated Section 5 with latest performance results based on v4.1.0 1.00 Feb 2.21 Initial release.

© 202 Renesas Electronics Corporation. All rights reserved. IMPORTANT NOTICE AND DISCLAIMER RENESAS ELECTRONICS CORPORATION AND ITS SUBSIDIARIES (“RENESAS”) PROVIDES TECHNICAL SPECIFICATIONS AND RELIABILITY DATA (INCLUDING DATASHEETS), DESIGN RESOURCES (INCLUDING REFERENCE DESIGNS), APPLICATION OR OTHER DESIGN ADVICE, WEB TOOLS, SAFETY INFORMATION, AND OTHER RESOURCES “AS IS” AND WITH ALL FAULTS, AND DISCLAIMS ALL WARRANTIES, EXPRESS OR IMPLIED, INCLUDING, WITHOUT LIMITATION, ANY IMPLIED WARRANTIES OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE, OR NON-INFRINGEMENT OF THIRD PARTY INTELLECTUAL PROPERTY RIGHTS. These resources are intended for developers skilled in the art designing with Renesas products. You are solely responsible for (1) selecting the appropriate products for your application, (2) designing, validating, and testing your application, and (3) ensuring your application meets applicable standards, and any other safety, security, or other requirements. These resources are subject to change without notice. Renesas grants you permission to use these resources only for development of an application that uses Renesas products. Other reproduction or use of these resources is strictly prohibited. No license is granted to any other Renesas intellectual property or to any third party intellectual property. Renesas disclaims responsibility for, and you will fully indemnify Renesas and its representatives against, any claims, damages, costs, losses, or liabilities arising out of your use of these resources. Renesas' products are provided only subject to Renesas' Terms and Conditions of Sale or other applicable terms agreed to in writing. No use o any Renesas resources expands or otherwise alters any applicable warranties or warranty disclaimers for these products. ('LVFODLPHURev.1.0 Mar 2020) Corporate Headquarters Contact Information TOYOSU FORESIA, 3-2-24 Toyosu, For further information on a product, technology, the most Koto-ku, Tokyo 135-0061, Japan up-to-date version of a document, or your nearest sales www.renesas.com office, please visit: www.renesas.com/contact/ Trademarks Renesas and the Renesas logo are trademarks of Renesas Electronics Corporation. All trademarks and registered trademarks are the property of their respective owners.