XRT74L73 Datasheet, PDF (139/488 Pages) Exar Corporation – 3 CHANNEL, ATM UNI/PPP DS3/E3 FRAMING CONTROLLER

PRELIMINARY
XRT74L73
3 CHANNEL, ATM UNI/PPP DS3/E3 FRAMING CONTROLLER
REV. P1.0.1
is operating in the “HUNT” state, it has no knowledge
of the location of the boundaries of the incoming
cells. In the HUNT state, the Receive Cell Processor
is searching through the incoming (“unframed”) cell
data-stream for a possible valid cell header pattern
(e.g., one that does not produce a HEC byte error).
Therefore, while in this state, the Receive Cell
Processor will read in five octets of the data that it
receives from the Receive DS3 framer. The Receive
Cell Processor will then compute a “HEC byte value”
based upon the first four of these five octets. The
Receive Cell Processor will then compare this com-
puted value with that of the 5th “read-in” octet. If the
two values are not the same, then the Receive Cell
Processor will increment its sampling set (of the 5
bytes) by one bit, and repeat the above-process with
this new set of “candidate” header bytes. In other
words, the Receive Cell Processor make its next
selection of the five octets, 53 bytes and 1 bit later.
If the Receive Cell Processor comes across a set of
five octets, that are such that the computed HEC byte
value does match the 5th (read in) octet, then the
Receive Cell Processor will transition to the
PRESYNC state.
The PRE-SYNC State
The Receive Cell Processor will transition from the
“HUNT” state to the “PRESYNC” state; when it has
located an “apparently” valid set of cell header bytes.
However, it is possible that the Receive Cell Processor
is being “fooled” by user data that mimics the cell
header byte pattern. Therefore, further evaluation is
required in order to confirm that this set of octets are
truly valid cell header bytes. The purpose of the “PRE-
SYNC” state is to facilitate this “further evaluation.”
When the Receive Cell Processor is operating in the
PRE-SYNC state, it will then begin to sample 5 “can-
didate header bytes” at 53 byte intervals. During this
sampling process, the Receive Cell Processor will
compute and compare its newly computed “HEC byte
value” with that of the fifth (read-in) octet. If the
Receive Cell Processor, while operating in the PRE-
SYNC state, comes across a single invalid cell header
byte pattern, then the Receive Cell Processor will
transition back to the “HUNT” state. However, if the
Receive Cell Processor detects “DELTA” consecutive
valid cell byte headers, then it will transition into the
SYNC state.
The SYNC State
The Receive Cell Processor will notify the local µP
(and external circuitry) of its transition to the SYNC
state by
• Generating a “Change of LCD (Loss of Cell Delin-
eation) State” interrupt. When the Receive Cell Pro-
cessor generates the “Change in LCD Condition”
interrupt, it will also set Bit 1 (LCD Interrupt Status)
within the “RxCP Interrupt Status” Register, as
depicted below.
RxCP Interrupt Status Register (Address = 4Eh)
BIT 7
RO
0
BIT 6
RO
0
BIT 5
Unused
RO
0
BIT 4
RO
0
BIT 3
RO
0
BIT 2
Received OAM
Cell Interrupt Sta-
tus
RUR
0
BIT 1
LCD Interrupt
Status
RUR
1
BIT 0
HEC Error
Interrupt Status
RUR
x
• Negating the RxLCD output pin (e.g., toggling it
“low”); and
• Setting bit 7 (RxLCD) within the RxCP Configuration
Register to “0”.
The SYNC State
When the Receive Cell Processor is operating in the
SYNC state, it will tolerate some sporadic errors in the
cell header bytes and, in some cases, even attempt to
correct them. However, the occurrence of “ALPHA”
consecutive cells with header byte errors (single or
multi-bit), will cause the Receive Cell Processor to
return to the “HUNT” state. The Receive Cell Processor
will notify the external circuitry that is is not properly
delineating cells by doing the following.
• Generating a “Change in LCD State” interrupt.
• Assert the RxLCD output pin (e.g., toggling it
“high”).
• Setting bit 7 (RxLCD) within the “RxCP Configuration
Register” to “0”, as depicted below.
140