
3.0 Client Interface
(Continued)
TABLE 3.3. Client Type (TxT/RxT) Field Definitions
T
[
1
]
T
[
0
]
Name
Description
0
0
Head
Associated symbol is a head
symbol
0
1
Data
Associated payload symbol is a
data symbol
1
0
Frame
Associated payload symbol is a
frame symbol
1
1
Null
No associated symbol
3.8 Transmit Port Head Fields
A head symbol must be loaded into the transmit port when-
ever the client wants to start a transmission, or when the
context of the loaded symbols is switched to another
stream. Redundant heads are acceptable to the controller
transmit port. If multiple heads are loaded without interven-
ing data or frame symbols, then all but the last head are
ignored. The transmit port evaluates the connection, target,
and all hop fields. The controller adds its own ID to the
source field internally, based on the local node ID value that
was set during initialization. The ACCess field is ignored and
should be set to zero by the client. Table 3.4 shows the
format of a head symbol that the local client must load into
the Tx Port to establish a connection.
TABLE 3.4. Transmit Port Head Fields
TxT
[
1:0
]
TxS
[
31:0
]
1:0
31:30 29:28 27:24 23:20 19:16 15:12 11:8
7:4
3:0
Type
Acc
Conn Srce
Trgt
HOP
[
0
]
XX
Conn XXXX Trgt Hop1 Hop2 Hop3 Hop4 Hop5
3.9 Receive Port Head Fields
The receive port head symbol format contains the same
fields as are found in heads at the transmit port, but are
shifted from their original positions when they exit the re-
ceive port. The purpose is to support routing of streams in
multiple-ring topologies. Head symbols only appear at the
receive port when there is an actual change of head. Re-
dundant head symbols are always deleted. Head symbols at
the receive port hold valid information in the connection,
source, target, and all hop fields. The ACCess field is unde-
fined and should be ignored by the client.
Table 3.5 shows the format of the head field at the receive
port of the controller.
TABLE 3.5. Receive Port Head Fields
RxT
[
1:0
]
RxS
[
31:0
]
1:0
31:30 29:28 27:24 23:20 19:16 15:12 11:8
7:4
3:0
Type
Acc
Conn
Trgt
HOP
Srce
0
XX
Conn
Trgt
Hop1 Hop2 Hop3 Hop4 Hop5 Srce
3.10 Payload Symbols at the Rx and Tx Ports
Payload symbols at the transmit or receive ports follow the
head symbol that identifies them. A payload consists of a
sequence of data and/or frame symbols that are distin-
guished by a 1 or 2 in the accompanying type field, refer to
Table 3.6. The identification of a frame or data symbol is
encoded in the Type field at the Tx and Rx port. If the type
field has a value of 1, it is a data symbol, and if the value is
2, then it is a frame symbol. The type field at the receive
port leads the symbol field that it identifies by one clock
cycle, and at the transmit port it lags the symbol field by one
clock, when PIPE is asserted. However, if the controller is in
non-pipelined timing, PIPE is negated, the type field corre-
sponds to the symbol at the same clock
TABLE 3.6. Payload Symbols at Tx/Rx Ports
Type
[
1:0
]
Tx/Rx S
[
31:0
]
1
DATA. User Defined Information
2
FRAME. User Denfined Information
3.11 Null Symbols at the Rx and Tx Ports
The lack of a head symbol or payload symbol is indicated, at
the Rx port, by null symbols whose type field is 3, and
whose other bits are undefined outputs or don’t care inputs.
At the Tx port, if a head or payload is not ready to be trans-
mitted, a null symbol code should be presented at the TxT.
The value of the type fields at the client ports is as indicated
in Table 3.7.
TABLE 3.7. Null Symbol Format
Type
[
1:0
]
Tx/Rx S
[
1:0
]
3
NULL. Don’t Care
3.12 The HOP fields and the Uniqueness of Symbol
Streams
The identity of a symbol stream is fixed by the combination
of the connection, source, target, and hop fields. If the
heads of symbol streams differ in any of these fields, then
they represent different symbol streams.
The symbols of a unique stream will always arrive in order.
Multiple streams targeted at the same node may arrive in-
terleaved. The interleaving will always be indicated by an
appropriate head symbol, identifying the switch in stream
context.
The Hop Fields were created to route packets through
bridges in multiple ring topologies. In single ring topologies
they have the function of identifying different streams. The
hop fields can be used to distinguish between 2
20
different
data streams in a single ring. However, in multiple ring topol-
ogies, every time a bridge is crossed, one hop field is used.
Therefore, it is lost for identifying unique data streams. Ta-
ble 3.8 shows the hop field locations at the transmit port
and Table 3.9 shows the hop fields at the receive port.
If the particular node is a bridge to another ring, the PIPE
signal should be negated, high voltage level. The HOP fields
rotate the same regardless of the state of the PIPE input.
The actual rotation of the Source, Target, and HOP fields
occurs at the client receive port, see Tables 3.8, 3.9. The
HOP fields rotate between the Transmit Client and the Re-
ceive Client as follows (from Receive Client perspective):
D Source bits (27:24) shift to bit field (3:0)
D All other HOP fields (including Target field) move up one
HOP field to the next more significant 4-bit positions (Ex
HOP 5 moves from (3:0)
7:4)).
Given this information the system interface should be able
to determine how the Source, Target and HOP fields rotate
up to a Ring of Rings architecture including 5 HOPs.
14