IEEE
`Sid 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`8 bits
`(1 octet)
`
`input data stream
`
`I
`
`I
`
`I
`
`I
`
`~~~~~i~
`6T code group formed from one octet
`coded~int~
`six ternary
`l---:---.---:2:---r--:3-,--,4---,--=-s----r--=6----,l
`symbols
`
`I.-
`
`Each ternary
`symbol = 40 ns
`
`Figure 23-4--8B6T coding
`
`which is 33.333 ... Mb/s. The temruy symbol transmission rate on each pair is 6/8 times 33.33 Mb/s, or pre(cid:173)
`cisely 25.000 MHz.
`
`Refer to annex 23A for a complete listing of 8B6T code words.
`
`The PCS ftmctions and state diagrams are specified in23.2. The PCS elecnical interface to the Mil confonns
`to the interface requirements of clause 21 . The PCS inte1face to the PMA is an abstract message-passing
`interface specified in 23.3.
`
`23.1.4.2 Summary of physical medium attachment (PMA) specification
`
`The PMA couples messages from the PMA se1v ice interface onto the twisted-pair physical medimn. The
`PMA provides comnnmications, at I 00 Mb/s, over four pairs of twisted-pair wiring up to I 00 m in length.
`
`The PMA Transmit function, shown in figure 23-2, comprises three independent temruy data transmitters.
`Upon receipt of a PMA _ UNITDATA request message, the PMA synthesizes one tema1y symbol on each of
`the three output charmels (TX_D l , BI_D3, and BI_D4). Each output driver has a temmy output, meaning
`that the output waveform cru1 asstnne ru1y of three values, conesponding to the transmission of temruy sym(cid:173)
`bols CSO, CSI or CS- I (see 23.4.3. I) on each of the twisted pairs.
`
`The PMA Receive ftmction comprises tlrree independent tema1y data receivers. The receivers are responsi(cid:173)
`ble for acquiring clock, decoding the Sta.t1 of Sb·eam Delimiter (SSD) on each channel, and providing data to
`the PCS in the synchronous fashion defined by the PMA _ UNITDATA.indicate message. The PMA also con(cid:173)
`tains ftmctions for PMA Cru·rier Sense and Link Integrity.
`
`PMA functions and state diagrams appear in 23.4. PMA electrical specifications apperu· in 23.5.
`
`23.1 .5 Application of 100BASE-T4
`
`23.1.5.1 Compatibility considerations
`
`All implementations of the twisted-pair link shall be compatible at the MDI. The PCS, PMA, and the
`medimn are defined to provide compatibility among devices designed by different mrumfacturers. Designers
`are free to implement circuiby within the PCS ru1d PI\1A (in an application-dependent marmer) provided the
`MDI (ru1d Mil, when implemented) specifications are met.
`
`23.1.5.21ncorporating the 100BASE-T4 PHY into a DTE
`
`T he PCS is required when used with a DTE. The PCS prov ides fi.mctions necessary to the overall system
`operation (such as 8B6T coding) and crumot be omitted. Refer to figure 23-I.
`
`This is ang~rchive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 101
`
` Dell Inc.
` Exhibit 1009 (Part 2 of 5)
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`When the PHY is incorporated within the physical bounds of a DTE, conformance to the MII interface is
`optional, provided that the observable behavior of the resulting system is identical to a system with a full
`MII implementation. For example, an integrated PHY may incorporate an interface between PCS and MAC
`that is logically equivalent to the MII, but does not have the full output current drive capability called for in
`the MII specification.
`
`23.1.5.3 Use of 100BASE-T4 PHY for point-to-point communication
`
`The 100BASE-T4 PHY, in conjunction with the MAC specified in clauses 1-4 (including parameterized val-
`ues in 4.4.2.3 to support 100 Mb/s operation), may be used at both ends of a link for point-to-point applica-
`tions between two DTEs. Such a configuration does not require a repeater. In this case each PHY may
`connect through an MII to its respective DTE. Optionally, either PHY (or both PHYs) may be incorporated
`into the DTEs without an exposed MII.
`
`23.1.5.4 Support for Auto-Negotiation
`
`The PMA service interface contains primitives used by the Auto-Negotiation algorithm (clause 28) to auto-
`matically select operating modes when connected to a like device.
`
`23.2 PCS functional specifications
`
`The 100BASE-T4 PCS couples a Media Independent Interface (MII), as described in clause 22, to a
`100BASE-T4 Physical Medium Attachment sublayer (PMA).
`
`At its interface with the MII, the PCS communicates via the electrical signals defined in clause 22.
`
`The interface between PCS and the next lower level (PMA) is an abstract message-passing interface
`described in 23.3. The physical realization of this interface is left to the implementor, provided the require-
`ments of this standard, where applicable, are met.
`
`23.2.1 PCS functions
`
`The PCS comprises one PCS Reset function and five simultaneous and asynchronous operating functions.
`The PCS operating functions are PCS Transmit, PCS Receive, PCS Error Sense, PCS Carrier Sense, and
`PCS Collision Presence. All operating functions start immediately after the successful completion of the
`PCS Reset function.
`
`The PCS reference diagram, figure 23-5, shows how the five operating functions relate to the messages of
`the PCS-PMA interface. Connections from the management interface (signals MDC and MDIO) to other
`layers are pervasive, and are not shown in figure 23-5. The management functions are specified in clause 30.
`See also figure 23-6, which defines the structure of frames passed from PCS to PMA. See also figure 23-7,
`which presents a reference model helpful for understanding the definitions of PCS Transmit function state
`variables ohr1-4 and tsr.
`
`23.2.1.1 PCS Reset function
`
`The PCS Reset function shall be executed any time either of two conditions occur. These two conditions are
`“power on” and the receipt of a reset request from the management entity. The PCS Reset function initializes
`all PCS functions. The PCS Reset function sets pcs_reset
` ON for the duration of its reset function. All state
`diagrams take the open-ended pcs_reset branch upon execution of the PCS Reset function. The reference
`diagrams do not explicitly show the PCS Reset function.
`
`85
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 102
`
`£
`

`
`IEEE
`Sid 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`link_status
`
`carrier_ status
`
`rx_code_vector
`
`rxerror _status
`
`PMASERVICE
`INTERFACE
`
`CRS
`
`RX_CLK
`RXD<3:0>
`RX_Dv ~------_,~
`
`RXr R
`
`MEDIA
`INDEPENDENT
`INTERFACE
`(Mil)
`
`Figure 23-5--PCS reference diagram
`
`23.2.1.2 PCS Transmit function
`
`The PCS Transmit function shall confonn to the PCS Transmit state diagram in figure 23-8.
`
`The PCS Transmit function receives nibbles limn the TXD signals of the Mil, assembles pairs of nibbles to
`form octets, converts the octets into 6T code groups according to the 8B6T code table, and passes the result(cid:173)
`ing ternary data to the PMA using the PMA _ UNITDATA request message. The state diagram of figure 23-8
`depicts the PCS Transmit function operation. Definitions of state variables tsr, ohr, sosa, sosb, eopl-5, and
`tx_ extend used in that diagram, as well as in the following text, appear in 23.2.4 .1. The physical structure
`represented in figure 23-7 is not required; it merely setves to explain the meaning of the state diagram vari(cid:173)
`ables ohr and tsr in figure 23-8. Implementors are free to constmct any logical devices having fimctionality
`identical to that described by this functional description and the PCS Transmit state diagram, figure 23-8.
`
`PCS Transmit makes use of the tsr and olu shift registers to manage nibble assembly and ternary symbol
`transmission. Nibbles from the Mil go into tsr, w hich PCS Transmit reads as octets. PCS Transmit then
`encodes those octets and writes 6T code groups to the olu registers. The PMA_ UNITDATA.request message
`passes temruy symbols from the ohr registers to the PMA. In each state diagram block, the ohr loading oper(cid:173)
`ations are conducted first, then tx_code_ vector is loaded and the state diagram waits 40 ns.
`
`The fu·st 5 octets assembled by the PCS TratiSmit function are encoded into the sosa code word and the next
`3 octets assembled are encoded into the sosb code word. TIJ.is guru·antees that evety packet begins with a
`valid preamble pattern. This is accomplished by the definition of tsr. In addition, the PCS Transmit state dia(cid:173)
`gram also specifies that at the stat1 of a packet all three output holding registers ohrl, ohr3 and ohr4 will be
`loaded with the same value (sosa). This produces the ternruy symbols labeled P3 and P4 in figure 23-6.
`
`This is ang~rchive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 103
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`At the conclusion of the MAC frame, the PCS Transmit function appends eop1-5. This is accomplished by
`defining a variable tx_extend to stretch the TX_EN signal, and defining tsr during this time to be a sequence
`of constants that decodes to the proper eop code groups.
`
`The encoding operation shall use the 8B6T code table listed in annex 23A, and the dc balance encoding rules
`listed below. Encoding is performed separately for each transmit pair.
`
`23.2.1.2.1 DC balance encoding rules
`
`The encoding operation maintains dc balance on each transmit pair by keeping track of the cumulative
`weight of all 6T code groups (see
`
`weight of 6T code group, annex 21A) transmitted on that pair. For each
`pair, it initiates the cumulative weight to 0 when the PCS Transmit function is in the AWAITING DATA TO
`TRANSMIT state. All 6T code groups in the code table have weight 0 or 1. The dc balance algorithm condi-
`tionally negates transmitted 6T code groups, so that the code weights transmitted on the line include 0, +1,
`and –1. This dc balance algorithm ensures that the cumulative weight on each pair at the conclusion of each
`6T code group is always either 0 or 1, so only one bit per pair is needed to store the cumulative weight. As
`used below, the phrase “invert the cumulative weight bit” means “if the cumulative weight bit is zero then set
`it to one, otherwise set it to zero.”
`
`After encoding any octet, except the constants sosa, sosb, eop1-5 or bad_code, update the cumulative weight
`bit for the affected pair according to rules a) through c):
`
`a)
`b)
`c)
`
`If the 6T code group weight is 0, do not change the cumulative weight.
`If the 6T code group weight is 1, and the cumulative weight bit is 0, set the cumulative weight bit to 1.
`If the 6T code group weight is 1, and the cumulative weight bit is also 1, set the cumulative weight
`bit to 0, and then algebraically negate all the ternary symbol values in the 6T code group.
`
`After encoding any of the constants sosa, sosb, or bad_code, update the cumulative weight bit for the
`affected pair according to rule d):
`
`d) Do not change the cumulative weight. Never negate sosa, sosb or bad_code.
`
`After encoding any of the constants eop1-5, update the cumulative weight bit for the affected pair according
`to rules e) and f):
`
`e)
`
`f)
`
`If the cumulative weight is 0, do not change the cumulative weight; algebraically negate all the ter-
`nary symbol values in eop1-5.
`If the cumulative weight is 1, do not change the cumulative weight.
`
`NOTE—The inversion rules for eop1-5 are opposite rule b). That makes eop1-5 look very unlike normal data, increasing
`the number of errors required to synthesize a false end-of-packet marker.
`
`23.2.1.3 PCS Receive function
`
`The PCS Receive function shall conform to the PCS Receive state diagram in figure 23-9.
`
`the
`the PMA, communicated via
`ternary symbols from
`The PCS Receive function accepts
`PMA_UNITDATA.indicate message, converts them using 8B6T coding into a nibble-wide format and
`passes them up to the MII. This function also generates RX_DV. The state diagram of figure 23-9 depicts the
`PCS Receive function. Definitions of state variables ih2, ih3, and ih4 used in that diagram, as well as in the
`following text, appear in 23.2.4.1.
`
`The last 6 values of the rx_code_vector are available to the decoder. PCS Receive makes use of these stored
`rx_code_vector values as well as the ih2-4 registers to manage the assembly of ternary symbols into 6T code
`
`87
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 104
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`groups, and the conversion of decoded data octets into nibbles. The last 6 ternary symbols for pair BI_D3 (as
`extracted from the last 6 values of rx_code_vector) are referred to in the state diagram as BI_D3[0:5]. Other
`pairs are referenced accordingly.
`
`The PCS Receive state diagram starts the first time the PCS receives a PMA_UNITDATA.indicate message
`with rx_code_vector=DATA (as opposed to IDLE or PREAMBLE). The contents of this first
`PMA_UNITDATA.indicate (DATA) message are specified in 23.4.1.6.
`
`message (state DECODE CHANNEL 3), there is
`After the sixth PMA_UNITDATA.indicate (DATA)
`
`enough information to decode the first data octet. The decoded data is transmitted across the MII in two
`parts, a least significant nibble followed by a most significant nibble (see clause 22).
`
`During state COLLECT 4TH TERNARY SYMBOL the PCS Receive function raises RX_DV and begins
`shifting out the nibbles of the 802.3 MAC SFD, least significant nibble first (SFD:LO). The most significant
`nibble of the 802.3 MAC SFD, called SFD:HI, is sent across the MII during the next state, COLLECT 5TH
`TERNARY SYMBOL.
`
`Once eop is signaled by the decode operation, the state diagram de-asserts RX_DV, preventing the end-of-
`packet bits from reaching the MII. At any time that RX_DV is de-asserted, RXD<3:0> shall be all zeroes.
`
`The decode operation shall use the 8B6T code table listed in annex 23A, and the error-detecting rules listed
`in 23.2.1.3.1. Decoding and maintenance of the cumulative weight bit is performed separately for each
`receive pair.
`
`23.2.1.3.1 Error-detecting rules
`
`The decoding operation checks the dc balance on each receive pair by keeping track of the cumulative
`weight of all 6T code group received on that pair. For each pair, initialize the cumulative weight to 0 when
`the PCS Receive function is in the AWAITING INPUT state. As in the encoding operation, only one bit per
`pair is needed to store the cumulative weight.
`
`Before decoding each octet, check the weight of the incoming code group and then apply rules a) through h)
`in sequence:
`
`a)
`
`b)
`
`c)
`
`d)
`
`e)
`
`f)
`
`g)
`
`h)
`
`If the received code group is eop1 (or its negation), set eop=ON. Then check the other pairs for con-
`formance to the end-of-packet rules as follows: Check the last four ternary symbols of the next pair,
`and the last two ternary symbols from the third pair for exact conformance with the end-of-packet
`pattern specified by PCS Transmit, including the cumulative weight negation rules. If the received
`data does not conform, set the internal variable eop_error=ON. Skip the other rules.
`If the received code group weight is greater than 1 or less than –1, set the internal variable
`dc_balance_error=ON. Decode to all zeros. Do not change the cumulative weight.
`If the received code group weight is zero, use the code table to decode. Do not change the cumula-
`tive weight.
`If the received code group weight is +1, and the cumulative weight bit is 0, use the code table to
`decode. Invert the cumulative weight bit.
`If the received code group weight is –1, and the cumulative weight bit is 1, algebraically negate each
`ternary symbol in the code group and then use the code table to decode. Invert the cumulative weight
`bit.
`If the received code group weight is +1 and the cumulative weight bit is 1, set the internal variable
`dc_balance_error=ON. Decode to all zeros. Do not change the cumulative weight.
`If the received code group weight is –1 and the cumulative weight bit is 0, set the internal variable
`dc_balance_error=ON. Decode to all zeros. Do not change the cumulative weight.
`If the (possibly negated) code group is not found in the code table, set codeword_error =ON. Decode
`to all zeros. Do not change the cumulative weight.
`
`88
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 105
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`The variables dc_balance_error, eop_error and codeword_error shall remain OFF at all times other than
`those specified in the above error-detecting rules.
`
`The codeword_error=ON indication for a (possibly negated) code group not found in the code table shall set
`RX_ER during the transfer of both affected data nibbles across the MII.
`
`The dc_balance_error=ON indication for a code group shall set RX_ER during the transfer of both affected
`data nibbles across the MII.
`
`The eop_error=ON indication shall set RX_ER during the transfer of the last decoded data nibble of the pre-
`vious octet across the MII. That is at least one RX_CLK period earlier than the requirement for
`codeword_error and dc_balance_error.
`
`These timing requirements imply consideration of implementation delays not specified in the PCS Receive
`state diagram.
`
`RX_DV is asserted coincident with the transmission across the MII of valid packet data, including the clause
`4 MAC SFD, but not including the 100BASE-T4 end-of-packet delimiters eop1-5. When a packet is trun-
`cated due to early de-assertion of carrier_status, an RX_ER indication shall be generated and RX_DV shall
`be de-asserted, halting receive processing. The PCS Receive Function may use any of the existing signals
`codeword_error, dc_balance_error, or eop_error to accomplish this function.
`
`23.2.1.4 PCS Error Sense function
`
`The PCS Error Sense function performs the task of sending RX_ER to the MII whenever
`rxerror_status=ERROR is received from the PMA sublayer or when any of the PCS decoding error condi-
`tions occur. The PCS Error Sense function shall conform to the PCS Error Sense state diagram in figure 23-
`10.
`
`Upon detection of any error, the error sense process shall report RX_ER to the MII before the last nibble of
`the clause 4 MAC frame has been passed across the MII. Errors attributable to a particular octet are reported
`to the MII coincident with the octet in which they occurred.
`
`The timing of rxerror_status shall cause RX_ER to appear on the MII no later than the last nibble of the first
`data octet in the frame.
`
`23.2.1.5 PCS Carrier Sense function
`
`The PCS Carrier Sense function shall perform the function of controlling the MII signal CRS according to
`the rules presented in this clause.
`
`While link_status = OK, CRS is asserted whenever rx_crs=ON or TX_EN=1, with timing as specified in
`23.11.2, and table 23-6.
`
`23.2.1.6 PCS Collision Presence function
`
`IDLE and the assertion of
`A PCS collision is defined as the simultaneous occurrence of tx_code_vector
`carrier_status=ON while link_status=OK. While a PCS collision is detected, the MII signal COL shall be
`asserted, with timing as specified in 23.11.2 and table 23-6.
`
`At other times COL shall remain de-asserted.
`
`89
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 106
`
`„
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IEEE
`Std 802.3u-1995
`
`23.2.2 PCS interfaces
`
`23.2.2.1 PCS–MII interface signals
`
`SUPPLEMENT TO 802.3:
`
`The following signals are formally defined in 22.2.2. Jabber detection as specified in 22.2.4.2.12 is not
`required by this standard.
`
`Table 23-1—MII interface signals
`
`Signal name
`TX_CLK
`TXD<3:0>
`TX_ER
`TX_EN
`COL
`CRS
`RX_CLK
`RXD<3:0>
`RX_DV
`RX_ER
`MDC
`MDIO
`
`Meaning
`
`Transmit Clock
`Transmit Data
`Forces transmission of illegal code
`Frames Transmit Data
`Collision Indication
`Non-Idle Medium Indication
`Receive Clock
`Receive Data
`Frames Receive SFD and DATA
`Receive Error Indication
`Management Data Clock
`Management Data
`
`23.2.2.2 PCS–Management entity signals
`
`The management interface has pervasive connections to all functions. Operation of the management control
`lines MDC and MDIO, and requirements for managed objects inside the PCS and PMA, are specified in
`clauses 22 and 30, respectively.
`
`The loopback mode of operation shall be implemented in accordance with 22.2.4.1.2. The loopback mode of
`operation loops back transmit data to receive data, thus providing a way to check for the presence of a PHY.
`
`No spurious signals shall be emitted onto the MDI when the PHY is held in power-down mode as defined in
`22.2.4.1.5 (even if TX_EN is ON) or when released from power-down mode, or when external power is first
`applied to the PHY.
`
`23.2.3 Frame structure
`
`Frames passed from the PCS sublayer to the PMA sublayer shall have the structure shown in figure 23-6.
`This figure shows how ternary symbols on the various pairs are synchronized as they are passed by the
`PMA_UNITDATA.indicate and PMA_UNITDATA request messages. Time proceeds from left to right in
`the figure.
`
`In the frame structure example, the last 6T code group, DATA N, happens to appear on transmit pair BI_D3.
`It could have appeared on any of the three transmit pairs, with the five words eop1 through eop5 appended
`afterward as the next five octets in sequence. The end of packet as recognized by the PCS is defined as the
`end of the last ternary symbol of eop1. At this point a receiver has gathered enough information to locate the
`last word in the packet and check the dc balance on each pair.
`
`If the PMA service interface is exposed, data carried between PCS and PMA by the PMA_UNITDATA.indi-
`and PMA_UNITDATA request messages shall have a clock in each direction. Details of the clock
`cate
`
`
`90
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 107
`
`

`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`CSMA/CD
`
`tx_code_vector =
`IDLE
`
`tx_code_vector =
`DATA
`
`rx_code_vector =
`IDLE
`
`rx_code_vector =
`
`PREAMBLE
`
`rx_code_vector =
`DATA
`
`IEEE
`Std 802.3u-1995
`
`tx_code_vector =
`IDLE
`
`rx_code_vector =
`IDLE
`
`TX_D1
`
`RX_D2
`
`BI_D3
`
`BI_D4
`
`BI-D4
`
`BI_D3
`
`SOSA
`
`SOSA
`
`SOSB
`
`DATA 2
`
`DATA N-1
`
`EOP_2
`
`EOP_5
`
`P3
`
`SOSA
`
`SOSA
`
`SOSB
`
`DATA 3
`
`DATA N
`
`EOP_3
`
`P4
`
`SOSA
`
`SOSB
`
`DATA 1
`
`EOP_1
`
`EOP_4
`
`2T
`
`2T
`
`2T
`
`6T
`
`Transmit
`pair
`
`Receive
`pair
`
`SSD
`Start-of-
`Stream
`Delimiter
`
`Last
`data
`octet
`
`Defined end of
`packet for timing
`references (23.11)
`carrier_status = ON
`
`End of packet recognized
`by PCS and DC balance
`checked at end of eop1
`
`Figure 23-6—PCS sublayer to PMA sublayer frame structure
`
`implementation are left to the implementor. The choice of binary encoding for each ternary symbol is left to
`the implementor.
`
`The following frame elements appear in figure 23-6 (ternary symbols are transmitted leftmost first):
`
`SOSA
`
`SOSB
`
`P3
`P4
`DATA
`
`EOP1-5
`
`[ 1 -1 1 -1 1 -1]
`
`, which is the result of
`
`The succession of six ternary symbols:
`encoding the constant sosa.
`The succession of six ternary symbols:
`encoding the constant sosb.
`.
`The succession of two ternary symbols:
`[ 1 -1]
`.
`The succession of four ternary symbols:
`[ 1 -1 1 -1]
`A 6T code group that is the result of encoding a data octet in a packet that is not part of the clause
`4 MAC preamble or SFD.
`A 6T code group that is the result of encoding one of the end-of-packet patterns eop1-5.
`
`[ 1 -1 1 -1 -1 1]
`
`, which is the result of
`
`23.2.4 PCS state diagrams
`
`The notation used in the state diagrams follows the conventions of 21.5. Transitions shown without source
`states are evaluated continuously and take immediate precedence over all other conditions.
`
`23.2.4.1 PCS state diagram constants
`
`Register tsr may take on any of the nine constant values listed below (sosa through eop5, bad_code, and
`zero_code). These values are used to describe the functional operation of the coding process.
`
`NOTE—Implementors are under no obligation to implement these constants in any particular way. For example, some
`implementors may choose to implement these codes as special flag bits attached to MII TXD nibble registers. Other
`implementors may choose to implement insertion of these codes on the downstream side of the coder function, using
`precoded 6T sequences.
`
`91
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 108
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`All 6T code words are sent leftmost ternary symbol first.
`
`A constant that encodes to:
`sosa
`A constant that encodes to:
`sosb
`A constant that encodes to:
`eop1
`A constant that encodes to:
`eop2
`A constant that encodes to:
`eop3
`A constant that encodes to:
`eop4
`A constant that encodes to:
`eop5
`bad_code A constant that encodes to:
`zero_code A constant that encodes to:
`
`].
`[
` 1 -1 1 -1 1 -1
`].
`[
` 1 -1 1 -1 -1 1
`[
`].
` 1 1 1 1 1 1
`[
`].
` 1 1 1 1 -1 -1
`[
`].
` 1 1 -1 -1 0 0
`[
`].
` -1 -1 -1 -1 -1 -1
`[
`].
` -1 -1 0 0 0 0
`[
`].
` -1 -1 -1 1 1 1
`[
`].
` 0 0 0 0 0 0
`
`23.2.4.2 PCS state diagram variables
`
`codeword_error
`Indicates reception of invalid 6T code group.
`Values:
`ON and OFF
`Set by:
`PCS Receive; error-detecting rules
`dc_balance_error
`Indicates reception of dc coding violation.
`Values:
`ON and OFF
`Set by:
`PCS Receive; error-detecting rules
`
`eop
`
`Indicates reception of eop1.
`A state variable set by the decoding operation. Reset to OFF when in PCS Receive state
`AWAITING INPUT. When the decoder detects eop1 on any pair, it sets this flag ON. The timing
`of eop shall be adjusted such that the last nibble of the last decoded data octet in a packet is the last
`nibble sent across the MII by the PMA Receive state diagram with RX_DV set ON.
`Values:
`ON and OFF
`Set by:
`PCS Receive; error-detecting rules
`eop_error
`Indicates reception of data with improper end-of-packet coding.
`Values:
`ON and OFF
`Set by:
`PCS Receive; error-detecting rules
`
`92
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 109
`
`

`
`CSMA/CD
`
`
`
`
`
`
`IEEE
`Std 802.3u-1995
`
`ih2, ih4, and ih3 (input holding registers)
`A set of holding registers used for the purpose of holding decoded data octets in preparation for
`sending across the MII one nibble at a time. One register is provided for each of the three receive
`pairs RX_D2, BI_D4, and BI_D3, respectively.
`Value:
`octet
`Set by:
`PCS Receive
`
`Each time the PCS Receive function decodes a 6T code group, it loads the result (an octet) into
`one of the ih2-4 registers. These three registers are loaded in round-robin fashion, one register
`being loaded every two ternary symbol times.
`
`The PCS Receive state diagram reads nibbles as needed from the ih2-4 registers and stuffs them
`into RXD.
`ohr1, ohr3, and ohr4 (output holding registers)
`(See figure 23-7.) A set of shift registers used for the purpose of transferring coded 6T ternary
`symbol groups one ternary symbol at a time into the PMA. One register is provided for each of the
`three transmit pairs TX_D1, BI_D3, and BI_D4, respectively.
`Value:
`6T code group. Each of the six cells holds one ternary symbol (i.e., –1, 0, or 1).
`Set by:
`PCS Transmit
`
`Each time the PCS Transmit function encodes a data octet, it loads the result (a 6T code group)
`into one of the ohr registers. Three registers are loaded in round-robin fashion, one register being
`loaded every two ternary symbol times. The PCS shall transmit octets on the three transmit pairs
`in round-robin fashion, in the order TX_D1, BI_D3, and BI_D4, starting with TX_D1.
`
`The PMA_UNITDATA request (DATA) message picks the least significant (rightmost) ternary
`symbol from each ohr register and sends it to the PMA, as shown below. (Note that 6T code words
`in annex 23A are listed with lsb on the left, not the right.)
`tx_code_vector[TX_D1] = the LSB of ohr1, also called ohr1[0]
`tx_code_vector[BI_D3] = the LSB of ohr3, also called ohr3[0]
`tx_code_vector[BI_D4] = the LSB of ohr4, also called ohr4[0]
`
`After each PMA_UNITDATA request message, all three ohr registers shift right by one ternary
`symbol, shifting in zero from the left. The PCS Transmit function loads a new 6T code group into
`each ohr immediately after the last ternary symbol of the previous group is shifted out.
`
`At the beginning of a preamble, the PCS Transmit function loads the same value (sosa) into all
`three output holding registers, which causes alternating transitions to immediately appear on all
`three output pairs. The result on pairs BI_D3 and BI_D4 is depicted by code words P3 and P4 in
`figure 23-6.
`pcs_reset
`Causes reset of all PCS functions when ON.
`Values:
`ON and OFF
`Set by:
`PCS Reset
`
`93
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 110
`
`

`
`IEEE
`Std 802.3u-1995
`
`rx_crs
`
`
`
`
`
`
`
`
`
`
`
`SUPPLEMENT TO 802.3:
`
`A latched asynchronous variable. Timing for the MII signal CRS is derived from rx_crs.
`Values:
`ON and OFF
`Set ON when:
`carrier_status changes to ON
`Set OFF when
`either of two events occurs:
`carrier_status changes to OFF, or
`detection of eop1, properly framed, on any of the lines RX_D2, BI_D4, or
`BI_D3
`
`
`
`Additionally, if, 20 ternary symbol times after rx_crs falls, carrier_status remains set to ON then
`
`
`set rx_crs=ON.
`
`NOTE—A special circuit for the detection of eop1 and subsequent de-assertion of rx_crs, faster than the full
`8B6T decoding circuits, is generally required to meet the timing requirements for CRS listed in clause
`23.11.
`
`tsr (transmit shift register)
`(See figure 23-7.) A shift register defined for the purpose of assembling nibbles from the MII TXD
`into octets.
`Values:
`
`The variable tsr always contains both the current nibble of TXD and the previous
`nibble of TXD. Valid values for tsr therefore include all octets. Register tsr may
`also take on any of the nine constant values listed in 23.2.4.1.
`Nibble order: When encoding the tsr octet, the previous TXD nibble is considered the least
`significant nibble.
`PCS Transmit
`
`Set by:
`
`During the first 16 TX_CLK cycles after TX_EN is asserted, tsr shall assume the following values
`in sequence regardless of TXD: sosa, sosa, sosa, sosa, sosa, sosa, sosa, sosa, sosa, sosa, sosb, sosb,
`sosb, sosb, sosb, sosb. This action substitutes the 100BASE-T4 preamble for the clause 4 MAC
`preamble. The PCS Transmit state diagram samples the tsr only every other clock, which reduces
`the number of sosa and sosb constants actually coded to 5 and 3, respectively.
`
`During the first 10 TX_CLK cycles after TX_EN is de-asserted, tsr shall assume the following
`values in sequence, regardless of TXD: eop1, eop1, eop2, eop2, eop3, eop3, eop4, eop4, eop5,
`eop5. This action appends the 100BASE-T4 end-of-packet delimiter to each pair. The PCS
`Transmit state diagram samples the tsr only every other clock, which reduces the number of eop1-
`5 constants actually coded to 1 each.
`
`Except for the first 16 TX_CLK cycles after TX_EN is asserted, any time TX_ER and TX_EN are
`asserted, tsr shall assume the value bad_code with such timing as to cause both nibbles of the
`affected octet to be encoded as bad_code. If TX_ER is asserted at any time during the first 16
`TX_CLK cycles after TX_EN is asserted, tsr shall during the 17th and 18th clock cycles assume
`the value bad_code.
`
`If TX_EN is de-asserted on an odd nibble boundary, the PCS shall extend TX_EN by one
`TX_CLK cycle, and behave as if TX_ER were asserted during that additional cycle.
`
`Except for the first 10 TX_CLK cycles after TX_EN is de-asserted, any time TX_EN is not
`asserted, tsr shall assume the value zero_code.
`
`94
`
`
`
`This is an Archive IEEE Standard. It has been superseded by a later version of this standard.
`
`Page 111
`
`

`
`CSMA/CD
`
`
`
`
`
`
`
`
`
`
`
`
`
`
`IEEE
`Std 802.3u-1995
`
`tx_extend
`A latched, asynchronous state variable used to extend the TX_EN signal long enough to ensure
`complete transmission of all nonzero ternary symbols in eop1-5.
`Values:
`ON and OFF
`Set ON upon:
`rising edge of TX_EN
`Set OFF upon
`either of two conditions:
`a) In the event of a collision (COL is asserted at any time during transmission)
`set tx_extend=OFF when TX_EN de-asserts.
`b) In the event of no collision (COL remains de-asserted throughout
`transmission) set tx_extend=OFF upon completion of transmission of last
`ternary symbol in eop4.
`
`NOTES
`1—The 6T code group eop5 has four zeroes at the end. The 6T code group eop4 contains the last nonzero
`ternary symbol to be transmitted.
`2—The effect of a collision, if present, is to truncate the frame at the original boundary determined by
`TX_EN. Noncolliding frames are extended, while colliding frames are not.
`
`23.2.4.3 PCS state diagram timer
`
`tw1_timer
`A continuous free-running timer.
`Values:
`The condition tw1_timer_done goes true when the timer expires.
`Restart when:
`Immediately after expiration (restarting the timer