DS92UT16TUF Datasheet, PDF (8/86 Pages) National Semiconductor (TI) – UTOPIA-LVDS Bridge for 1.6 Gbps Bi-directional Data Transfers

6.0 Functional Description (Continued)
During normal operation in the up-bridge direction, the de-
vice monitors the HEC bytes for errors, with an option to
reject cells containing errored HEC’s. A performance metric
on the number of errored cells detected is maintained.
Although the HEC byte normally over-writes the UDF1 byte
before cells are passed out over a physical medium, the
DS92UT16 has the option to retain the UDF1 and UDF2
information fields in order to provide a truly transparent
UTOPIA bridge. If it is not necessary to pass the UDF1/2
bytes between the ATM and PHY devices at either end of the
link, then the user has the option to suppress them to im-
prove link efficiency.
Furthermore, in order to easily share-out the F Channel
bandwidth between flow control and various OAM functions,
the DS92UT16 uses a frame structure as shown in Section
6.3.6 F Channel Byte Usage Within the Frame. A frame
contains 56 transport containers with ATM cells. The start of
frame is indicated by the HEC byte of TC0, which has had
the coset x⁶ + x⁴ + x² + 1 added to it. This differentiates the
start of frame HEC from the normal cell HEC’s.
6.3.5 Flow Control
The flow control mechanism within the DS92UT16 enables
applying back-pressure to the source of the ATM cells in both
directions. The flow control works independently per queue
for all 31 queues. It uses a simple ‘halt/send’ command per
PHY Port. At the destination buffer, the fill level of each Port
queue is examined against a programmed threshold. Should
the threshold be reached, a halt command is returned to the
source, which prevents any more cells being sent to that Port
until a ‘send’ command is subsequently received. Only the
Port in question is affected, so this is a non-blocking protocol
over the normal 31 Ports. However, the 8 sub-ports within a
Port do not have individual flow control. This means a sub-
port can block other sub-ports within that Port.
Since a regular flow control opportunity is provided via the
F1/F2 bytes of the F Channel, only a small amount of head-
room need be reserved to allow for latency in this protocol.
Furthermore, should a number of PHY ports approach their
limit simultaneously and/or the overall buffer approach a
defined global threshold, a global halt may be issued, tem-
porarily blocking all traffic.
The global halt/send command also allows the user to safely
maximize the use of the shared buffer by over-assigning the
memory among the Ports.
The flow control command is illustrated in Table 3. Each port
is assigned a control bit in specified F-bytes within the frame
structure, as shown in Section 6.3.6 F Channel Byte Usage
Within the Frame. Within the F byte logic, 1 represents a
‘halt’ command to that port and logic 0 represents a ‘send’
command. A global halt is indicated by all ports containing a
halt command. The msb of Flow Control 3 byte is reserved.
TABLE 3. Flow Control Coding Within the F Bytes
Flow
Flow
Flow
Flow
Control 3
Control 2 Control 1 Control 0
Res Ports 30–24 Ports 23–16 Ports 15–8 Ports 7–0
6.3.6 F Channel Byte Usage Within the Frame
For the majority of time, the F Channel F1/F2 bytes are used
as a flow control opportunity, providing a rapid throttle-back
mechanism as described in Section 6.3.5 Flow Control. In
addition, a small number of F bytes are stolen in a regular
fashion to provide a low bandwidth OAM channel. This is
controlled by the TC number within the frame, as illustrated
in Table 4. Hence, an OAM channel is formed by the F1/F2
bytes in TCs 6, 13, 20, 27, 34, 41, 48 and 55, with the F1/F2
bytes in the remaining containers forming a flow control
signalling channel.
www.national.com
8