Inverse Multiplexing for ATM (IMA)
MPC8260 PowerQUICC II Family Reference Manual, Rev. 2
Freescale Semiconductor 33-71
4. GDS (Group Delay Synchronized)—Group delay synchronized achieved or group delay
synchronized not achieved. In some cases, it is not possible for the GDS to complete. GDS can not
complete if a link experiences problems during the GDS process - for example losing SYNC state
for the IFSM. If this occurs, it is not possible to determine the links true differential delay with
respect to other member links of the group. In order to determine if the GDS process completed
successfully, the ucode will set IGRST ATE[GDSS] to either of the following values after the GDS
interrupt has been generated:
IGRSTATE[GDSS] = 00 - GDS process failed, a link lost IFSM SYNC during GDS process
IGRSTATE[GDSS] = 11 - GDS process completed
Software can then read IGRSTATE[GDSS] and use this status information before deciding whether
to change the links to the active state or to try and resynchronize again at the group level. In
addition to the above status information, the ILRSTA TE[ADD_NEW_M] bit of the link that caused
the failure of the GDS process will be flipped such that it is logically inverted with respect to the
ILRCNTL[ADD_NEW] bit. It is recommended however, that software, after GDS failure and
when restarting the GDS process, changes all of the links in the group to the group unassigned state
and then update the link and group parameters to their default values before starting the GDS
process again. Note that a link losing SYNC during the GDS process can cause DCBO interrupt
for other links in the group. If this situation occurs, the GDS process should be restarted as
described above.
5. IFSD (Link (IMA) Frame Synchronization Defect)—Indicates that the link has lost
synchronization (e.g., unexpected IFSN value for a number (GAMMA + 2) of consecutive frames).
If this condition persists, the link should be removed. The threshold that would trigger the removal
of the link is system specific. The IFSD event corresponds to the “Loss of IMA Frame” (LIF) state
and the software should react to this by informing the FE (via the ICP cell, RxDefect = LIF) of the
problem. If the condition persists, IFSD events will continue to be generated every GAMMA+2
frames. The PowerQUICC II maintains counters (if enabled) to track the overall “quality” of a
particular link: see OIF (Out of IMA Frame) and ICPVIOL (ICP Violation) in Section 33.4.5.3,
“IMA Link Receive Statistics Table.” If the link returns to working state, the PowerQUICCII will
automatically perform Link Delay Synchronization and generate an LDS event upon achieving
synchronization. The software can use one of the PowerQUICCII timers as a time stamp when
handling IFSD events and check if the “persistence” time threshold has been crossed when
subsequent events take place. The LIF state time stamp should be reset when the IFSW event is
reported.
6. IFSW (Link (IMA) Frame Synchronization Working)—Indicates that the link is has achieved
frame synchronization. This event is reported when a link has been assigned to a group (start-up or
link addition) or it was previously assigned and working, but had a defect (see IFSD event). If
going from defect to working, the software should update the RxDefect field of the ICP. Again, a
time stamp (timer) can be used to measure the “persis tence” time.
7. DSL (DCB Synchronisation Lost)—Indicates that a link in a group with IGRSTATE[GDSS] = 11
loses synchronization and enters the HUNT state at the IFSM. When this interrupt occurs, the link
should be removed by software, and the CPM will no longer perform the automatic LASR
procedure. Note that when the interrupt is generated, the ILRSTATE[DL] bit is set, and the
software should clear the IMA group and link receive state information as described above for the
GDS interrupt.