 |
AM263Px MCU+ SDK
10.01.00
|
|
|
AM263Px MCU+ SDK
10.01.00
|
|
| Term/Abbreviation | Expansion |
|---|---|
| PRU-ICSS | Programmable Real-Time Unit Industrial Communication Subsystem |
| PTP | Precision Time Protocol |
| E2E | End to End |
| P2P | Peer to Peer |
| TC | Transparent Clock |
| OC | Ordinary clock |
| Time Source | PTP Time Source |
| Receiver | PTP Receiver |
| RCF | Syntonization/(Frequency Compensation) factor |
ICSS TimeSync Driver uses the 64-bit free running IEP Timer inside PRU-ICSS running at 200 MHz as the base timer for all synchronization related activities. PRU-ICSS has the capability to timestamp entry and exit of a frame based on this timer.
Sync signal is enabled in IEP with a sync pulse width that is relative to the sync signal generation interval. This sync is equivalent to the 1PPS output and should not be confused with PTP Sync frame. For the sync signal generation CMP1 is programmed to a value ranging from 1ms to 1 second. Firmware checks this event and re-programs it after every hit to ensure that accurate sync pulses are generated. The sync interval must not be configured such that the 1000000000 ns or 1 seconds is not an integral multiple of it. This will lead to sync signal generation which is not at the second boundary, this might impact synchronizing other devices using the sync output.
The timestamps are read from 64-bit free running IEP Timer inside PRU-ICSS running at 200 MHz. The timer has a resolution of 5 ns. The Rx and Tx timestamps are stored in PRU-ICSS Shared RAM. For Rx timestamps there is another mechanism where the timestamps are appended to the end of the frame being sent to host, this method isn't available for all protocols. In the driver, this mode is controlled by the user configurable variable timestamp_from_shared_ram (in structure TimeSync_Config_t).
For Rx, both Start of Frame (SOF) and Start of Frame Delimiter (SFD) timestamping is possible using IEP. For Tx, only SOF timestamp is available. Since PTP/1588 specifies that SFD time stamps are to be used we store the RX SFD time stamp for all frames and add 640ns to the Tx SOF time stamp, the underlying assumption being that the preamble length is 8 bytes. This is correct because PRU-ICSS inserts it's own preamble and CRC instead of copying from the received frames. It is also important to compensate the PHY delay and other known delay parameters in timestamps for accurate timing. For this purpose, txPhyLatency and rxPhyLatency (which are a part of the configuration structure TimeSync_Config_t) should be configured properly during initialization.
Following are details on timestamping availability for different PTP packets :
The PTP state machine has the following states:
When the firmware receives PTP packets initially, it puts all Announce and Management frames in highest priority queue and no sync signal is generated (until sync Time Source is determined). RCF value used is the default 1.0. Once BMCA has determined the Time Source, it's MAC ID should be provided to firmware using TimeSync_updateParentAddress. The firmware checks against this MAC ID to put Sync frames in Host queue, Announce and Management frames are always forwarded to Host. Clock synchronization starts and RCF is computed along with other values.
The stateMachine variable is part of TimeSync runtime variable timeSync_RuntimeVar_t which is a part of TimeSync_ParamsHandle. It has 5 states:
They correspond to states 3-7 of the states described earlier. States 1, 2 and 8 are implicit states.
Synchronization is about ensuring that the local clock on both Time Source and receiver reflect the same value (after adjustment for path delay). This is done by
Synchronization is done in the Sync frame context and adjustment must be complete by the time next Sync packet arrives. To calculate the drift the assumption is that seconds field is synchronized and hence only nanoseconds field is compared to find the drift irrespective of the sync interval. Exception is when there is a wraparound and Seconds field is not the same, this can happen when the receiver is so far from the Time Source that seconds field increments by the time Sync frame reaches it. Actual synchronization is done by the function TimeSync_synchronizeClock which computes the current offset from the Time Source and calls the function TimeSync_adjTimeSlowComp to adjust the IEP counter using slow compensation mechanism.
Line delay refers to the delay between PTP Time Source and Receiver. The line delay is calculated in response to the Delay request frame which is sent every time a Sync frame is received. This behavior is not mandated by the standard but is chosen for simplicity.
The API used for this is TimeSync_lineDelayCalc. It is called once the firmware receives a Delay Response packet meant for the receiver. This processing is done in the function TimeSync_processDelayResFrame.
The calculation of line delay (time distance between two nodes) is required for finding out things like clock drift and frequency syntonization factor (RCF). The mechanism for Line Delay is roughly the same for both Delay Request and Peer Delay packets.
The basic concept to understand here is that we want to find out the time it takes for a packet to traverse between the nodes. This is done by sending a packet from one node to another (usually from Time Source to receiver), which is called a sync packet. The sync packet contains a timestamp that indicates when it left the Time Source. This is present either in the correction field or the timestamp. If the device is incapable of providing an accurate timestamp in the sync packet, a follow up packet is sent which contains this information.
Upon receipt of the follow up information the receiver sends a Delay Request packet which again is timestamped like the sync packet with the exit timestamp. When a delay request is received at the Time Source, a Delay Response is sent meant only for that receiver which issued the Delay Request (Delay Response is tagged with Receiver information). The Delay Response contains the time at which Delay Request was received at the Time Source.
The entire process is depicted in the diagram below.
The timestamps are respectively indicated by t1, t2, t3 and t4.
Line delay is calculated as Mean Path Delay = (Forward Delay + Reverse Delay) / 2 = ((t2 – t1) + (t4 – t3))/ 2
Since on both receiver and Time Source the counters are free counters, it makes more sense to re-arrange the computation like this. Mean Path Delay = ((t4 - t1) – (t3 – t2))/2
Peer delay refers to the time delay between adjacent PTP nodes in a P2P network. The API for this is TimeSync_peerDelayCalc. It is called inside the function TimeSync_processPdelayRespFrame which processes the peer delay response frame. As soon as a response is detected the peer delay calculation runs, it is run for both the ports. For an adjacent node requesting a Pdelay Response the receiver gives a 2-step response. Upon receiving the Pdelay Request, it's Rx timestamp is stored and when Pdelay Response goes out, it's Tx timestamp is used to calculate the resident time. This resident time is reflected in the correction field of Pdelay Response.
The main differences compared to E2E mode is that Peer Delay Request/Response messages are used instead of Delay Request/Response messages and Sync packets are not required.
Since Peer to Peer Requests are meant for adjacent nodes, it is important that these packets are dropped and not forwarded.
Syntonization is accounting for the frequency difference between Time Source and Receiver. This is done by
The RCF or syntonization factor is computed as RCF = Time Source time/receiver time. Any delay computed on receiver is then multiplied by this factor.
For example if Time Source is running twice as fast as receiver then RCF will be 2 and any delay computed on receiver will get multiplied by this value to reflect time in terms of Time Source. In reality the RCF rarely goes out of the range 0.99-1.01 and any value outside this should be interpreted as an error.
Timestamps are recorded and Syntonization is done in a PTP task context and not inside Sync frame processing. The function which calculates RCF is TimeSync_calcRcfAndSyncInterval.
If we consider the image shown in Line Delay Calculation for E2E mode, RCF is calculated as follows.
T3 is the sync transmit timestamp from Time Source and T4 is the sync receive timestamp on receiver. T3' is T3 measured again in future (same for T4). ‘RCF = (T3’ – T3) / (T4' – T4) Mean Path Delay (compensated) = Mean Path Delay * rcf;`
This section talks about the ICSS TimeSync driver reset. The various PTP variables and state machine inside the driver require a reset every time an exception occurs. TimeSync_reset can be called for this reset.
The steps performed during this reset are
stateMachine set to 0rcf set to 1.0clockDrift and syncTimeoutInterval set to 10000driftThreshold set to init value TIMESYNC_OFFSET_STABLE_ALGO_THRESHOLDThe reset is called under the followng conditions
PTP frames have a common format but the implementation varies widely depending on the Annex or Profile in use. ICSS TimeSync driver supports following profile:
The forwarding rules for different frame types are as follows. Here forward means to Host as well as to the other port if link is available unless mentioned specifically.
This section describes the OS entities used by ICSS TimeSync. All initialization is again done in the function TimeSync_isrAndTaskInit.
txIntNum which is a part of configuration structure TimeSync_Config_t. This interrupt is mapped to the ISR TimeSync_txTSIsr.rxRTCallBack needs to be registered to process these frames in queues. Therefore, either TimeSync_processPTPFrame must be registered as rxRTCallBack, or if different types of frames (other than PTP) are coming on the high priority queues, then application must differentiate PTP frames in rxRTCallBack and then call the TimeSync_processPTPFrame API for PTP frames.ICSS TimeSync driver uses a multitude of tasks to send/process frames, act as a watchdog and for book keeping.
| Task Function Name | Description |
|---|---|
TimeSync_PdelayReqSendTask | Send Peer Delay Requests periodically on both ports. Delay is configurable. Only applicable for P2P configuration. |
TimeSync_delayReqSendTask | Send Delay requests to PTP Time Source. This is currently done for every Sync frame. Pends indefinitely on delayReqTxSemObject semaphore. Only applicable for E2E configuration. |
TimeSync_TxTSTask_P1 | Process Tx timestamp for Port 1. Pends on an event posted by Tx ISR indefinitely. |
TimeSync_TxTSTask_P2 | Same as above but for Port 2. |
TimeSync_NRT_Task | NRT stands for non real time. Processes Peer delay frames in the background and calculate peer delay. |
TimeSync_BackgroundTask | Checks for Sync timeout and performs offset stabilization. |
| Name | Description |
|---|---|
delayReqTxSemObject | This is posted when a Sync frame is received. It enables a suspended task to send Delay Request frame to PTP Time Source. Only applicable for E2E configuration. |
ICSS TimeSync driver uses a lot of events to process PTP frames. All events are in pairs, one each for physical port.
| Name | Description | Corresponding Event IDs |
|---|---|---|
txTSAvailableEvtObject | Posted by the Tx ISR to indicate that a timestamp is available and processing can be completed | eventIdSync and eventIdPdelayResp |
ptpPdelayResEvtObject | Used to process Peer Delay Response and Peer Delay Response Follow Up messages | eventIdPdelayResp and eventIdPdelayRespFlwUp |
ptpPdelayReqEvtObject | Used to process Pdelay request messages and send a response | eventIdPdelayReq |
ptpSendFollowUpEvtObject | Used to generate Follow up frame in case of forced 2-step mode | eventIdSync and eventIdFlwUpGenerated |
1.8.20