`
`IEEE
`Std 8D2.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 MD.
`
`The dc_balance_error=ON indication for a code group shall set RX_ER during the transfer of both aifected
`data nibbles across the NHL
`
`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 l00BASE-T4 end-of-packet delimiters eopl-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 task of sending RX_ER to the M11 whenever
`The PCS Error Sense function performs
`rxerror_status=ERROR is received from the PMA sublayer or when any of the PCS decoding error condi-
`tions occur. The PCS Error Sense fimction 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 MH before the last nibble of
`the clause 4 MAC frame has been passed across the M11. Errors attributable to a particular octet are reported
`to the lV[II 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 M11 signal CRS according to
`the rules presented in this clause.
`
`While link_status = OK, CRS is asserted whenever rx_crs=ON or TX_EN=l, with timing as specified in
`23.112, and table 23-6.
`
`23.2.1.6 PCS Collision Presence function
`
`A PCS collision is defined as the simultaneous occurrence of tx_code_vector¢IDLE and the assertion of
`carrier_status=ON while link_status=OK. While a PCS collision is detected, the MH 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.
`
`This is an Archive IEEE Standard.
`
`It has been superseded by a later version of this standgayd.
`
`it 1025
`
`0106
`
`
`
`Aerohive - Exhibit 1025
`
`0106
`
`
`
`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—M|| interface signals
`
`
`
`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_UN'ITDATA 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 eopl through eop5 appended
`afierward 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 eopl. 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-
`cate and PMA_UNITDATA request messages shall have a clock in each direction. Details of the clock
`
`This is angarchive IEEE Standard.
`
`It has been superseded by a later version of this standard.
`
`it 1025
`
`0107
`
`
`
`Aerohive - Exhibit 1025
`
`0107
`
`
`
`CSMAICD
`
`tx_code_vector =
`IDLE
`
`tx_code_vector =
`DATA
`
`Ix_code_vector =
`
`rX_c0de_VeG10r =
`
`r'x_code_vector =
`
`IEEE
`Std 802.3u-1995
`
`tx_code_vector =
`IDLE
`
`rx_oode_vector =
`
`IDLE
`
`PREAMBLE
`
`DATA
`
`I
`
`IDLE
`
`B|_D3 B|_D4
`
`
`
` -TI I I
`
`
`
`TX_D1 RX_D2 I §
`I
`I
`I
`
`
`9'43‘ “U33 IEIEEEEI DATA 1 _
`IEZIIEII
`2T |2T |2T
`SSD
`Last
`6T
`jStart_r_ data
`Stream
`Octet
`Delimiter
`
`T -
`Transmrt Recerve
`pair
`pair
`
`Defined end of
`packet for timing
`references (23_1-1)
`
`End of packet recognized
`by PCS and DC balance
`checked at end of eop1
`
`‘T carrier_status = ON4|
`
`implementation are left to the implementor. The choice of binary encoding for each temary 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 temary 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.
`
`
`
`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.
`
`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:
`
`[
`
`[
`
`[
`
`[
`
`[
`
`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].
`
`Aconstant that encodes to:
`
`[ -1 -1 -1 -1 -1 -1].
`
`sosa
`
`sosb
`
`eopl
`
`eop2
`
`eop3
`
`eop4
`
`eop5
`
`A constant that encodes to:
`
`[ -1 - 1
`
`0
`
`bad_code A constant that encodes to:
`
`[ -1 - 1 - 1
`
`zero_code A constant that encodes to:
`
`[
`
`O
`
`O
`
`0
`
`23.2.4.2 PCS state diagram variables
`
`codeword_error
`
`O
`
`1
`
`O
`
`O
`
`1
`
`O
`
`O].
`
`1].
`
`O].
`
`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.
`
`0109
`
`tl025
`
`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.
`
`0110
`
`'t 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.
`
`0111
`
`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_UNITDATA 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.
`
`
`
`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 —a—a—l_l—a—a—u—a—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.
`
`113
`
`025
`
`Aerohive - Exhibit 1025
`
`0113
`
`
`
`CSMNCD
`
`23.2.4.5 PCS state diagrams
`
`AwArr|N(3 DATA To TRN-.|sM|T
`
`u_wde_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_tJ'mer_done
`
`COLLECT 1ST NIBBLE
`
`c= IDLE
`lX_D0d€_V€Ct0f
`PMA_UNlTDATA request(tx_oode_vector)
`
`tw1_tJ'mer_done
`
`COLLECT NIBBLE 2: CODE 1ST octet
`(First octet always codes to sosa)
`onr1c= ohr3 ¢= ahrat ¢= sosa
`lX_00de_VeCt0r = (DhI1[0l. 0hr3[0]. 0hr4[0]J
`PMA_UN|TD‘\TA-re<IUB5i(tX_C0de_Vect0r}
`tw1_timer_done
`
`E‘?
`
`COLLECT NIBBLE 6N+3
`
`IEEE
`Std BI[]2_3u—1995
`
`The Mll TX_CLK is generated
`sgmcnronously with the transitions of
`
`of this state diagram.
`See defintnons of
`PCS state variables in
`23.2.4 2.
`
`;
`
`COLLECT NIBBLE 5N+5
`
`snm ngm ohr1, ohr3 and anus
`tx_oode_vector c: (:)hr1[(]]_ uhr3[D], ohr4{0])
`PMA_UNITDAT-MeqUB51(bt_t0de_VeC10r)
`tw1_timer_done
`
`Y
`COLLECT NIBBLE 6N+6
`shifl righ cum and ohr3
`ohral 4:: enoode( tsr)
`b(_code_vectar c: (uhr1[t)], ohr3[U], onr4[0])
`PMA UNlTDATA_{eque5t(tx code vector}
`
`tw1_tfrner_d0ne
`
`Y
`COLLECT NIBBLE SN-I7
`
`shtfl right ohr1, 0hI'3 and ohr4
`Ix_cude_vec1or -: (ohr1[t]], onr3{G], ohr4[D]}
`PMA_UNlTDATA_reques‘t(tx_D0de_vector)
`
`Sh?“ “gm OHT1. ONT3 anti OTIT4
`b!_C0de_Ve€10r
`== {0hI?[0]. 0hr3[0]. 0hr4[0]}
`PMA_UNITDATA-reqUeSt(b<_00de_Vect0r)
`
`tw1_“mer_d0ne
`
`tw1_timer_done
`
`COLLECT NIBBLE 6N+4
`
`COLLECT NIBBLE 5N+B
`
`5'“ “'9” 0"" 3"“ ‘W4
`mm c enwde( Br J
`tx_code_vet:tor c: (ohr1{G]_ omam], nhr4[[]])
`PMA_UNlTDATA_request(tx_code_vector)
`{W1 1'
`d
`_ Imer_ one
`
`shin right ohr3 and ohr4
`ohr1 c: enc0de( tsr }
`“F‘,i|°idE;‘":°[;‘:T: (°"'1§:x°':§)]‘ °hcr:“G)])
`_
`.rBqUe
`_
`e_VB OT
`
`tW1_ :mer_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 - Exhibit 1
`
`Aerohive - Exhibit 1025
`
`0114
`
`
`
`IEEE
`Std 802.3u-1995
`
`pcs_reset = ON
`
`AWAITING INPUT
`
`RX_DV <= 0; RXD<3:0><= oooo; eop 4:: OFF
`
`
`
`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
`
`
`
`
`rx_code_vector = DATA
`* PMA_UN|TDATA.indicate
`COLLECT 1ST TERNARY SYMBOL
`
`PMA_UN|TDATA.indicate
`
`COLLECT 2ND TERNARY SYMBOL
`
`
`
`(rx_code_vector = IDLE)
`+ (rx_code_vector = PREAMBLE)
`
`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.
`
`it 1025
`
`0115
`
`
`
`PMA_UN|TDATA.indicate
`
`
`
`AWAITING IDLE
`
`RX_DV : 0; RXD<3:O> c 0000
`
`RX_DV c: 0; RXD<3:O> c: 0000
`
` RX_DV c: 0; RXD<3:O> <: 0000
`
`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.
`
`0116
`
`it 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.
`
`0117
`
`tlO25
`
`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.
`
`0118
`
`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.
`
`0119
`
`it 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.
`
`tl025
`0120
`
`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 i