CSMA/CD
`
`tx_code_vector =
`IDLE
`
`tx_code_vector =
`DATA
`
`rx_code_vector =
`
`rx_code_vector =
`
`rx_code_vector =
`
`IEEE
`Std 802.3u-1995
`
`tx_code_vector =
`IDLE
`
`rx_oode_vector =
`
`IDLE
`
`_PREAMBLE
`
`DATA
`
`I
`
`IDLE
`
`TX_D1RX_D2
`
`SOSA E$EI§El DATA2
`I
`I
`
`DATA N-1EiIEI§Ei
`I
`
`a:_ns s:_n4
`
`
`
`lEEEE$EEEI DATA3 I DATA N EEEI
`I
`I
`I
`
`
`
`B"°4 B'—°3 IEIEEEEI DATA 1 _
`2T |2T |2T
`SSD
`Last
`Defined end of
`it t f data
`packet for timing
`6T
`Stile?‘
`Octet
`references (23_1-1)
`Denmiter
`carrier_status = ON
`
`T
`T
`Transmit Receive
`pair
`pair
`
`IEEIIEEII
`
`End of packet recognized
`by PCS and DC balance
`checked at end of eop1
`
`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
`
`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:
`
`The succession of four ternary symbols:
`
`[
`
`[
`
`[
`
`[
`
`1 -1
`
`1 -1
`
`1 -1] , which is the result of
`
`1 -1
`
`1 -1 — 1
`
`1] , which is the result of
`
`1 -1] .
`
`1 -1
`
`1 -1] .
`
`A 6T code group that is the result ofencoding a data octet in a packet that is not part ofthe clause
`4 MAC preamble or SFD.
`
`EOP1—5
`
`A 6T code group that is the result of encoding one of the end—of—packet patterns eop1—5.
`
`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 fimctional 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 T)G) nibble registers. Other
`implementors may choose to implement insertion of these codes on the downstream side of the coder function, using
`precoded 6T sequences.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
` bit 1025
`0108
`
`Aerohive - Exhibit 1025
`0108
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`All 6T code words are sent leftmost ternary symbol first.
`
`-1
`
`1 -1].
`
`-1 -1
`
`1
`
`1
`
`1].
`
`1].
`
`1 -1 -1].
`
`-1
`
`0
`
`0].
`
`-1 -1 -1}
`
`0
`
`1
`
`o
`
`o
`
`1
`
`o
`
`0].
`
`1].
`
`0].
`
`1 1 1 1
`
`-1
`
`-1
`
`0
`
`-1
`
`0
`
`sosa
`
`sosb
`
`eopl
`
`eop2
`
`eop3
`
`eop4
`
`eop5
`
`bad_code
`
`A constant that encodes to:
`
`A constant that encodes to:
`
`A constant that encodes to:
`
`A constant that encodes to:
`
`A constant that encodes to:
`
`A constant that encodes to:
`
`A constant that encodes to:
`
`A constant that encodes to:
`
`zero_code A constant that encodes to:
`
`I—II—II—II—II—II—II—II—II—I
`
`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 do coding violation.
`Values:
`ON and OFF
`
`Set by:
`
`PCS Receive; error—detecting rules
`
`eop
`
`Indicates reception of eopl.
`
`A state variable set by the decoding operation. Reset to OFF when in PCS Receive state
`AWAITING INPUT. When the decoder detects eopl on any pair, it sets this flag ON. The timing
`of eop shall be adjusted such that the last nibble ofthe last decoded data octet in a packet is the last
`nibble sent across the M11 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
`
`This is an9¢\rchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
` bit 1025
`0109
`
`Aerohive - Exhibit 1025
`0109
`
`

`
`CSMA/CD
`
`ih2, ih4, and ih3 (input holding registers)
`
`IEEE
`Std 802.3u-1995
`
`A set of holding registers used for the purpose of holding decoded data octets in preparation for
`sending across the M11 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.
`
`ohrl, 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 ofthe
`three transmit pairs TX_Dl, BI_D3, and BI_D4, respectively.
`
`Value:
`
`Set by:
`
`6T code group. Each of the six cells holds one ternary symbol (i.e., -1, 0, or 1).
`
`PCS Transmit
`
`Each time the PCS Transmit function encodes a data octeg 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_Dl, 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_Dl] = the LSB of ohrl, also called ohrl [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:
`
`Set by:
`
`ON and OFF
`
`PCS Reset
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standgajd.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0110
`
`

`
`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:
`Set OFF when
`
`carrier_status changes to ON
`either of two events occurs:
`
`carrier_status changes to OFF, or
`detection of eopl, 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 eopl 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 ofassembling nibbles from the MII TXD
`into octets.
`
`Values:
`
`The variable tsr always contains both the current nibble ofTXD 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.
`
`Set by:
`
`PCS Transmit
`
`During the first 16 TX_CLK cycles afier 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 l00BASE-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 alter TX_EN is de-asserted, tsr shall assume the following
`values in sequence, regardless of TXD: eopl, eopl, eop2, eop2, eop3, eop3, eop4, eop4, eop5,
`eop5. This action appends the l00BASE-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 eopl-
`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 afier 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.
`
`This is an94\rchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0111
`
`

`
`CSMA/CD
`
`tx_extend
`
`IEEE
`Std 802.3u-1995
`
`A latched, asynchronous state variable used to extend the TX_EN signal long enough to ensure
`complete transmission of all nonzero ternary symbols in eopl-5.
`Values:
`ON and OFF
`
`Set ON upon:
`
`rising edge of TX_EN
`
`Set OFF upon
`
`NOTES
`
`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.
`
`l—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 trlmcate the fiarne 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
`
`twl_timer
`
`A continuous free-running timer.
`
`Values:
`
`The condition twl_timer_done goes true when the timer expires.
`
`Restart when:
`
`Duration:
`
`Immediately after expiration (restarting the timer resets condition
`twl_timer_done).
`40 ns nominal.
`
`TX_CLK shall be generated synchronous to twl_timer (see tolerance required for TX_CLK in
`23.5.l.2.lO).
`
`On every occurrence of twl_timer_done, the state diagram advances by one block. The message
`PMA_UN1TDATA request is issued concurrent with twl_timer_done.
`
`23.2.4.4 PCS state diagram functions
`
`encode()
`
`decode()
`
`The encode operation of 23.2. 1 .2.
`
`Argument:
`
`octet
`
`Returns:
`
`6T code group
`
`The decode operation of 23.2.1.3.
`
`Argument:
`Returns:
`
`6T code group
`octet
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standgrd.
`
` bit 1025
`0112
`
`Aerohive - Exhibit 1025
`0112
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`Mll
`
`(25 MHz clock)
`
`
`
`61-
`
`parallel load
`
`ohr1 [0]
`
`tx_code_vector
`takes lsb
`from each
`ohr
`
`
`
`clear ohr3 & 4
`during collisions
`
`
`
`tsr 4 l4— ohr1, 3 and 4
`
`CLR
`
`msb
`ls
` b ohr4[0]
`—Pl
`
`
`
`Loading sequence for registers OHR1. 3, & 4
`speciai constants used by 1-SR
`parallel load ohr1 —l_l—i—i—i—i—l_l—i—
`start of packet
`end of packet parallel load ohr3 —.—.—l_l—.—.—.—.—l_
`TX_ER = 1
`parallel load ohr4 —|—I—I—I—l—l—I—|—|—
`—>l|<—
`TX_CLK period
`
`This is aI'l9€\l'ChlVe
`
`IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0113
`
`

`
`CSMNCD
`
`23.2.4.5 PCS state diagrams
`
`AwArr|N(3 DATA To Tnm-.|sM|T
`
`t_‘_mde_vedm C: IDLE
`PMA_UNlTDATA_reques1(tx_code_vec1or)
`
`cs reset = ON
`‘P;
`txjmem 2 OFF
`
`tx_extend = U * tw1_timer_done
`
`tx_extend = 1
`‘ tw1_iJ'mer_done
`
`COLLECT 1ST NIBBLE
`
`c= IDLE
`lX_D0d€_V€Ct0f
`PMA_UNlTDATA request(tx_oode_vecLor)
`
`tw1_timer_done
`
`COLLECT NIBBLE 2: CODE 1ST octet
`(First octet always codes to Sosa)
`ohr1c= ohr3 ¢= ohrat .:= 5053
`lX_00de_VeCt0r = (DhI1[0l. 0t=r3[0]. 0hr4i0]J
`PMA_UN|TDF-TA-re<iUB5i(D4_C0de_Vect0r)
`tw1_timer_done
`
`T‘?
`
`COLLECT NIBBLE 6N+3
`
`IEEE
`Std BC|2_3u—1995
`
`The Mll TX_CLK is generated
`sgmchronousiy with the transitions of
`
`of this state diagram.
`See definitions at
`PCS state variables in
`23.2.4 2.
`
`;
`
`COLLECT NIBBLE 5N+5
`
`snrn ngm onn, 0hr3 and aim
`tx_oode_\iector c: (:)hr1[0]_ uhr3[D], ohr4{(]])
`PMA_UNITDAT-MeqUB51(bt_E0de_VB€10r)
`tw1_timei_dane
`
`Y
`COLLECT NIBBLE 6N+6
`shifl ii-gh ohr1 and ohra
`ohrai 4:: enoode( tsr)
`tx_code_vect0r c: (ohr1[0], ohr3[t]], ohr4[0])
`PMA uNiTDATA_requesi(tx code vector}
`
`tw1_tirner_done
`
`Y
`COLLECT NIBBLE EN-I7
`
`shifl right ohr1, 0hI'3 and ohrzt
`b(_code_vector -: (ohr1[(]], onr3[G], ohr4[D])
`F’MA_UNlTDATA.request(Ix_oode_vei:tor)
`
`Sh?“ Tight OHT1. ONF3 3713 OTIT4
`b€_C0de_Ve€10r
`== (0hI1[0]. 0hr3[0]. 0hr4[0])
`PMA_UNITDF-TA-reqUeSt(b<_00de_Vect0r)
`
`tw1_“mer_dme
`
`tw1_timer_done
`
`COLLECT NIBBLE 6N+4
`
`COLLECT NIBBLE 5N+EI
`
`shift right ohm and ohrzt
`mm c enwde( Br J
`ix_coae_ue::1or ¢': (ohr1{G]_ main], uhr4[lJ])
`PMA_UNlTDATA_request(tx_coue_vec10r)
`{W1 1'
`d
`_ lmer_ one
`
`shin n-gm 0m.3 and ohm
`ohr1 c: enc0de( tsr }
`t:;fl°:dE;‘":°D1‘:T: (“"1 Eaxnhmgl‘ °hcr14m)]’
`_
`.reqUe
`_C0 e_VB OT
`
`tW1_ imer_dnne
`
`Figure 23-8—PCS Transmit state diagram
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exh
`
`Aerohive - Exhibit 1025
`0114
`
`

`
`IEEE
`Std 802.3u-1995
`
`pcs_reset = ON
`
`
`
`AWAITING INPUT
`
`RX_DV <= 0; RXD<3:0><= oooo; eop 4:: OFF
`
`rx_code_vector = DATA
`* PMA_UN|TDATA.indica1e
`
`SUPPLEMENT TO 802.3:
`
`See definitions of
`PCS state variables in
`23.2.4.2.
`
`(carrier_status = OFF) " (RX_DV = 1)
`
`eop = 0N
`
`l
`
`INSERT RX_ER
`RX_DV<= 1; RX_ER¢=1
`
`
`
`
`pMA_uN|TDATA_indicate
`
`COLLECT 1ST TERNARY SYMBOL
`
`PMA_UN|TDATA.indicate
`
`COLLECT 2ND TERNARY SYMBOL
`
`RX_DV c: 0; RXD<3:O> c: 0000
`
`
`
`
`AWAITING IDLE
`
`RX_DV : 0; RXD<3:O> c 0000
`
`
`
`(rx_code_vector = IDLE)
`+ (rx_code_vector = PREAMBLE)
`
`RX_DV c: 0; RXD<3:O> <: 0000
`
`PMA_UN|TDATA.indicate
`
`COLLECT 3RD TERNARY SYMBOL
`
`RX_DV = o; RXD<3:O> ¢= oooo
`
`PMA_UNlTDATA.indicate
`
`COLLECT 4TH TERNARY SYMBOL
`RXD<0:3> c SFD:LO
`
`DECODE CHANNEL 2
`
`ih2 c deoode(RX_D2[0:5])
`RXD<0:3> <= ih2:LO
`RX_DV <= 1
`
`RX_DV <= 1
`
`PMA UN|TDATA.indite
`‘
`
`_
`_
`PMA_UN|TDATA.IndIcate
`
`COLLECT 5TH TERNARY SYMBOL
`
`RXD<0:3> <= SFD:Hl
`RX_DV = 1
`
`RX_DV <= 1
`
`GET (6N+5)TH SYMBOL CHANNEL 4
`RXD<0:3> c ih2:Hl
`
`PMA_UN|TDATA.indicate
`
`PMA_UN|TDATA.indicate
`
`DECODE CHANNEL 3
`
`ma <: deoode(Bl_D3[O:5])
`RXD<0:3> c ih3:LO
`
`RX_DV c 1
`
`DECODE CHANNEL 4
`
`ih4 : decode(B|_D4[0:5])
`RXD<0:3> <= ih4:L0
`RX_DV c 1
`
`pMA_uN|TDATA_indicate
`
`PMA_UN|TDATA.indicate
`
`RX_DV c 1
`
`GET (6N+5)TH SYMBOL CHANNEL 2
`RXD<0:3> <= ih3:H|
`
`RX_DV c: 1
`
`GET (6N+5)TH SYMBOL CHANNEL 3
`RXD<0:3> = ih4:Hl
`
`PMA_UN|TDATA.indicate
`
`PMA_UN I-I-DA-I-A_indicate
`
`This is anggtrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`0115
`
`bit 1025
`
`Aerohive - Exhibit 1025
`0115
`
`

`
`CSMA/CD
`
`IEEE
`Std 802.3u-1995
`
`pcs_reset = ON
`
`NO ERROR
`
`de-assert RX_ER
`
`codeword_error = ON
`+ dc_ba|ance_error = ON
`+ eop_error = ON
`
`PCS ERROR
`
`assert RX_ER
`
`
`
`assert RX_ER
`
`carrier_status = OFF
`
`
`
`
`
`See timing requirements in 23.2.1.4.
`
`23.2.5 PCS electrical specifications
`
`The interface between PCS and PMA is an abstract message-passing interface, having no specified electrical
`properties.
`
`Electrical characteristics of the signals passing between the PCS and M11 may be found in clause 22.
`
`23.3 PMA service interface
`
`This clause specifies the services provided by the PMA to either the PCS or a Repeater client. These services
`are described in an abstract manner and do not imply any particular implementation.
`
`The PMA Service Interface supports the exchange of code vectors between the PMA and its client (either
`the PCS or a Repeater). The PMA also generates status indications for use by the client.
`
`The following primitives are defined:
`
`PMA_TYPE.indicate
`
`PMA_UNITDATA.request
`
`PMA_UNITDATA.indicate
`
`PMA_CARR1ER.indicate
`
`PMA_LINK.indicate
`
`PMA_LINK request
`
`PMA_RXERROR.indicate
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standgajd.
`
`bit 1025
`
`
`
`rxerror_status = ERROR
`
`:9: carrier_s‘[atu5 :
`
`PMA ERROR
`
`°°deW°"d—e"°" = OFF
`* dc_ba|ance_error =
`* eop_error = OFF
`
`Aerohive - Exhibit 1025
`0116
`
`

`
`IEEE
`Std 802.3u-1995
`
`23.3.1 PMA_TYPE.indicate
`
`SUPPLEMENT TO 802.3:
`
`This primitive is generated by the PMA to indicate the nature of the PMA instantiation. The purpose of this
`primitive is to allow clients to support connections to the various types of IOOBASE-T PMA entities in a
`generalized manner.
`
`23.3.1.1 Semantics of the service primitive
`
`PMA_TYPE.indicate (pma_type)
`
`The pma_type parameter for use with the 100BASE-T4 PMA is T4.
`
`23.3.1.2 When generated
`
`The PMA shall continuously generate this primitive to indicate the value of pma_type.
`
`23.3.1.3 Effect of receipt
`
`The client uses the value of pma_type to define the semantics of the PMA_UNITDATA.request and
`PMA_UNITDATA.indicate primitives.
`
`23.3.2 PMA_UN|TDATA.request
`
`This primitive defines the transfer of data (in the form of tx_code_vector parameters) from the PCS or
`repeater to the PMA.
`
`23.3.2.1 Semantics of the service primitive
`
`PMA_UNITDATA.request (tx_code_vector)
`
`When transmitting data using 100BASE-T4 signaling, the PMA_UNITDATA.request conveys to the PMA
`simultaneously the logical output value for each of the three transmit pairs TX_Dl, BI_D3, and BI_D4. The
`value of tx_code_vector during data transmission is therefore a three-element vector, with one element cor-
`responding to each output pair. Each of the three elements of the tx_code_vector may take on one of three
`logical values: 1, 0, or -1, corresponding to the three ternary possibilities +, 0, and - listed for each ternary
`symbol in the 8B6T code table (see armex 23A).
`
`Between packets, the 100BASE-T4 PMA layer sends the 100BASE-T4 idle signal, TP_IDL_100. The PCS
`informs the PMA layer that it is between packets, thus enabling the PMA idle signal, by setting the
`tx_code_vector parameter to IDLE.
`
`For pma_type 100BASE-T4, the tx_code_vector parameter can take on either of two forms:
`
`IDLE
`
`DATA
`
`A single value indicating to the PMA that there is no data to convey. The PMA generates
`link integrity pulses during the time that tx_code_vector = IDLE.
`
`A vector ofthree ternary symbols, one for each ofthe three transmit pairs TX_D 1 , BI_D3 ,
`and BI_D4. The ternary symbol for each pair may take on one ofthree values, 1, 0, or -1.
`
`The ternary symbols comprising tx_code_vector, when they are conveyed using the DATA format, are
`called,
`according
`to
`the pair
`on which
`each will be
`transmitted,
`tx_code_Vector[BI_D4],
`tx_code_vector[TX_D1], and tx_code_vector[BI_D3].
`
`This is anlegchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0117
`
`

`
`CSMA/CD
`
`23.3.2.2 When generated
`
`IEEE
`Std 802.3u-1995
`
`The PCS or Repeater client generates PMA_UNITDATA.request synchronous with every M11 TX_CLK.
`
`For the purposes of state diagram descriptions, it may be assumed that at the time PMA_UNITDATA request
`is generated, the MII signals TX_EN, and TX_ER, and TXD instantly become valid and that they retain their
`values until the next PMA_UNITDATA request.
`
`In the state diagrams, PMA_UNITDATA.request is assumed to occur at the conclusion of each twl wait
`function.
`
`23.3.2.3 Effect of receipt
`
`Upon receipt of this primitive, the PMA transmits the indicated ternary symbols on the MDI.
`
`23.3.3 PMA_UNlTDATA.indicate
`
`This primitive defines the transfer of data (in the form of rx_code_vector parameters) from the PMA to the
`PCS or repeater during the time that link_status=OK.
`
`23.3.3.1 Semantics of the service primitive
`
`PMA_UNITDATA.indicate (rx_code_vector)
`
`When receiving data using IOOBASE-T4 signaling, the PMA_UNITDATA.indicate conveys to the PCS
`simultaneously the logical input value for each of the three receive pairs RX_D2, BI_D4, and BI_D3. The
`value of rx_code_vector during data reception is therefore a three-element vector, with one element corre-
`sponding to each input pair. Each of the three elements of the rx_code_vector may take on one of three logi-
`cal values: 1, 0, or -1, corresponding to the three ternary possibilities +, 0, and - listed for each ternary
`symbol in the 8B6T code table (see annex 23A).
`
`Between packets, the rx_code_vector is set by the PMA to the value IDLE.
`
`From the time the PMA asserts carrier_status=ON until the PMA recognizes the SSD pattern (not all of the
`pattern need be received in order for the PMA to recognize the pattern), the PMA sets rx_code_vector to the
`value PREAMBLE.
`
`For pma_type 100BASE-T4, the rx_code_vector parameter can take on any of three forms:
`
`IDLE
`
`A single value indicating that the PMA has no data to convey.
`
`PREAMBLE
`
`A single value indicating that the PMA has detected carrier, but has not received a valid
`SSD.
`
`DATA
`
`A vector ofthree ternary symbols, one for each of the three receive pairs RX_D2, BI_D3,
`and BI_D4. The ternary symbol for each pair may take on one of three values, 1, 0, or -1.
`
`The ternary symbols comprising rx_code_vector, when they are conveyed using the DATA format, are
`called,
`according to the pair upon which each symbol was
`received,
`rx_code_vector[BI_D3],
`rx_code_vector[RX_D2], and rx_code_vector[BI_D4].
`
`23.3.3.2 When generated
`
`The PMA shall generate PMA_UNITDATA.indicate (DATA) messages synchronous with data received at
`the MDI.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0118
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`23.3.3.3 Effect of receipt
`
`The effect of receipt of this primitive is unspecified.
`
`23.3.4 PMA_CARRIER.indicate
`
`This primitive is generated by the PMA to indicate the status of the signal being received from the MDI. The
`purpose of this primitive is to give the PCS or repeater client the earliest reliable indication of activity on the
`underlying medium.
`
`23.3.4.1 Semantics of the service primitive
`
`PMA_CARRlER.ir1d1'cate (car'rier_status)
`
`The carrier_status parameter can take on one of two values: OFF or ON, indicating whether the incoming
`signal should be interpreted as being between packets (OFF) or as a packet in progress (ON).
`
`23.3.4.2 When generated
`
`The PMA shall generate this primitive to indicate the value of carrier_status.
`
`23.3.4.3 Effect of receipt
`
`The effect of receipt of this primitive is unspecified.
`
`23.3.5 PMA_LINK.indicate
`
`This primitive is generated by the PMA to indicate the status of the underlying medium. The purpose of this
`primitive is to give the PCS or repeater client or Auto-Negotiation algorithm a means of determining the
`validity of received code elements.
`
`23.3.5.1 Semantics of the service primitive
`
`PMA_LINK.indicate (link_status)
`
`The link_status parameter can take on one of three values: FAIL, READY, or OK:
`
`FAIL
`
`READY
`
`OK
`
`The link integrity fimction does not detect a valid 100BASE—T4 link.
`
`The link integrity fimction detects a valid 100BASE—T4 link, but has not been enabled by
`Auto-Negotiation.
`
`The 100BASE—T4 link integrity function detects a valid 100BASE—T4 link, and has been
`enabled by Auto-Negotiation.
`
`23.3.5.2 When generated
`
`The PMA shall generate this primitive to indicate the value of link_status.
`
`23.3.5.3 Effect of receipt
`
`The efl'ect of receipt of this primitive is unspecified.
`
`This is anlagrchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0119
`
`

`
`CSMA/CD
`
`23.3.6 PMA_LlNK.request
`
`IEEE
`Std 802.3u-1995
`
`This primitive is generated by the Auto—Negotiation algorithm. The purpose of this primitive is to allow the
`Auto—Negotiation algorithm to enable and disable operation of the PHY.
`
`23.3.6.1 Semantics of the service primitive
`
`PMA_LINK request (lir1k_control)
`
`The link_control parameter can take on one of three values: SCAN_FOR_CARRIER, DISABLE, or
`ENABLE.
`
`SCAN_FOR_CARR[ER Used by the Auto—Negotiation algorithm prior to receiving any fast link
`pulses. During this mode the PHY reports 1ink_status=READY if it
`recognizes IOOBASE-T4 carrier from the far end, but no other actions are
`enabled.
`
`DISABLE
`
`ENABLE
`
`Used by the Auto—Negotiation algorithm to disable PHY processing in
`the event fast link pulses are detected. This gives the Auto—Negotiation
`algorithm a chance to determine how to configure the link.
`
`Used by Auto—Negotiation to turn control over to the PHY for data
`processing functions. This is the default mode ifAuto—Negotiation is not
`present.
`
`23.3.6.2 Default value of parameter link_control
`
`Upon power-on, reset, or release fiom power-down, the link_control parameter shall revert to ENABLE. If
`the optional Auto—Negotiation algorithm is not implemented, no PMA_LINK.request message will arrive
`and the PHY will operate indefinitely with link_control=ENABLE.
`
`23.3.6.3 When generated
`
`The Auto—Negotiation algorithm generates this primitive to indicate to the PHY how to behave.
`
`Upon power-on, reset, or release from power down, the Auto—Negotiation algorithm, if present, issues the
`message PMA_LINK request (SCAN_FOR_CARRIER).
`
`23.3.6.4 Effect of receipt
`
`Whenever link_control=SCAN_FOR_CARRIER, the PHY shall enable the Link Integrity state diagram, but
`block passage into the state LINK_PASS, while holding rcv=DISABLE, and xmit=DISABLE. While
`link_control=SCAN_FOR_CARRIER,
`the PHY shall
`report
`link_status=READY if it
`recognizes
`IOOBASE-T4 link integrity pulses coming from the far end, otherwise it reports link_status=FAIL.
`
`Whenever 1ink_contro1=DISABLE, the PHY shall report link_status=FAIL and hold the Link Integrity state
`diagram in the RESET state, while holding rcv=disable and xmit=DISABLE.
`
`While link_control=ENABLE, the PHY shall allow the Link Integrity function to determine if the link is
`available and, if so, set rcv=ENABLE and xmit=ENABLE.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0120
`
`

`
`IEEE
`Std 802.3u-1995
`
`23.3.7 PMA_RXERROR.indicate
`
`SUPPLEMENT TO 802.3:
`
`The primitive is generated in the PMA by the PMA Align function to indicate the status of the signal being
`received from the MDI. The purpose of this primitive is to give the PCS or repeater client an indication of a
`PMA detectable receive error.
`
`23.3.7.1 Semantics of the service primitive
`
`PMA_RXERROR.indicate (rxerror_status)
`
`The rxerror_status parameter can take on one of two values: ERROR or NO_ERROR, indicating whether the
`incoming signal contains a detectable error (ERROR) or not (NO_ERROR).
`
`23.3.7.2 When generated
`
`The PMA shall generate this primitive to indicate whether or not each incoming packet contains a PMA
`detectable error (23 .2. 1 .4).
`
`23.3.7.3 Effect of receipt
`
`The efl'ect of receipt of this primitive is unspecified.
`
`23.4 PMA functional specifications
`
`The PMA couples messages from a PMA service interface (23.3) to the 100BASE-T4 baseband medium
`(23.6).
`
`The interface between PCS and the baseband medium is the Medium Dependent Interface (MDI), specified
`in 23.7.
`
`23.4.1 PMA functions
`
`The PMA sublayer comprises one PMA Reset function and six simultaneous and asynchronous operating
`functions. The PMA operating functions are PMA Transmit, PMA Receive, PMA Carrier Sense, Link Integ-
`rity, PMA Align, and Clock Recovery. All operating firnctions are started immediately after the successful
`completion of the PMA Reset function. When the PMA is used in conjunction with a PCS, the RESET func-
`tion may be shared between layers.
`
`The PMA reference diagram, figure 23-11, shows how the operating functions relate to the messages of the
`PMA Service interface and the signals of the MDI. Connections from the management interface, comprising
`the signals MDC and MDIO, to other layers are pervasive, and are not shown in figure 23-11. The Manage-
`ment Interface and its functions are specified in clause 22.
`
`23.4.1.1 PMA Reset function
`
`The PMA Reset firnction 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 PMA Reset function initializes
`all PMA functions. The PMA Reset function sets pma_reset <= ON for the duration of its reset function. All
`state diagrams take the open-ended pma_reset branch upon execution of the PMA Reset function. The refer-
`ence diagrams do not explicitly show the PMA Reset function.
`
`This is anlarchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`bit 1025
`
`
`
`Aerohive - Exhibit 1025
`0121
`
`

`
`CSMNCD
`
`IEEE
`Std BC|2_3u—1995
`
`Optional clause 23: Iink_contIo|
`
`LINK
`INTEGRITY
`
`|ink_status
`‘T
`
`tx_code_eiement
` ,
`
`carn'er_status
`
`PMA CARRiER
`SENSE
`
`rx_code_vector
`‘T
`rxenor_stalus
`Ia
`
`PMH SERVICE
`NTERFACE
`
`PMA
`RECEIVE
`
`iv
`CLOCK
`
`RECOVERY
`
`Figure 23-1 1—PMA reference diagram
`
`MEDIUM
`DEPENDENT
`mrenmce
`(MDI)
`
`23.4.1.2 PMA Transmit function
`
`Except as provided for in the next paragraph. whenever (tx_code_vector=DATA)><(pma_carrier=OFF), the
`PMA shall
`transmit onto the MDI ternary symbols on pairs TX_Dl, BI_D3, and BI_D4 equal
`to
`tx_code_vecto1'[TX_D1], tx_code_vector[BI_D3], and tx_code_vecto1‘[BI_D4], respectively.
`
`Whenever (tx_code_vector=DATA)><(pma_carIie1=ONj, the PMA shall transmit onto the MDI ternary sym-
`bols on pairs TX_D1_. BI_D3, and BI_D4 equal to tx_code_vector[TX_Dl], CS0, and CS0, respectively, and
`continue doing so until tx_code_vecto1=]DLE.
`
`NOTE—This shuts olf the transmitters on channels BI_D3 and BI_D4_. and keeps them 0E. in tlie event of a collision.
`Shutting ofltlie transniitters prevents overload and saturation of me transmitters. and also reduces the amount of near-
`end crosstalk present while monitoring for the end of carrier.
`
`Whenever tx_code_vecto1=]DLE, an idle signal shall be transmitted on pair TX_Dl and silence o11 pairs
`BI_D3 and BI_D4. The idle signal consists of periods of silence (times where the differential output voltage
`remains at 0 mV :: 50 mV) broken by the transmission of link integrity test pulses.
`
`The IOOBASE-T4 idle signal is similar to the IOBASE-T idle signal, but with IOOBASE-T4 ternary signal
`levels and a faster repetition 1'ate. The IUUBASE-T4 idle signal is called TP_IDL_100. The "[P_IDL_I00
`signal shall be a repeating sequence formed from one 1.2 ms :: 0.6 ms period of silence (the time where the
`differential voltage remains at 0 mV :: 50 mV) and one link test pulse. Each link test pulse shall be a succes-
`sion of two ternaijr symbols having logical values of —l and 1 transmitted on pair TX_Dl using CS-1 and
`CS1 as defined in 23.4.3.1. Following a packet, the TP_]DL_100 shall start with a period of silence.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`Aerohive - Exh
`
`Aerohive - Exhibit 1025
`0122
`
`

`
`IEEE
`Std 802.3u-1995
`
`SUPPLEMENT TO 802.3:
`
`Transmission of TP_IDL_100 may be terminated at any time with respect to the link test pulse. It shall be
`terminated such that ternary symbols of the subsequent packet are not corrupted, and are not delayed any
`more than is specified in 23.11.
`
`For any link test pulse occurring within 20 ternary symbol times of the beginning of a preamble, the zero
`crossing jitter (as defined in 23.5. 1 .2.5) of the link test pulse when measured along with the zero crossings of
`the preamble shall be less than 4 ns p-p.
`
`NOTE—The above condition allows clock recovery implementations that optionally begin fast-lock sequences on part
`of a link integrity pulse to properly acquire lock on a subsequent preamble sequence.
`
`Regardless of other considerations, when the transmitter is disabled (xmit=DISABLE), the PMA Transmit
`function shall transmit the TP_IDL_l 00 signal.
`
`23.4.1.3 PMA Receive function
`
`PMA Receive contains the circuits necessary to convert physically encoded ternary symbols from the physi-
`cal MDI receive pairs (RX_D2, BI_D3 and BI_D4) into a logical format suitable for the PMA Align func-
`tion. Each receive pair has its own dedicated PMA Receive circuitry.
`
`The PHY shall receive the signals on the receive pairs (RX_D2, BI_D3, and