XRT7245
DS3 UNI FOR ATM
á
PRELIMINARY
REV. 1.03
34
The remainder of this text will frequently refer to each
of these “entities” as:
The ATM Layer Processor
The Local Microprocessor
The Line Interface Unit (LIU) IC
1.2
Internal Operation of the XRT7245 DS3
UNI device
Whenever an ATM switch, that has access to a DS3
line, needs to transmit ATM cell data to the “Far-End”
Terminal over the DS3 line, it will write the ATM cell
data into the Transmit UTOPIA Interface block of the
XRT7245 DS3 UNI device. Afterwards, the Transmit
UTOPIA Interface block will ultimately write this cell
data to an internal FIFO (referred to as Tx FIFO
throughout this document); where it can be read and
further processed by the Transmit Cell Processor. The
Transmit UTOPIA Interface block will also perform
some parity checking on the data that it receives from
the ATM Layer processor. Finally, the Transmit UTOPIA
Interface block will provide signaling to support data-
flow control between the ATM Layer Processor and
the UNI IC.
The Transmit Cell Processor block will read in the
ATM cell from the Tx FIFO. It will then (optionally)
proceed to take the first four octets of this cell and
compute the HEC byte from these bytes. Afterwards
the Transmit Cell Processor will insert this HEC byte
into the 5th octet position within the cell. The Transmit
Cell Processor will also (optionally) scramble the pay-
load portion of the cell (bytes 6 through 53) in order
to prevent user data from mimicing framing or control
bits/bytes. Once the cell has gone through this process
it will then be transferred to the Transmit PLCP
Processor (or Transmit DS3 Framer, if the “Direct
Mapped” ATM option is selected).
If the Tx FIFO (within the Transmit UTOPIA Interface
block) is depleted and has no (user) cells available,
then the Transmit Cell Processor will automatically
generate Idle cells. These Idle cells will be processed
in the exact same manner as are the user cells, prior
to transmission to the Transmit PLCP Processor (or
the Transmit DS3 Framer) block. The Transmit Cell
Processor has provisions to allow the user to generate
an OAM cell via software control.
Note:
The OAM cells will be subjected to the same
processing (e.g., HEC Byte Calculation/Insertion and Cell
Payload Scrambling) as are user and Idle cells.
The Transmit PLCP Processor block will take 12 ATM
cells and pack them into a single PLCP frame. In addi-
tion to the ATM Cells, the PLCP frame will consists of
numerous overhead bytes and either a 13 or 14 nibble
trailer to frequency justify the PLCP frame to the
specified 8 kHz frame rate. Once these PLCP frames
have been formed they will be transferred to the
Transmit DS3 Framer.
The Transmit DS3 Framer block will take the PLCP
frame (or ATM cells, if the Direct-Mapped ATM option
was selected), and insert this data into the payload
portions of the outbound DS3 frame. The Transmit
DS3 Framer will also generate overhead (OH) bits
that support framing, performance monitoring (parity
bits), path maintenance data link as well as alarm and
status information originating from the “Near-End”
Receiver section of the UNI. The purpose of these
alarm and status information bits is to alert the “Far-
End” equipment that the “Near-End” UNI Receiver
has detected some problems in receiving data from
it. The Transmit DS3 Framer will output this DS3 data
stream to an off-chip LIU (Line Interface Unit) chip via
the TxPOS, TxNEG, and TxLineClk output pins. The
LIU chip will take on the responsibility of driving the
DS3 data out on the DS3 Transport Medium to the
“Far-End” Terminal.
Likewise, whenever ATM cell data arrives at the UNI,
over the DS3 line, the Receive DS3 Framer block will
synchronize itself to this incoming DS3 Data Stream
(containing ATM cells) via the RxPOS, RxNEG, and
RxLineClk input pins, and proceed to “strip off” and
process the OH bits of the DS3 frame. Once all of the
OH bits have been removed, the payload portion of
the received DS3 Frame should consist of either
PLCP frames or ATM cells (if the Direct-Mapped ATM
option was selected). The PLCP frames are transferred
to the Receive PLCP Processor and the “Direct-
Mapped” ATM Cells are sent onto the Receive Cell
Processor.
The Receive PLCP Processor block will take the
PLCP frame data and search for the A1 and A2
frame alignment bytes, in order to locate the PLCP
frame boundaries. Once PLCP framing is established,
the Receive PLCP Processor will proceed to check
and process the OH bytes, within the PLCP frame.
The PLCP Frames, along with framing information
are sent on to the Receive Cell Processor.
The Receive Cell Processor takes delineated PLCP
frames from the Receive PLCP Processor, and per-
forms the following operations:
Cell Delineation
HEC Byte Verification
The Receive Cell Processor takes the first four octets
of the cell (the header) and computes a HEC byte. The
Receive Cell Processor will then compare this com-
puted HEC value with that of the fifth octet, within the