XRT72L52
217
REV. 1.0.3
TWO CHANNEL DS3/E3 FRAMER IC WITH HDLC CONTROLLER
NOTE: The Message Size pertains to the size of the Information portion of the LAPD Message Frame (as presented in
Bit 3 - Flag Present
The LAPD Receiver should receive another Flag Sequence octet, which marks the End of the Message.
Therefore, this bit field should be asserted once again.
Bit 1 - EndOfMessage - End of LAPD Message Frame
Upon receiving a valid header, the EOM bit will be set “Low” (if “High” from a previous valid LAPD message
reception).
Upon receipt of the closing Flag Sequence octet, this bit-field should be asserted. The assertion of this bit-field
indicates that a LAPD Message Frame has been completely received. Additionally, if this newly received
LAPD Message is different from the previous message, then the LAPD Receiver will inform the C/P of the
EndOfMessage event by generating an interrupt.
Bit 2 - RxFCSErr - Frame Check Sequence Error Indicator
The LAPD Receiver will take the incoming (“Zero” de-stuffed) LAPD Message and compute its own version of
the Frame Check Sequence (FCS) word. Afterwards, the LAPD Receiver will compare its computed value with
that it has received from the remote LAPD Transmitter. If these two values match, then the LAPD Receiver will
presume that the LAPD Message has been properly received and the contents of the Received LAPD
Message (payload portion) will be retained at locations 0xDE through 0x135 in on-chip RAM. The LAPD
Receiver will indicate an error-free reception of the LAPD Message by keeping this bit field negated (Bit 2 = 0).
However, if these two FCS values do not match, then the received LAPD Message is corrupted and the user is
advised not to process this erroneous information. The LAPD Receiver will indicate an erred receipt of this
message by setting this bit-field to 1.
NOTE: The Receive DS3 HDLC Controller block will not generate an interrupt to the
P due to the detection of an FCS
error. Therefore, the user is advised to validate each and every received LAPD message by checking this bit-field
prior to processing the LAPD message.
Removal of Stuff Bits from the Payload Portion of the incoming LAPD Message
While the LAPD Receiver is receiving a LAPD Message, it has the responsibility of removing all of the "0" stuff
bits from the Payload Portion of the incoming LAPD Message Frame. Recall that the text in
Section 4.2.3.2indicated that the LAPD Transmitter (at the remote terminal) will insert a "0" immediately following a string of 5
consecutive “1s” within the payload portion of the LAPD Message frame. The LAPD Transmitter performs this
bit-stuffing procedure in order to prevent the user data from mimicking the Flag Sequence octet (0x7E) or the
ABORT sequence. Therefore, in order to recover the user data to its original content (prior to the bit-stuffing),
the LAPD Receiver will remove the "0" that immediately follows a string of 5 consecutive 1s.
Writing the Incoming LAPD Message into the Receive LAPD Message Buffer
The LAPD receiver will obtain the LAPD Message frame from the incoming DS3 data-stream. In addition to
processing the framing overhead octets, performing error checking (via FCS) and removing the stuffed 0s from
the user payload data. The LAPD Receiver will also write the payload portion of the LAPD Frame into the
Receive LAPD Message buffer at locations 0xDE through 0x135 in on-chip RAM.
TABLE 43: THE RELATIONSHIP BETWEEN RXLAPDTYPE[1:0] AND THE RESULTING LAPD MESSAGE TYPE AND SIZE
RXLAPD TYPE[1, 0]
MESSAGE TYPE
MESSAGE SIZE
00
CL Path Identification
76 bytes
01
Idle Signal Identification
76 bytes
10
Test Signal Identification
76 bytes
11
TU-T Path Identification
82 bytes