VSC8582-10 Datasheet
Dual-Port 10/100/1000BASE-T PHY with Synchronous
Ethernet, VeriTime™, Intellisec™, and QSGMII/SGMII
MAC
Microsemi Headquarters
One Enterprise, Aliso Viejo,
CA 92656 USA
Within the USA: +1 (800) 713-4113
Outside the USA: +1 (949) 380-6100
Sales: +1 (949) 380-6136
Fax: +1 (949) 215-4996
Email: sales.support@microsemi.com
www.microsemi.com
©2019 Microsemi, a wholly owned
subsidiary of Microchip Technology Inc. All
rights reserved. Microsemi and the
Microsemi logo are registered trademarks of
Microsemi Corporation. All other trademarks
and service marks are the property of their
respective owners.
Microsemi makes no warranty, representation, or guarantee regarding the information contained herein or the suitability of
its products and services for any particular purpose, nor does Microsemi assume any liability whatsoever arising out of the
application or use of any product or circuit. The products sold hereunder and any other products sold by Microsemi have
been subject to limited testing and should not be used in conjunction with mission-critical equipment or applications. Any
performance specifications are believed to be reliable but are not verified, and Buyer must conduct and complete all
performance and other testing of the products, alone and together with, or installed in, any end-products. Buyer shall not
rely on any data and performance specifications or parameters provided by Microsemi. It is the Buyer’s responsibility to
independently determine suitability of any products and to test and verify the same. The information provided by Microsemi
hereunder is provided “as is, where is” and with all faults, and the entire risk associated with such information is entirely
with the Buyer. Microsemi does not grant, explicitly or implicitly, to any party any patent rights, licenses, or any other IP
rights, whether with regard to such information itself or anything described by such information. Information provided in this
document is proprietary to Microsemi, and Microsemi reserves the right to make any changes to the information in this
document or to any products and services at any time without notice.
About Microsemi
Microsemi, a wholly owned subsidiary of Microchip Technology Inc. (Nasdaq: MCHP), offers a comprehensive portfolio of
semiconductor and system solutions for aerospace & defense, communications, data center and industrial markets.
Products include high-performance and radiation-hardened analog mixed-signal integrated circuits, FPGAs, SoCs and
ASICs; power management products; timing and synchronization devices and precise time solutions, setting the world's
standard for time; voice processing devices; RF solutions; discrete components; enterprise storage and communication
solutions, security technologies and scalable anti-tamper products; Ethernet solutions; Power-over-Ethernet ICs and
midspans; as well as custom design capabilities and services. Learn more at www.microsemi.com.
VMDS-10421. 4.3 4/19
Contents
1 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1
1.2
1.3
1.4
1.5
1.6
Revision 4.3
Revision 4.2
Revision 4.1
Revision 4.0
Revision 2.1
Revision 2.0
.......................................................................
.......................................................................
.......................................................................
.......................................................................
.......................................................................
.......................................................................
1
1
2
2
2
2
2 Product Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1
2.2
Key Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.1
Low Power . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.2
Advanced Carrier Ethernet Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.3
Wide Range of Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.4
Flexibility . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.5
IEEE 1588v2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.1.6
MACsec Encryption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
4
4
4
4
4
5
5
6
3 Functional Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1
3.2
3.3
3.4
3.5
3.6
Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.1
QSGMII/SGMII MAC-to-1000BASE-X Link Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
3.1.2
QSGMII/SGMII MAC-to-100BASE-FX Link Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.3
QSGMII/SGMII MAC-to-AMS and 1000BASE-X Media SerDes . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.4
QSGMII/SGMII MAC-to-AMS and 100BASE-FX Media SerDes . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.5
QSGMII/SGMII MAC-to-AMS and Protocol Transfer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.1.6
QSGMII/SGMII MAC-to-Cat5 Link Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
3.1.7
QSGMII/SGMII MAC-to-Protocol Transfer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.1.8
1000BASE-X MAC-to-Cat5 Link Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
SerDes MAC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.1
1000BASE-X MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.2
SGMII MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
3.2.3
QSGMII MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
SerDes Media Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
3.3.1
QSGMII/SGMII to 1000BASE-X . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.2
QSGMII/SGMII to 100BASE-FX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3
QSGMII to SGMII Protocol Conversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.4
Unidirectional Transport for Fiber Media . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
PHY Addressing and Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.1
PHY Addressing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.4.2
SerDes Port Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Cat5 Twisted Pair Media Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5.1
Voltage Mode Line Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.5.2
Cat5 Autonegotiation and Parallel Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.3
Automatic Crossover and Polarity Detection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.5.4
Manual MDI/MDIX Setting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.5
Link Speed Downshift . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.6
Energy Efficient Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.5.7
Ring Resiliency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
MACsec Block Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.1
MACsec Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.6.2
MACsec Target Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
iii
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.15
3.16
3.17
3.6.3
Formats, Transforms, and Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
3.6.4
MACsec Integration in PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.6.5
MACsec Pipeline Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.6.6
Debug Fault Code in FCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.6.7
Capture FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
3.6.8
Flow Control Buffer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6.9
Media Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Automatic Media Sense Interface Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
Reference Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.8.1
Configuring the Reference Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.8.2
Single-Ended REFCLK Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.8.3
Differential REFCLK Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
IEEE 1588 Reference Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Ethernet Inline Powered Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
IEEE 802.3af PoE Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
ActiPHY Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.12.1 Low Power State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.12.2 Link Partner Wake-Up State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.12.3 Normal Operating State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
IEEE 1588 Block Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.13.1 IEEE 1588 Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.13.2 IEEE 1588 One-Step E2E TC in Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.13.3 IEEE 1588 TC and BC in Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.13.4 Enhancing IEEE 1588 Accuracy for CE Switches and MACs . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.13.5 MACsec Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.13.6 Supporting One-Step Boundary Clock/Ordinary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.13.7 Supporting Two- Step Boundary/Ordinary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
3.13.8 Supporting One-Step End-to-End Transparent Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
3.13.9 Supporting One-Step Peer-to-Peer Transparent Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
3.13.10 Supporting Two-Step Transparent Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
3.13.11 Calculating OAM Delay Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.13.12 Supporting Y.1731 One-Way Delay Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.13.13 Supporting Y.1731 Two-Way Delay Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
3.13.14 Device Synchronization for IEEE 1588 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
3.13.15 Time Stamp Update Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
3.13.16 Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
3.13.17 Time Stamp Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
3.13.18 Time Stamp FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.13.19 Serial Time Stamp Output Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.13.20 Rewriter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
3.13.21 Local Time Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3.13.22 Serial Time of Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
3.13.23 Programmable Offset for LTC Load Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.13.24 Adjustment of LTC counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 115
3.13.25 Pulse per Second Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
3.13.26 Accuracy and Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.13.27 Loopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
3.13.28 IEEE 1588 Register Access using SMI (MDC/MDIO) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
3.13.29 1588_DIFF_INPUT_CLK Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Daisy-Chained SPI Time Stamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
SPI I/O Register Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Media Recovered Clock Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
3.16.1 Clock Selection Settings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
3.16.2 Clock Output Squelch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Serial Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
3.17.1 SMI Frames . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
3.17.2 SMI Interrupt . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
iv
3.18
3.19
3.20
3.21
3.22
3.23
3.24
LED Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.18.1 LED Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.18.2 Extended LED Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.18.3 LED Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.18.4 Basic Serial LED Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.18.5 Enhanced Serial LED Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.18.6 LED Port Swapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Fast Link Failure Indication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Integrated Two-Wire Serial Multiplexer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.20.1 Read/Write Access Using the Two-Wire Serial MUX . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPIO Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Testing Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.22.1 Ethernet Packet Generator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.22.2 CRC Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.22.3 Far-End Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.22.4 Near-End Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.22.5 Connector Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.22.6 SerDes Loopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.22.7 VeriPHY Cable Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.22.8 JTAG Boundary Scan . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.22.9 JTAG Instruction Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.22.10 Boundary Scan Register Cell Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
100BASE-FX Far-End Fault Indication (FEFI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.23.1 100BASE-FX Halt Code Transmission and Reception . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
3.24.1 Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
122
123
124
125
125
126
126
126
127
127
128
129
129
129
130
130
131
131
134
135
135
137
137
137
138
138
4 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
4.1
4.2
Register and Bit Conventions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
IEEE 802.3 and Main Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
4.2.1
Mode Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
4.2.2
Mode Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
4.2.3
Device Identification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.2.4
Autonegotiation Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
4.2.5
Link Partner Autonegotiation Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.2.6
Autonegotiation Expansion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
4.2.7
Transmit Autonegotiation Next Page . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.2.8
Autonegotiation Link Partner Next Page Receive . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.2.9
1000BASE-T Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
4.2.10 1000BASE-T Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
4.2.11 MMD Access Control Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.2.12 MMD Address or Data Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.2.13 1000BASE-T Status Extension 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.2.14 100BASE-TX/FX Status Extension . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
4.2.15 1000BASE-T Status Extension 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
4.2.16 Bypass Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
4.2.17 Error Counter 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
4.2.18 Error Counter 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
4.2.19 Error Counter 3 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
4.2.20 Extended Control and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
4.2.21 Extended PHY Control Set 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
4.2.22 Extended PHY Control Set 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
4.2.23 Interrupt Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
4.2.24 Interrupt Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
4.2.25 Device Auxiliary Control and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
4.2.26 LED Mode Select . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
4.2.27 LED Behavior . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
v
4.3
4.4
4.5
4.6
4.7
4.8
4.2.28 Extended Page Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Extended Page 1 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4.3.1
SerDes Media Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
4.3.2
Cu Media CRC Good Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
4.3.3
Extended Mode Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
4.3.4
ActiPHY Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
4.3.5
PoE and Miscellaneous Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
4.3.6
Ethernet Packet Generator Control 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
4.3.7
Ethernet Packet Generator Control 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Extended Page 2 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
4.4.1
Cu PMD Transmit Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
4.4.2
EEE Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.4.3
Extended Chip ID, Address 18E2 (0x12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
4.4.4
Entropy Data, Address 19E2 (0x13) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
4.4.5
Extended Interrupt Mask, Address 28E2 (0x1C) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
4.4.6
Extended Interrupt Status, Address 29E2 (0x1D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
4.4.7
Ring Resiliency Control (0x1E) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Extended Page 3 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
4.5.1
MAC SerDes PCS Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.5.2
MAC SerDes PCS Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
4.5.3
MAC SerDes Clause 37 Advertised Ability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.5.4
MAC SerDes Clause 37 Link Partner Ability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.5.5
MAC SerDes Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.5.6
Media/MAC SerDes Transmit Good Packet Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.5.7
Media/MAC SerDes Transmit CRC Error Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
4.5.8
Media SerDes PCS Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
4.5.9
Media SerDes PCS Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
4.5.10 Media SerDes Clause 37 Advertised Ability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
4.5.11 Media SerDes Clause 37 Link Partner Ability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
4.5.12 Media SerDes Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
4.5.13 Media/MAC SerDes Receive CRC Good Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
4.5.14 Media/MAC SerDes Receive CRC Error Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
Extended Page 4 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
4.6.1
CSR Access Controls and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
4.6.2
1588_PPS_0/1 Mux Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
4.6.3
SPI Daisy-Chain Controls and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
General Purpose Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
4.7.1
Reserved General Purpose Address Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
4.7.2
LED/SIGDET/GPIO Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
4.7.3
GPIO Control 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
4.7.4
GPIO Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
4.7.5
GPIO Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
4.7.6
GPIO Pin Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
4.7.7
Microprocessor Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
4.7.8
MAC Configuration and Fast Link . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
4.7.9
Two-Wire Serial MUX Control 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
4.7.10 Two-Wire Serial MUX Control 2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
4.7.11 Two-Wire Serial MUX Data Read/Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
4.7.12 Recovered Clock 1 Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
4.7.13 Recovered Clock 2 Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
4.7.14 Enhanced LED Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
4.7.15 Global Interrupt Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Clause 45 Registers to Support Energy Efficient Ethernet and 802.3bf . . . . . . . . . . . . . . . . . . . . . . . 188
4.8.1
PMA/PMD Status 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
4.8.2
PCS Status 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
4.8.3
EEE Capability . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
4.8.4
EEE Wake Error Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
4.8.5
EEE Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
vi
4.8.6
EEE Link Partner Advertisement . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
5 Electrical Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
5.1
5.2
5.3
5.4
DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
5.1.1
VDD25 and VDDMDIO (2.5 V) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
5.1.2
VDDMDIO (1.2 V) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
5.1.3
Supply Voltage . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
5.1.4
LED and GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
5.1.5
Internal Pull-Up or Pull-Down Resistors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
5.1.6
Reference Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
5.1.7
1588 Reference Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
5.1.8
SerDes Interface (SGMII) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
5.1.9
Enhanced SerDes Interface (QSGMII) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
5.1.10 Current Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
5.1.11 Thermal Diode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
5.2.1
Reference Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
5.2.2
Recovered Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
5.2.3
SerDes Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
5.2.4
SerDes Driver Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.2.5
SerDes Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.2.6
SerDes Receiver Jitter Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.2.7
Enhanced SerDes Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
5.2.8
Basic Serial LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
5.2.9
Enhanced Serial LEDs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
5.2.10 Serial CPU Interface (SI) for Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
5.2.11 JTAG Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
5.2.12 Serial Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
5.2.13 Reset Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
5.2.14 IEEE 1588 Timing Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
5.2.15 Serial Timestamp Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
5.2.16 Local Time Counter Load/Save Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Stress Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
6 Pin Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
6.1
6.2
6.3
6.4
6.5
Pin Identifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pin Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pins by Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.1
1588 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.2
1588 Support and GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.3
GPIO and Signal Detect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.4
GPIO and Two-Wire Serial . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.5
JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.6
Miscellaneous . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.7
Power Supply and Ground . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.8
SerDes MAC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.9
SerDes Media Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.10 Serial Management Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.11 SPI Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
6.3.12 Twisted Pair Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pins by Number . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Pins by Name . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
214
214
216
216
217
217
217
218
218
220
220
221
221
222
222
223
226
7 Package Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
7.1
Package Drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
vii
7.2
7.3
8
Thermal Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 230
Moisture Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
8.12
8.13
8.14
8.15
8.16
8.17
8.18
8.19
8.20
8.21
8.22
8.23
8.24
8.25
8.26
8.27
8.28
Clause 45, register 3.22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Clause 45, register 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Clause 45 register address post-increment . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Clause 45, register 7.60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Link performance in 100BASE-TX and 1000BASE-T modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
10BASE-T signal amplitude . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
Fiber-media recovered clock does not squelch based on link status . . . . . . . . . . . . . . . . . . . . . . . . . . 233
MAC-interface transmit CRC packet counters do not work in far-end loopback . . . . . . . . . . . . . . . . . 233
Near-end loopback non functional in protocol transfer mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
Ethernet Packet Generator control register write corruption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
10BASE-T 1588 ingress time stamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 233
1588 SPI time stamp bus daisy chaining ignores PHYADD[4:2] setting . . . . . . . . . . . . . . . . . . . . . . . 233
Special high-resolution 1588 time stamping accuracy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
1588 bypass and datapath loopbacks ignore IDLE symbol boundaries . . . . . . . . . . . . . . . . . . . . . . . 234
1588 SPI time stamp interface not working properly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Interrupt not set when non-zero contents in PTP reserved field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
Large egress TS error in 10 Mbps mode with MACsec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
VTSS_MACSEC_uncontrolled_counters_get shows incorrect counter values . . . . . . . . . . . . . . . . . . 234
Controlled port counter if_in_octets does not get set correctly . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 235
MACsec engine may shrink the minimum 100M IPG during wire-speed transmission . . . . . . . . . . . . 235
Operate MACsec with flow control to handle bandwidth expansion . . . . . . . . . . . . . . . . . . . . . . . . . . 235
Transparent Clock Mode A is not backwards compatible with previous generation VSC8574 family of
PHYs 236
Fiber-media recovered clock does not squelch based on link status . . . . . . . . . . . . . . . . . . . . . . . . . . 236
Anomalous PCS error indications in Energy Efficient Ethernet mode . . . . . . . . . . . . . . . . . . . . . . . . . 236
1588 bypass shall be enabled during engine reconfiguration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
MACsec datapath switch may cause large timestamp errors in the 1588 engine . . . . . . . . . . . . . . . . 236
Out-of-sync FIFOs in the 1588 engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
1000BASE-X parallel detect mode with Clause 37 autonegotiation enabled . . . . . . . . . . . . . . . . . . . . 237
9 Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
viii
Figures
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Figure 13
Figure 14
Figure 15
Figure 16
Figure 17
Figure 18
Figure 19
Figure 20
Figure 21
Figure 22
Figure 23
Figure 24
Figure 25
Figure 26
Figure 27
Figure 28
Figure 29
Figure 30
Figure 31
Figure 32
Figure 33
Figure 34
Figure 35
Figure 36
Figure 37
Figure 38
Figure 39
Figure 40
Figure 41
Figure 42
Figure 43
Figure 44
Figure 45
Figure 46
Figure 47
Figure 48
Figure 49
Figure 50
Figure 51
Figure 52
Figure 53
Figure 54
Dual Media Application Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
Copper Transceiver Application Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Fiber Media Transceiver Application Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
SGMII MAC-to-1000BASE-X Link Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
QSGMII MAC-to-1000BASE-X Link Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
QSGMII/SGMII MAC-to-100BASE-FX Link Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
QSGMII/SGMII MAC-to-AMS and 1000BASE-X Media SerDes . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
QSGMII/SGMII MAC-to-AMS and 100BASE-FX Media SerDes . . . . . . . . . . . . . . . . . . . . . . . . . . 10
QSGMII/SGMII MAC-to-AMS and Protocol Transfer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
QSGMII/SGMII MAC-to-Cat5 Link Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
QSGMII/SGMII MAC-to-Protocol Transfer Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
1000BASE-X MAC-to-Cat5 Link Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
SerDes MAC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
SGMII MAC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
QSGMII MAC Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
Cat5 Media Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Low Power Idle Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
MACsec Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
Secure Enterprise Infrastructure and WAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
Secure Carrier Ethernet Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Secure Mobile Backhaul with IEEE 1588 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 23
Untagged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Standard MACsec Transform of Untagged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Single-Tagged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Standard MACsec Transform of Single-Tagged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Dual-Tagged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Standard MACsec Transform of Dual-Tagged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Single-Tagged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
MACsec Transform to Single Tag Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
Dual-Tagged Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
MACsec Transform to Single and Dual Tag Bypass . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
EoMPLS with One Label . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Standard and Advanced MACsec Transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
EoMPLS with Two Labels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
Standard and Advanced MACsec Transform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
MACsec in PHY . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
MACsec Egress Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
MACsec Ingress Data Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
VLAN Tag Bypass Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
EoMPLS Header Bypass Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Capture FIFO Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Line Back-Pressure by Remote Link Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
Host Back-Pressure by Remote Link Partner . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
Advanced Flow Control Handling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
MAC Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Automatic Media Sense Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
2.5 V CMOS Single-Ended REFCLK Input Resistor Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.3 V CMOS Single-Ended REFCLK Input Resistor Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
5 V CMOS Single-Ended REFCLK Input Resistor Network . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
AC Coupling for REFCLK Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Inline Powered Ethernet Switch Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
ActiPHY State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
IEEE 1588 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
ix
Figure 55
Figure 56
Figure 57
Figure 58
Figure 59
Figure 60
Figure 61
Figure 62
Figure 63
Figure 64
Figure 65
Figure 66
Figure 67
Figure 68
Figure 69
Figure 70
Figure 71
Figure 72
Figure 73
Figure 74
Figure 75
Figure 76
Figure 77
Figure 78
Figure 79
Figure 80
Figure 81
Figure 82
Figure 83
Figure 84
Figure 85
Figure 86
Figure 87
Figure 88
Figure 89
Figure 90
Figure 91
Figure 92
Figure 93
Figure 94
Figure 95
Figure 96
Figure 97
Figure 98
Figure 99
Figure 100
Figure 101
Figure 102
Figure 103
Figure 104
Figure 105
Figure 106
Figure 107
Figure 108
Figure 109
Figure 110
Figure 111
Figure 112
Figure 113
IEEE 1588 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
TC and BC Linecard Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
One-Step E2E BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
Two-Step E2E BC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
One-Step E2E TC Mode A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
One-Step E2E TC Mode B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Delay Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
One-Step P2P TC Mode B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Two-Step E2E TC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Y.1731 1DM PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
Y.1731 One-Way Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
Y.1731 DMM PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
Y.1731 Two-Way Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
RFC6374 DMM/DMR OAM PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
Draft-bhh DMM/DMR/1DM OAM PDU Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
PTP Packet Encapsulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
OAM Packet Encapsulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
TSU Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 85
Analyzer Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Type II Ethernet Basic Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Ethernet Frame with SNAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Ethernet Frame with VLAN Tag and SNAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
Ethernet Frame with VLAN Tags and SNAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
PBB Ethernet Frame Format (No B-Tag) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
PBB Ethernet Frame Format (1 B-Tag) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
MPLS Label Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
MPLS Label Stack within an Ethernet Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
MPLS Labels and Control Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
IPv4 with UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
IPv6 with UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
ACH Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
ACH Header with Protocol ID Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
IPSec Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
IPv6 with UDP and IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
PTP Frame Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
OAM 1DM Frame Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
OAM DMM Frame Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
OAM DMR Frame Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
RFC6374 DMM/DMR OAM PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
G8113.1/draft-bhh DMM/DMR/1DM OAM PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Serial Time Stamp/Frame Signature Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Preamble Reduction in Rewriter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Local Time Counter Load/Save Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Standard PPS and 1PPS with TOD Timing Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
ToD Octet Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
SPI Time Stamping Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
SPI Write Cycles . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
SPI Read Cycle . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
SMI Read Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
SMI Write Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
MDINT Configured as an Open-Drain (Active-Low) Pin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Two-Wire Serial MUX with SFP Control and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Two-Wire Serial MUX Read and Write Register Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Far-End Loopback Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Near-End Loopback Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Connector Loopback Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Data Loops of the SerDes Macro . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Test Access Port and Boundary Scan Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
Register Space Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 139
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
x
Figure 114
Figure 115
Figure 116
Figure 117
Figure 118
Figure 119
Figure 120
Figure 121
Figure 122
Figure 123
Figure 124
Figure 125
Figure 126
Figure 127
Figure 128
Figure 129
Figure 130
Figure 131
Figure 132
SGMII DC Transmit Test Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SGMII DC Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SGMII DC Driver Output Impedance Test Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SGMII DC Input Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Circuit for Recovered Clock Output Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
QSGMII Transient Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Basic Serial LED Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Enhanced Serial LED Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SI Input Data Timing Diagram for Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SI Output Data Timing Diagram for Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Circuit for SI_DO Disable . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
JTAG Interface Timing Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Test Circuit for TDO Disable Time . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Serial Management Interface Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
SPI Interface Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Local Time Counter Load/Save Timing Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Top-Left Pin Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Top-Right Pin Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Package Drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
195
195
195
196
200
203
205
206
206
207
208
209
209
210
211
212
215
216
230
xi
Tables
Table 1
Table 2
Table 3
Table 4
Table 5
Table 6
Table 7
Table 8
Table 9
Table 10
Table 11
Table 12
Table 13
Table 14
Table 15
Table 16
Table 17
Table 18
Table 19
Table 20
Table 21
Table 22
Table 23
Table 24
Table 25
Table 26
Table 27
Table 28
Table 29
Table 30
Table 31
Table 32
Table 33
Table 34
Table 35
Table 36
Table 37
Table 38
Table 39
Table 40
Table 41
Table 42
Table 43
Table 44
Table 45
Table 46
Table 47
Table 48
Table 49
Table 50
Table 51
Table 52
Table 53
Table 54
Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
MAC Interface Mode Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
Supported MDI Pair Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
Standard MACsec Frame Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 24
Advanced MACsec Frame Combinations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
MACsec Tag Parsing Checks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Match Criteria and Maskable Bits . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Egress SA Flow Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Ingress SA Flow Actions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 34
Transform Record Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Context Control Word Fields . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
Egress SA Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Egress Global Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
Ingress SA Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Ingress Global Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Egress Per-User Global Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
802.1AE Correlation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
Egress Per-User Global Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
FCS Fault Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Ingress Global Stat Event Vector Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
Egress Global Stat Event Vector Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Ingress SA Stat Event Vector Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
Egress SA Stat Event Vector Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
AMS Media Preferences . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 56
REFCLK Frequency Selection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
Flows Per Engine Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Ethernet Comparator: Next Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Comparator ID Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 88
Ethernet Comparator (Next Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
Ethernet Comparator (Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
MPLS Comparator: Next Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
MPLS Comparator: Per-Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
MPLS Range_Upper/Lower Label Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Next MPLS Comparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Next-Protocol Registers in OAM-Version of MPLS Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Comparator Field Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
IP/ACH Next-Protocol Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
IP/ACH Comparator Flow Verification Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
PTP Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
PTP Comparison: Common Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
PTP Comparison: Additions for OAM-Optimized Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Frame Signature Byte Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
Frame Signature Address Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
LTC Time Load/Save Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Output Pulse Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 116
Daisy-Chain Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
SI_ADDR Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
LED Drive State . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
LED Mode and Function Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Extended LED Mode and Function Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
LED Serial Bitstream Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Register Bits for GPIO Control and Status . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
SerDes Macro Address Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
JTAG Instruction Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 135
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
xii
Table 55
Table 56
Table 57
Table 58
Table 59
Table 60
Table 61
Table 62
Table 63
Table 64
Table 65
Table 66
Table 67
Table 68
Table 69
Table 70
Table 71
Table 72
Table 73
Table 74
Table 75
Table 76
Table 77
Table 78
Table 79
Table 80
Table 81
Table 82
Table 83
Table 84
Table 85
Table 86
Table 87
Table 88
Table 89
Table 90
Table 91
Table 92
Table 93
Table 94
Table 95
Table 96
Table 97
Table 98
Table 99
Table 100
Table 101
Table 102
Table 103
Table 104
Table 105
Table 106
Table 107
Table 108
Table 109
Table 110
Table 111
Table 112
Table 113
IDCODE JTAG Device Identification Register Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
USERCODE JTAG Device Identification Register Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . 136
JTAG Instruction Code IEEE Compliance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
IEEE 802.3 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Main Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
Mode Control, Address 0 (0x00) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
Mode Status, Address 1 (0x01) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
Identifier 1, Address 2 (0x02) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Identifier 2, Address 3 (0x03) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Device Autonegotiation Advertisement, Address 4 (0x04) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Autonegotiation Link Partner Ability, Address 5 (0x05) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Autonegotiation Expansion, Address 6 (0x06) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Autonegotiation Next Page Transmit, Address 7 (0x07) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Autonegotiation LP Next Page Receive, Address 8 (0x08) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
1000BASE-T Control, Address 9 (0x09) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
1000BASE-T Status, Address 10 (0x0A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
MMD EEE Access, Address 13 (0x0D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
MMD Address or Data Register, Address 14 (0x0E) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
1000BASE-T Status Extension 1, Address 15 (0x0F) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
100BASE-TX/FX Status Extension, Address 16 (0x10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
1000BASE-T Status Extension 2, Address 17 (0x11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
Bypass Control, Address 18 (0x12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
Extended Control and Status, Address 19 (0x13) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Extended Control and Status, Address 20 (0x14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Extended Control and Status, Address 21 (0x15) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Extended Control and Status, Address 22 (0x16) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
Extended PHY Control 1, Address 23 (0x17) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
Extended PHY Control 2, Address 24 (0x18) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Interrupt Mask, Address 25 (0x19) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 153
Interrupt Status, Address 26 (0x1A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
Auxiliary Control and Status, Address 28 (0x1C) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
LED Mode Select, Address 29 (0x1D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
LED Behavior, Address 30 (0x1E) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
Extended/GPIO Register Page Access, Address 31 (0x1F) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Extended Registers Page 1 Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
SerDes Media Control, Address 16E1 (0x10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 158
Cu Media CRC Good Counter, Address 18E1 (0x12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Extended Mode Control, Address 19E1 (0x13) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Extended PHY Control 3, Address 20E1 (0x14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Extended PHY Control 4, Address 23E1 (0x17) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
EPG Control Register 1, Address 29E1 (0x1D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
EPG Control Register 2, Address 30E1 (0x1E) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Extended Registers Page 2 Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
Cu PMD Transmit Control, Address 16E2 (0x10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
EEE Control, Address 17E2 (0x11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
Extended Chip ID, Address 18E2 (0x12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Entropy Data, Address 19E2 (0x13) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Extended Interrupt Mask, Address 28E2 (0x1C) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Extended Interrupt Status, Address 29E2 (0x1D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Ring Resiliency, Address 30E2 (0x1E) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Extended Registers Page 3 Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
MAC SerDes PCS Control, Address 16E3 (0x10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
MAC SerDes PCS Status, Address 17E3 (0x11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
MAC SerDes Cl37 Advertised Ability, Address 18E3 (0x12) . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
MAC SerDes Cl37 LP Ability, Address 19E3 (0x13) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
MAC SerDes Status, Address 20E3 (0x14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
Media/MAC SerDes Tx Good Packet Counter, Address 21E3 (0x15) . . . . . . . . . . . . . . . . . . . . . 171
Media/MAC SerDes Tx CRC Error Counter, Address 22E3 (0x16) . . . . . . . . . . . . . . . . . . . . . . . 172
Media SerDes PCS Control, Address 23E3 (0x17) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
xiii
Table 114
Table 115
Table 116
Table 117
Table 118
Table 119
Table 120
Table 121
Table 122
Table 123
Table 124
Table 125
Table 126
Table 127
Table 128
Table 129
Table 130
Table 131
Table 132
Table 133
Table 134
Table 135
Table 136
Table 137
Table 138
Table 139
Table 140
Table 141
Table 142
Table 143
Table 144
Table 145
Table 146
Table 147
Table 148
Table 149
Table 150
Table 151
Table 152
Table 153
Table 154
Table 155
Table 156
Table 157
Table 158
Table 159
Table 160
Table 161
Table 162
Table 163
Table 164
Table 165
Table 166
Table 167
Table 168
Table 169
Table 170
Table 171
Table 172
Media SerDes PCS Status, Address 24E3 (0x18) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
Media SerDes Cl37 Advertised Ability, Address 25E3 (0x19) . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
MAC SerDes Cl37 LP Ability, Address 26E3 (0x1A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Media SerDes Status, Address 27E3 (0x1B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 174
Media/MAC SerDes Receive CRC Good Counter, Address 28E3 (0x1C) . . . . . . . . . . . . . . . . . . 175
Media/MAC SerDes Receive CRC Error Counter, Address 29E3 (0x1D) . . . . . . . . . . . . . . . . . . 175
Extended Registers Page 4 Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
CSR Access Control, Address 16E4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
CSR Buffer, Address 17E4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
1588_PPS_0 Mux Control, Address 21E4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
CSR Buffer, Address 18E4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
CSR Access Control, Address 19E4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
CSR Status, Address 20E4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 177
SPI Daisy-Chain Control, Address 26E4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
SPI Daisy-Chain Status, Address 27E4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
SPI Daisy-Chain Counter, Address 28E4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
1588 RefClk Input Buffer Control (LSW), Address 29E4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
1588 RefClk Input Buffer Control (MSW), Address 30E4 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
General Purpose Registers Page Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
LED/SIGDET/GPIO Control, Address 13G (0x0D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
GPIO Control 2, Address 14G (0x0E) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
GPIO Input, Address 15G (0x0F) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
GPIO Output, Address 16G (0x10) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
GPIO Input/Output Configuration, Address 17G (0x11) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
Microprocessor Command Register, Address 18G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
MAC Configuration and Fast Link Register, Address 19G (0x13) . . . . . . . . . . . . . . . . . . . . . . . . 183
Two-Wire Serial MUX Control 1, Address 20G (0x14) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Two-Wire Serial MUX Interface Status and Control, Address 21G (0x15) . . . . . . . . . . . . . . . . . . 184
Two-Wire Serial MUX Data Read/Write, Address 22G (0x16) . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Recovered Clock 1 Control, Address 23G (0x17) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Recovered Clock 2 Control, Address 24G (0x18) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
Enhanced LED Control, Address 25G (0x19) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Global Interrupt Status, Address 29G (0x1D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
Clause 45 Registers Page Space . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
PMA/PMD Status 1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
PCS Status 1, Address 3.1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
EEE Capability, Address 3.20 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
EEE Wake Error Counter, Address 3.22 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
EEE Advertisement, Address 7.60 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
EEE Advertisement, Address 7.61 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 190
802.3bf Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
VDD25 and VDDMDIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
VDDMDIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 192
Supply Voltage Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
LED and GPIO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Internal Pull-Up or Pull-Down Resistors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
Reference Clock DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
1588 Reference Clock DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
SerDes Driver DC Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 194
SerDes Receiver DC Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Enhanced SerDes Driver DC Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
Enhanced SerDes Receiver DC Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
Current Consumption (1588 and MACsec Disabled) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 197
1588 Current Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
MACsec Current Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
Thermal Diode Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Reference Clock AC Characteristics for QSGMII 125 MHz Differential Clock . . . . . . . . . . . . . . . 199
Recovered Clock AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
SerDes Outputs AC Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 201
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
xiv
Table 173
Table 174
Table 175
Table 176
Table 177
Table 178
Table 179
Table 180
Table 181
Table 182
Table 183
Table 184
Table 185
Table 186
Table 187
Table 188
Table 189
Table 190
Table 191
Table 192
Table 193
Table 194
Table 195
Table 196
Table 197
Table 198
Table 199
Table 200
Table 201
Table 202
Table 203
Table 204
Table 205
Table 206
Table 207
Table 208
SerDes Driver Jitter Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
SerDes Input AC Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
SerDes Receiver Jitter Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
Enhanced SerDes Outputs AC Specifications, SGMII Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Enhanced SerDes Outputs AC Specifications, QSGMII Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
Enhanced SerDes Input AC Specifications, SGMII Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Enhanced SerDes Inputs AC Specifications, QSGMII Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . 204
Enhanced SerDes Receiver Jitter Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Basic Serial LEDs AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
Enhanced Serial LEDs AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 206
SI Timing Specifications for Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
JTAG Interface AC Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 208
Serial Management Interface AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
Reset Timing Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
IEEE 1588 Timing Specifications AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
SPI Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 211
Local Time Counter Load/Save Timing Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
PHY Latency in IEEE 1588 Timing Bypass Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Recommended Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Stress Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 213
Pin Type Symbol Definitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
1588 Support Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
1588 Support and GPIO Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
GPIO and SIGDET Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
GPIO and Two-Wire Serial Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
JTAG Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Miscellaneous Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 218
Power Supply and Ground Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
SerDes MAC Interface Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
SerDes Media Interface Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
SerDes Media Interface Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
SMI Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
SPI Interface Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Twisted Pair Interface Pins . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Thermal Resistances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 231
Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
xv
Revision History
1
Revision History
This section describes the changes that were implemented in this document. The changes are listed by
revision, starting with the most current publication.
1.1
Revision 4.3
Revision 4.3 of this datasheet was published in April 2019. In revision 4.3, VeriPHY descriptions were
updated and VeriPHY register information was deleted. For functional details of the VeriPHY suite and
operating instructions, see the ENT-AN0125 PHY, Integrated PHY-Switch VeriPHY - Cable Diagnostics
application note.
1.2
Revision 4.2
Revision 4.2 was published in August 2017. The following is a summary of the changes in this document.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
Key features was updated to correctly reflect available functionality. For more information, see Key
Features, page 4.
Operating modes were updated to correctly reflect available functionality. For more information, see
Operating Modes, page 7.
All references to LVDS were clarified to reflect LVDS compatibility.
All references to CLK1588P/N were clarified as 1588_DIFF_INPUT_CLK_P/N.
The Analyzer block diagram was updated. For more information, see Figure 73, page 86.
A note was added about IPv4/UDP frames. For more information, see IPv4 Header Format,
page 94.
A note was added about IPv6/UDP frames. For more information, see IPv6 Header Format, page 95
Details on PTP accuracy and resolution were added. For more information, see Accuracy and
Resolution, page 117.
A note was added about the use of recovered clock outputs. For more information, see Media
Recovered Clock Outputs, page 120.
A note was added about fast link failure indication in EEE mode. For more information, see Fast Link
Failure Indication, page 126.
The equipment loop description was updated to correctly reflect available functionality. For more
information, see Equipment Loop, page 133.
The cable pair termination and cable length description was updated. For more information, see
VeriPHY Cable Diagnostics, page 134.
JTAG ID code was updated. For more information, see Table 56, page 136.
Configuration steps were updated. For more information, see Configuration, page 138.
ActiPHY control description was updated. For more information, see Table 93, page 160.
EEE Control register descriptions were updated to indicate sticky bits. For more information, see
Table 99, page 165.
Media/MAC SerDes transmit CRC error counter register descriptions were updated. For more
information, see Table 112, page 172 and Table 119, page 175.
Reference clock DC specifications were updated. For more information, see Table 160, page 194
and Table 161, page 194.
Enhanced SerDes receiver DC specifications parameter was updated. For more information, see
Table 165, page 197.
Specifications for the IEEE 1588 timing, timestamp interface, and local time counter were updated.
For more information, see Table 187, page 211, Serial Timestamp Interface, page 211, and Local
Time Counter Load/Save Timing, page 211.
Pin E16 name was corrected to remove GPIO functionality.
All references to serial parallel interface were corrected to serial peripheral interface.
Design considerations were updated. For more information, see Design Considerations, page 232.
Temperature specifications were added to the part ordering information. For more information, see
Table 208, page 238.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
1
Revision History
1.3
Revision 4.1
Revision 4.1 of this datasheet was published in November 2014. The following is a summary of the
changes implemented in the datasheet:
•
•
•
•
•
1.4
Register settings for fiber media configuration were updated. For more information, see
Configuration, page 138.
Bit 13 functionality for the Media SerDes PCS control register 23E3 was clarified. For more
information, see Table 113, page 172.
Input differential peak voltage specifications for the reference clock, and the SerDes and enhanced
SerDes receiver, were updated. For more information, see Table 160, page 194, Table 163,
page 196, and Table 165, page 197.
Pin description for the PHYADD1 pin F13, normally tied to VSS, was clarified. For more information,
see Table 199, page 218.
Design considerations were updated. For more information, see Design Considerations, page 232.
Revision 4.0
Revision 4.0 of this datasheet was published in March 2014. The following is a summary of the changes
implemented in the datasheet:
•
•
•
•
•
•
•
1.5
The method for determining the PHY address was clarified.
Functional descriptions for SPI register I/O were added.
Register descriptions for extended page 4 registers were updated.
Electrical specifications were updated to reflect characterization results.
ESD (electrostatic discharge) was added. For human body model (HBM), it is a Class 2 rating for all
pins except the VDD_MDIO pin, which is ±1000 V. For charged device model (CDM), it is ±250 V for
all pins except the 1588_DIFF_INPUT_CLK_N pin and the 1588_DIFF_INPUT_CLK_P pin, which
are ±200 V.
Moisture sensitivity level (MSL) is level 4.
Design considerations were added.
Revision 2.1
Revision 2.1 of this datasheet was published in November 2013. The following is a summary of the
changes implemented in the datasheet:
•
•
•
•
•
•
1.6
Functional descriptions for the MACsec engine were updated.
Functional descriptions for the IEEE 1588 time stamping engine were updated.
Supply voltage information was added.
DC and AC specifications for enhanced serdes were updated.
Pin descriptions for unused pin terminations were clarified.
Ordering information was updated.
Revision 2.0
Revision 2.0 of this datasheet was published in May 2013. This was the first publication of the document.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
2
Product Overview
2
Product Overview
VSC8582-10 is a low-power, dual-port Gigabit Ethernet transceiver with two SerDes interfaces for dualport dual media capability. It also includes an integrated dual-port two-wire serial multiplexer (MUX) to
control SFPs or PoE modules. It has a low electromagnetic interference (EMI) line driver, and integrated
line side termination resistors that conserve both power and printed circuit board (PCB) space.
The VSC8582-10 device includes Intellisec™, Microsemi’s implementation of IEEE 802.1AE 128/256-bit
MACsec protocols to meet the security requirements for protecting data traversing Ethernet LANs. It
does input classification, frame encryption/decryption, performance, and latency monitoring.
The VSC8582-10 includes VeriTime™, Microsemi’s patent-pending distributed timing technology that
delivers the industry’s most accurate IEEE 1588v2 timing implementation. IEEE 588v2 timing integrated
in the VSC8582-10 device is the quickest, lowest cost method of implementing the timing accuracy to
maintain existing timing-critical capabilities during the migration from TDM to packet-based architectures.
The VSC8582-10 device offers a seamless integration between IEEE 1588v2 and the MACsec engine
with no loss of precision.
The VSC8582-10 device supports 1-step and 2-step PTP implementations to provide accuracies below
8 ns that greatly minimize internal system delays and variabilities for ordinary clock, boundary clock, and
transparent clock applications. Complete Y.1731 OAM performance monitoring capabilities, master,
slave, boundary, and transparent clock configurations, and sophisticated classifications including, UDP,
IPv4, IPv6 packets and VLAN, and MPLS-TP encapsulations are also supported.
The VSC8582-10 also supports a ring resiliency feature that allows a 1000BASE-T connected PHY port
to switch between master and slave timing without having to interrupt the 1000BASE-T link.
Using Microsemi’s EcoEthernet v2.0 PHY technology, the VSC8582-10 supports energy efficiency
features such as Energy Efficient Ethernet (EEE), ActiPHY link down power savings, and PerfectReach
that can adjust power based on the cable length. It also supports fully optimized power consumption in all
link speeds.
Microsemi's mixed signal and digital signal processing (DSP) architecture is a key operational feature of
the VSC8582-10, assuring robust performance even under less-than-favorable environmental
conditions. It supports both half-duplex and full-duplex 10BASE-T, 100BASE-TX, and 1000BASE-T
communication speeds over Category 5 (Cat5) unshielded twisted pair (UTP) cable at distances greater
than 100 m, displaying excellent tolerance to NEXT, FEXT, echo, and other types of ambient
environmental and system electronic noise. The device also supports two dual media ports that can
support up to two 100BASE-FX, 1000BASE-X fiber, and/or triple-speed copper SFPs.
The following illustrations show a high-level, general view of typical VSC8582-10 applications.
Figure 1 •
Dual Media Application Diagram
½ QSGMII,
2x SGMII, or
2x 1000BASE-X MAC
½ QSGMII,
2x SGMII MAC, or
2x 1000BASE-X MAC
1.0 V
1.2 V
(optional)
2.5 V
2× RJ-45
and Magnetics
VSC8582
2 ports dual media
(fiber or copper)
SGMII or half QSGMII
MAC interface
SerDes
SCL/SDA
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
2× SFPs
(fiber or copper)
3
Product Overview
Figure 2 •
Copper Transceiver Application Diagram
½ QSGMII,
2x SGMII, or
2x 1000BASE-X MAC
1.0 V
2x RJ-45
and Magnetics
2 ports copper media
SGMII or half QSGMII
MAC interface
Fiber Media Transceiver Application Diagram
½ Q SGM II,
2x SGM II, or
2x 1000BASE-X M AC
1.0 V
1.2 V
(optional)
2.5 V
VSC8582
½ QSGMII,
2x SGMII MAC, or
2x 1000BASE -X MAC
2.1
2.5 V
VSC8582
½ QSGMII,
2x SGMII MAC, or
2x 1000BASE-X MAC
Figure 3 •
1.2 V
(optional)
2 ports fiber media
SGMII or half QSGMII
MAC interface
2× 1000BASE -X SFP
or
2x 100BASE-FX SFP
Key Features
This section lists the main features and benefits of the VSC8582-10 device.
2.1.1
Low Power
•
•
•
•
2.1.2
Advanced Carrier Ethernet Support
•
•
•
•
•
2.1.3
Recovered clock outputs with programmable clock squelch control and fast link failure indication
(typical 0, then frames have been captured, read CAPT_DEBUG_TRIGGER_SA1/SA2 to
confirm if the packet for that SA has been captured. Bits will fall back to 0b automatically when a
packet is captured for the SA.
Stop the capture by programming CAPT_DEBUG_TRIGGER.ENABLE = 0 to enable software to
access the FIFO.
Read CAPT_DEBUG_DATA (0 to 127) to read the packet from the capture FIFO.
Flow Control Buffer
The following list provides an overview of the flow control buffer functionality in the VSC8582-10 device.
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
•
3.6.8.1
Frame buffering in egress to handle frame expansion by MACsec and flow control back-pressure to
host/switch ASIC.
Frame buffering in ingress to handle pause frame insertion (from host MAC) and rate adaptation.
Cut-through mode of operation.
Configurable pause reaction (including pause timer handling) for line received pause frames.
Pause generation triggers to host MAC based on configurable XOFF/XON thresholds.
Control queue and data queue with strict priority scheduling in egress with highest priority given to
control queue.
Transmit MAC control frames irrespective of pause state.
Rate adaptation between line and host clocks for PPM compensation.
Rate difference between line and host clocks based on LAN/WAN modes.
Flow control (back-pressure) feedback from MACsec block by compensating gap between frames.
Pass link fault/LF/RF/LPI in both directions using special control word in-band with frames.
EEE controller state machine for activating LPI and wake-up.
4X MTU buffering in egress.
Ingress buffer for pause frame insertion by host MAC.
ECC support in RAM's.
Frame drops recorded for statistics.
Sticky bits and interrupt.
Flow Control Handling
This section describes the basic flow control mode of operation. Buffering provided handles frame
expansion and its own latency. Buffering required for long interconnects that depend upon cable/fiber
length need to be provided separately. The following illustration shows the sequence of events when a
pause frame is received from line.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
49
Functional Descriptions
Figure 43 • Line Back-Pressure by Remote Link Partner
PHY with MACSec
xMII
4
FC Buffer
(Egress)
Host
MAC Rx
(Egress)
2
H
Host/
Switch/
MAC
1588
(Egress)
MACSec
(Egress)
Line
MAC Tx
(Egress)
1588
(Ingress)
MACSec
(Ingress)
Line
MAC Rx
(Ingress)
xMII
L
OR
AND
Tx-XOFF
3
xMII
Tx-XON
Host
MAC Tx
(Ingress)
FC Buffer
(Ingress)
xMII
1
The following steps describe the sequence of events depicted in the illustration.
1.
2.
3.
4.
Pause frame (XOFF) is received by PHY at line MAC Rx. This frame is internally consumed by MAC.
The MAC Rx signals the Tx FC buffer with pause received indication and pause quanta.
The Tx FC buffer goes to pause state at the next frame boundary. Pause timer will be maintained by
Tx FC buffer and is started only after it goes to pause state, which may be immediate in some cases.
The Tx FC buffer drain rate is 0 and fill rate can be max port speed. The Tx FC buffer signals XOFF
to host MAC Tx to schedule a pause transmission upstream. This signaling is shown via the optional
OR gate. Without back-pressured from the remote link partner the Tx FC buffer uses XOFF/XON
thresholds to signal XOFF/XON to host MAC Tx to manage frame expansion due to MACsec.
The host MAC Tx can schedule a pause frame for transmission at the next frame boundary. The Tx
FC buffer needs to be able to hold at least one jumbo frame until XOFF pause is scheduled so that it
can continue to receive data downstream. The XOFF frame is then received by host/switch.
The host device can only stop transmission at next frame boundary because it may have started
transmitting a second jumbo frame.
The following configuration signals control the basic flow control mode.
PAUSE_REACT_ENA. Enables pause reaction and pause timer maintenance in egress flow control
buffer. Set to 1.
PAUSE_GEN_ENA. Enables XON and XOFF pause frame signaling to host MAC based on XON and
XOFF thresholds. Set to 1.
INCLUDE_PAUSE_RCVD_IN_PAUSE_GEN. Enables the optional OR and AND gate. Set to 1. If not
enabled the pause gen signaling to host MAC is purely based on XOFF/XON thresholds.
The following illustration shows the sequence of events when a pause frame is received from host.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
50
Functional Descriptions
Figure 44 • Host Back-Pressure by Remote Link Partner
PHY with MACSec
3
CRTL Queue
2
xMII
1
Host/
Switch/
MAC
xMII
Host
MAC Rx
(Egress)
5
FC Buffer
(Egress)
4
Host
MAC Tx
(Ingress)
1588
(Egress)
MACSec
(Egress)
Line
MAC Tx
(Egress)
1588
(Ingress)
MACSec
(Ingress)
Line
MAC Rx
(Ingress)
FC Buffer
(Ingress)
xMII
xMII
The following steps describe the sequence of events depicted in the illustration.
1.
2.
3.
4.
5.
Host experiences congestion in ingress and sends pause (XOFF) to line.
Host MAC Rx receives pause frame. It is not enabled to react on received pause frames so it passes
the pause frame to Tx FC buffer.
Tx FC buffer maintains two logical queues, one for data and one for MAC control frames. If a data
frame is already scheduled and in progress, it passes on MAC control frames at the next boundary
to quickly relay MAC control frames to line, despite the presence of other data frames in the data
queue.
Tx FC buffer transmits any or all control frames in the control queue.
Pause frame passes through the MACsec block. The MACsec egress block detects frame as a
control frame and does not encrypt it. Frame eventually passes through the line MAC Tx block and
the rest of the PHY blocks.
TX_CTRL_QUEUE_ENA determines if the control queue is enabled in the egress flow control buffer.
This should be set to 1 in basic flow control mode. The physical memory of egress FC buffer can be
partitioned between data and control queues using TX_CTRL_QUEUE_START/END and
TX_DATA_QUEUE_START/END configuration fields.
3.6.8.2
Advanced Flow Control Handling
The following illustration shows the sequence of events when the PHY is configured to the advanced flow
control mode of operation. PAUSE_GEN_ENA needs to be set to 1 and other configuration bits of FC
buffer, such as PAUSE_REAhT_ENA, INCLUDE_PAUSE_RCVD_IN_PAUSE_GEN, and
TX_CTRL_QUEUE_ENA, need to be set to 0. All other configurations for this mode are part of line MAC
and host MAC.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
51
Functional Descriptions
Figure 45 • Advanced Flow Control Handling
Tx-XOFF/
XON
xMII
4
Host
MAC Rx
(Egress)
PHY with MACSec
FC Buffer
(Egress)
1588
(Egress)
H
MACSec
(Egress)
Line
MAC Tx
(Egress)
xMII
L
2
Host/
Switch/
MAC
Pause
Tx-XOFF
3
xMII
Tx-XOFF
Host
MAC Tx
(Ingress)
1588
(Ingress)
MACSec
(Ingress)
Tx-XON
Line
MAC Rx
(Ingress)
FC Buffer
(Ingress)
xMII
1
The following steps describe the sequence of events depicted in the illustration.
PHY Back-Pressured by Remote Link partner
1.
2.
Pause frame (XOFF) is received by PHY at line MAC Rx. This frame is internally consumed by MAC.
Line MAC Rx signals line MAC Tx with pause received indication and pause quanta.
Line MAC Tx goes to pause state at the next frame boundary. Line MAC Tx stalls to pause the
pipeline. Pause timer maintained by line MAC Tx is started only after it goes to pause state. The Tx
FC buffer signals XOFF/XON to host MAC Tx based on XOFF/XON threshold.
Host Back-Pressuring Remote Link Partner
3.
4.
3.6.8.3
System pause is consumed by host MAC Rx. Pause timer maintained in host MAC Rx (instead of
Tx) for egress direction to generate XOFF/XON pause gen signal for line MAC Tx.
Line MAC Tx stalls to send pause frame (either XOFF or XON). This path will work irrespective of
whether line MAC is in pause state.
Frame Drop Statistics
The following 32-bit counters provide frame drop statistics. These counters roll over to 0 when the
maximum value is reached.
TX_CTRL_QUEUE_OVERFLOW_DROP_CNT. Number of control frame drops due to overflow in the
control queue of the egress flow control buffer.
TX_CTRL_QUEUE_UNDERFLOW_DROP_CNT. Number of control frame drops due to underflow in the
control queue of the egress flow control buffer.
TX_CTRL_UNCORRECTED_FRM_DROP_CNT. Number of control frames aborted due to ECC check
fail during reading from RAM in egress flow control buffer.
TX_DATA_QUEUE_OVERFLOW_DROP_CNT. Number of data frame drops due to overflow in the data
queue of the egress flow control buffer.
TX_DATA_QUEUE_UNDERFLOW_DROP_CNT. Number of data frame drops due to underflow in the
data queue of the egress flow control buffer.
TX_DATA_UNCORRECTED_FRM_DROP_CNT. Number of data frames aborted due to ECC check fail
during reading from RAM in egress flow control buffer.
RX_OVERFLOW_DROP_CNT. Number of frame drops due to overflow in the ingress flow control buffer.
RX_UNDERFLOW_DROP_CNT. Number of frame drops due to underflow in the ingress flow control
buffer.
RX_UNCORRECTED_FRM_DROP_CNT. Number of frames aborted due to ECC check fail during
reading from RAM in ingress flow control buffer.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
52
Functional Descriptions
3.6.9
Media Access Control
This section describes the media access control sub layer (MAC) block. There are two instances of MAC
block in each channel. One instance, which interfaces with MACsec and PCS/PMA, is called Line MAC
and other instance which interfaces with FC Buffer and PHY XS is called Host MAC.
The MAC is defined in IEEE 802.3, clauses 3 and 4. The purpose of the MAC is to control the MACsec
block access to the physical layer. In other words, it takes frames from the MACsec and converts those to
a continuous byte stream on the xMII interface. In doing so, it is responsible for frame CRC generation
and checking, preamble insertion and extraction, and pause frame generation and detection. The MAC
block also contains the counters for an SNMP management information base (MIB) statistics module.
The MAC block supports frame sizes up to 10240 bytes in both receive and transmit directions. The
maximum frame size is controlled by the host. The maximum frame size can also be set to the standard
1518 bytes or 1522 bytes, if desired. Maximum frame length restrictions are not enforced in the transmit
direction. The following illustration shows the block diagram of MAC.
Figure 46 • MAC Block Diagram
MAC
Rx Clock Domain
mac_pause_frm
Early Pause
Detector
WRAPPER
KERNEL
xMII Rx I /F
RX- MAC
Host I/ F to
Packet I/F
Converter
Pause
Frame
Detector
LF/ RF Status
LPI Detect
Packet Rx I /F
Pause frame Indication
CW
Generator
Pause State
Early Pause Detect
Packet /I F to
Host I/ F
Converter
xMII Tx I /F
TX- MAC
Packet Tx I/F
Pause gen Signalling
MAC ready Indication
Pause
Frame
Generator
Force
LF/RF/LPI
CW Detect
Tx Clock Domain
Configuration, Status, Counters( CSR)
Interface
3.6.9.1
MAC Transmit
The transmit section of the MAC contains three blocks, packet interface wrapper, pause frame generator,
and MAC Tx kernel. All three blocks operate off the same clock, TX_MAC_CLK.
The MAC Tx kernel block handles the reconciliation sublayer functions as per IEEE 802.3.
•
•
•
•
•
Calculates the CRC for pause frames generated by the pause frame generator.
Converts MAC frames to the xMII format and adds control characters for framing as required by
IEEE 802.3.
Generates the interframe gap (IFG) on the xMII using the deficit idle count algorithm to achieve an
average IPG of 12 bytes.
Shapes all the traffic to go out with an average IPG of 12 bytes after MACsec frame expansion.
Analyzes each packet and increments statistical counters used for RMON support.
The Pause Frame Generator (PFG) block performs the following two major functions.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
53
Functional Descriptions
•
•
Requests packets from the upstream blocks, when packets are present and the Tx direction is not in
the pause state (because a pause frame has been received in the Rx direction). They are forwarded
to the MAC Tx kernel block for further processing.
Generates flow control packets. Pause frames are generated based upon seeing the
MAC_PAUSE_FRM_GEN signal. For the Host MAC this signal is generated by the FC buffer based
upon programmable XOFF/XON threshold values in the FC buffer. In advance flow control mode of
operation the line MAC can also generate pause frames based on MAC_PAUSE_FRM_GEN signal
from Host MAC to relay pause frames that are deleted in Host MAC in this mode.
When the pause frame generator sees the MAC_PAUSE_FRM_GEN signal asserted, it generates pause
frames using settings in configuration registers. Part of the pause frame is the pause value, which
specifies how long the link partner (the network entity that the pause frame is destined for) stops sending
traffic. The pause value specifies the requested delay in bit times and uses the equation 512 ×
PAUSE_VALUE.
After the PFG starts generating pause frames, it continues to generate pause frames at specified
intervals until the de-assertion of the MAC_PAUSE_FRM_GEN signal. When this signal is deasserted,
the PFG does one of two things, depending upon the configuration in MAC_TX_PAUSE_MODE. In
normal mode, the PFG stops sending pause frames. This causes the link partner to start sending frames
again after its pause frame timer has expired. In XON mode, the PFG generates a single pause frame
with a pause value of 0 and sends it to the link partner. This causes the link partner to start sending
frames again right away.
The PFG contains a configurable pause frame interval register, MAC_TX_PAUSE_INTERVAL. This
register controls the time between generated pause frames when the FC buffer continues to request that
pause frames be generated.
The packet interface wrapper handles the following functions:
•
•
•
•
•
3.6.9.2
Provides the packet interfacing support to MACsec and FC buffer blocks. On this packet interface,
frames are transported without preamble and FCS.
Supports LF/RF/LPI generation on xMII interface through special control word received on packet
interface. This special control word is received on packet interface if relaying of LF/RF/LPI is desired
in MACsec subsystem.
Padding of frames whose length is less than 64 bytes. This is required for padding of MACsec short
length frames whose length is less than 64 bytes. This padding is enabled by configuring
ENABLE_TX_PADDING in host MAC.
Standard preamble insertion.
FCS insertion.
MAC Receive
The receive section of the MAC contains three blocks, MAC Rx kernel, pause frame detector, and packet
interface wrapper. All three blocks operate off the same clock, RX_MAC_CLK.
The MAC Rx kernel receives the byte stream from the xMII interface and handles the reconciliation sub
layer processing to convert them to frames sent over the host interface. It checks the CRC of each frame
for validity and abort marks any frame with an invalid CRC. A variety of length checks are performed,
including looking for short frames (less than 64 bytes), oversized, and jabber frames (longer than the
configured maximum). VLAN tagging is supported up to three VLAN tags. Length checks are adjusted
accordingly when VLAN tags are encountered. The Rx kernel supports counters in support of RMON
statistics.
The pause frame detector (PFD) detects and reacts to valid pause frames received by the MAC from the
xMII interface. The PFD reacts to PAUSE frames with a DMAC equal to either the multicast address (0180-c2-00-00-01) or the address of the MAC (MAC_ADDRESS_LSB/MSB register value) in accordance
with IEEE 802.3-2008, Annex 31B. Pause frames that are too short, or have invalid CRC, are abort
marked and ignored by the PFD. Pause frames carry a pause value that indicates the desired pause time
in units of pause quanta, where 1 pause-quantum equals 512 bit times. Because the data path in the
MAC is 8 bytes (or 64 bits) wide, the extracted pause value is multiplied by 8 and stored in the pause
counter. A signal from the PFG indicates if a packet is currently being transmitted.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
54
Functional Descriptions
After the current packet has completed or if there is no packet, the PFD tells the PFG to stop requesting
packets (XOFF) and the pause counter is decremented by one for each MAC Rx clock cycle. When the
counter reaches 0, the PFG is instructed that it may resume requesting packets from the upstream
blocks. Pause frames must have a destination address equal to either the multicast address (01-80-c200-00-01) or the address of the MAC (MAC_ADDRESS_LSB/MSB register value). If there is no match,
then the pause frame is ignored. If a pause frame is received while the Tx direction is already being
paused (because a valid pause frame was already received and the pause counter had not yet counted
down to 0), the pause counter is simply updated with the new value. If the received pause value is 0, then
the state machine transitions immediately to END_PAUSE and frames are again requested from the
upstream blocks.
The packet interface wrapper handles the following functions:
•
•
•
•
3.6.9.3
Provides the packet interfacing support to MACsec and FC buffer blocks. On this packet interface,
frames are transported without preamble and FCS.
Supports LF/RF/LPI indication on packet interface through special control word. This special control
word is relayed to other MAC if relaying of LF/RF/LPI is desired.
Preamble strip on packet interface.
FCS check and strip.
RMON Statistical Counters
The following counters count the number of bytes or frames received or transmitted. The counters count
continuously and are only cleared if the device is reset or the counter is written with 0 through the CPU
interface. These counters roll-over to 0 when the maximum value is reached. Unless specified otherwise,
each counter is 32 bits.
•
•
•
•
•
RX_IN_BYTES_CNT (40 bits) counts the total bytes received including preamble
RX_OK_BYTES_CNT (40 bits) counts the number of bytes received in valid frames
RX_BAD_BYTES_CNT counts the number of bytes received in invalid frames
TX_OUT_BYTES_CNT (40 bits) counts the total number of bytes transmitted including preamble
TX_OK_BYTES_CNT (40 bits) counts the number of bytes in successfully transmitted frames
The following counters are based on the type of frame received or transmitted.
•
•
•
•
•
•
•
•
•
RX_PAUSE_CNT counts the number of pause frames received
RX_UNSUP_OPCODE_CNT counts the number of control frames received with unsupported
opcodes
RX_UC_CNT counts the number of unicast frames received
RX_MC_CNT counts the number of multicast frames received
RX_BC_CNT counts the number of broadcast frames received
TX_PAUSE_CNT counts the number of pause frames transmitted
TX_UC_CNT counts the number of unicast frames transmitted
TX_MC_CNT counts the number of multicast frames transmitted
TX_BC_CNT counts the number of broadcast frames transmitted
The following error counters are provided.
•
•
•
•
•
•
•
•
•
RX_SYMBOL_ERR_CNT counts the number of symbol errors received
RX_CRC_ERR_CNT counts the number of frames received with CRC errors
RX_UNDERSIZE_CNT counts the number of undersized frames received with valid CRC
RX_FRAGMENTS_CNT counts the number of undersized frames received with invalid CRC
RX_IN_RANGE_LENGTH_ERR_CNT counts the number of frames where the length field does not
match the frame length
RX_OUT_OF_RANGE_LENGTH_ERR_CNT counts the number of frames with an illegal length
field
RX_OVERSIZE_CNT counts the number of oversize frames with valid CRC
RX_JABBERS_CNT counts the number of oversize frames with an invalid CRC
RX_XGMII_PROT_ERR_CNT counts the number of XGMII protocol errors detected.
The following size histogram counters are provided for both transmit and receive directions.
•
•
Frames with 64-byte payloads
Frames with 65-byte to 127-byte payloads
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
55
Functional Descriptions
•
•
•
•
•
Frames with 128-byte to 255-byte payloads
Frames with 256-byte to 511-byte payloads
Frames with 512-byte to 1023-byte payloads
Frames with 1024-byte to 1518-byte payloads
Frames with 1519-byte to maximum size payloads
Frame size counters also count invalid frames, as long as they are not short frames, fragments, long
frames, or jabber frames. Long frames are defined as those greater than MAX_LEN bytes.
3.7
Automatic Media Sense Interface Mode
Automatic media sense (AMS) mode automatically sets the media interface to Cat5 mode or SerDes
mode. The active media mode chosen is based on the automatic media sense preferences set in the
device register 23, bit 11. The following illustration shows a block diagram of AMS functionality on ports 0
through 3 of the VSC8582-10 device.
Figure 47 • Automatic Media Sense Block Diagram
PHY port_n
Cat5
MAC
TD
RD
SGMII/
QSGMII
Serial MAC
Auto Sense
Logic
SerDes
SIGDET
Fiber Optic
Module
When both the SerDes and Cat5 media interfaces attempt to establish a link, the preferred media
interface overrides a linkup of the nonpreferred media interface. For example, if the preference is set for
SerDes mode and Cat5 media establishes a link, Cat5 becomes the active media interface. However,
after the SerDes media interface establishes a link, the Cat5 interface drops its link because the
preference was set for SerDes mode. In this scenario, the SerDes preference determines the active
media source until the SerDes link is lost. Also, Cat5 media cannot link up unless there is no SerDes
media link established. The following table shows the possible link conditions based on preference
settings.
Table 24 •
AMS Media Preferences
Preference
Setting
Cat5 Linked,
Fiber Not Linked
SerDes Linked,
Cat5 Not Linked
Cat5 Linked,
SerDes Attempts
to Link
SerDes Linked,
Cat5 Attempts
to Link
Both Cat5 and
SerDes Attempt
to Link
SerDes
Cat5
SerDes
SerDes
SerDes
SerDes
Cat5
Cat5
SerDes
Cat5
Cat5
Cat5
The status of the media mode selected by the AMS can be read from device register 20E1, bits 7:6. It
indicates whether copper media, SerDes media, or no media is selected. Each PHY has four automatic
media sense modes. The difference between the modes is based on the SerDes media modes:
•
•
•
SGMII or QSGMII MAC to AMS and 1000BASE-X SerDes
SGMII or QSGMII MAC to AMS and 100BASE-FX SerDes
SGMII or QSGMII MAC to AMS and SGMII (protocol transfer)
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
56
Functional Descriptions
For more information about SerDes media mode functionality with AMS enabled, see SerDes Media
Interface, page 14.
3.8
Reference Clock
The device reference clock supports both 25 MHz and 125 MHz clock signals. The IEEE 1588 differential
input clock supports frequencies of 125 MHz to 250 MHz. Both reference clocks can be either differential
or single-ended. If differential, they must be capacitively coupled and LVDS compatible.
3.8.1
Configuring the Reference Clock
The REFCLK_SEL2 pin configures the reference clock speed. The following table shows the functionality
and associated reference clock frequency.
Table 25 •
REFCLK Frequency Selection
REFCLK_SEL2 Frequency
3.8.2
0
25 MHz
1
125 MHz
Single-Ended REFCLK Input
To use a single-ended reference clock, an external resistor network is required. The purpose of the
network is to limit the amplitude and to adjust the center of the swing. The configurations for a singleended REFCLK, with the clock centered at 1 V and a 500 mV peak-to-peak swing, are shown in the
following illustrations.
Figure 48 • 2.5 V CMOS Single-Ended REFCLK Input Resistor Network
VDD1A
2.5 V
CMOS
220 Ω
910 Ω
REFCLK_P
REFCLK_N
VDD1A
VSSA
Figure 49 • 3.3 V CMOS Single-Ended REFCLK Input Resistor Network
VDD1A
3.3 V
CMOS
270 Ω
430 Ω
REFCLK_P
REFCLK_N
VDD1A
VSSA
Figure 50 • 5 V CMOS Single-Ended REFCLK Input Resistor Network
VDD1A
5V
CMOS
430 Ω
300 Ω
REFCLK_P
REFCLK_N
VDD1A
VSSA
Note: A single-ended 25 MHz reference clock is not guaranteed to meet requirements for QSGMII MAC
operation.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
57
Functional Descriptions
3.8.3
Differential REFCLK Input
AC coupling is required when using a differential REFCLK. Differential clocks must be capacitively
coupled and LVDS-compatible. The following illustration shows the configuration.
Figure 51 • AC Coupling for REFCLK Input
PHY Equivalent
Termination Circuit
REFCLK_P
0.1 µF
50 Ω
VTT (Internal Voltage)
50 Ω
REFCLK_N
0.1 µF
3.9
IEEE 1588 Reference Clock
The device IEEE 1588 reference clock input supports a continuum of frequencies between 125 MHz and
250 MHz. Both single-ended and differential clocks are supported, but differential clocks are preferred for
better performance. If differential, they must be capacitively coupled and LVDS compatible. For more
information about configuring the clock for single-ended operation, see Reference Clock, page 57.
3.10
Ethernet Inline Powered Devices
The VSC8582-10 can detect legacy inline powered devices in Ethernet network applications. Inline
powered detection capability is useful in systems that enable IP phones and other devices (such as
wireless access points) to receive power directly from their Ethernet cable, similar to office digital phones
receiving power from a private branch exchange (PBX) office switch over telephone cabling. This type of
setup eliminates the need for an external power supply and enables the inline powered device to remain
active during a power outage, assuming that the Ethernet switch is connected to an uninterrupted power
supply, battery, back-up power generator, or other uninterruptable power source.
For more information about legacy inline powered device detection, visit the Cisco Web site at
www.cisco.com. The following illustration shows an example of an inline powered Ethernet switch
application.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
58
Functional Descriptions
Figure 52 • Inline Powered Ethernet Switch Diagram
Gigabit Switch
SGMII/
QSGMII
Interface
Processor
Control
SMI
PHY_port0
PHY_port1
PHY_portn
Transformer
Transformer
Transformer
RJ-45
I/F
RJ-45
I/F
RJ-45
I/F
Link
Partner
Link
Partner
Inline,
Power-Over-Ethernet
(PoE)
Power Supply
Cat5
Link
Partner
The following procedure describes the process that an Ethernet switch must perform to process inline
power requests made by a link partner (LP) that is, in turn, capable of receiving inline power:
1.
2.
3.
4.
5.
6.
Enable the inline powered device detection mode on each VSC8582-10 PHY using its serial
management interface. Set register bit 23E1.10 to 1.
Ensure that the VSC8582-10 autonegotiation enable bit (register 0.12) is also set to 1. In the
application, the device sends a special fast link pulse (FLP) signal to the LP. Reading register
bit 23E1.9:8 returns 00 during the search for devices that require power over Ethernet (PoE).
The VSC8582-10 PHY monitors its inputs for the FLP signal looped back by the LP. An LP capable
of receiving PoE loops back the FLP pulses when the LP is in a powered down state. This is
reported when VSC8582-10 register bit 23E1.9:8 reads back 01. It can also be verified as an inline
power detection interrupt by reading VSC8582-10 register bit 26.9, which should be a 1, and which
is subsequently cleared and the interrupt de-asserted after the read. When an LP device does not
loop back the FLP after a specific time, VSC8582-10 register bit 23E1.9:8 automatically resets to 10.
If the VSC8582-10 PHY reports that the LP requires PoE, the Ethernet switch must enable inline
power on this port, externally of the PHY.
The PHY automatically disables inline powered device detection when the VSC8582-10 register bits
23E1.9:8 automatically reset to 10, and then automatically changes to its normal autonegotiation
process. A link is then autonegotiated and established when the link status bit is set (register bit 1.2
is set to 1).
In the event of a link failure (indicated when VSC8582-10 register bit 1.2 reads 0), it is
recommended that the inline power be disabled to the inline powered device external to the PHY.
The VSC8582-10 PHY disables its normal autonegotiation process and re-enables its inline
powered device detection mode.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
59
Functional Descriptions
3.11
IEEE 802.3af PoE Support
The VSC8582-10 device is compatible with designs that are intended for use in systems that supply
power to data terminal equipment (DTE) by means of the MDI or twisted pair cable, as described in IEEE
802.3af Clause 33.
3.12
ActiPHY Power Management
In addition to the IEEE-specified power-down control bit (device register bit 0.11), the device also
includes an ActiPHY power management mode for each PHY. This mode enables support for powersensitive applications. It utilizes a signal-detect function that monitors the media interface for the
presence of a link to determine when to automatically power-down the PHY. The PHY wakes up at a
programmable interval and attempts to wake up the link partner PHY by sending a burst of FLP over
copper media.
The ActiPHY power management mode in the VSC8582-10 is enabled on a per-port basis during normal
operation at any time by setting register bit 28.6 to 1.
The following operating states are possible when ActiPHY mode is enabled:
•
•
•
Low power state
Link partner wake-up state
Normal operating state (link-up state)
The VSC8582-10 switches between the low power state and LP wake-up state at a programmable rate
(the default is two seconds) until signal energy has been detected on the media interface pins. When
signal energy is detected, the PHY enters the normal operating state. If the PHY is in its normal operating
state and the link fails, the PHY returns to the low power state after the expiration of the link status timeout timer. After reset, the PHY enters the low power state.
When autonegotiation is enabled in the PHY, the ActiPHY state machine operates as described. When
autonegotiation is disabled and the link is forced to use 10BASE-T or 100BASE-TX modes while the
PHY is in its low power state, the PHY continues to transition between the low power and LP wake-up
states until signal energy is detected on the media pins. At that time, the PHY transitions to the normal
operating state and stays in that state even when the link is dropped. When autonegotiation is disabled
while the PHY is in the normal operation state, the PHY stays in that state when the link is dropped and
does not transition back to the low power state.
The following illustration shows the relationship between ActiPHY states and timers.
Figure 53 • ActiPHY State Diagram
Low Power State
Signal Energy Detected on
Media
FLP Burst or
Clause 37 Restart
Signal Sent
Sleep Timer Expires
Timeout Timer Expires and
Auto-negotiation Enabled
LP Wake-up
State
Normal
Operation State
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
60
Functional Descriptions
3.12.1
Low Power State
In the low power state, all major digital blocks are powered down. However, the SMI interface (MDC,
MDIO, and MDINT) functionality is provided.
In this state, the PHY monitors the media interface pins for signal energy. The PHY comes out of low
power state and transitions to the normal operating state when signal energy is detected on the media.
This happens when the PHY is connected to one of the following:
•
•
Autonegotiation-capable link partner
Another PHY in enhanced ActiPHY LP wake-up state
In the absence of signal energy on the media pins, the PHY periodically transitions from low-power state
to LP wake-up state, based on the programmable sleep timer (register bits 20E1.14:13). The actual sleep
time duration is randomized from –80 ms to 60 ms to avoid two linked PHYs in ActiPHY mode entering a
lock-up state during operation.
3.12.2
Link Partner Wake-Up State
In the link partner wake-up state, the PHY attempts to wake up the link partner. Up to three complete FLP
bursts are sent on alternating pairs A and B of the Cat5 media for a duration based on the wake-up timer,
which is set using register bits 20E1.12:11.
In this state, SMI interface (MDC, MDIO, and MDINT) functionality is provided.
After sending signal energy on the relevant media, the PHY returns to the low power state.
3.12.3
Normal Operating State
In the normal operating state, the PHY establishes a link with a link partner. When the media is
unplugged or the link partner is powered down, the PHY waits for the duration of the programmable link
status time-out timer, which is set using register bit 28.7 and bit 28.2. It then enters the low power state.
3.13
IEEE 1588 Block Operation
The VSC8582-10 device uses a second generation IEEE 1588 engine that is backward compatible with
the earlier version of the Microsemi IEEE 1588 time stamping engine, stand alone and in combination
with MACsec. It is also compatible with the IEEE 1588 operations supported in Microsemi CE switches.
The following list shows the new features of the Microsemi second generation IEEE 1588.
•
•
•
•
•
•
•
•
•
•
MACsec support
Increased time stamp accuracy
Auto clear enables after system time is read or written
Ability to load or extract the current system time in serial format
Full 48-bit math support for incoming correction field
Ability to add or subtract fixed offset from system time to synchronize between slaves
Each direction of IEEE 1588 can be independently controlled and bypassed
Support to extract frame signature in an IPv6 frame
MPLS-TP OAM support in third analyzer engine
Special mode where all frames traversing the system can be time stamped
The unique architecture of the MACsec and the second generation IEEE 1588 block combination
provides for the lowest latency and maximum throughput on the channel. The following illustration shows
a block diagram of the IEEE 1588 architecture in the VSC8582-10 device.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
61
Functional Descriptions
Figure 54 • IEEE 1588 Architecture
PH Y 0
PH Y 1
1588 instance
MAC 0
MAC 1
1588 instance
registers
Pro c0
Pro c1
config
LTC0
LTC1
Egress
Pro cesso r 0
deco nstructo r
Ingress
Pro cessor 0
co nstructo r
analyzer
Tim e stam p
Engine0
rewriter
tsp
delay
fifo
Engine1
Engine2
Egress
Pro cessor1
Ingress
Pro cesso r1
Engine0
delay
fifo
Engine1
rewriter
tsp
Engine2
co nstructo r
deconstructo r
analyzer
The following sections list some of the major IEEE 1588 applications.
3.13.1
IEEE 1588 Block
The IEEE 1588 engine may be configured to support one-step and two-step clocks as well as Ethernet
and MPLS OAM delay measurement. It detects the IEEE 1588 frames in both the Rx and Tx paths,
creates a time stamp, processes the frame, and updates them. It can add a 30/32-bit Rx time stamp to
the 4-bytes reserved field of the PTP packet. It can also modify the IEEE 1588 correction field and
update the CRC of changed frames. There are local time counters (reference for all time stamps) that
can be preloaded and adjusted though the register interface.
A local time counter is used to hold the local time for Rx and Tx paths. A small FIFO delays frames to
allow time for processing and modification. An analyzer detects the time stamp frames (PTP and OAM)
and a time stamp block calculates the new correction field. The rewriter block replaces the correction
field with an updated one and checks/calculates the CRC. For the Tx path, a time stamp FIFO saves Tx
event time stamp plus frame identifier for use in some modes.
The IEEE 1588 engine’s registers and time stamps are accessible through the MDIO or 4-pin SPI. To
overcome the MDIO or 4-pin SPI speed limitations, the dedicated “push-out” style SPI output bus can be
used for faster or large amounts of time stamp reads. This SPI output is used to push out time stamp
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
62
Functional Descriptions
information to an external device only and does not provide read/write to the registers of the IEEE 1588
engine or registers of other blocks in the VSC8582-10 device. In addition, there is a LOAD/SAVE pin that
is used to load the time in the PHYs and ensure that all the PHYs are in sync. The local time counter may
come from any one of the following sources:
•
•
•
Data path clock (varies according to mode)
250 MHz from host side PLL
External clock from 1588 DIFF_INPUT_CLK_P/N pins
The local time counters contain two counters: nanosecond_counter and second_counter. The 1 PPS
(pulse per second signal) output pin can be used for skew monitoring and adjustment. The following
illustration shows an overview of a typical system using IEEE 1588 PHYs. The LOAD/SAVE and 1 PPS
pins are signals routed to the GPIO pins. The following illustration shows how the PHY is embedded in a
system.
Figure 55 • IEEE 1588 Block Diagram
Ethernet Port
Ethernet Line Card
System Card
Ethernet Line Card
Linecard Control
Processor
System 1588
Control
Processor
Linecard Control
Processor
1G
PHY
MAC
Packet
Processing
RefClk
Fabric
Packet
Processing
MAC
Timing Card
Optional
frequency
conversion
Timing
Card
10G
PHY
Ethernet Port
RefClk
Optional
frequency
conversion
1 PPS Sync
The system card has to drive the refclk (125 MHz or 250 MHz timetick clock) to all the PHYs, including
the VSC8582-10 device. The system clock may need local frequency conversion to match the required
reference clock frequency. The system clock may be locked to a PRC by SyncE or by IEEE 1588. If
locked by IEEE 1588, the central CPU recovers the PTP timing and adjusts the frequency of the system
clock to match the PTP frequency. If the system clock is free running, the central CPU must calculate the
frequency offset between the system clock and the synchronized IEEE 1588 clock and program the
PHYs to make internal adjustments.
Other than the clock, the system card also provides a sync pulse to all PHYs, including the VSC8582-10
device to the LOAD/SAVE pin. This signal is used to load the time to the PHYs and to ensure that all the
PHYs are in sync. This may just be a centrally divided down system clock that gives a pulse at fixed time
intervals. The delay from the source of the signal to each PHY must be known and taken into account
when writing in the load time in the PHYs.
The VSC8582-10 device supports a vast variety of IEEE 1588 applications. In simple one-step end-toend transparent clock applications, the VSC8582-10 device can be used without any central CPU
involvement except for initial configuration. The IEEE 1588 block inside the VSC8582-10 device forwards
Sync and Delay_req frames with automatic updates to the Correction field.
In other applications, the VSC8582-10 device enhances the performance by working with a central
processor that runs the IEEE 1588 protocol. The VSC8582-10 device performs the accurate time stamp
operations needed for all the different PTP operation modes. For example, at startup in a boundary clock
application, the central CPU receives PTP sync frames that are time stamped by the ingress PHY and
recovers the local time offset from the PTP master using the PTP protocol. It then sets the save bit in the
VSC8582-10 device connected to the PTP master and later reads the saved time. The central CPU loads
the expected time (time of the next LOAD/SAVE pulse, corrected by the offset to the recovered PTP
time) into the PHY and sets the save bit. It checks that the time offset is 0. If not, it makes small
adjustments to the time in the PHY by issuing add 1 ns or subtract 1 ns commands to the VSC8582-10
device through MDIO, until the time matches the PTP master. A save command is issued to the PHY
connected to the PTP master and reads the saved time. The central CPU then writes the saved time plus
the sync pulse interval plus any sync pulse latency variation (trace length difference compared to the
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
63
Functional Descriptions
PHY connected to the PTP master) to the other PHYs and sets the load bit in these VSC8582-10
devices.
The preceding sequence may be completed in several steps. Not all PHYs need to be loaded at once.
The central CPU sets the save bit in all PHYs and reads back the values. They should all save the same
value.
The central CPU continuously detects if the system time drifts off compared to the recovered PTP time. If
needed, it can adjust each PHY for any known skew between PHYs without affecting the operation of the
device. It can program the PHYs, including the VSC8582-10 device, to automatically add 1 ns or subtract
1 ns at specific time intervals.
3.13.2
IEEE 1588 One-Step E2E TC in Systems
Unique advantages for implementing IEEE 1588-2008:
•
•
•
When several VSC8582-10 devices or Microsemi PHYs with integrated IEEE 1588 time stamping
blocks are used on all ports within the system that support IEEE 1588 one-step E2E TC, the rest of
the system does not need to be IEEE 1588 aware and there is no CPU maintenance needed once
the system is set up
As all the PHYs in a system can be configured the same way, it supports fail-over of IEEE 1588
masters without any CPU intervention
VSC8582-10 and other Microsemi PHYs with integrated IEEE 1588 time stamping blocks also work
for pizza box solutions, where the switch/router can be upgraded to support IEEE 1588 E2E TC
Requirements for the rest of the system are:
•
•
•
3.13.3
Delivery of a synchronous global timetick clock (or reference clock) to the PHYs
Delivery of a global timetick load pulse, that synchronizes the local time counters in each port.
CPU access to each PHY to set up the required configuration. Can be MDC/MDIO or a dedicated
CPU interface.
IEEE 1588 TC and BC in Systems
This is the same system as described previously, with the addition of a central IEEE 1588 engine
(Boundary Clock). The IEEE 1588 engine is most likely a CPU system, possibly together with hardware
support functions to generate Sync frames (for BC and ordinary clock masters). The switch/fabric needs
to have the ability to redirect (and copy) PTP frames to the IEEE 1588 engine for processing.
Figure 56 • TC and BC Linecard Application
Ethernet Port
Ethernet Line Card
System Card
Ethernet Line Card
Linecard Control
Processor
System Control
Processor
Linecard Control
Processor
1G
PHY
MAC
Packet
Processing
Fabric
Packet
Processing
MAC
1G
PHY
Ethernet Port
Boundary
Clock
This solution also works for pizza boxes. To ensure that blade redundancy works, it the PHYs for the
redundant blades must have the same 1588-in-the-PHY configuration.
Requirements for the rest of the system are:
•
•
•
Delivery of a synchronous global timetick clock (or reference clock) to the PHYs
Delivery of a global timetick load, that synchronizes the local time counters in each port
CPU access to each PHY to set up the required configuration. For one-step support this can be
MDC/MDIO. For two-step support, a higher speed CPU interface (such as the SPI) might be
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
64
Functional Descriptions
•
required (depending on the number of time stamps that are required to be read by the CPU). In
blade systems it might be required to have a local CPU on the blade that collects the information and
sends it to the central IEEE 1588 engine by means of the control plane or the data plane. In
advanced MAC/Switch devices this might be an internal CPU
Fabric must be able to detect IEEE 1588 frames and redirect them to the central IEEE 1588 engine
The same solution can also be used to add Y.1731 delay measurement support. This does not require a
local CPU on the blade, but the fabric must be able to redirect OAM frames to a local/central OAM
processor
3.13.4
Enhancing IEEE 1588 Accuracy for CE Switches and MACs
Connecting VSC8582-10 or other Microsemi PHYs that have integrated IEEE 1588 time stamping in
front of the CE Switches and MACs improves the accuracy of the IEEE 1588 time stamp calculation. This
is due to the clock boundary for the XAUI and SGMII/QSGMII interface. It will also add support for onestep TC and BC on the Jaguar-1 family of devices.
3.13.5
MACsec Support
MACsec is required when the physical link between two MACs must provide secure communication.
MACsec PHYs such as the VSC8582-10 device are connected with CE switches to provide secure
communication. PTP and OAM frames are recognizable only before or after encryption, meaning that the
MACsec block must precede the IEEE 1588 block from the line inward.
Even though MACsec introduces large delay variation because of the insertion/removal of the MACsec
header on all encrypted frames, the VSC8582-10 device provides the same accuracy with MACsec
enabled as without. In all other aspects, the IEEE 1588 operation is as described in previous sections.
3.13.6
Supporting One-Step Boundary Clock/Ordinary Clock
In one-step boundary clock, the BC device acts as an ordinary clock slave on one port and as master on
the other ports. On the master ports, Sync frames are transmitted from the IEEE 1588 engine that holds
the Origin time stamp. These frames will have the correction field or the full Tx time stamp updated on
the way out though the PHY.
Master ports also receive Delay_req from the slaves and respond with Delay_resp messages. The
Delay_req messages are time stamped on ingress through the PHY and the IEEE 1588 engine receives
the Delay_req frame and generates a Delay_resp message. The Delay_resp messages are not event
messages and are passed though the PHY as any other frame.
The port configured as slave receives Sync frames from its master. The Sync frames have an Rx time
stamp added in the PHY and forwarded to the IEEE 1588 engine.
The IEEE 1588 engine also generates Delay_req frames that are sent on the port configured as slave
port. Normally the transmit time for the Delay_req frames, t3, is saved in a time stamp FIFO in the PHYs,
but when using Microsemi IEEE 1588 PHYs a slight modification can be made to the algorithm to remove
the CPU processing overhead of reading the t3 time stamp.
To modify the algorithm, the IEEE 1588 engine should send the Delay_req message with a software
generated t3 value in the origin time stamp, the sub-second value of the t3 time stamp in the reserved
bytes of the PTP header and a correction field of 0. The software generated t3 time stamp should be
within a second before the actual t3 time. The Egress PHY should then be configured to perform E2E TC
egress operation, meaning calculate the “residence time” from the inserted t3 time stamp to the actual t3
time and insert this value in the correction field of the frame. When the local IEEE 1588 engine receives
the corresponding Delay_resp frame back it can use the software generated t3 value because the
correction field of the Delay_resp frame contains a value that compensates for the actual t3 transmission
time.
Boundary clocks and ordinary clocks must also reply to Pdelay_req messages just as P2P TC using the
same procedure for the P2P TC. For more information, see Supporting One-Step Peer-to-Peer
Transparent Clock, page 72.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
65
Functional Descriptions
Figure 57 • One-Step E2E BC
PTP Sync Or Delay_req Frame
Correction Field = A
Reserved Bytes = 0
IEEE 1588
PHY
PTP Sync or Delay_req Frame
Correction Field = A
Reserved bytes = RxTimestamp
PTP Pdelay_req Frame
Correction Field = C
PTP Sync Frame
OriginTime = F
Correction Field = E
Packet processing and
Switching
PTP Pdelay_req Frame
Correction Field = C
PTP Sync Frame
Correction Field = A
Reserved bytes = RxTimestamp +
Peer Delay
PTP Sync Frame
Origin Time = F
Correction Field = E
Central
IEEE 1588
Engine
(CPU)
Engine recovers
frequency from Sync
frames and controls
1588 frequency
IEEE 1588
IEEE
1588
PHY
PHY
PTP delay_req Frame
Correction Field = C
(TxTimestamp saved in FIFO)
3.13.6.1
PTP Sync Frame
OriginTime = TxTimestamp
Correction Field = E
Ingress
Each time the PCS/PMA detects the start of a frame it sends a pulse to the time stamp block, which
saves the value of the Local_Time received from the Local Time counter. In the time stamp block the
programmed value in the local_correction register is subtracted from the saved time stamp. The
local_correction register is programmed with the fixed latency from the measurement point to the place
that the start of frame is detected in the PCS/PMA logic. The time stamp block also contains a register
that can be programmed with the known link asymmetry. This value is added or subtracted from the
correction field, depending on the frame type.
When the frame leaves the PCS/PMA block it is loaded into a small FIFO block that delays and stores
the frame data for a few clock cycles to allow for later modifications of the frame. The data is also copied
to the analyzer block that parses the incoming frame to detect whether it is an IEEE 1588 Sync or
Delay_req frame belonging to the PTP domain that the system is operating on. If so it signals to the
ingress time stamp block in the PHY which action to perform (Write). It also delivers the write offset and
data size (location of the four reserved bytes in the PTP header, 4 bytes wide) to the rewriter block in the
PHY.
If the analyzer detects that the frame is not matched, it signals to the time stamp block and the rewriter
block to ignore the frame (NOP), which allows it to pass unmodified and flushes the saved time stamp in
the time stamp block.
If the time stamp block gets the Write action, it delivers the value of the calculated time stamp for the
frame to the rewriter block and the rewriter block adds this time stamp (ns part of it) to the four reserved
bytes in the frame and recalculates FCS.
The rewriter block takes data out of the FIFO block continuously and feeds it to the system side
PCS/PMA block using a counter to keep track of the byte positions of the frame. When the rewriter block
receives a signal from the time stamp block to rewrite a specific position in the frame (that information
comes from the analyzer block), it overwrites the position with the data from the time stamp block and
replaces the FCS of the frame. The rewriter also checks the original FCS of the frame to ensure that a
frame that is received with a bad FCS and then modified by the rewriter is also sent out with a bad FCS.
This is achieved by inverting the new FCS. If the frame is an IPv4 frame the rewriter ensures that the IP
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
66
Functional Descriptions
checksum is 0. If the frame is IPv6 the rewriter keeps track of the modifications done to the frame and
modifies a couple of bytes placed at the end of the PTP frame (for this specific purpose) so that the IP
checksum stays correct.
The following full calculations are performed:
•
•
3.13.6.2
Sync frames: Reserved_bytes = (Raw_Timestamp_ns – Local_correction) Correction
field = Original Correction field + Asymmetry
Delay_req frames: Reserved_bytes = (Raw_Timestamp_ns – Local_correction)
Egress
When a frame is received from the system side PCS/PMA block it is loaded into a FIFO block that delays
and stores the frame data for a few clock cycles to allow for later modifications of the frame. The data is
also copied to the analyzer block that parses the incoming frame to detect whether it is an IEEE 1588
Sync or Delay_req frame belonging to the PTP domain that the system is operating on.
If the egress analyzer of the PHY detects that the frame is an IEEE 1588 Sync frame belonging to the
PTP domain(s) of the system, it signals to the egress time stamp block which action to perform (Write). It
also delivers the write offset and data size (location of the Tx time stamp inside the frame, 10 bytes wide)
to the rewriter.
If the egress analyzer detects that the frame is an IEEE 1588 Delay_req frame belonging to the PTP
domain(s) of the system, it signals to the time stamp block which action to perform (Write, Save). It also
delivers the write offset and data size (location of the Tx time stamp inside the frame, 10 bytes wide) to
the rewriter. It also outputs up to 16 bytes of frame identifier to the Tx time stamp FIFO, to be saved along
with the Tx time stamp. The frame identifier bytes are selected information from the frame, configured in
the analyzer.
If the time stamp block gets the (Write, Save) action it delivers the calculated time stamp and signals to
the time stamp FIFO block that it must save the time stamp along with the frame identifier data it received
from the analyzer block.
The Tx time stamp FIFO block contains a buffer memory. It simply stores the Tx time stamp values that it
receives from the time stamp block together with the frame identifier data it receives from the analyzer
block and has a CPU interface that allows the IEEE 1588 engine to read out the time stamp sets (Frame
identifier + New Tx time stamp).
The following full calculations are performed:
•
•
3.13.7
Sync frames: OriginTimestamp = (Raw_Timestamp + Local_correction)
Delay_req frames: OriginTimestamp = (Raw_Timestamp + Local_correction) Correction
field = Original Correction field + Asymmetry
Supporting Two- Step Boundary/Ordinary Clock
Two-step clocks are used in systems that cannot update the correction field on-the-fly and this requires
more CPU processing than one-step.
Each time a Tx time stamp is sent in a frame, the IEEE 1588 engine reads the actual Tx transmission
time from the time stamp FIFO and issues a follow-up message containing this time stamp. Even though
the VSC8582-10 device supports one-step operation, thereby eliminating the need to run in two-step
mode, support for this mode is provided for networks that include two-step-only implementations.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
67
Functional Descriptions
Figure 58 • Two-Step E2E BC
PTP Sync Or Delay_req Frame
Correction Field = A
Reserved Bytes = 0
IEEE 1588
PHY
PTP Sync or Delay_req Frame
Correction Field = A
Reserved bytes = RxTimestamp
PTP Pdelay_req Frame
Correction Field = C
PTP Sync Frame
OriginTime = F
Correction Field = E
Packet processing and
Switching
PTP Pdelay_req Frame
Correction Field = C
PTP Sync Or Delay_req Frame
Correction Field = A
Reserved bytes = RxTimestamp
PTP Sync Frame
Origin Time = F
Correction Field = E
Central
IEEE 1588
Engine
(CPU)
Engine recovers
frequency from Sync
frames and controls
1588 frequency
IEEE 1588
PHY
PTP delay_req Frame
Correction Field = C
(TxTimestamp saved in FIFO)
3.13.7.1
PTP Sync Frame
OriginTime = F
Correction Field = E
(TxTimestamp saved in FIFO)
Ingress
If the ingress analyzer in the PHY detects that the frame is an IEEE 1588 Sync or Delay_req frame
belonging to the PTP domain(s) of the system, it signals to the time stamp block which action to perform
(Write). It also delivers the write offset and data size (location of the four reserved bytes in the PTP
header, 4 bytes wide) to the rewriter.
If the time stamp block gets the Write action, it delivers the calculated time stamp to the rewriter block
and the rewriter block adds this time stamp (ns part of it) to the four reserved bytes in the frame and
recalculates FCS.
Note:
When secure timing delivery is required, when using IPsec authentication for instance, the four
reserved bytes must be reverted back to 0 before performing integrity check.
The following full calculations are performed:
•
•
3.13.7.2
Sync frames: Reserved_bytes = (Raw_Timestamp – Local_correction)
Correction field = Original Correction field + Asymmetry
Delay_req frames: Reserved_bytes = (Raw_Timestamp – Local_correction)
Egress
If the egress analyzer detects that the frame is an IEEE 1588 Sync or Delay_req frame belonging to the
PTP domain(s) of the system, it signals to the time stamp block which action to perform (Write, Save).
The analyzer outputs up to 15 bytes of frame identifier to the Tx time stamp FIFO to be saved along with
the Tx time stamp. The frame identifier must include, at a minimum, the sequenceId field so the CPU can
match the time stamp with the follow-up frame.
If the time stamp block gets the Write, Save action it delivers the calculated time stamp to the time stamp
FIFO and signals to the time stamp FIFO block that it must save the time stamp along with the frame
identified data it received from the analyzer block.
The following full calculations are performed:
•
Sync frames: FIFO = (Raw_Timestamp + Local_correction)
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
68
Functional Descriptions
•
3.13.8
Delay_req frames: FIFO = (Raw_Timestamp + Local_correction)
Correction field = Original Correction field – Asymmetry
Supporting One-Step End-to-End Transparent Clock
End-to-end transparent clocks add the residence time (the time it takes to traverse the system from the
input to the output port(s)) to all Sync and Delay_req frames. It does not need to have any knowledge of
the actual time, but if it is not locked to the frequency of the IEEE 1588 time, it will produce an error that
is the ppm difference in frequency times the residence time.
When the TC is frequency-locked by means of IEEE 1588 or other methods (SyncE), the error is only
caused by sampling inaccuracies.
The VSC8582-10 device supports a number of different transparent clock modes that can be divided into
two main modes, as follows:
•
•
Mode A subtracts the ingress time stamp at ingress and adds the egress time stamp at egress. This
mode can run in a number of sub-modes, depending on the format of the time stamp that is
subtracted or added.
Mode B saves the ingress time stamp in the reserved bytes of the PTP header (just as is done in BC
and ordinary clock modes) and performs the residence time calculation at the egress PHY where the
calculated residence time is added to the correction field of the PTP frame.
Mode B is recommended because it has a number of advantages, including the option to support TC and
BC operation in the same system and on the same traffic and the ease of implementing syntonized TC
operation.
When an E2E TC recovers frequency using IEEE 1588 and is using Mode A, it must either have a PHY
with IEEE 1588 time stamping Mode A support or another way of adding the local time to the correction
field placed in front of the IEEE 1588 engine. The IEEE 1588 engine is then able to receive Sync frames
and adjust the local frequency to match the IEEE 1588 time.
If using Mode B the IEEE 1588 engine can recover the frequency directly from the Sync frames because
it can extract the ingress time stamp directly from the frames. The frequency adjustment can be done by
adjusting the time counter in each PHY or by adjusting the global Timetick clock.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
69
Functional Descriptions
Figure 59 • One-Step E2E TC Mode A
P TP S ync or D elay_R eq Fram e
C orrection Field = A
IEEE 1588
PHY
P TP S ync or D elay_R eq Fram e
C orrection Field = A – R xTim estam p
P acket processing and
S w itching
Central
IEEE 1588
Engine
(CP U )
P TP S ync or D elay_R eq Fram e
C orrection Field = A – R xTim estam p
IEEE 1588
IEEE
P H1588
Y
PHY
P TP S ync or D elay_R eq Fram e
C orrection Field =
A – R xTim estam p + TxTim estam p
When the system works in one-step E2E TC mode Sync and Delay_req frames must be forwarded
through the system and the residence time = (Egress time stamp – Ingress time stamp) must be added
to the correction field in the frame before it leaves the system.
The following sections describe the operation in Modes A and B.
3.13.8.1
Ingress, Mode A
If the analyzer detects that the frame is an IEEE 1588 Sync or Delay_req frame belonging to the PTP
domain(s) of the system, it signals to the time stamp block which action to perform (Subtract), along with
the correction field of the frame. It also delivers the write offset and data size (location of the correction
field inside the frame, 8 bytes wide) to the rewriter.
If the time stamp block gets the Subtract action, it subtracts the time stamp converted to ns from the
original correction field of the frame and outputs the value to the rewriter block.
As a result the frame is sent towards the system with a correction field containing the value: Original
Correction field – Rx time stamp (converted to ns).
The following full calculations are performed:
•
•
3.13.8.2
Sync frames: Internal Correction field = Original Correction field – (Raw_Timestamp_ns –
Local_correction) + Asymmetry
Delay_req frames: Internal Correction field = Original Correction field – (Raw_Timestamp_ns –
Local_correction)
Egress, Mode A
The egress side works that same way as ingress, but the analyzer is set up to add the active_timestamp
to the correction field.
If the analyzer detects that the frame is aa IEEE 1588 Sync or Delay_req frame belonging to the PTP
domain(s) of the system, it signals to the time stamp block which action to perform (Add), along with the
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
70
Functional Descriptions
correction field of the frame. It also delivers the write offset and data size (location of the correction field
inside the frame, 8 bytes wide) to the rewriter.
If the analyzer detects that the frame is not matched, it signals the time stamp block and the rewriter
block to ignore the frame (let it pass unmodified and flush the saved time stamp in the time stamp block).
If the time stamp block gets the Add action, it adds the current value of the active_timestamp to the value
of the correction field received from the analyzer and outputs the value to the rewriter block.
When the rewriter block receives a signal from the analyzer block to rewrite a specific position in the
frame, it overwrites the position with the data received from the time stamp block and replaces the FCS
of the frame. The rewriter also checks the original FCS of the frame and ensures that a frame that is
received with a bad FCS and then modified by the rewriter is also sent out with a bad FCS. This is
achieved by inverting the new FCS.
The following full calculations are performed:
•
•
Sync frames: Correction field = Internal Correction field + (Raw_Timestamp_ns + Local_correction)
Delay_req frames: Correction field = Internal Correction field + (Raw_Timestamp_ns +
Local_correction) – Asymmetry
Figure 60 • One-Step E2E TC Mode B
PTP Sync or Delay_Req Frame
Correction Field = A
Reserved Bytes = 0
IEEE 1588
IEEE
1588
PHY
PHY
PTP Sync or Delay_Req Frame
Correction Field = A
Reserved bytes = RxTimestamp
Packet processing and
Switching
PTP Sync Frame
Correction Field = A
Reserved bytes = RxTimestamp
PTP Sync or Delay_Req Frame
Correction Field = A
Reserved bytes = RxTimestamp
Central
IEEE 1588
Engine
(CPU)
Engine recovers frequency
from Sync frames and
controls 1588 frequency
IEEE 1588
PHY
PTP Sync or Delay_Req Frame
Correction Field =
A – RxTimestamp + TxTimestamp
Reserved bytes = 0
3.13.8.3
Ingress, Mode B
In ingress mode B, all calculations are performed at the egress port.
On the ingress side, when the analyzer detects Sync or Delay_req frames it adds the Rx time stamp to
the four reserved bytes in the PTP frame.
The following full calculations are performed:
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
71
Functional Descriptions
•
•
3.13.8.4
Sync frames: Reserved_bytes = Raw_Timestamp_ns – Local_correction Correction field = Original
Correction field + Asymmetry
Delay_req frames: Reserved_bytes = Raw_Timestamp_ns – Local_correction
Egress, Mode B
All calculations are done at the egress side. When the analyzer detects Sync or Delay_req frames it
performs the following calculation:
Correction field = Original Correction field + Tx time stamp – Rx time stamp
The value of the Rx time stamp is extracted from four reserved bytes in the PTP header. The four
reserved bytes are cleared back to 0 before transmission.
The result is that every Sync and Delay_req frame that belongs to the PTP domain(s) and is configured
as one-step E2E TC in the system will exit the system with a correction field that contains the following:
Correction field = Original correction field + Tx time stamp – Rx time stamp
All this is done without any interaction with a CPU system, other than the initial setup. There is no
bandwidth expansion. Standard switching/routing tunneling can be done between the ingress and egress
PHY, provided that the analyzers in the ingress PHY and egress PHY are set up to catch the Sync and
Delay_req on both. If the PTP Sync and Delay_req frames are modified inside the system, the egress
analyzer must be able to detect the egress Sync and Delay_req frames; otherwise, the egress Sync and
Delay_req frames will have an incorrect correction field.
The following full calculations are performed:
•
•
3.13.9
Sync frames: Correction field = Original Correction
field + (Raw_Timestamp_ns + Local_correction) – Reserved_bytes
Delay_req frames: Correction field = Original Correction
field + (Raw_Timestamp_ns + Local_correction) – Reserved_bytes – Asymmetry
Supporting One-Step Peer-to-Peer Transparent Clock
When a Sync frame traverses a P2P TC, the correction field is updated with both the residence time and
the calculated path delay on the port that the Sync frame came in on.
3.13.9.1
Peer Link Delay Measurement
In P2P TC, the P2P TC device actively sends and receives Pdelay_req and Pdelay_resp messages, and
calculates the path delays to each neighbor node in the PTP network. The following illustration shows the
delay measurements.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
72
Functional Descriptions
Figure 61 • Delay Measurements
Master
time
t-ms
Slave
time
t1
Timestamps
known by slave
Sync
Follow_U
p
t2
t3
t-sm
Pde
t2
t1, t2
t3
Req
lay_
t4
t5
Pdela
y_Res
p
Pdela
y_
Grandmaster-M
Resp_
Follow
_Up
t6
S- BC -M
t6
t3, t4, t5, t6
S- OC
To calculate the path delays on a link, the IEEE 1588 engine (located somewhere in the system)
generates Pdelay_req messages on all ports. When transmitted, the actual Tx time stamp t3 is saved for
the CPU to read.
When a P2P TC, BC, or OC receives a Pdelay_req frame, it saves the Rx time stamp (t4) and generates
a Pdelay_resp frame, which adds t5 – t4 to the correction field copied from the received Pdelay_req
frame, where t5 is the time that the Pdelay_resp leaves the port (t5).
When a P2P TC receives the Pdelay_resp frame, it saves the Rx time stamp (t6) and then calculates the
path delay as (t6 – t3 – the correction field of the frame)/2. The time stamp corrections are combined into
a single formula as follows:
Path delay = (t6 – (t3 + (t5 – t4))/2 = (t6 – t3 – t5 + t4)/2 = ((t4 – t3) + (t6 – t5))/2
The two path delays are divided by two, but in such a way as to cancel out any timing difference between
the two devices.
A slight modification can be made to the algorithm to remove the CPU processing overhead of reading
the t3 time stamp. To modify the algorithm, the IEEE 1588 engine should send the Pdelay_req message
with a software generated t3 value in the origin time stamp, the sub-second value of the t3 time stamp in
the reserved bytes of the PTP header, and a correction field of 0. The software generated t3 time stamp
should just be within a second before the actual t3 time. The egress PHY should then be configured to
perform E2E TC egress operation, meaning calculate the “residence time” from the inserted t3 time
stamp to the actual t3 time and insert this value in the correction field of the frame. When the IEEE 1588
engine receives the corresponding Pdelay_resp frame back it can use the software generated t3 value
as the correction field of the Pdelay_resp frame will contain a value that compensates for the actual t3
transmission time.
A P2P TC adds the calculated one-way path delay to the ingress correction field, and this ensures that
the time stamp + correction field in the egress Sync frames is accurate and a slave connected to the P2P
TC only needs to add the link delay from the TC to the slave.
The following sections describe both the standard and modified methods for taking P2P measurements.
As with E2E TC operations, the VSC8582-10 device also supports the different TC modes: mode A (with
different time stamp formats) and mode B. Mode B is also the preferred method to implement P2P TC.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
73
Functional Descriptions
3.13.9.2
Ingress, Mode A
If the analyzer detects that the frame is an IEEE 1588 Sync frame belonging to the PTP domain(s) of the
system, it signals to the time stamp block which action to perform (subtract_p2p), along with the
correction field of the frame. It also delivers the write offset and data size (location of the correction field
inside the frame, 8 bytes wide) to the rewriter.
If the analyzer detects that the frame is an IEEE 1588 Pdelay_req or Pdelay_resp frame belonging to the
PTP domain(s) of the system, it signals to the time stamp block which action to perform (Write). It also
delivers the write offset and data size (location of the reserved 4 bytes in the PTP header that is used to
save the ns part of the Rx time stamp, 4 bytes wide) to the rewriter.
If the time stamp block gets the subtract_p2p action, it subtracts the value in the ingress time stamp from
the correction_field data, adds the configured path delay value, and delivers the result to the rewriter
block.
If the time stamp block gets the Write action, it outputs the value of the ingress time stamp register to the
rewrite block and te rewriter block writes the sub-second value to the reserved bytes in the PTP header.
The following full calculations are performed:
•
•
•
3.13.9.3
Sync frames: Internal Correction field = Original Correction field – (Raw_Timestamp_ns –
Local_correction) + Path_delay + Asymmetry
Pdelay_req frames: Reserved_bytes = Raw_Timestamp_ns – Local_correction
Pdelay_resp frames: Reserved_bytes = Raw_Timestamp_ns – Local_correction
Correction Field = Original Correction field + Asymmetry
Egress, Mode A
If the analyzer detects that the frame is an IEEE 1588 Sync frame belonging to the PTP domain(s) of the
system, it signals to the time stamp block which action to perform (Add), along with the correction field of
the frame. It also delivers the write offset and data size (location of the correction field inside the frame,
8 bytes wide) to the rewriter.
If the analyzer detects that the frame is an IEEE 1588 Pdelay_req frame belonging to the PTP domain(s)
of the system, it signals to the time stamp block which action to perform (Sub_add), along with the
original correction field of the frame (will have the value of 0) and the time stamp extracted from the
reserved bytes. It also delivers the write offset and data size (location of the correction field inside the
frame, 8 bytes wide) to the rewriter.
If the user prefers to use to use the normal t3 handling where the t3 time stamp is saved in a time stamp
FIFO the following configuration should be used: If the analyzer detects that the frame is an IEEE 1588
Pdelay_req frame belonging to the PTP domain(s) of the system, it signals to the time stamp block which
action to perform (Write, Save), along with the original correction field of the frame (will have the value of
0). It also delivers the write offset and data size (0 No data is actually written into the frame) to the
rewriter. In addition it outputs the field that holds the frame identifier (sequenceId from the PTP header) to
the time stamp FIFO, to save along with the Tx time stamp.
If the analyzer detects that the frame is an IEEE 1588 Pdelay_resp frame belonging to the PTP
domain(s) of the system, it signals to the time stamp block which action to perform (Sub_add), along with
the original correction field of the frame (will have the value of the CF received from the Pdelay_req
frame) and the time stamp extracted from the reserved bytes. It also delivers the write offset and data
size (location of the correction field inside the frame, 8 bytes wide) to the rewriter.
If the analyzer detects that the frame is not matched, it signals to the time stamp block and the rewriter
block to ignore the frame (let it pass unmodified and flush the saved time stamp in the time stamp block).
The following full calculations are performed:
•
•
•
Sync frames: Correction field = Internal Correction field + (Raw_Timestamp_ns + Local_correction)
Pdelay_req frames: Correction field = Internal Correction
field + (Raw_Timestamp_ns + Local_correction) – Reserved_bytes – Asymmetry
Pdelay_resp frames: Correction field = Original Correction
field + (Raw_Timestamp_ns + Local_correction) – Reserved_bytes
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
74
Functional Descriptions
3.13.9.4
Ingress, Mode B
If the analyzer detects that the frame is an IEEE 1588 Sync frame belonging to the PTP domain(s) of
system, it signals to the time stamp block which action to perform (subtract_p2p), along with the
correction field of the frame. It also delivers the write offset and data size (location of the correction field
inside the frame, 8 bytes wide) to the rewriter.
If the analyzer detects that the frame is an IEEE 1588 Pdelay_req frame belonging to the PTP domain(s)
of system, it signals to the time stamp block which action to perform (Write). It also delivers the write
offset and data size (location of the reserved 4 bytes in the PTP header we use to save the ns part of the
Rx time stamp, 4 bytes wide) to the rewriter.
If the analyzer detects that the frame is an IEEE 1588 Pdelay_resp frame belonging to the PTP
domain(s) of system, it signals to the time stamp block which action to perform (Write). It also delivers the
write offset and data size (location of the reserved 4 bytes in the PTP header we use to save the ns part
of the Rx time stamp, 4 bytes wide) to the rewriter.
If the time stamp block gets the Subtract_p2p action, it subtracts the value in the
active_timestamp_ns_p2p register from the correction_field data and outputs the value on the New_Field
bus to the Rewriter block.
If the time stamp block gets the Write action, it outputs the value of the active_timestamp_ns register on
the New_field bus to the Rewriter block.
The following full calculations are performed:
•
•
•
3.13.9.5
Sync frames: Internal Correction field = Original Correction field – (Raw_Timestamp_ns –
Local_correction) + Path_delay + Asymmetry
Pdelay_req frames: Reserved_bytes = Raw_Timestamp_ns – Local_correction
Pdelay_resp frames: Reserved_bytes = Raw_Timestamp_ns – Local_correction + Asymmetry
Egress, Mode B
If the analyzer detects that the frame is an IEEE 1588 Sync frame belonging to the PTP domain(s) of
system, it signals to the time stamp block which action to perform (Add), along with the correction field of
the frame. It also delivers the write offset and data size (location of the correction field inside the frame,
8 bytes wide) to the rewriter.
If the analyzer detects that the frame is an IEEE 1588 Pdelay_req frame belonging to the PTP domain(s)
of system, it signals to the time stamp block which action to perform (Write, Save), along with the original
correction field of the frame (will have the value of 0). It also delivers the write offset and data size (0 No
data is actually written into the frame) to the rewriter. In addition it outputs the field that holds the frame
identifier (sequenceId from the PTP header) to the time stamp FIFO, to save along with the Tx time
stamp.
If the analyzer detects that the frame is an IEEE 1588 Pdelay_resp frame belonging to the PTP
domain(s) of system, it signals to the time stamp block which action to perform (Add - this requires that
the IEEE 1588 engine has subtracted the Rx time stamp from the correction field), along with the original
correction field of the frame. It also delivers the write offset and data size (location of the correction field
inside the frame, 8 bytes wide) to the rewriter.
If the time stamp block gets the Write, Save action it outputs the value of the active_timestamp_ns
register on the New_field bus to the Rewriter block and sets the save_timestamp bit.
If the time stamp block gets the Add action, it adds the correction field value to the value in the
active_timestamp_ns register and outputs the value on the New_Field bus to the Rewriter block.
The Tx time stamp FIFO block contains an (implementation specific) amount of buffer memory. It simply
stores the Tx time stamp values that it receives from the time stamp block together with the frame
identifier data it receives from the Analyzer block and has a CPU interface that allows the IEEE 1588
engine to read out the time stamp sets (Frame identifier + New Tx time stamp).
The following full calculations are performed:
•
•
Sync frames: Correction field = Internal Correction field + (Raw_Timestamp_ns + Local_correction)
Pdelay_req frames: FIFO = Raw_Timestamp_ns + Local_correction – Asymmetry
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
75
Functional Descriptions
•
Pdelay_resp frames: Correction field = Internal Correction field +
(Raw_Timestamp_ns + Local_correction)
Figure 62 • One-Step P2P TC Mode B
PTP Pdelay_req/resp Frame
Correction Field = B
Reserved Bytes = 0
PTP Sync Frame
Correction Field = A
Reserved Bytes = 0
Central
IEEE 1588
IEEE
1588
Engine
PHY
(CPU)
PTP Sync Frame
PTP Pdelay_req/resp Frame
Correction Field = A
Correction Field = B
Reserved bytes = RxTimestamp +
Reserved Bytes = RxTimestamp
Peer Delay
PTP Pdelay_req Frame
Correction Field = C
PTP Pdelay_resp Frame
Correction Field = D
(D = B – RxTimestamp)
Packet processing and
Switching
PTP Pdelay_resp Frame
Correction Field = D
(D = B – RxTimestamp)
PTP Pdelay_req Frame
Correction Field = C
PTP Sync Frame
Correction Field = A
Reserved bytes = RxTimestamp +
Peer Delay
Central
IEEE 1588
Engine
(CPU)
PTP Sync Frame
Correction Field = A
Reserved bytes = RxTimestamp +
Peer Delay
Central
IEEE 1588
Engine
(CPU)
Engine recovers
frequency from Sync
frames and controls
1588 frequency
PTP Pdelay_req/resp Frame
Correction Field = B
Reserved Bytes = RxTimestamp
PTP Sync Frame
Correction Field =
PTP Pdelay_resp Frame
PTP Pdelay_req Frame
A – RxTimestamp + TxTimestamp
Correction Field = D + TxTimestamp Correction Field = C
+ Peer Delay
(TxTimestamp saved in FIFO)
Reserved bytes = 0
3.13.10 Supporting Two-Step Transparent Clock
In two-step transparent clocks, the Rx and Tx time stamps are saved for the IEEE 1588 engine to read
and the follow-up message is redirected to the IEEE 1588 engine so that it can update the correction field
with the residence time.
Even though two-step transparent clocks can be used with this architecture, it is also possible to process
the frames in the same manner as a one-step TC, because the slaves are required to take both the
correction fields from the Sync frames and the follow-up frames into account. This significantly reduces
the CPU load for the TC. The following illustration shows two-step transparent clock normal operation.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
76
Functional Descriptions
Figure 63 • Two-Step E2E TC
PTP Sync Or Delay_req Frame
Correction Field = A
Reserved Bytes = 0
IEEE 1588
PHY
PTP Sync or Delay_req Frame
Correction Field = A
Reserved bytes = RxTimestamp
Packet processing and
Switching
PTP Sync Or Delay_req Frame
Correction Field = A
Reserved bytes = RxTimestamp
PTP Sync Or Delay_req Frame
Correction Field = A
Reserved bytes = RxTimestamp
Central
IEEE 1588
Engine
(CPU)
Engine recovers
frequency from Sync
frames and controls
1588 frequency
IEEE 1588
PHY
PTP Sync Or Delay_req Frame
Correction Field = A
Reserved bytes = 0
TxTimestamp and RxTimestamp in
FIFO
3.13.10.1 Ingress
If the analyzer detects that the frame is an IEEE 1588 Sync or Delay_req frame belonging to the PTP
domain(s) of the system, it signals to the time stamp block which action to perform (Write). The analyzer
also delivers the write offset and data size to the rewriter (four reserved bytes in the PTP header, which
will be passed out on the egress port of the system). A changed reserved value may be significant in
security protection. This method allows the frames to be copied to the IEEE 1588 engine, so that it can
extract the Rx time stamp and that it knows that it needs to read the Tx time stamps to be ready for the
follow up message. It is also possible to save the Rx time stamp value along with the Tx time stamp in
the Tx time stamp FIFO.
If the time stamp block gets the Write action, it outputs the current time stamp to the rewriter and the
rewriter writes the ns part of the time stamp into the reserved bytes and recalculates FCS.
The following full calculations are performed:
•
•
Sync frames: Reserved_bytes = (Raw_Timestamp_ns – Local_correction) Correction
field = Original Correction field + Asymmetry
Delay_req frames: Reserved_bytes = Raw_Timestamp_ns – Local_correction
3.13.10.2 Egress
If the analyzer detects that the frame is an IEEE 1588 Sync or Delay_req frame belonging to the PTP
domain(s) of the system, it signals to the time stamp block which action to perform (Write, Save). The
analyzer also delivers the write offset and data size (but as nothing is to be overwritten the values will be
0) to the rewriter. The analyzer outputs 10 bytes of frame identifier to the Tx time stamp FIFO to be saved
along with the Tx time stamp. The frame identifier must include, at minimum, the sequenceId field so the
CPU can match the time stamp with the follow-up frame. The analyzer also outputs the offset for the
reserved fields in the PTP header to the rewriter, so that the rewriter field is reset to 0 and the temporary
Rx time stamp value is cleared.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
77
Functional Descriptions
If the time stamp block gets the Write, Save action it outputs the current time stamp value to the rewriter
(and time stamp FIFO) and sets the save_timestamp bit. The time stamp FIFO block saves the New_field
data along with the frame identifier data it received from the analyzer block. The frame identifier data that
is saved can contain the reserved field in the PTP header that was written with the Rx time stamp, so that
the CPU now can read the set of Tx and Rx time stamp from the Tx time stamp FIFO.
The following full calculations are performed:
•
•
Sync frames: FIFO = Raw_Timestamp_ns + Local_correction (reserved_bytes containing the Rx
time stamp saved together with Tx time stamp)
Delay_req frames: FIFO = Raw_Timestamp_ns + Local_correction – Asymmetry (reserved_bytes
containing the Rx time stamp saved together with Tx time stamp)
3.13.11 Calculating OAM Delay Measurements
Frame delay measurements can be made as one-way and two-way delay measurements. Microsemi
recommends that the delay measurement be measured before the packets enter the queues, if the
purpose is to measure the delay for different priority traffic, but it can be used with time stamping in the
PHY to measure the delay through the network devices placed in the path between the measurement
points.
The function is mainly an on-demand OAM function, but it can run continuously.
3.13.12 Supporting Y.1731 One-Way Delay Measurements
One-way delay measurements require that the two peers are synchronized in time. When they are not
synchronized, only frame delay variations can be measured.
The MEP periodically sends out 1DM OAM frames containing a TxTimeStampf value in IEEE 1588
format.
The receiver notes the time of reception of the 1DM frame and calculates the delay.
Figure 64 • Y.1731 1DM PDU Format
1.
2.
3.
4.
5.
6.
7.
For one-way delay measurements, both MEPs must support IEEE 1588 and be in sync.
1DM frame is generated by the CPU, but with an empty Tx time stamp.
The frame is transmitted by the initiating MEP.
The 1DM frame is classified as an outgoing 1DM frame by the egress PHY and the PHY rewrites the
frame with the time as TxFCf.
The receiving PHY classifies the incoming 1DM frame and writes the receive time stamp in reserved
place (RxTimeStampf).
The frame is received by the peer MEP.
The frame is forwarded to the CPU that can calculate the delay.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
78
Functional Descriptions
Figure 65 • Y.1731 One-Way Delay
Y.1731 1DM Message
TxTimeStampf = A
RxTimeStampf = 0
IEEE 1588
PHY
Y.1731 1DM Message
TimeStampsf = A
RxTimeStampf = RxTimestamp
Y.1731 1DM Message
TimeStampsf = 0
RxTimeStampf = 0
Packet processing and
Switching
Y.1731 1DM Message
TimeStampsf = A
RxTimeStampf = RxTimestamp
Y.1731 1DM Message
TimeStampsf = 0
RxTimeStampf = 0
Central
Y.1731
Engine
(CPU)
IEEE 1588
PHY
Y.1731 1DM Message
TimeStampsf = TxTimestamp
RxTimeStampf = 0
3.13.12.1 Ingress
If the analyzer detects that the frame is a Y.1731 1DM PDU frame belonging to the MEP, it signals to the
time stamp block which action to perform (Write). The analyzer also delivers the write offset and data size
(location of the RxTimeStampf location in the frame, 8 bytes wide) to the rewriter.
If the time stamp block gets the Write action, it delivers the time stamp to the rewriter block and the
rewriter block adds this time stamp to the reserved bytes in the frame and recalculates FCS.
The following calculation is performed for 1DM frames:
RxTimeStampf = (Raw_Timestamp – Local_correction)
3.13.12.2 Egress
If the analyzer detects that the frame is a Y.1731 1DM PDU frame belonging to the MEP, it signals to the
time stamp block which action to perform (Write). It also delivers the write offset and data size (location of
the TxTimeStampf location in the frame, 8 bytes wide) to the rewriter.
If the time stamp block gets the Write action, it delivers the time stamp to the rewriter block and the
rewriter block adds this time stamp to the reserved bytes in the frame and recalculates FCS.
The following calculation is performed for 1DM frames:
TxTimeStampf = (Raw_Timestamp + Local_correction)
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
79
Functional Descriptions
3.13.13 Supporting Y.1731 Two-Way Delay Measurements
When performing two-way delay measurements, the initiating MEP transmits DMM frames containing a
TxTimeStampf value. The receiving MEP replies with a DMR frame that is the same as the DMM frame,
but with destination and source MAC address swapped and with a different OAMPDU opcode.
When the DMR frame is received back at the initiating MEP, the time of reception is noted and the total
delay is calculated.
As an option, it is allowed to include two additional time stamps in the DMR frame: RxTimeStampf and
TxTimeStampb. These contain the time that the DMM page is received for processing and the time the
responding DMR reply is sent back, both in IEEE 1588 format.
Including these time stamps allows for the exclusion of the processing time in the peer MEP, but it does
not require that the two MEPs are synchronized.
Figure 66 • Y.1731 DMM PDU Format
In that case, the following frame flow is needed (two-way delay measurement):
1.
2.
3.
4.
5.
6.
7.
8.
DMM frame is generated by the CPU (initiating MEP), but with an empty Tx time stamp.
In the egress PHY the DMM frame is classified as an outgoing DMM frame from the MEP and the
PHY rewrites the frame with the time as TxTimeStampf.
In the ingress PHY the frame is classified as an incoming DMM belonging to the MEP and the
RxTimeStampf in the frame is written (the frame has a reserved space for this).
The DMM frame is forwarded to the MEP (CPU).
The CPU processes the frame (swaps SA/DA MAC addresses, modifies the opcode to DMT) and
sends out a DMT frame.
The outgoing DMT frame is detected in the egress PHY and the TxTimeStampb is written into the
frame.
In the ingress PHY the frame is classified as an incoming DMT belonging to the MEP and the
RxTimeStampb in the frame in written (the frame has a reserved space for this).
The frame is forwarded to the CPU that can calculate the delays.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
80
Functional Descriptions
Figure 67 • Y.1731 Two-Way Delay
Y.1731 DMR Message
TxTimeStampf = D
RxTimeStampf = E
TxTimeStampb = F
RxTimeStampb = 0
Y.1731 DMM Message
TxTimeStampf = A
RxTimeStampf = 0
TxTimeStampb = 0
RxTimeStampb = 0
IEEE 1588
PHY
Y.1731 DMR Message
Y.1731 DMM Message
TxTimeStampf = D
TxTimeStampf = A
RxTimeStampf = E
RxTimeStampf = RxTimestamp
TxTimeStampb = F
TxTimeStampb = 0
RxTimeStampb = RxTimestamp RxTimeStampb = 0
Y.1731 DMM Message
TxTimeStampf = 0
RxTimeStampf = 0
TxTimeStampb = 0
RxTimeStampb = 0
Y.1731 DMR Message
TxTimeStampf = B
RxTimeStampf = C
TxTimeStampb = 0
RxTimeStampb = 0
Packet processing and
Switching
Y.1731 DMR Message
TxTimeStampf = B
RxTimeStampf = C
TxTimeStampb = 0
RxTimeStampb = 0
Y.1731 DMM Message
TxTimeStampf = A
RxTimeStampf = RxTimestamp
TxTimeStampb = 0
RxTimeStampb = 0
Y.1731 DMM Message
TxTimeStampf = 0
RxTimeStampf = 0
TxTimeStampb = 0
RxTimeStampb = 0
IEEE 1588
PHY
Central
Y.1731
Engine
(CPU)
Y.1731 DMR Message
TxTimeStampf = D
RxTimeStampf = E
TxTimeStampb = F
RxTimeStampb = RxTimestamp
Y.1731 DMM Message
Y.1731 DMR Message
TxTimeStampf = TxTimestamp
TxTimeStampf = B
RxTimeStampf = 0
RxTimeStampf = C
TxTimeStampb = 0
TxTimeStampb = TxTimestamp
RxTimeStampb = 0
RxTimeStampb = 0
3.13.13.1 Ingress
If the analyzer detects that the frame is a Y.1731 DMM PDU frame belonging to the MEP, it signals to the
time stamp block which action to perform (Write). It also delivers the write offset and data size (location of
the RxTimeStampf location in the frame, 8 bytes wide) to the rewriter.
If the analyzer detects that the frame is a Y.1731 DMT PDU frame belonging to the MEP, it signals to the
time stamp block which action to perform (Write). It also delivers the write offset and data size (location of
the RxTimeStampf location in the frame, 8 bytes wide) to the rewriter.
If the time stamp block gets the Write action, it delivers the time stamp to the rewriter block and the
rewriter block adds this time stamp to the reserved bytes in the frame and recalculates FCS.
The following calculations are performed:
•
•
DMM frames: RxTimeStampf = (Raw_Timestamp – Local_correction)
DMR frames: RxTimeStampb = (Raw_Timestamp – Local_correction)
3.13.13.2 Egress
If the analyzer detects that the frame is a Y.1731 DMM PDU frame belonging to the MEP, it signals to the
time stamp block which action to perform (Write). It also delivers the write offset and data size (location of
the TxTimeStampf location in the frame, 8 bytes wide) to the rewriter.
If the analyzer detects that the frame is a Y.1731 DMT PDU frame belonging to the MEP, it signals to the
time stamp block which action to perform (Write). It also delivers the write offset and data size (location of
the TxTimeStampb location in the frame, 8 bytes wide) to the rewriter.
If the time stamp block gets the Write action, it delivers the time stamp to the rewriter block and the
rewriter block adds the time stamp to the reserved bytes in the frame and recalculates FCS as follows:
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
81
Functional Descriptions
•
•
DMM frames: TxTimeStampf = (Raw_Timestamp + Local_correction)
DMR frames: TxTimeStampb = (Raw_Timestamp + Local_correction)
3.13.13.3 Supporting MPLS-TP One-Way and Two-Way Delay Measurements
MPLS-TP one- and two-way delay measurement are defined in RFC6374 (G.8113.2) and G.8113.1 (draftbhh). These mechanisms are similar to the ones described for Y.1731 Ethernet OAM delay measurement
except for the encapsulations. The following illustrations show the PDU formats.
Figure 68 • RFC6374 DMM/DMR OAM PDU Format
ETH (1)
14/18/22B
MPLS labels (2)
4/8/12/16B
DMM/DMR OAM PDUs
ACH
4B
OAM PDU Header
8B
Time stamp 1
8B
Time stamp 1
8B
Time stamp 1
8B
Time stamp 1
8B
padding
(variable size)
FCS
4B
(1) 0, 1, or 2 VLAN tags
(2) Up to 4 MPLS labels
Figure 69 • Draft-bhh DMM/DMR/1DM OAM PDU Formats
DMM/DMR
MPLS labels (2)
DMM/DMR OAM PDUs
ACH
14/18/22B
ETH (1)
14/18/22B
4/8/12/16B
MPLS labels (2)
4/8/12/16B
4B
OAM PDU Header
8B
Time stamp 1
8B
Time stamp 1
8B
Time stamp 1
8B
Time stamp 1
End TLV indicator
FCS
ACH
1DM OAM PDUs
ETH (1)
1DM
4B
OAM PDU Header
8B
Time stamp 1
8B
Time stamp 1
8B
End TLV indicator
1B
8B
FCS
1B
(1) 0, 1, or 2 VLAN tags
(2) Up to 4 MPLS labels
4B
4B
(1) 0, 1, or 2 VLAN tags
(2) Up to 4 MPLS labels
3.13.14 Device Synchronization for IEEE 1588 Support
It is important to keep all the local clock blocks synchronized to the accurate time over a complete
system. To maintain ns accuracy, the signal routing and internal signal delays must be taken into account
when configuring a system.
The architecture described in this document assumes that there is a global synchronous clock available
in the system. If the system is a telecom system where the system is locked to a PRC, the system clock
can be adjusted to match the PRC, meaning that once locked, the frequency of the system clock ensures
that the local clocks are progressing (counting) with the accurate frequency. This system clock can be
locked to the PRC using IEEE 1588, SyncE, SDH, or by other means.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
82
Functional Descriptions
A global timing signal must also be distributed to all the devices. This could be a 1 pps pulse or another
slow synchronization pulse, like a 4 kHz synchronization frequency. It can also just be a one-shot pulse.
The system CPU can load each local counter with the time value that happens next time the
synchronization pulse goes high (+ the known delay of the synchronization pulse traces). It can also just
load the same approximate time value into all the local clock blocks (again + the known delay of the
synchronization pulse traces) and load them in parallel. Then the local time can be adjusted to match the
actual time by adjusting the local clock blocks using the ±1 ns function.
If the Save signal is triggered synchronously on all PHYs of the system, software can read the saved time
stamp in each PHY and correct the time accordingly. On a blade with multiple PHYs, it is possible to
connect the 1588_PPS_1 pin on one PHY to the 1588_LOAD_SAVE pin on the next PHY. If the routing
delay (both internal chip delay and trace delay) is known, Microsemi recommends that the value saved in
the next PHYs correspond to this delay.
If the global system clock is not synchronous, the PPM offset between system clock and the IEEE 1588
time progress can be calculated. This PPM offset can be used to calculate how many local-time-clocks is
takes to reach a time offset of 1 ns and this value can be programmed into each local time block. The
CPU still need to keep track of the smaller PPM offset and adjust the local time blocks with ± writes when
necessary.
By measuring the skew between the 1 pps test output from each PHY, it is possible to measure the
nominal correction values for the time counters in a system. These can be incorporated into the software
of the system. Variations from system to system and temperature variations should be minimized by
design.
3.13.15 Time Stamp Update Block
The IEEE 1588 block is also called the Time Stamp Update block (TSU) and supports the implementation
of IEEE 1588v2 and ITU-T Y.1731 in PHY hardware by providing a mechanism for time stamp update
(PTP) and time stamping (OAM).
The TSU block works with other blocks to identify PTP/OAM messages, process these messages, and
insert accurate time stamp updates/time stamps where necessary. For IEEE 1588 timing distribution the
VSC8582-10 device supports ordinary clocks, boundary clocks, end-to-end transparent clocks, and peerto-peer transparent clocks in a chassis based IEEE 1588 capable system. One-step and two-step
processing is also supported. For details on the timing protocol, refer to IEEE 1588v2. For OAM details
refer to ITU-T Y.1731 and G.8113.1/G.8113.2. The TSU block implements part of the functionality
required for full IEEE 1588 compliance.
The IEEE 588 protocol has four different types of messages that require action by the TSU: Sync,
Delay_req, Pdelay_req, and Pdelay_resp. These frames may be encapsulated in other protocols, several
layers deep. The processor is able to detect PTP messages within these other protocols. The supported
encapsulations are as follows:
•
•
•
•
•
•
Ethernet
UDP over IPv4
UDP over IPv6
MPLS
Pseudo-wires
PBB and PBB-TE tunnels
OAM frames for delay measurement (1DM, DMM, and DMR) with the following supported
encapsulations:
•
•
•
Ethernet (Y.1731 Ethernet OAM)
Ethernet in MPLS pseudo-wires (Y.1731 Ethernet OAM)
MPLS-TP (G.8113.1 (~draft-bhh-mpls-tp-oam-y1731) and G.8113.2 (RFC6374))
The following illustration shows an overview of the supported PTP encapsulations. Note that the
implementation is flexible such that encapsulations not defined here may also be covered.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
83
Functional Descriptions
Figure 70 • PTP Packet Encapsulations
ETH1
ETH2
M PLS
"PB B "
"E TH "
M A C -in - M A C
IP /U D P
PTP
PTP
PTP
" IP -M P L S "
d ra ft- ie tf-tic to c 1 5 8 8 o v e rm p ls
d ra ft-ie tf-tic to c 1 5 8 8 o v e rm p ls
ETH2
IP /U D P
PTP
PTP
IP /U D P
IP /U D P
PTP
"PW E"
U n ta g g e d /T a g g e d
P B (Q -in -Q )
PTP
The following illustration shows the same overview of the supported encapsulations with the focus on
OAM.
Figure 71 • OAM Packet Encapsulations
ETH1
ETH2
M PLS
"PBB"
"ETH"
MAC -in-MAC
Y.1731 OAM
"PW E"
"ACH"
ETH2
ACH
(RFC-5718)
U ntagged/Tagged
PB (Q -in-Q )
Y.1731 OAM
Y.1731 OAM
G.8113.1
(~draft-bhh-mpls-tp-oam-y1731)
G.8113.2 (RFC6374)
There is one TSU per channel in the VSC8582-10 device. The TSU detects and updates up to three
different encapsulations of PTP/OAM. Non-matching frames are transferred transparently. This includes
IFG, preamble, and SFD. For all frames there is no bandwidth expansion/shrink.
Once these frames are detected in the receive path, they are stamped with the ingress time and
forwarded for further PTP/OAM processing. In the transmit path, the correction field of the appropriate
PTP message (or the Rx and Tx fields of the OAM frame) is updated with the correct time stamp. A local
time counter is maintained to provide the time stamps. Implementation of some of the IEEE 1588
protocol requires interaction with the TSU block over the CPU interface and external processing.
The system has an ingress processor, egress processor, and a local time counter. The ingress and
egress processing logic blocks are identical except that the time stamp FIFO is only required in the
egress direction because the CPU needs to know the actual time stamps of some of the transmitted PTP
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
84
Functional Descriptions
frames. The CPU reads the time stamps and any associated frame information out of the time stamp
FIFO. The FIFO saves the generated time stamps along with information that uniquely identifies the
frame to be read out by the CPU.
The ingress and egress processing blocks run on the same clock as the data paths for the corresponding
directions. The local time counter is the primary reference clock for the system and it maintains the local
reference time used by the TSU logic. It should be synchronized by an external entity. The block provides
a method to load and view its value when the 1588_LOAD_SAVE pin is asserted. The block also
provides a one pulse-per-second output signal with a programmable duty cycle. The local time counter
runs at several clock frequencies.
The following illustration shows the block diagram of the TSU.
Figure 72 • TSU Block Diagram
Ingress processor
Data
SOF
detect
Data
Data
FIFO
Rewriter
Corr_TS
Ingress
predictor
Cntrl
Time stamp
External
Analyzer
1 PPS
Ingress
timing
domain
Adapt
Load/
Save
Local Time
Counter
Adapt
External
Serial
time
stamps
Time stamp
FIFO
Sign.
TS
Time stamp
Egress
timing
domain
Analyzer
Cntrl
Egress
predictor
Corr_TS
Rewriter
FIFO
SOF
detect
Data
Data
Data
Egress processor
In both directions, the input data from the PHY layer is first fed to an SOF detect block. Data is then fed to
both the programmable time-delay FIFO and the analyzer. The FIFO delays the data by the time needed
to complete the operations necessary to update the PTP frame. That is, the data is delayed to the input
of the rewriter so that the rewriter operations are known when the frame arrives. This includes the
analyzer and time stamp processor block's functions.
The analyzer block checks the data stream and searches for PTP/OAM frames. When one is detected, it
determines the appropriate operations to be performed based on the operating mode and the type of
frame detected.
Note: The analyzer blocks of two channels share configuration registers and have identical setups.
The time stamp block waits for an SOF to be detected, captures a time stamp from the local time counter,
and builds the new time stamp that is to be written into the PTP/OAM frame. Captured time stamps can
be read by the CPU.
The rewriter block handles the actual writing of the new time stamp into the PTP/OAM frame. It is also
able to clear parts of the frame such as the UDP checksum, if required, or it can update the frame to
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
85
Functional Descriptions
ensure that the UDP checksum is correct (for IPv6 PTP frames). The block also calculates the new FCS
to be written to the PTP frame after updating the fields with the new time stamp.
The VSC8582-10 device has variable latency in the PCS block. These variations are predicted and used
to compensate/maximize the accuracy of the IEEE 1588 time stamp logic.
If the time stamp update function is not used the block can be bypassed. When the TSU is bypassed, the
block can be configured and then enabled and taken out of bypass mode. The change in bypass mode
takes effect only when an IDLE is in the bypass register. This allows the TSU block to be switched on
without corrupting data.
Each direction of the IEEE 1588 can be bypassed individually by programming the
INTERFACE_CTL.SPLIT_BYPASS bit. Bypass is then controlled by INTRERFACE_CTL.INGR_BYPASS
and INTERFACE_CTL.EGR_BYPASS.
Pause frames pass unmodified through the TSU, but the latency may cause a violation of the allowed
pause flow-control latency limits per IEE 802.3.
3.13.16 Analyzer
The packet analyzer parses incoming packets looking for PTP/OAM frames. It determines the offset of
the correction field within the packet for all PTP frames/for the time stamp in Y.1731 OAM frames. The
analyzer has the following characteristics:
•
•
•
Can compare against two different filter sets plus one optimized for OAM
Each filter targets PTP or OAM frames
Flexible comparator sequence with fixed start (Ethernet/SNAP) and end (PTP/OAM) comparator.
Configurable intermediate comparators (Ethernet/SNAP, 2x IP/UDP/ACH, and MPLS)
The following illustration shows a block diagram of the analyzer.
Figure 73 • Analyzer Block Diagram
Data
Data
SOF
Analyzer
SOF
detect
Encap Engine A0 controller
Offsets &
Next protocol
Ethernet/SNAP
Comparator 1
Encap A
Ethernet/SNAP
Comparator 2
Encap A
IP/UDP/ACH
Comparator 1
Encap A
IP/UDP/ACH
Comparator 2
Encap A
MPLS
Comparator
Encap A
PTP/OAM
Comparator
Encap A
Align
Frame
signature
builder
Encap Engine B1 controller
Offsets &
Next protocol
Ethernet/SNAP
Comparator 1
Encap B
Ethernet/SNAP
Comparator 2
Encap B
IP/UDP/ACH
Comparator 1
Encap B
IP/UDP/ACH
Comparator 2
Encap B
MPLS
Comparator
Encap B
PTP/OAM
Comparator
Encap B
MPLS
Comparator
Encap C
A
PTP/OAM
Comparator
Encap C
A
Encap Engine A2 controller
Offsets &
Next protocol
Ethernet/SNAP
Comparator 1
Encap C
A
A-flow
Ethernet/SNAP
Comparator 2
Encap C
A
B-flow
(OAM optimized)
A-flow
A-flow
A-flow
B-flow
A-flow
B-flow
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
86
Functional Descriptions
The analyzer process is divided into engines and stages. Each engine represents a particular
encapsulation stack that must be matched. There are up to six stages in each engine. Each stage uses a
comparator block that looks for a particular protocol. The comparison is performed stage-by-stage until
the entire frame header has been parsed.
Each engine has its own master enable, so that it can be shut down for major reconfiguration, such as
changes in encapsulation order, without stopping traffic. Other enabled engines are not affected.
The SOF detect block searches for the SFD in the preamble and uses that to indicate the SOF position.
This information is carried along in the pipeline and also passed to the analyzer.
The first stage of the analyzer is a data path aligner that aligns the first byte of the packet (without the
preamble & SFD) to byte 0 of the analyzer data path.
The encapsulation engine handles numerous types of encapsulation stacks. These can be broken down
to their individual protocols, and a comparator is defined for each type. The order in which these are
applied is configurable. Each comparator outputs a pattern/flow match bit and an offset to the start of the
next protocol. The cumulative offset points to the time stamp field.
The sequence in which the protocol comparators are applied is determined by configuration registers
associated with each comparator and the transfer of parameters between comparators is controlled by
the encapsulation engine controller.
It receives the pattern match and offset information from one comparator stage and feeds the start-ofprotocol position to the next comparator. This continues until the entire encapsulation stack has been
parsed and always ends with the PTP/OAM stage or until a particular comparator stage cannot find a
match in any of its flows. If at any point along the way no valid match is found in a particular stage, the
analyzer sends the NOP communication to the time stamp block indicating that this frame does not need
modification and that it should discard its time stamp.
There are two types of engines in the analyzer, one optimized for PTP frames and the other optimized for
OAM frames. The two engine types are mostly identical except that the IP comparators are removed
from the OAM engines. The following table shows the comparator layout per engine type and the number
of flows in each comparator. There are two PTP engines and one OAM engine in each analyzer.
Additional differences in the Ethernet and MPLS blocks are defined in their respective sections. For more
information, see Ethernet/SNAP/LLC Comparator, page 88 and MPLS Comparator, page 92.
Table 26 •
Flows Per Engine Type
Number of Flows
Comparator
PTP Engine
OAM Engine
Ethernet 1
8
8
Ethernet 2
8
8
MPLS
8
8
IP/ACH 1
8
0
IP/ACH 2
8
0
PTP/OAM
6
6
Encapsulation matches can be set independently in each direction by setting the
ANALYZER_MODE.SPLIT_ENCAP_FLOW register. However strict and non-strict flow cannot be set
independently for group A and group B of analyzer engine C.
Choice of strict flow or non-strict has to be made on each direction rather than on an engine by engine
basis. Valid values for INGR_ENCAP_FLOW_ENA and EGR_ENCAP_FLOW_ENA are 3'b000 or
3'b111.
Each comparator stage has an offset register that points to the beginning of the next protocol relative to
the start of the current one. The offset is in bytes, and the first byte of the current protocol counts as byte
0. As an example, the offset register for a stage would be programmed to 10 when the header to match is
10 byte long. With the exception of the MPLS stage (offsets are automatically calculated in that stage), it
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
87
Functional Descriptions
is the responsibility of the programmer to determine the value to put in these registers. This value must
be calculated based upon the expected length of the header and is not expected to change from frameto-frame when matching a given flow.
Table 27 •
Ethernet Comparator: Next Protocol
Parameter
Width
Description
Encap_Engine_ENA 1 bit
For each encapsulation engine and enable bit that turns the
engine on or off. The engine enables and disables either during
IDLE (all 8 bytes must be IDLE) or at the end of a frame. If the
enable bit is changed during the middle of a frame, the engine will
wait until it sees either of those conditions before turning on or off.
Encap_Flow_Mode
There is a separate bit for each engine. For each encapsulation
engine:
1 = Strict flow matching, a valid frame must use the same flow IDs
in all comparators in the engine except the PTP and MPLS
comparators.
0 = A valid frame may match any enabled flow in all comparators
If more than one encapsulation produces a match, the analyzer
sends NOP to the rewriter and sets a sticky bit.
1 bit
The following table shows the ID codes comparators use in the sequencing registers. The PTP packet
target encapsulations require only up to five comparators.
Table 28 •
Comparator ID Codes
ID
Name
Sequence
0
Ethernet Comparator 1
Must be the first
1
Ethernet Comparator 2
Intermediate
2
IP/UDP/ACH Comparator 1
Intermediate
3
IP/UDP/ACH Comparator 2
Intermediate
4
MPLS Comparator
Intermediate
5
PTP/OAM Comparator
Must be the last
The following sections describe the comparators. The frame format of each comparator type is described
first, followed by match/mask parameter definition. All upper and lower bound ranges are inclusive and
all match/mask registers work the same way. If the corresponding mask bit is 1, then the match bit is
compared to the incoming frame. If a mask bit is 0, then the corresponding match bit is ignored (a
wildcard).
3.13.16.1 Ethernet/SNAP/LLC Comparator
There are two such comparators in each engine. The first stage of each engine is always an
Ethernet/SNAP/LLC comparator. The other comparator can be configured to be at any point in the chain.
Ethernet frames can have multiple formats. Frames that have an actual length value in the ethertype field
(Ethernet type I) can have one of three formats: Ethernet with an EtherType (Ethernet type II), Ethernet
with LLC, or Ethernet with LLC & SNAP. Each of these formats can be compounded by having one or two
VLAN tags.
Type II Ethernet
Type II Ethernet is the most common and basic type of Ethernet frame. The Length/EtherType field
contains an EtherType value and either 0, 1, or 2 VLAN tags. Both VLAN can be of type S/C (with
EtherType 0x8a88/0x8100). The payload would be the start of the next protocol.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
88
Functional Descriptions
Figure 74 • Type II Ethernet Basic Frame Format
Destination Address (DA)
5
4
3
2
1
0
5
4
3
2
1
0
5
Destination Address (DA)
5
4
3
2
1
4
3
2
0
1
0
3
0
3
1
0
5
4
3
2
1
3
2
Etype
VLAN Tag
2
1
0
1
0
3
VLAN Tag 1
Source Address (SA)
4
Payload
0
Source Address (SA)
Destination Address (DA)
5
Etype
Source Address (SA)
1
2
Payload
0
VLAN Tag 2
1
2
1
Payload
Etype
1
0
0
Ethernet with LLC and SNAP
If an Ethernet frame with LLC contains a SNAP header, it always follows a three-octet LLC header. The
LLC values for DSAP & SSAP are either 0xAA or 0xAB and the control field contains 0x03. The SNAP
header is five octets long and consists of two fields, the 3-octet OUI value and the 2-octet EtherType. As
with the other types of Ethernet frames, this format can have 0, 1, or 2 VLAN tags. The OUI portion of the
SNAP header is hard configured to be 0 or 0xf8.
The following illustration shows an Ethernet frame with a length in the Length/EtherType field, an LLC
header, and a SNAP header.
Figure 75 • Ethernet Frame with SNAP
Destination Address (DA)
5
4
3
2
1
5
4
3
2
Protocol ID
Length DSAPSSAP Ctl
Source Address (SA)
0
1
0
1
AA/AB AA/AB 0x03
0
2
0x000000
1
EtherType
0
1
0
The following illustration shows an Ethernet frame with an LLC/SNAP header and a VLAN tag in the
SNAP header. The Ethertype in the SNAP header is the VLAN identifier and tag immediately follows the
SNAP header.
Figure 76 • Ethernet Frame with VLAN Tag and SNAP
Destination Address (DA)
$
#
$
#
$
$
$
$
#
Protocol ID
Length DSAPSSAP Ctl
Source Address (SA)
$
$
$
#
AA/AB AA/AB 0x03
#
#
0x000000
#
VLAN EType VLAN Tag ID
#
#
#
#
#
The following illustration shows the longest form of the Ethernet frame header that needs to be
supported: two VLAN tags, an LLC header, and a SNAP header.
Figure 77 • Ethernet Frame with VLAN Tags and SNAP
LLC
Destination Address (DA)
5
4
3
2
1
0
5
Source Address (SA)
4
3
2
1
VLAN 1
EtherType
0
1
VLAN 1
Tag
0
1
VLAN 2
EtherType
0
1
VLAN 2
Tag
0
1
SNAP
Protocol ID
Etype DSAPSSAP Ctl
0
1
0
AA/AB AA/AB 0x03
2
1
0
1
Payload
0
Provider Backbone Bridging (PBB) Support
The provider backbone bridging protocol is supported using two Ethernet comparator blocks back-toback. The first portion of the frame has a type II Ethernet frame with either 0 or 1 VLAN tags followed by
an I-tag. The following illustrations show two examples of the PBB Ethernet frame format.
Figure 78 • PBB Ethernet Frame Format (No B-Tag)
First Ethernet Comparator
Second Ethernet Comparator
I-Tag
Backbone Destination Address (B-DA)
5
4
3
2
1
0
EtherType
Flags
88E7
Backbone Source Address (B-SA)
5
4
3
2
1
0
1
0
0
SID
2
Customer Destination Address (C-DA)
0
1
5
4
3
2
1
0
Rest of
E-net Header
Customer Source Address (C-SA)
5
4
3
2
1
0
Figure 79 • PBB Ethernet Frame Format (1 B-Tag)
Second Ethernet Comparator
First Ethernet Comparator
B-Tag
Backbone Destination Address (B -DA)
5
4
3
2
1
0
Backbone Source Address (B -SA)
5
4
3
2
1
0
EtherType
88A8
1
0
I-Tag
B-VID
1
0
EtherType
88E7
1
0
SID
Flags
0
2
1
Customer Destination Address (C -DA)
0
5
4
3
2
1
0
Customer Source Address (C -SA)
5
4
3
2
1
0
Rest of
E-net Header
Ethernet Comparison
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
89
Functional Descriptions
The Ethernet comparator block has two forms of comparison, as follows:
•
•
Next protocol comparison is common for all flows in the comparator. It is the single set of registers
and is used to verify what the next protocol in the encapsulated stack will be.
Flow comparison is used to match any of the possible flows within the comparator.
Ethernet Next Protocol Comparison
The next protocol comparison field looks at the last EtherType field in the header (there can be multiple in
the header) to verify the next protocol. It may also look at VLAN tags and the EtherType field when it is
used as a length. Each has a pattern match/mask or range, and an offset.
The following table lists the next protocol parameters for the Ethernet comparator.
Table 29 •
Ethernet Comparator (Next Protocol)
Parameter
Width
Description
Eth_Nxt_Comparator
3 bit
Pointer to the next comparator.
Eth_Frame_Sig_Offset
5 bit
Points to the start of the field used to build the frame
signature.
Eth_VLAN-TPID_CFG
16 bit
Globally defines the value of the TPID for an S-tag, B-tag,
or any other tag type other than a C-tag or I-tag.
Eth_PBB_ENA
1 bit
Configures if the packet carries PBB or not. This
configuration bit is only present in the first Ethernet
comparator block. PBB is disabled in Ethernet comparator
block 2.
Eth_Etype_Match_Enable
1 bit
Configures if the Ethertype field match register is used or
not. Only valid when the packet is a type II Ethernet packet.
Eth_Etype_Match
16 bit
If the packet is a type II Ethernet packet and
Eth_Etype_Match_Enable is a 1, the Ethertype field in the
packet is compared against this value.
Ethernet Flow Comparison
The Ethernet flow is determined by looking at VLAN tags and either the source address (SA) or the
destination address (DA). There are a configurable number of these matched sets. The following table
lists the flow parameters for the Ethernet comparator.
Table 30 •
Ethernet Comparator (Flow)
Parameter
Width
Description
Eth_Flow_Enable
1 bit/flow 0 = Flow disabled
1 = Flow enabled
Eth_Channel_Mask
1
0 = Do not use this flow match group for this channel
bit/chann 1 = Use this flow match group for this channel
el/flow
Eth_VLAN_Tags
2 bit
Configures the number of VLAN tags in the frame (0, 1,
or 2)
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
90
Functional Descriptions
Table 30 •
Ethernet Comparator (Flow) (continued)
Parameter
Width
Description
Eth_VLAN_Tag1_Type
1 bit
Configures the VLAN tag type for VLAN tag 1
If PBB is not enabled:
0 = C-tag, value of 0x8100
1 = S-tag, match to the value in CONF_VLAN_TPID
(global for all ports/directions)
If PBB enabled:
0 = S-tag (or B-tag), to the value in CONF_VLAN_TPID
(global for all ports/directions)
There must be 2 VLAN tags, 1 S-tag and one I-tag
1 = I-tag
Eth_VLAN_Tag2_Type
1 bit
Configures the VLAN tag type for VLAN tag 2
If PBB is not enabled:
0 = C-tag, value of 0x8100
1 = S-tag, match to the value in CONF_VLAN_TPID
(global for all ports/directions)
If PBB enabled:
The second tag is always an I-tag and this register
control bit is not used. The second tag in PBB is always
an I-tag.
Eth_Ethertype_Mode
1 bit
0 = Only type 2 Ethernet frames supported, no
SNAP/LLC expected
1 = Type 1 & 2 Ethernet packets supported. Logic looks
at the Ethertype/length field to determine the packet
type. If the field is a length (less than 0x0600), then the
packet is a type 1 packet and MUST include a SNAP &
3-byte LLC header. If the field is not a length, it is
assumed to be an Ethertype and SNAP/LLC must not
be present
Eth_VLAN_Verify_Ena
1 bit
0 = Parse for presence of VLAN tags but do not check
the values. For PBB mode, the I-tag is still always
checked.
1 = Verify the VLAN tag configuration including number
and value of the tags.
Eth_VLAN_Tag_Mode
2 bit
0 = No range checking on either VLAN tag
1 = Range checking on VLAN tag 1
2 = Range checking on VLAN tag 2
Eth_Addr_Match
48 bit
Matches an address field selected by
Eth_Addr_Match_Mode
Eth_Addr_Match_Select
2 bit
Selects the address to match
0 = Match the destination address
1 = Match the source address
2 = Match either the source or destination address
3 = Reserved, do not use
Eth_Addr_Match_Mode
3 bits per Selects the address match mode. One or multiple bits
flow
can be set in this mode register allowing any
combination of match types. For unicast or multicast
modes, only the MSB of the address field is checked
(0 = unicast; 1 = multicast). See section 3.2.3.1 of
IEEE 802.3 for more details.
0 = Match the full 48-bit address
1 = Match any unicast address
2 = Match any multicast address
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
91
Functional Descriptions
Table 30 •
Ethernet Comparator (Flow) (continued)
Parameter
Width
Description
Eth_VLAN_Tag1_Match
12 bit
Match field for the first VLAN tag (if configured to be
present).
Eth_VLAN_Tag1_Mask
12 bit
Mask for the first VLAN tag. If a match set is not used,
set this register to all 0s.
Eth_VLAN_Tag2_Match
12 bit
Match field for the update VLAN tag (if configured to be
present).
Eth_VLAN_Tag2_Mask
12 bit
Mask for the second VLAN tag. If a match set is not
used, set this register to all 0s.
Eth_VLAN_Tag_Range_Upper 12 bit
Upper limit of the range for one of the VLAN fields
selected by ETH_VLAN_TAG_MODE register. If PBB
mode is enabled, this register is not used for range
checking but rather is the upper 12 bit of the I-tag.
Eth_VLAN_Tag_Range_Lower 12 bit
Lower limit of the range for one of the VLAN fields
selected by ETH_VLAN_TAG_MODE register. If PBB
mode is enabled, this register is not used for range
checking but rather is the lower 12 bit of the I-tag SID.
Eth_Nxt_Prot_Grp_Sel
Per flow, maps a particular flow to a next-protocol group
register set. This register only appears in the Ethernet
block in the OAM-optimized engine.
1 bit
If the Ethernet block is part of the OAM optimized engine, there are two sets of next-protocol
configuration registers. Both sets are identical except one has an _A suffix and the other has a _B suffix.
In the per-flow registers an additional register, ETH_NXT_PROT_SEL, is included to map a particular
flow with a set of next protocol register set. This function allows the Ethernet block within the OAMoptimized engine to act like two separate engines with a configurable number of flows assignable to each
with a total maximum number of eight flows. It effectively allows two separate protocol encapsulation
stacks to be handled within the engine.
3.13.16.2 MPLS Comparator
The MPLS comparator block counts MPLS labels to find the start of the next protocol. The MPLS header
can have anywhere from 1 to 4 labels. Each label is 32 bit long and has the format shown in the following
illustration.
Figure 80 • MPLS Label Format
Label
19
18
17
16
15
14
13
12
11
10
9
Class
8
7
6
5
4
3
2
1
0
2
Time To Live
S
1
0
7
6
5
4
3
2
1
0
The S bit is used to indicate the last label in the stack, as follows: If S = 0, then there is another label. If
S = 1, then this is the last label in the stack.
Also, the MPLS stack can optionally be followed by a control word (CW). This is configurable per flow.
The following illustration shows a simple Ethernet packet with either one label or three labels and no
control word.
Figure 81 • MPLS Label Stack within an Ethernet Frame
CW=0
CW=0
Destination Address (DA)
5
4
3
2
1
0
5
Destination Address (DA)
5
4
3
2
1
0
5
Source Address (SA)
4
3
2
1
Source Address (SA)
4
3
2
1
Label (S=1)
Etype
0
1
0
1
0
3
1
Payload
0
Label (S=0)
Label (S=0)
Etype
0
2
3
2
1
0
3
2
1
Label (S=1)
0
3
2
1
0
Payload
The following illustration shows an Ethernet frame with four labels and a control word. Keep in mind that
this comparator is used to compare the MPLS labels and control words; the Ethernet portion is checked
in the first stage.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
92
Functional Descriptions
Figure 82 • MPLS Labels and Control Word
CW=1
Destination Address (DA)
5
4
3
2
1
0
4
3
2
1
Label (S=0)
Etype
Source Address (SA)
5
0
1
0
3
2
1
Label (S=0)
0
3
2
1
Label (S=0)
0
3
2
1
Label (S=1)
0
3
2
1
Control
0
3
2
1
0
Payload
There could be VLAN tags between the SA and the Etype fields and, potentially, an LLC and SNAP
header before the MPLS stack, but these would be handled in the Ethernet/LLC/SNAP comparator.
The only configuration registers that apply to all flows within the comparator are the match_mode register
and the nxt_comparator register. The match mode register determines how the match filters are used
and there is one per stage. Each flow has it own complete set of match registers.
Table 31 •
Table 32 •
MPLS Comparator: Next Word
Parameter
Width
Description
MPLS_Nxt_Comparator
3 bit
Pointer to the next comparator
MPLS Comparator: Per-Flow
Parameter
Width
Description
MPLS_Flow_Enable
1 bit per flow
0 = Flow disabled
1 = Flow enabled
MPLS_Channel_Mask 1 bit per channel
per flow
0 = Do not use this flow match group for this channel
1 = Use this flow match group for this channel
MPLS_Ctl_Word
1 bit
Indicates if there is a 32-bit control word after the last
label. This should only be set if the control word is not
expected to be an ACH header. ACH headers are
checked in the IP block. If the control word is a nonACH control word, only the upper 4 bits of the control
are checked and are expected to be 0.
0 = There is no control word after the last label
1 = There is expected to be a control word after the
last label
MPLS_REF_PNT
1 bit
The MPLS comparator implements a searching
algorithm to properly parse the MPLS header. The
search can be performed from either the top of the
stack or the end of the stack.
0 = All searching is performed starting from the top of
the stack
1 = All searching if performed from the end of the
stack
MPLS_STACK_DEPT
H
4 bit
Each bit represents a possible stack depth, as shown
in the following list.
MPLS_STACK_DEPTH Bit
0
1
2
3
Table 33 •
Parameter
Allowed Stack Depth
1
2
3
4
MPLS Range_Upper/Lower Label Map
MPLS_REF_PNT = 0,
top-of-stack referenced
MPLS_REF_PNT=1,
end-of-stack referenced
MPLS_Range_Upper/Lower_0 Top label
Third label before the end label
MPLS_Range_Upper/Lower_1 First label after the top label
Second label before the end
label
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
93
Functional Descriptions
Table 33 •
MPLS Range_Upper/Lower Label Map (continued)
MPLS_REF_PNT = 0,
top-of-stack referenced
Parameter
MPLS_REF_PNT=1,
end-of-stack referenced
MPLS_Range_Upper/Lower_2 Second label after the top label
First label before the end label
MPLS_Range_Upper/Lower_3 Third label after the top label
End label
The offset to the next protocol is calculated automatically. It is based upon the number of labels found
and whether a control word is configured to be present. It points to the first octet after the last label or
after the control word, if present.
Table 34 •
Next MPLS Comparator
Parameter
Width
Description
MPLS_Range_Lower
20 bit × 4 labels
Lower value of the label range when range checking
is enabled
MPLS_Range_Upper
20 bit × 4 labels
Upper value of the label range when range checking
is enabled
If an exact label match is desired, set the upper and lower range values to the same value. If a label
value is a don't care, then set the upper value to the maximum value and the lower value to 0.
The MPLS comparator block used in the OAM-optimized engine differs from the one used in the PTPoptimized engine.
Just like the Ethernet comparator block, there are two sets of next protocol blocks along with a next
protocol association configuration field per-flow. This allows two different encapsulations to occur in a
single engine.
Table 35 •
Parameter
Next-Protocol Registers in OAM-Version of MPLS Block
Width
MPLS_Nxt_Prot_Grp_Sel 1 bit per flow
Description
Maps each flow to next-protocol-register set A or B
3.13.16.3 IP/UDP/ACH Comparator
The IP/UDP/ACH comparator is used to verify one of three possible formats, IPv4, IPV6, and ACH.
Additionally, IPv4 and IPv6 can also have a UDP header after the IP header. There are two of these
comparators and they can operate at stages 2, 3, or 4 of the analyzer pipeline. Note that if there is an
IP-in-IP encapsulation, a UDP header will only exist with the inner encapsulation.
3.13.16.4 IPv4 Header Format
The following illustration shows an IPv4 frame header followed immediately by a UDP header. IPv4 does
not always have the UDP header, but the comparator is designed to work with or without it. The Header
Length field is used to verify the offset to the next protocol. It is a count of 32-bit words and does not
include the UDP header. If the IPv4 frame contains a UDP header, the Source and Destination ports are
also checked. These values are the same for all flows within the comparator. Note that IPv4 options,
extended headers, and UDP fragments are not supported.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
94
Functional Descriptions
Figure 83 • IPv4 with UDP
Octet/Bit
0/0
31
0
Version
2
1
0
3
15
3
14
13
12
11
2
7
6
5
5
4
3
2
1
0
15
9
1
0
8
7
6
6
5
4
3
2
1
0
2
1
0
7
6
5
1
0
15
7
Identification
10
Time to Live
IPv4
4
3
Total Length
Differentiated Services
Hdr Length
14
13
12
11
10
9
1
0
12
11
10
9
14
13
12
11
10
Flags
Protocol
2
4
3
8
7
6
5
3
2
1
0
4
4
3
2
1
0
4
3
2
1
0
Fragment Offset
8
7
6
5
Header Checksum
2
9
8
7
6
5
Source Address
Destination Address
16/128
Source Port
UDP
24/192
Destination Port
Length
Checksum (over-write with 0)
Note: Checksum over-write with 0 occurs on ingress only. PTP applications that generate 1588 frames with this
format are responsible for creating IPv4/UDP frames with a zeroed checksum upon generation from the
application.
Per flow validation is performed on the Source or Destination Address in the IPv4 header. The
comparator can be configured to indicate a match in the flow if the source, destination, or either the
source or destination fields match.
3.13.16.5 IPv6 Header Format
The following illustration shows an IPv6 frame header followed immediately by a UDP header. IPv6 does
not always have the UDP header, but the comparator is designed to work with or without it. The Next
Header field is used to verify the offset to the next protocol. It is a count of 32-bit words and does not
include the UDP header. If the IPv6 frame contains a UDP header, the Source and Destination ports are
also checked. These values are the same for all flows within the comparator.
Figure 84 • IPv6 with UDP
Octet/Bit
0/0
31
0
3
15
Version
2
1
14
13
0
12
7
11
6
Traffic
Class
5
4
3
2
Payload Length
10
9
8
7
6
1
5
0
4
19
3
18
2
17
1
16
0
15
7
14
6
13
12
11
Flow9 Label
8
10
Next Header
5
4
3
2
1
0
7
7
6
6
5
5
4
3
Hop Limit
2
1
0
4
3
2
1
0
5
4
3
2
1
0
5
4
3
2
1
0
Source Address
IPv6
Destination Address
24/288
UDP
40/352
Destination Port
Source Port
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
15
14
13
12
11
10
9
8
6
5
4
3
2
1
0
15
14
13
12
11
10
9
8
Length
15
14
13
12
11
10
9
8
7
7
6
Checksum
7
6
Per flow validation is performed on the Source or Destination Address in the IPv6 header. The
comparator can be configured to indicate a match in the flow if the source, destination, or either the
source or destination fields match.
If the IPv6 frame is the inner most IP protocol, then the checksum field must be valid. This is
accomplished using a pair of pad bytes after the PTP frame. The checksum is computed using one's
compliment of the one's compliment sum of the IPv6 header, UDP header, and payload including the pad
bytes. If any of the fields in the frame are updated, the pad byte field at the end of the frame will be
updated by the PHY so that the checksum field does not have to be modified.
Note: IPv6 extension headers are not supported.
3.13.16.6 ACH Header Format
The following illustrations show ACH headers. They can appear after a MPLS label stack in place of the
control word. ACH is verified as a protocol only. There are no flows within the protocol for ACH. The ACH
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
95
Functional Descriptions
header can optionally have a Protocol ID field. The protocol is verified using the Version, Channel type,
and optional Protocol ID field.
Figure 85 • ACH Header Format
Octet/Bit
0/0
4/32
31
0
0x1
Reserved
Version
3
2
1
0
3
15
14
13
12
11
2
1
7
0
6
Protocol ID or Payload
10
9
8
7
6
Channel Type
5
4
3
2
1
0
5
4
3
2
1
0
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Payload
Figure 86 • ACH Header with Protocol ID Field
Octet/Bit
0/0
4/32
31
0
0x1
Version
3
2
1
0
3
2
1
15
14
13
12
11
10
9
Reserved
0
7
Protocol ID
8
7
Channel Type
6
5
4
3
2
1
0
6
5
4
3
2
1
0
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
3.13.16.7 IPSec
IPSec adds security to the IP frame using an Integrity Check Value (ICV), a variable-length checksum
that is encoded with a special key. The key value is known by the sender and the receiver, but not any of
the devices in between. A frame must have a correct ICV to be valid. The sequence number field is a
continuously incrementing value that is used to prevent replay attacks (resending a known good frame).
Little can be done with frames when IPSec is used because the IEEE 1588 block cannot recalculate the
ICV and the frame cannot be modified on egress. Therefore, one-step processing cannot be performed,
only two-step processing can be done. The only task here is to verify the presence of the protocol
header. Stored time stamps in the TS FIFO are used to create follow-up messages. On ingress, the time
stamp can be added to the PTP frame by writing it into the reserved bytes or by overwriting the CRC with
it and appending a new CRC. The CPU must know how to handle these cases correctly.
The following illustration shows the format of the IPSec frame. It normally appears between the IP
header (IPv4 or IPv6) and the UDP header or at the start of the payload.
Figure 87 • IPSec Header Format
Octet/Bit
0/0
8/64
variable #
of octets
31
0
Next Header
7
6
5
4
3
31
30
29
28
27
31
30
29
28
Reserved
Payload Length
2
1
0
7
6
5
4
26
25
24
23
22
21
20
26
25
24
23
22
21
20
2
3
1
0
15
14
13
11
10
9
8
7
6
5
4
3
2
1
0
13
12
12
11
10
9
8
7
6
5
4
3
2
1
0
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Security Parameters Index (SPI)
19
18
19
18
17
16
15
14
Sequence Number
27
17
16
15
14
Integrity Check Value (ICV)
...
There is only one set of match/mask registers associated with IPSec and they are used to verify the
presence of the IPSec header. The following illustration shows the largest possible IP frame header with
IPv6, IPSec, and UDP.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
96
Functional Descriptions
Figure 88 • IPv6 with UDP and IPSec
Octet/Bit
0/0
31
0
Version
3
2
15
14
1
13
0
12
7
11
Traffic Class
6
5
4
3
Payload Length
10
9
8
7
2
6
1
5
0
19
4
3
18
17
2
1
16
0
15
7
14
6
13
12
11
Flow Label
10
Next Header
5
9
4
3
2
1
12
11
10
9
8
0
7
7
6
6
5
5
4
3
Hop Limit
4
3
2
1
0
2
1
0
0
Source Address
IPv6
Destination Address
36/288
7
48/384
IPSec
6
Next Header
5
4
3
2
1
7
6
Payload Length
5
4
31
30
29
28
27
26
25
24
23
22
21
20
31
30
29
28
27
26
25
24
23
22
21
20
3
2
1
0
15
14
13
19
18
19
18
17
16
15
14
Sequence Number
17
16
15
14
Reserved
8
7
6
5
4
3
2
1
13
12
11
10
9
8
7
6
5
4
3
2
1
0
13
12
11
10
9
8
7
6
5
4
3
2
1
0
5
4
3
2
1
0
5
4
3
2
1
0
Security Parameters Index (SPI)
Integrity Check Value (ICV)
variable #
of octets
UDP
0
Destination Port
Source Port
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
15
14
13
12
11
10
9
8
6
5
4
3
2
1
0
15
14
13
12
11
10
9
8
Length
15
14
13
12
11
10
9
8
7
7
6
Checksum
7
6
3.13.16.8 Comparator Field Summary
The following table shows a summary of the fields and widths to verify IPv4, IPv6, and ACH protocols.
Table 36 •
Comparator Field Summary
Protocol
Next Protocol Fields
NPF Bit Widths
Flow Fields
Flow Bit Widths
IPv4
Header length
One 4-bit field
Source/
Destination
Address
One 32-bit field
UDP Source/Destination Port
One 32-bit field
Next header
One 8-bit field
Source/
Destination
Address
One 128-bit field
UDP Source/Destination Port
One 32-bit field
ACH
Entire ACH header
One 64-bit field
IPSec
Next Header/Payload Length/
SPI
One 64-bit field
IPv6
IP/ACH Comparator Next Protocol
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
97
Functional Descriptions
The following table shows the registers used to verify the current header protocol and the next protocol.
They are universal and cover IPv4, IPv6, and ACH. They can also be used to verify other future
protocols.
Table 37 •
IP/ACH Next-Protocol Comparison
Parameter
Width
Description
IP_Mode
2 bit
Specifies the mode of the comparator. If IPv4 or IPv6 is selected,
the version field is automatically checked to be either 4 or 6
respectively. If another protocol mode is selected, then the version
field is not automatically checked. In IPv4, the fragment offset field
must be 0, and the MF flag bit (LSB of the flag field) must be 0.
0 = IPv4
1 = IPv6
2 = Other protocol, 32-bit address match
3 = Other protocol, 128-bit address match
IP_Prot_Match_1
8 bit
Match bit for Protocol field in IPv4 or next header field in IPv6
IP_Prot_Mask_1
8 bit
Mask bits for IP_Prot_Match_1. For each bit, if it is a 1, the
corresponding match bit is valid. If it is 0, the corresponding match
bit is ignored. Disable this match/mask set by setting the mask
register to all 0’s.
IP_Prot_Offset_1
5 bit
Indicates the starting position relative to the beginning of the IP
frame header to start matching for the match/mask 1 register pair.
IP_Prot_Match_2
64 bit
Match bits for the IPSec header or any other desired field. For
ACH, this register should be used to match the ACH header.
IP_Prot_Mask_2
64 bit
Mask bits for IP_Prot_Match_2. For each bit, if it is a 1, the
corresponding match bit is valid. If it is 0, the corresponding match
bit is ignored. Disable this match/mask set by setting the mask
register to all 0’s.
IP_Prot_Offset_2
7 bit
Indicates the starting position relative to the beginning of the IP
frame header to start matching for the match/mask two-register
pair.
IP_Nxt_Protocol
8 bit
Points to the start of the next protocol relative to the beginning of
this header. It is the responsibility of the programmer to determine
this offset, it is not calculated automatically. Each flow within an
encapsulation engine must have the same encapsulation order and
each header must be the same length. This field is current protocol
header length in bytes.
IP_Nxt_Comparator 3 bit
Pointer to the next comparator.
0 = Reserved
1 = Ethernet comparator 2
2 = IP/UDP/ACH comparator 1
3 = IP/UDP/ACH comparator 2
4 = Reserved
5 = PTP/OAM comparator
6,7 = Reserved
IP_Flow_Offset
Indicates the starting position relative to the beginning of the IP
frame header to start matching for the flow match/mask register
pair. When used with IPv4 or 6, this will point to the first byte of the
source address. When used with a protocol other that IPv4 or 6,
this register points to the beginning of the field that will be used for
flow matching.
5 bit
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
98
Functional Descriptions
Table 37 •
IP/ACH Next-Protocol Comparison (continued)
Parameter
Width
Description
IP_UDP_Checksum 1 bit
_Clear_Ena
If set, the 2-byte UDP checksum should be cleared (written with
zeroes). This would only be used for UDP in IPv4.
IP_UDP_Checksum 1 bit
_Update_Ena
If set, the last two bytes in the UDP frame must be updated to
reflect changes in the PTP or OAM frame. This is necessary to
preserve the validity of the IPv6 UDP checksum.
Note that IP_UDP_Checksum_Clear_Ena &
IP_UDP_Checksum_Update_Ena should never be set at the same
time.
IP_UDP_Checksum 8 bit
_Offset
This configuration field is only used if the protocol is IPv4. This
register points to the location of the UDP checksum relative to the
start of this header. This info is used later by the PTP/Y.1731 block
to inform the rewriter of the location of the checksum in a UDP
frame. This is normally right after the Log Message Interval field.
IP_UDP_Checksum 2 bit
_Width
Specifies the length of the UDP checksum in bytes (normally 2
bytes)
The IP/ACH Comparator Flow Verification registers are used to verify the current frame against a
particular flow within the engine. When this engine is used to verify IPv4 or IPv6 protocol, the flow is
verified using either the source or destination address in the frame.
If the protocol is something other than IPv4 or IPv6, then the flow match can be used to match either a 32
or 128 bit field pointed to by the IP_Flow_Offset register. Mask bits can be used to shorten the length of
the match, but there is no concept of source or destination address in this mode.
Table 38 •
IP/ACH Comparator Flow Verification Registers
Parameter
Width
Description
IP_Flow_Ena
1 bit per flow
0 = Flow disabled
1 = Flow enabled
IP_Flow_Match_Mode
2 bit per flow
This register is only valid when the comparator block is
configured to match on IPv4 or IPv6. It allows the match
to be performed on the source address, destination
address, or either address.
0 = Match on the source address
1 = Match on the destination address
2 = Match on either the source or the destination
address
IP_Flow_Match
128 bit
Match bits for source & destination address in IPv4 & 6.
Also used as the flow match for protocols other than
IPv4 or 6. When used with IPv4, only the upper 32 bits
are used and the remaining bits are not used.
IP_Flow_Mask
128 bit
Mask bits for IP_Flow_Match. For each bit, if it is a 1, the
corresponding match bit is valid. If it is 0, the
corresponding match bit is ignored.
IP_Channel_Mask
1 bit per
channel per
flow
Enable for this match set for this channel
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
99
Functional Descriptions
Table 38 •
IP/ACH Comparator Flow Verification Registers (continued)
Parameter
Width
Description
IP_Frame_Sig_Offset
5 bit
Points to the start of the field that will be used to build
the frame signature. This register is only present in
comparators where frame signature is supported. In
other words, if there is no frame signature FIFO in a
particular direction, this register will be removed.
3.13.16.9 PTP/OAM Comparator
The PTP/OAM comparator is always the last stage in the analyzer for each encapsulation engine. It can
validate IEEE 1588 PTP frames or OAM frames.
3.13.16.10PTP Frame Header
The following illustration shows the header of a PTP frame.
Figure 89 • PTP Frame Layout
Octet/Bit
31
0
0/0
3
Tspt Spcfc
2
7
6
1
0
M sg Type
3
2
Dom ain Num ber
5
4
3
2
Rsvd
1
0
3
1
0
7
2
M essage Length
Vrsn PTP
1
0
3
2
1
0
15
14
13
12
11
10
9
5
4
3
2
1
0
2
1
0
15
14
13
12
11
10
9
8
8
7
6
5
4
3
2
1
0
Reserved
6
5
4
3
7
6
Flag Field
Correction Field
Reserved
Source Port Identity [79:48]
79
78
77
76
75
74
73
72
71
70
69
68
67
66
65
59
58
57
56
55
54
53
52
51
50
49
48
47
46
45
44
43
42
41
40
39
38
37
36
35
34
33
64
32
63
31
62
30
61
29
60
28
27
26
25
24
23
22
21
20
19
18
17
16
15
14
13
12
11
4
3
2
1
0
15
14
13
12
11
10
9
5
4
3
2
1
0
7
6
5
Source Port Identity [47:16]
Source Port Identity [15:0]
10
9
8
7
6
1
0
7
6
Control Field
32/256
4
3
2
5
Sequence ID
Log M essage Interval
5
4
3
2
1
8
7
6
0
Unlike most of the other stages, there is no protocol validation for PTP frames; only interpretation of the
header to determine what action to take. The first eight bytes of the header are used to determine the
action to be taken. These match fields in the flow comparison registers with a corresponding set of
command registers for each flow.
3.13.16.11Y.1731 OAM Frame Header
1DM, DMM, and DMR are the three supported Y.1731 frame headers. The following illustration shows
the header part of a 1DM Y.1731 OAM frame.
Figure 90 • OAM 1DM Frame Header Format
Octet/Bit
0/0
1DM Frame Header Format
0
2
MEG
1
0
4
Version (0)
3
2
1
0
7
6
5
4
3
2
31
TLV Offset (16)
Flags (0)
Opcode (1DM=45)
1
0
7
6
5
4
3
2
1
0
7
6
5
4
3
2
1
0
TxTimeStampf
Reserved for 1DM Receiving Equipment (0)
(for TxTimeStampf)
20/160
End TLV (0)
7
6
5
4
3
2
1
0
The following illustration shows a DMM frame header.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
100
Functional Descriptions
Figure 91 • OAM DMM Frame Header Format
Octet/Bit
0/0
2
31
DMM Frame Header Format
0
MEG
1
0
4
Version (0)
3
2
1
0
7
6
5
4
3
2
TLV Offset (32)
Flags (0)
Opcode (1DM=47)
1
0
7
6
5
4
3
2
1
0
7
6
5
4
3
2
1
0
TxTimeStampf
Reserved for DMM Receiving Equipment (0)
(for RxTimeStampf)
Reserved for DMR (0)
(for TxTimeStampb)
Reserved for DMR Receiving Equipment (0)
36/288
End TLV (0)
7
6
5
4
3
2
1
0
The following illustration shows a DMR frame header.
Figure 92 • OAM DMR Frame Header Format
Octet/Bit
0/0
DMR Frame Header Format
0
2
MEG
1
0
4
Version
3
2
1
0
7
6
5
4
3
2
31
Flags
Opcode (DMR=46)
1
0
7
6
5
4
3
TLV Offset
2
1
0
7
6
5
4
3
2
1
0
TxTimeStampf
RxTimeStampf
TxTimeStampb
Reserved for DMR Receiving Equipment (0)
(for RxTimeStampb)
36/288
End TLV (0)
7
6
5
4
3
2
1
0
As with PTP, there is no protocol validation for Y.1731 frames; only interpretation of the header to
determine what action to take. The first four bytes of the header are used to determine the action to be
taken.
3.13.16.12Y.1731 OAM PDU
1DM, DMM, and DMR are the three supported G.8113.1 PDUs and DMM/DMR are the two supported
RFC6374 PDUs. The following illustrations show the PDU formats.
Figure 93 • RFC6374 DMM/DMR OAM PDU Format
ETH (1)
14/18/22B
MPLS labels (2)
4/8/12/16B
DMM/DMR OAM PDUs
ACH
4B
OAM PDU Header
8B
Time stamp 1
8B
Time stamp 1
8B
Time stamp 1
8B
Time stamp 1
8B
padding
(variable size)
FCS
4B
(1) 0, 1, or 2 VLAN tags
(2) Up to 4 MPLS labels
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
101
Functional Descriptions
Figure 94 • G8113.1/draft-bhh DMM/DMR/1DM OAM PDU Format
DMM/DMR
1DM
ETH (1)
MPLS labels (2)
ETH (1)
14/18/22B
4/8/12/16B
MPLS labels (2)
4/8/12/16B
ACH
4B
OAM PDU Header
8B
Time stamp 1
8B
Time stamp 1
8B
Time stamp 1
8B
Time stamp 1
End TLV indicator
FCS
1DM OAM PDUs
DMM/DMR OAM PDUs
ACH
14/18/22B
4B
OAM PDU Header
8B
Time stamp 1
8B
Time stamp 1
8B
End TLV indicator
1B
8B
FCS
1B
(1) 0, 1, or 2 VLAN tags
(2) Up to 4 MPLS labels
4B
4B
(1) 0, 1, or 2 VLAN tags
(2) Up to 4 MPLS labels
As with PTP, there is no protocol validation for MPLS OAM; only interpretation of the header to determine
what action to take. The first four bytes of the header are used to determine the action to be taken.
3.13.16.13PTP Comparator Action Control Registers
The following registers perform matching on the frame header and define what action is to be taken
based upon the match. There is one mask register for all flows, and the rest of the registers are unique
for each flow.
Table 39 •
PTP Comparison
Parameter
Width
Description
PTP_Flow_Match
64 bit
Matches bits in the PTP/Y.1731 frame starting at the
beginning of the protocol header
PTP_Flow_Mask
64 bit
Mask bits for PTP_Flow_Match
PTP_Domain_Range_Lower 8 bit
Lower range of the domain field to match
PTP_Domain_Range_Upper 8 bit
Upper range of the domain field to match
PTP_Domain_Range_
Enable
1 bit
Enable for range checking
PTP_Domain_Offset
5 bit
Pointer to the domain field, or whatever field is to be used
for range checking
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
102
Functional Descriptions
Table 39 •
PTP Comparison (continued)
Parameter
Width
Description
PTP_Action_Command
3 bit
Command
Value
Mnemonic
Action
0
NOP
Do nothing
1
SUB
New correction field =
Current correction field –
Captured local time
2
SUB_P2P
New correction field =
Current correction field –
Local latency + path_delay
3
ADD
New correction field =
Current correction field +
Captured local time
4
SUB_ADD
New correction field =
Current correction field +
(Captured local time + Local
latency – Time storage field)
5
WRITE_1588 Write captured local time to
time storage field
6
WRITE_P2P
Active_timestamp_ns =
captured local time and
path_delay written to time
storage field and correction
field (deprecated command)
7
WRITE_NS
Write local time in
nanoseconds to the new field
8
WRITE_NS_
P2P
Write local time in
nanoseconds + p2p_delay to
the new field and correction
field
PTP_Save_Local_Time
1 bit
When set, saves the local time to the time stamp FIFO
(only valid for egress ports).
PTP_Correction_Field_Offset 5 bit
Points to the location of the correction field. Location is
relative to the first byte of the PTP/OAM header.
PTP_Time_Storage_Field_
Offset
6 bit
Points to a location in a PTP frame where a time value can
be stored or read.
PTP_Add_Delay_Asymmetry 1 bit
_Enable
When enabled, the value in the delay asymmetry register
is added to the correction field of the frame.
PTP_Subtract_Delay_
Asymmetry_Enable
1 bit
When enabled, the value in the delay asymmetry register
is subtracted from the correction field of the frame.
PTP_Zero_Field_Offset
6 bit
Points to a location in the PTP/OAM frame to be zeroed if
this function is enabled
PTP_Zero_Field_Byte_Count 4 bit
The number of bytes to be zeroed. If this field is 0, then
this function is not enabled.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
103
Functional Descriptions
Table 39 •
PTP Comparison (continued)
Parameter
Width
Description
PTP_Modified_Frame_Byte_ 3 bit
Offset
Indicates the position relative to the start of the PTP frame
in bytes where the Modified_Frame_Status bit resides.
This value is also used to calculate the offset from the
beginning of the Ethernet packet to this field for use by the
Rewriter.
PTP_Modified_Frame_Status 1 bit
_Update
If set, tells the rewriter to update the value of this bit.
Configuration registers inside the rewriter indicate if the bit
will be set to 0 or 1.
PTP_Rewrite_Bytes
4 bits
Number of bytes in the PTP or OAM frame that must be
modified by the Rewriter for the time stamp
PTP_Rewrite_Offset
8 bits
Points to where in the frame relative to the SFD that the
time stamp should be updated
PTP_New_CF_Loc
8 bits
Location where the updated correction field value is
written relative to the PTP header start
PTP_Channel_Mask
1 bit per Enable for this match set for this channel
channel
per flow
PTP_Flow_Enable
1 bit
When set, the fields associated with this flow are all valid
The following table shows controls that are common to all flows.
Table 40 •
PTP Comparison: Common Controls
Parameter
Width
Description
PTP_IP_CHKSUM_Se 1 bit
l
0 = Use IP checksum controls from comparator 1
1 = Use IP checksum controls from comparator 2
FSB_Adr_Sel
Selects the source of the address for use in the frame signature
builder
2 bits
The following table shows the one addition, per-flow, register.
Table 41 •
Parameter
PTP Comparison: Additions for OAM-Optimized Engine
Width
PTP_NXT_Prot_Group_Mask 2 bits
Description
There are two bits for each flow. Each bit indicates if the
flow can be associated with next-protocol group A or B.
One or both bits may be set. If a bit is 1 for a particular
next-protocol group, then a flow match is valid if the prior
comparator stages also produced matches with the same
next-protocol group.
3.13.16.14Future Protocol Compatibility
Except for MPLS, the comparators are not hardwired to their intended protocols. They can be used as
generic field and range comparators because all of the offsets or pointers to the beginning of the fields
are configurable. The IP comparator is the most generic and would probably be the first choice for
validating a new protocol.
Additionally, if there are not enough comparison resources in a single comparator block to handle a new
protocol, two comparators back-to-back can used by splitting up the comparison work. One portion can
be validated in one comparator and then handed off to another. The only restriction is that there must be
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
104
Functional Descriptions
at least one 64-bit word of separation between the start of the protocol and where the second starts to
operate.
3.13.16.15Reconfiguration
There are three ways to perform reconfiguration:
1.
2.
3.
Disable an entire encapsulation engine.
Once an engine has been disabled, any of the configuration registers associated with it may be
modified in any order. If other encapsulation engines are still active, they will still operate normally.
Disable a flow in an active engine.
Each stage in the engine has an enable bit for each flow. If a flow is disabled in a stage, its registers
may be modified. Once reconfiguration for a flow in a stage is complete, it can be enabled.
Disable a comparator.
Each comparator within the active encapsulation engine can be disabled. If an Ethernet header
according to the configuration Type I or Type II with SNAP/LLC is not found then subsequent flows
will not be matched. The ETH1 comparator can also be disabled so that all frames flowing through
the IEEE 1588 block are time stamped.
The disabling of engines and flows is always done in a clean manner so that partial matches do not
occur. Flows and engines are always enabled or disabled during inter-packet gaps or at the end of a
packet. This guarantees that when a new packet is received that it will be analyzed cleanly.
If strict flow matching is enabled and a flow is disabled in one of the stages, then the entire flow is
automatically disabled.
If any register in a stage that applies to all flows needs to be modified, then the entire encapsulation
engine must be disabled.
3.13.16.16Frame Signature Builder
Along with time stamp and CRC updates, the analyzer outputs a frame signature that can be stored in
the time stamp FIFO to help match frames with other info in the FIFO. This information is used by the
CPU so that it can match time stamps in the time stamp FIFO with actual frames. The frame signature is
up to 16 bytes long and contains information from the Ethernet header (SA or DA), IP header (SA or DA),
and from the PTP or OAM frame. The frame signature is only used in the egress direction.
The PTP block contains a set of mapping registers to configure which bytes are mapped into the frame
signature. The following tables show the mapping for each byte.
Table 42 •
Table 43 •
Frame Signature Byte Mapping
Select
Source Byte
0-23
PTP header byte number = (31-select)
24
PTP header byte number 6
25
PTP header byte number 4
26
PTP header byte number 0
27
Reserved
28-35
Selected address byte (select-28)
Frame Signature Address Source
Parameter
Width
Description
FSB_Map_Reg_0-15
6 bits
For each byte of the frame signature, use Table 42, page 105 to
select which available byte is used. Frame signature byte 0 is the
LSB. If not all 16 bytes are needed, the frame signature should
be packed towards the LSB and the upper unused byte
configuration values do not need to be programmed.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
105
Functional Descriptions
Table 43 •
Frame Signature Address Source (continued)
Parameter
Width
Description
FSB_Adr_Sel
2 bits
Selects the source of the address for use in the frame signature
builder according to the following list
Select Value
0
1
2
3
Address Source
Ethernet block 1
Ethernet block 2
IP block 1
IP block 2
Configuration registers in each comparator block supply an address to select if it is the source address or
the destination address.
A frame signature can be extracted from frames matching in all the three engines. The frame signature
address selection is limited to Ethernet Block1 because only a limited number of encapsulations are
supported in the third engine, Engine C.
Engine C has two parts: part A and part B. Part A supports ETH1, ETH2, MPLS protocols while part B
supports only ETH1 protocol. Selection of Ethernet block 1 or 2 is dependent on whether part A flow
matches or part B flow matches.
If a frame matches part A flow configuration, then the frame signature as configured in
ETH1_NXT_PROTOCOL_A and ETH2_NXT_PROTOCOL_A using FSB_ADR_SEL will be considered
in computing the frame signature.
If a frame matches part B flow configuration, then the frame signature as configured in
ETH1_NXT_PROTOCOL_A and FSB_ADR_SEL will be considered in computing the frame signature. In
this configuration if FSB_ADR_SEL is set to 1, to select ETH2 then all zeros are padded as frame
signature because ETH2 is not supported by part B.
3.13.16.17Configuration Sharing
The analyzer configuration services both channels. Each flow within each comparator has a channelmask register that indicates which channels the flow is valid for. Each flow can be valid for channel A,
channel B, or both channels.
A total of eight flows can be allocated the two channels if the analyzer configuration cannot be shared.
They can each have four distinct flows (or three for the one, and five for the other, etc.).
3.13.16.18OAM-Optimized Engine
The OAM optimized engine, Engine C, supports a fewer set of encapsulations such as ETH1, ETH2,
MPLS, and ACH. Engine C is was enhanced with an ACH comparator to support the MPLS-TP OAM
protocol. The MPLS-TP OAM protocol for Engine C is configured in the following registers.
•
•
•
EGR2_ACH_PROT_MATCH_UPPER/LOWER_A
EGR2_ACH_PROT_MASK_UPPER/LOWER_A
EGR2_ACH_PROT_OFFSET_A
The ACH comparator will start the comparison operation right after the MPLS comparator.
In addition to the descriptions of the Ethernet and MPLS blocks in the OAM optimized engine, there is the
notion of protocol-A/protocol-B. When a match occurs in the Ethernet 1 block the status of the protocol
set that produced the match is indicated. There are two bits, one for protocol A and another for protocol
B. If both sets produce a match, then both bits are set.
These bits are then carried to the next comparison block and only allow flow matches for the protocol
sets that produced matches in the prior block. This block also produces a set of protocol match bits that
are also carried forward.
This feature is provided to prevent a match with protocol set A in the first block and protocol set B in the
second block.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
106
Functional Descriptions
3.13.17 Time Stamp Processor
The primary function of the time stamp processor block is to generate a new Timestamp_field or new
Correction_field (Transparent clocks) for the rewriter block. The time stamp block generates an output
that is either a snapshot of the corrected Local Time (struct time stamp) or a signed (two's complement)
64 bit Correction_field.
In the ingress direction the time stamp block calculates a new time stamp for the rewriter that indicates
the earlier time when the corresponding PTP event frame entered the chip (crossed the reference plane
referred to in the IEEE 1588 standard).
In the egress direction the time stamp block calculates a new time stamp for the rewriter in time for the
PCS block to transmit the new time stamp field in the frame. In this case the time stamp field indicates
when the corresponding PTP event frame will exit the chip.
Transparent clocks correct PTP event messages for the time resided in the transparent clock. Peer-toPeer transparent clocks additionally correct for the propagation time on the inbound link (Path_delay).
The Path_delay [ns] input to the time stamp block is software programmed based upon IEEE 1588 path
delay measurements.
In general, the IEEE 1588 standard allows for a transparent clock to update the Correction_Field for both
PTP event messages as well as the associated follow up message (for two-step operation). However, the
TSP only updates PTP event messages. Also, the IEEE 1588 standard allows that end-to-end
transparent clocks correct and forward all PTP-timing messages while Peer-to-Peer transparent clocks
only correct and forward Sync and Follow_Up messages. Again, the TSP only updates PTP event
messages (not Follow_Up messages).
Internally the time stamp block generates an Active_timestamp from the captured/time stamped Local
time (Raw_timestamp). The Active_time stamp is the Raw_timestamp corrected for the both fixed
(programmed) local chip, and variable chip latencies relative to where the Start_of_Frame_Indicator
captures the local time. The time stamp block operates on the Active_timestamp based on the Command
code.
The Active_timestamp is calculated differently in the Ingress and Egress directions and the equations are
given below.
In the ingress direction:
Active_timestamp = Raw_timestamp - Local_latency - Variable_latency
In the egress direction:
Active_timestamp = Raw_timestamp + Local_latency + Variable_latency
In addition, the following values are also calculated for use by the commands:
Active_timestamp_ns = Active_timestamp converted to nanoseconds
Active_timestamp_p2p_ns = active_timestamp_ns + path delay
The Local_latency is a programmed fixed value while the Variable_latency is predicted from the PCS
logic based upon the current state of the ingress or egress data pipeline.
For the option of Peer-to-Peer transparent clocks, the ingress Active_timestamp calculation includes an
additional Path_delay component. The path delay is always added for a transparent clock per the
standard. The path delay is always added to the correction field.
The signed 32-bit two's complement Delay Asymmetry register (bits 31–0) can be programmed by the
user. Bit 31 is the sign bit. Bits 15–0 are scaled nanoseconds just like for the CorrectionField format. The
DelayAsymmetry register (whether it be positive or negative) will be sign extended and added to the
64-bit correction field (signed add) if the Add_Delay_Asymmetry bit is set. The DelayAsymmetry register
(whether it be positive or negative) will be sign extended and subtracted from the 64-bit correction field
(signed Subtract) if the Subtract_Delay_Asymmetry bit is set.
The time stamp block keeps a shadow copy of the programmed latency values (Local_latency,
Path_delay, and Delay_Asymmetry) to protect against CPU updates.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
107
Functional Descriptions
3.13.18 Time Stamp FIFO
The time stamp FIFO stores time stamps along with frame signature information. This information can be
read out by a CPU or pushed out on a dedicated Serial Time Stamp Output Interface and used in 2-step
processing mode to create follow-up messages. The time stamp FIFO is only present in the egress data
path.
The time stamp FIFO takes a frame signature from the analyzer and the updated correction field, and the
full data set for that time stamp is saved to the FIFO. This creates an interrupt to the CPU. If the FIFO
ever overflows this is indicated with an interrupt.
The stored frame signature can be of varying sizes controlled by the
EGR_TSFIFO_CSR.EGR_TS_SIGNAT_BYTES register. Only the indicated number of signature bytes is
saved with each time stamp. The saved values are packed so that reducing the number of signature
bytes allows more time stamps to be saved.
The packing of the time stamp data is done by logic before the write occurs to the FIFO. When no
compression is used, each time stamp may contain 208 bits of information consisting of 128 bits of frame
signature and 80 bits of time stamp data. Therefore a full sized time stamp is 26 bytes long. Compressing
the frame signature can reduce this to as little as 10 bytes (or 4 bytes if
EGR_TSFIFO_CSR.EGR_TS_4BYTES = 1) if no signature information is saved
(EGR_TSFIFO_CSR.EGR_TS_SIGNAT_BYTES = 0). The value to store is built up in an internal
register. When the register contains 26 valid bytes, that data is written to the time stamp FIFO. Data in
the FIFO is packed end-to-end. It is up to the reader of the data to unpack the data.
The time stamps in the FIFO are visible and accessible for the CPU as a set of 32-bit registers. Multiple
register reads are required to read a full time stamp if all bits are used. Bit 31 in register EGR_TSFIFO_0
contains the current FIFO empty flag, which can be used by the CPU to determine if the current time
stamps are available for reading. If the bit is set, the FIFO is empty and no time stamps are available.
The value that was read can be discarded because it does not contain any valid time stamp data. If the
bit is 0 (deasserted), the value contains 16 valid data bits of a time stamp. The remaining bits should be
read from the other registers in the other locations and properly unpacked to recreate the time stamp.
Care should be taken to read the time stamps one at a time as each read of the last (7th) address will
trigger a pop of the FIFO.
Time stamps are packed into seven registers named EGR_TSFIFO_0 to EGR_TSFIFO_6. If the time
stamp FIFO registers are read to the point that the FIFO goes empty and there are remaining valid bytes
in the internal packing register, then the packing register is written to the FIFO. In this case the registers
may not be fully packed with time stamps. Flag bits are used to indicate where the valid data ends within
the set of seven registers. The flag bits are in register EGR_TSFIFO_0.EGR_TS_FLAGS (together with
the empty flag) and are encoded as follows:
000 = Only a partial time stamp is valid in the seven register set
001 = One time stamp begins in the current seven register set
010 = Two time stamps begin in the current seven register set.
011 = Three time stamps begin in the current seven register set (4-byte mode)
100 = Four time stamps begin in the current seven register set (4-byte mode)
101 = Five time stamps begin in the current seven register set (4-byte mode)
110 = Six time stamps begin in the current seven register set (4-byte mode)
111 = The current seven register set is fully packed with valid time stamp data
The FIFO empty bit is visible in the EGR_TSFIFO_0.EGR_TS_EMPTY register so the CPU can poll this
bit to know when time stamps are available. There is also a maskable interrupt which will assert
whenever the time stamp FIFO level reaches the threshold given in
EGR_TSFIFO_CSR.EGR_TS_THRESH register. The FIFO level is also visible in the
EGR_TSFIFO_CSR.EGR_TS_LEVEL register. If the time stamp FIFO overflows, writes to the FIFO are
inhibited. The data in the FIFO is still available for reading but new time stamps are dropped.
Note: Time stamp FIFO exists only in the Egress direction. There is no time stamp FIFO in the Ingress direction
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
108
Functional Descriptions
3.13.19 Serial Time Stamp Output Interface
For each IEEE 1588 Processor 0 and 1, time stamp information stored in the Egress direction can be
read through either the register interface or through the Serial Time Stamp interface. These two ways to
read registers are mutually exclusive. While enabling/disabling the serial interface is done on a
Processor level, only one serial interface exists. This means the serial interface can be enabled for
Processor 0, while the time stamp FIFO can be read through registers for Processor 1. If the serial
interface is enabled for both Processor 0 and 1, then the serial interface will arbitrate between two
Egress time stamp FIFOs in Processor 0 and 1 and push the data out.
The time stamp FIFO serial interface block writes, or pushes, time stamp/frame signature pairs that have
been enqueued and packed into time stamp FIFOs to the external chip interface consisting of three
output pins: 1588_SPI_DO, 1588_SPI_CLK, and 1588_SPI_CS. There is one interface for all channels.
When the serial interface (SPI) is enabled, the time stamp/frame signature pairs are dequeued from time
stamp FIFO(s) and unpacked. Unpacked time stamp/frame signature pairs are then serialized and sent
one at a time to the external interface. Unpacking shifts the time stamp/frame signature into alignment
considering the configured size of the time stamps and frame signatures (a single SI write may require
multiple reads from a time stamp FIFO). The time stamp FIFO serial interface is an alternative to the
MDIO register interface described in the time stamp FIFO section. When the serial time stamp interface
is enabled in register TS_FIFO_SI_CFG.TS_FIFO_SI_ENA, data read from the time stamp FIFO
registers described in Time Stamp FIFO, page 108 are invalid.
Time stamp/Frame signature pairs from two egress time stamp FIFOs are serialized one at a time and
transmitted to the interface pins. The TS_FIFO_SI arbitrates in a round-robin fashion between the ports
that have non-empty time stamp FIFOs. The port associated with each transmitted time stamp/frame
signature pair is indicated in a serial address that precedes the data phase of the serial transmission.
Because the time stamp FIFOs are instantiated in the per port clock domains, a small single entry
asynchronous SI FIFO (per port) ensures that the time stamp/frame signature pairs are synchronized,
staged, and ready for serial transmission. When an SI FIFO is empty, the SI FIFO control fetches and/or
unpacks a single time stamp/frame signature performing any time stamp FIFO dequeues necessary. The
SI FIFO goes empty following the completion of the last data bit of the serial transmission. Enabled ports
(TS_FIFO_SI_CFG.TS_FIFO_SI_ENA) participate in the round-robin selection.
Register TS_FIFO_SI_TX_CNT accumulates the number of time stamp/frame signature pairs
transmitted from the serial time stamp interface for each channel. Register EGR_TS_FIFO_DROP_CNT
accumulates the number of time stamp/frame signature pairs that have been dropped per channel due to
a time stamp FIFO overflow.
The SPI compatible interface asserts a chip select (SPI_CS) for each write followed by a write command
data bit equal to 1, followed by a “don't care” bit (0), followed by an address phase, followed by a data
phase, followed by a deselect where SPI_CS is negated. Each write command corresponds to a single
time stamp/frame signature pair. The length of the data phase depends upon the sum of the configured
lengths of the time stamp and signature, respectively. The address phase is fixed at five bits. The
SPI_CLK is toggled to transfer each SPI_DO bit (as well as the command and address bits). The “Time
Stamp” and “Frame Identifier Data” from the following illustration are sent MSB first down to LSB (bit 0) in
the same format as stored in the seven registers of TS FIFO CSRs. For more information, see Time
Stamp FIFO, page 108 and Figure 95, page 110.
The frequency of the generated output 1588_SPI_CLK can be flexibly programmed from 10 MHz up to
62.5 MHz using TS_FIFO_SI_CFG to set the number of CSR clocks that the 1588_SPI_CLK is both high
and low. For example, to generate a 1588_SPI_CLK that is a divide-by-6 of the CSR clock, the CSR
register would be set such that both SI_CLK_LO_CYCS and SI_CLK_HI_CYCS equal 3. Also, the
number of CSR clocks after SPI_CS asserts before the first 1588_SPI_CLK is programmable
(SI_EN_ON_CYCS), as is the number of clocks before SI_EN negates after the last 1588_SPI_CLK
(SI_EN_OFF_CYCS). The number of clocks during which SI_EN is negated between writes is also
programmable (SI_EN_DES_CYCS). The 1588_SPI_CLK may also be configured to be inverted
(SI_CLK_POL).
Without considering de-selection between writes, if the PTP 16-byte SequenceID (frame signature) is
used as frame identifier each 10 byte time stamp write take 2 + 55 + 10 × 8 + 16 × 8 = 265 clocks (at
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
109
Functional Descriptions
40 MHz) ~6625 ns. This corresponds to a time stamp bandwidth of > 0.15 M time stamp/second/port.
The following illustration shows the serial time stamp/frame signature output.
Figure 95 • Serial Time Stamp/Frame Signature Output
SPI_CS
SPI_Clk
SPI_DO
4
3 2
1 0
Port
9 8
7 6
5 4
3 2
1 0
12
Frame Identifier Data
(0 to 16 bytes)
9 8 7
6 5 4 3 2 1 00
Time stamp
(4 or 10 bytes)
3.13.20 Rewriter
When the rewriter block gets a valid indication it overwrites the input data starting at the offset specified
in Rewrite_offset and replaces N bytes of the input data with updated N bytes. Frames are modified by
the rewriter as indicated by the analyzer-only PTP/OAM frames are modified by the rewriter.
The output of the rewriter block is the frame data stream that includes both unmodified frames and
modified PTP frames. The block also outputs a count of the number of modified PTP frames in
INGR_RW_MODFRM_CNT/EGR_RW_MODFRM_CNT, depending upon the direction. This counter
accumulates the number of PTP frames to which a write was performed and includes errored frames.
3.13.20.1 Rewriter Ethernet FCS Calculation
The rewriter block has to recalculate the Ethernet CRC for the PTP message to modify the contents by
writing a new time stamp or clear bytes. Two versions of the Ethernet CRC are calculated in accordance
with IEEE 802.3 Clause 3.2.9: one on the unmodified input data stream and one on the modified output
data stream. The input frame FCS is checked against the input calculated FCS and if the values match,
the frame is good. If they do not, then the frame is considered a bad or errored frame. The new
calculated output FCS is used to update the FCS value in the output data frame. If the frame was good,
then the FCS is used directly. If the frame was bad, the calculated output FCS is inverted before writing
to the frame. Each version of the FCS is calculated in parallel by a separate FCS engine.
A count of the number of PTP/OAM frames that are in error is kept in the INGR_RW_FCS_ERR_CNT or
EGR_RW_FCS_ERR_CNT register, depending upon the direction.
3.13.20.2 Rewriter UDP Checksum Calculation
For IPv6/UDP, the rewriter also calculates the value to write into the dummy blocks to correct the UDP
checksum. The checksum correction is calculated by taking the original frame's checksum, the value in
the dummy bytes, and the new data to be written; and using them to modify the existing value in the
dummy byte location. The new dummy byte value is then written to the frame to ensure a valid
checksum. The location of the dummy bytes is given by the analyzer. The UDP checksum correction is
only performed when enabled using the following register bits:
•
•
•
•
INGR_IP1_UDP_CHKSUM_UPDATE_ENA
INGR_IP2_UDP_CHKSUM_UPDATE_ENA
EGR_IP1_UDP_CHKSUM_UPDATE_ENA
EGR_IP2_UDP_CHKSUM_UPDATE_ENA
Based upon the analyzer command and the rewriter configuration, the rewriter writes the time stamp in
one of the following ways:
•
•
Using PTP_REWRITE_BYTES to choose four bytes write to PTP_REWRITE_OFFSET. This
method is similar to other PTP frame modifications and the time stamp is typically written to the
reserved field in the PTP header.
Using PTP_REWRITE_BYTES and RW_REDUCE_PREAMBLE to select the mode of operation
when writing Rx time stamps into the frame.
In these modes, it cannot do both a time stamp write/append and a PTP operation in the same
frame. If PTP_REWRITE_BYTES = 0xE and RW_REDUCE_PREAMBLE = 1, it does it by
overwriting the existing FCS with the time stamp in the lowest four bytes of the calculated time
stamp and generating a new FCS and appending it.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
110
Functional Descriptions
Because the rewriter cannot modify the IFG or change the size of the frame, if the original FCS is
overwritten with time stamp data a new FCS needs to be appended and the frame shortened by reducing
the preamble. The preamble length includes the
/S/ character and all preamble characters up to but not including the SFD. In this mode, it is assumed
that all incoming preambles are of sufficient (5 to 7-byte) length to delete four bytes and the preamble of
every frame (not only PTP frames) will be reduced by four bytes by deleting four bytes of the preamble.
Then, the new FCS is written at the end of the matched frame. For unmatched frames, or if the
PTP_REWRITE_BYTES is anything but 0xE, the IFG is increased by adding four IDLE (/I/) characters
after the /T/ which ends the packet.
To time stamp a frame in one of the modes, the actual length of the preamble is then checked and if the
preamble is too short to allow a deletion of four bytes (if the preamble is not five bytes or more) then no
operations are performed on the preamble, the FCS is not overwritten, and no time stamp is appended.
For all such frames, a counter is maintained and every time an unsuccessful operation is encountered,
the counter is incremented. This counter is read through register:
INGR_RW_PREAMBLE_ERR_CNT/EGR_RW_PREAMBLE_ERR_CNT. The following illustration shows
the deleted preamble bytes.
Figure 96 • Preamble Reduction in Rewriter
SFD
0xD5
Pre3
SFD
0xD5
Pre6
Pre2
Pre6
Pre5
Pre1
Pre5
Pre4
/S/
/S/
If PTP_REWRITE_BYTES = 0xF and RW_REDUCE_PREAMBLE = 0, the rewriter replaces the FCS of
the frame with the four lowest bytes of the calculated time stamp and does not write the FCS to the
frame. In this mode, all the frames have corrupted FCSs and the MAC needs to be configured to handle
this case. In the case of a CRC error in the original frame, the rewriter writes all ones (0xFFFFFFFF) to
the FCS instead of the time stamp. This indicates an invalid CRC to the MAC because this is reserved to
indicate an invalid time stamp. In the rare case that the actual time stamp has the value 0xFFFFFFFF
and the CRC is valid, the rewriter increments the time stamp to 0x0 and writes that value instead. This
causes an error of 1 ns but is required to reserve the time stamp value of 0xFFFFFFFF for frames with
an invalid CRC.
A flag bit may also be set in the PTP message header to indicate that the TSU has modified the frame
(when set) or to clear the bit (on egress). The analyzer sends the byte offset of the flag byte to the
rewriter in PTP_MOD_FRAME_BYTE_OFFSET and indicates whether the bit should be modified or not
using PTP_MOD_FRAME_STATUS_UPDATE. The bit offset within the byte is programmed in the
configuration register RW_FLAG_BIT. When the PTP frame is being modified, the selected bit is set to
the value in the RW_FLAG_VAL. This only occurs when the frame is being modified by the rewriter;
when the PTP frame matches and the command is not NOP.
3.13.21 Local Time Counter
The local time counter keeps the local time for the device and the time is monitored and synchronized to
an external reference by the CPU. The source clock for the counter is selected externally to be a
250 MHz, 200 MHz, 125 MHz, or some other frequency. The clock may be a line clock or the dedicated
1588_DIFF_INPUT_CLK_P/N pins. The clock source is selected in register LTC_CTRL.LTC_CLK_SEL.
To support other frequencies, a flexible counter system is used that can convert almost any frequency in
the 125–250 MHz range into a usable source clock. Supported frequencies of local time counter are
125 MHz, 156.25 MHz, 200 MHz, and 250 MHz. The frequency is programmed in terms of the clock
period. Set the LTC_SEQUENCE.LTC_SEQUENCE_A register to the clock period to the nearest whole
number of nanoseconds to be added to the local time counter on each clock cycle. Set
LTC_SEQ.LTC_SEQ_E to the amount of error between the actual clock period and the
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
111
Functional Descriptions
LTC_SEQUENCE.LTC_SEQUENCE_A setting in femtoseconds. Register
LTC_SEQ.LTC_SEQ_ADD_SUB indicates the direction of the error. An internal counter keeps track of
the accumulated error. When the accumulated error exceeds 1 nanosecond, an extra nanosecond is
either added or subtracted from the local time counter. Use the following as an example to program a
5.9 ns period:
LTC_SEQUENCE.LTC_SEQUENCE_A = 6 (6 ns)
LTC_SEQ.LTC_SEQ_E = 100000 (0.1 ns)
LTC_SEQ.LTC_SEQ_ADD_SUB = 0 (subtract an extra nanosecond, i.e add 5 ns)
To support automatic PPM adjustments, an internal counter runs on the same clock as the local time
counter, and increments using the same sequence to count nanoseconds. The maximum (rollover) value
of the internal counter in nanoseconds is given in register
LTC_AUTO_ADJUST.LTC_AUTO_ADJUST_NS. At rollover, the next increment of the local time counter
is increased by one additional or one less nanosecond as determined by the
LTC_AUTO_ADJUST.LTC_AUTO_ADD_SUB_1NS register. When
LTC_AUTO_ADJUST.LTC_AUTO_ADD_SUB_1NS is set to 0x1, an additional nanosecond is added to
the local time counter. When it is set to 0x2, one less nanosecond is added to the local timer counter. No
PPM adjustments are made when the register is set to 0x0 or 0x3.
PPM adjustments to the local time counter can be made on an as-needed basis by writing to the oneshot LTC_CTRL.LTC_ADD_SUB_1NS_REQ register. One nanosecond is added or subtracted from the
local time counter each time LTC_CTRL.LTC_ADD_SUB_1NS_REQ is asserted. The
LTC_CTRL.LTC_ADD_SUB_1NS register setting controls whether the local time counter adjustment is
an addition or a subtraction.
The current time is loaded into the local time counter with the following procedure.
1.
2.
3.
4.
Configure the 1588_LOAD_SAVE pin.
Write the time to be loaded into the local time counter in registers LTC_LOAD_SEC_H,
LTC_LOAD_SEC_L and LTC_LOAD_NS.
Program LTC_CTRL.LTC_LOAD_ENA to a 1.
Drive the 1588_LOAD_SAVE pin from low to high.
The time in registers LTC_LOAD_SEC_H, LTC_LOAD_SEC_L and LTC_LOAD_NS is loaded into the
local time counter when the rising edge of the 1588 LOAD_SAVE strobe is detected. The LOAD_SAVE
strobe is synchronized to the local time counter clock domain.
When the 1588_DIFF_INPUT_CLK_P/N pins are the clock source for the local time counter, and the
LOAD_SAVE strobe is synchronous to 1588_DIFF_INPUT_CLK_P/N, the LTC_LOAD* registers are
loaded into the local time counter, as shown in the following illustration.
Figure 97 • Local Time Counter Load/Save Timing
LOAD_SAVE
1588_DIFF_INPUT_CLK_P/N
System generates
LOAD_SAVE here
Device captures
LOAD_SAVE here
Time loaded into Local
Time Counter here
When the LOAD_SAVE strobe is not synchronous to the 1588_DIFF_INPUT_CLK_P/N pins or an
internal clock drives the local time counter, there is some uncertainty as to when the local time counter is
loaded, when higher accuracy circuit is turned off. This reduces the accuracy of the time stamping
function by the period of the local time counter clock. When higher accuracy circuit is ON, any difference
between the 1588_DIFF_INPUT_CLK_P and the rising edge of 1588_LOAD_SAVE is compensated
within an error of 1 ns. This applies to both load and save operations.
Note: There is a local time counter in each channel. The counter is initialized in both channels if the
LTC_CTRL.LTC_LOAD_ENA register in each channel is asserted when the LOAD_SAVE strobe occurs.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
112
Functional Descriptions
When LTC_CTRL.LTC_SAVE_ENA register is asserted when the 1588 LOAD_SAVE input transitions
from low to high, the state of the local time counter is stored in the LTC_SAVED_SEC_H,
LTC_SAVED_SEC_L, and LTC_SAVED_NS registers.
The current local time can be stored in registers with the following procedure.
1.
2.
3.
4.
5.
Configure the 1588_LOAD_SAVE pin.
Program LTC_CTRL.LTC_SAVE_ENA to a 1.
Set SER_TOD_INTF.LOAD_SAVE_AUTO_CLR to 1 if the operation is one-time save operation.
This will clear LTC_CTRL.LTC_SAVE_ENA after the operation.
Drive the 1588_LOAD_SAVE pin from low to high.
Read the value from LTC_SAVED_SEC_H, LTC_SAVED_SEC_L, and LTC_SAVED_NS registers.
As with loading the local time counter, there is one clock cycle of uncertainty as to when the time is saved
if the LOAD_SAVE strobe is not synchronous to the clock driving the counter.
3.13.22 Serial Time of Day
In addition to loading or saving as described in the preceding sections, it is possible to load or save LTC
time in a serial fashion. For serial load, 1588_LOAD_SAVE has to send Time of Day (ToD) information in
a specific format. For serial save, when the appropriate register bits is set, then PPS will drive out the
ToD information. The following illustration shows the format for serial load and save.
Figure 98 • Standard PPS and 1PPS with TOD Timing Relationship
1PPS Cycle (1 s)
Standard
PPS Signal
High Voltage
1PPS with
ToD Signal
Low Voltage
A
1.0 μs
B
20 μs
C
160 μs
D
999819.0 μs
3.13.22.1 Pulse per Second Segment
In the preceding illustration, segment A is the pulse per second segment. The PPS signal is transmitted
with high voltage. The rising edge of the PPS signal is aligned with the rising edge of the standard PPS
signal. This segment lasts 1 µs. To obtain high accuracy, the response delay of the rising edge of the
PPS signal should be considered.
3.13.22.2 Waiting Segment
In the preceding illustration, segment B is the Waiting segment. Due to the speed of operation, this
segment is needed to make it easier for the receiver to obtain the following Time-of-Day information in
current PPS cycle. The signal is in low voltage during this segment, which lasts 20 µs.
3.13.22.3 Time-of-Day Segment
In the preceding illustration, segment C is the Time-of-Day segment. The ToD information being carried
in this segment indicates the time instant of the rising edge of the PPS signal transmitted in segment A of
the current PPS cycle. The time instant is measured using the original network clock. In this segment, the
ToD information is continuously transported and is represented in 16 octets. It consists of the following
fields:
•
•
Second field: 6 octets. It represents the time instant of the rising edge of the PPS signal in second.
The value is defined as in IEEE 1588-2008.
Date field: 6 octets. It represents the time instant of the rising edge of the PPS signal in year, month,
day, hour, minute, and second. Each part is represented by one octet (the format of this field is
0xYYMMDDHHMMSS). In particular, only the lowest 2 decimal digits of the year are represented.
The receiver can easily obtain the time instant of the rising edge of the PPS signal in this transparent
format without additional circuitry to translate the value of the second field. It also has the significant
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
113
Functional Descriptions
•
benefit of changing the value of this field when leap year or leap second occurs. (The Date field is
ignored at the serial ToD input and is not generated at the serial ToD output.)
Reserved field: 4 octets. Reserved for future use.
The ToD information is represented in units of octet, with each octet being transmitted with the low-order
bit first. The following illustration shows an octet is transmitted between a start bit with high voltage and a
stop bit with low voltage. The other octets are transmitted in the same manner. As a result,
(1+8+1) × 1 µs = 10 µs are needed to transport one octet. This segment lasts 16 × 10 µs = 160 µs to
convey the ToD information.
Figure 99 • ToD Octet Waveform
Transmitting 1 ToD Octet (10 μs)
LSB
0
High Voltage
MSB
0
1
0
1
0
1
1
Low Voltage
Stop Bit
Start Bit
ToD Octet (1 Octet)
The entire Time-of-Day segment should be detected. If the second 6 octets representing the Date field
are not used by the upper layer, the Date field should still be detected and its value can be ignored.
3.13.22.4 Idle Segment
Segment D is the Idle segment in Figure 98, page 113. It follows segment C with high voltage until the
end of the PPS cycle. The duration of the Idle segment is given by the following calculation.
1 s – 0.5 µs – 20 µs – 160 µs = 999819.5 µs.
Use the following steps to enable Serial load.
1.
2.
3.
4.
5.
Set SER_TOD_INTF.SER_TOD_INPUT_EN to 1
Set LTC_CTRL.LOAD_EN to 1.
Start the transmission of 1588_LOAD_SAVE conforming to the format.
To check the data transmission, enable serial save or save LTC time to check the registers.
To enable serial save, set SER_TOD_INTF.SER_TOD_OUTPUT_EN to 1.
The following table lists the different options to load or save LTC time.
Table 44 •
LTC Time Load/Save Options
LTC_CTRL.L SER_TOD_INTF.SER_T LTC_CTR.S
OAD_EN
OD_INPUT_EN
AVE_EN
Expected Operation
0
0
1
Parallel Save
0
1
1
Save
0
0
0
No operation
0
1
0
No operation
1
0
0
Parallel Load
1
1
0
Serial Load
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
114
Functional Descriptions
Table 44 •
LTC Time Load/Save Options (continued)
LTC_CTRL.L SER_TOD_INTF.SER_T LTC_CTR.S
OAD_EN
OD_INPUT_EN
AVE_EN
Expected Operation
1
0
1
Parallel Load and Save
1
1
1
Serial Load and Save
When SER_TOD_INTF.SERIAL_ToD_OUTPUT_EN is set the PPS output is driven with a serial ToD
output based on the LTC timer value.
3.13.23 Programmable Offset for LTC Load Register
When a new LTC value is loaded into the system, a fixed offset may need to be added to the loaded
value. Program SER_TOD_INTF.LOAD_PULSE_DLY and this value will be added to LTC counter
whenever a new load occurs either through software, load_save pin or through serial ToD.
3.13.24 Adjustment of LTC counter
LTC counter value can be adjusted by about a sec without reloading a new LTC value. LTC value can be
programmed to tune the current value by adding or subtracting a specific value. The offset adjustment
can be positive or negative, very similar to 1 ns adjustment being positive or negative. An adjustment
every 232 ns can be performed using LTC_OFFSET_ADJ. Additionally, an adjustment every 220 ns can
be performed using LTC_AUTO_M_x.
The purpose of this register is to add/subtract a programmable offset register of 30-bit width in ns, to the
register block in order to cover the entire nanosecond portion of the 80-bit LTC. This offset control is
independent of the LTC load control. The LTC timer is adjusted - added or subtracted as per the bit
LTC_OFFSET_ADJ.LTC_ADD_SUB_OFFSET, by the value LTC_OFFSET_ADJ.LTC_OFFSET_VAL,
when a load offset command is issued by the software (assertion of
LTC_OFFSET_ADJ.LTC_OFFSET_ADJ). The hardware sets the status bit
LTC_OFFSET_ADJ_STAT.LTC_OFFSET_DONE after completing the operation. However, in case the
hardware cannot complete the operation because of the LTC value itself getting updated synchronously
due to parallel or serial LTC load at the same time, it sets the bit
LTC_OFFSET_ADJ_STAT.LTC_OFFSET_LOAD_ERR. The software on seeing either of these status
bits set (LTC_OFFSET_ADJ_STAT.LTC_OFFSET_DONE or
LTC_OFFSET_ADJ_STAT.LTC_OFFSET_LOAD_ERR), de-asserts the control bit
LTC_OFFSET_ADJ.LTC_OFFSET_ADJ and might potentially retry the operation.
The maximum value in nanoseconds for the offset LTC_OFFSET_ADJ.LTC_OFFSET_VAL can be up to
10^9 - 1. Thus, for addition operation, the maximum carry to the seconds counter is 2 because of the
clock period addition to this maximum value present in the offset and LTC nanoseconds counter. For
subtraction operation, if the resultant subtraction is negative or underflows the LTC timer would be set to
wrong value. Hence such operations should never be allowed.
LTC_OFFSET_ADJ register (with LTC_OFFSET_VAL[29:0] and LTC_ADD_SUB_OFFSET) should be
updated before asserting LTC_OFFSET_ADJ bit in LTC_OFFSET_ADJ register.
LTC_OFFSET_ADJ_STAT.LTC_OFFSET_DONE and
LTC_OFFSET_ADJ_STAT.LTC_OFFSET_LOAD_ERR bits are set by the hardware and cleared by the
software by writing a zero.
Should a conflict occur between LTC update due to parallel/serial load and LTC update due to offset
adjustment, the load LTC takes precedence and the error condition is noted so that the polling software
does not hang on the offset status bit assertion.
LTC counter could be adjusted for any known drift that occurs on every second. This feature will add or
subtract one nanosecond every time LTC crosses over LTC_AUTO_ADJ_M_NS.
Example 1: If LTC_AUTO_ADJ_M_NS is 100 ns and LTC is started from reset with a value of 0 ns, then
LTC counter will be added/subtracted 1 ns every time counter rolls over 100 ns.
Example 2: If LTC_AUTO_ADJ_M_NS is 100 ns and LTC is started from reset with a value of 0 ns, then
LTC counter will be added/subtracted 1 ns every time counter rolls over. When counter is at 10 ns and
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
115
Functional Descriptions
LTC counter is loaded with 2 sec, 80 ns. Now 1 ns is adjusted when counter increments from 10 ns and
rolls over 100 ns. It does not add/subtract when LTC timer rolls over 100 ns.
Example 3: LTC_AUTO_ADJ_M_NS value is loaded with 400 ns and after some time
LTC_AUTO_ADJ_M_NS value is loaded with 500 ns. The AUTO_ADJ_M_COUNTER value when the
new value is loaded is 333 ns. Then the next adjustment happens after 177 ns after load because the
AUTO_ADJ_M_COUNTER continues to count until it reaches the newly loaded value 500 ns.
Example 4: LTC_AUTO_ADJ_M_NS value is loaded with 400 ns and after some time
LTC_AUTO_ADJ_M_NS value is loaded with 100 ns. The AUTO_ADJ_M_COUNTER value when the
new value is loaded is 333 ns. Then adjustment happens immediately because 333 > 100 and the
AUTO_ADJ_M_COUNTER is reset to zero after the adjustment
If LTC counter is loaded with a new value, set LTC_AUTO_ADJ_M_UPDATE bit to 1 and reload the
LTC_AUTO_ADJ_M_NS value.
3.13.25 Pulse per Second Output
The local time counter generates a one pulse-per-second (1PPS) output signal with a programmable
pulse width routed to GPIO pins. The pulse width of the 1PPS signal is determined by the
LTC_1PPS_WIDTH_ADJ register.
When the LTC counter exceeds the value in PPS_GEN_CNT (both are in nanoseconds) the PPS signal
is asserted. In default operation where PPS_GEN_CNT = 0 the LTC timer generates a PPS signal every
time LTC crosses the 1 sec boundary. By writing a large value such as 109-60 ns, the 1PPS pulse
reaches its destination 60 ns away simultaneous with the LTC second wrap thus providing time-of-day
synchronism between two systems.
The 1PPS output has an alternate mode of operation that increases the frequency of the pulses. This
mode may be used for applications such as locking an external DPLL to the IEEE 1588 frequency. In the
alternate mode the 1PPS signal is driven directly from a single bit of the nanosecond field counter of the
local time counter. The pulse width can not be controlled in this alternate operation mode. The alternate
mode is enabled with register LTC_CTRL.LTC_ALT_MODE_PPS_BIT.
The output frequencies that result are 1 divided by powers of 2 nanoseconds (bit 4 = 1/32 ns, bit
5 = 1/64 ns, bit 6 = 1/128 ns, …). The output pulses may jitter by the amount of the programmed
nanoseconds of the adder to the local nanoseconds counter, and any automatic or one-shot
adjustments.
The following table shows the possible output pulse frequencies (including the range of 4 kHz to 10 MHz)
usable for external applications.
Table 45 •
Output Pulse Frequencies
Nanosecond Counter Bit
Output Pulse Frequency
4
31.25 MHz
5
15.625 MHz
6
7.8125 MHz
7
3.90625 MHz
8
1.953125 MHz
9
976.5625 kHz
10
488.28125 kHz
11
244.140625 kHz
12
122.0703125 kHz
13
61.03515625 kHz
14
30.51757813 kHz
15
15.25878906 kHz
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
116
Functional Descriptions
Table 45 •
Output Pulse Frequencies (continued)
Nanosecond Counter Bit
Output Pulse Frequency
16
7.629394531 kHz
17
3.814697266 kHz
In addition to the preceding frequencies, a specific frequency can be chosen by enabling the synthesizer
on the PPS pin using the following steps.
1.
2.
3.
4.
Set LTC_FREQ_SYNTH.LTC_FREQ_SYNTH_EN to 1.
A toggle signal with the frequency specified will be pushed out onto PPS. The number of
nanoseconds the signal stays high can be specified by
LTC_FREQ_SYNTH.FREQ_HI_DUTY_CYC_NS. The number of nanoseconds the signal stays low
can be specified by LTC_FREQ_SYNTH.FREQ_LO_DUTY_CYC_NS.
The above nanoseconds should be exactly divisible by clock frequency, otherwise the signal may
have a jitter as high as the high duration/clock period or low duration/clock period.
To disable the this feature and revert back to PPS functionality, reset
LTC_FREQ_SYNTH.LTC_FREQ_SYNTH_EN to 0
For example, to output a 10 MHz signal, set the FREQ_HI_DUTY_CYC_NS to 50 ns and
FREQ_LO_DUTY_CYC_NS to 50 ns. On a 250 MHz LTC clock, this will make high time and low time of
signal shift between 48 ns and 52 ns.
3.13.26 Accuracy and Resolution
Contact Microsemi with any questions regarding PTP accuracy calculations. The timestamp accuracy is
improved over the first generation IEEE 1588 engine from Microsemi. The timestamp accuracy is a
system-level property and may depend upon oscillator selection, port type and speed, system
configuration, and calibration decisions.
Supported frequencies of the local time counter are 125 MHz, 156.25 MHz, 200 MHz, and 250 MHz. The
time stamp resolution is equal to the local time counter clock period. For example, a 250MHz local time
counter clock will provide a 4ns time stamp resolution.
3.13.27 Loopbacks
Loopback options provide a means to measure the delay at different points to evaluate delays between
on chip wire delays and external delays down to a nanosecond.
3.13.27.1 Loopback from PPS to PPS_RI pin
In this loopback, an external device will connect the PPS coming out of the IEEE 1588 to PPS_RI of the
IEEE 1588 device. The external device could even process the PPS signal and then loopback at a farend.
3.13.27.2 Loopback from LOAD_SAVE to PPS
When LOAD_SAVE_PPS_LPBK_EN is set, input load_save pin is connected to output PPS coming out
of the IEEE 1588. In this mode, input load_save pin is taken as close to the pin as possible without going
through any synchronization logic on the load_save pin.
3.13.27.3 Loopback of LOAD_SAVE pin
When LOAD_SAVE_LPBK_EN is set, one clock cycle before the PPS is asserted, an output enable for
load_save pin is generated and PPS signal is pushed out on the load_save pin acting as an output pin.
After two cycles, output enable is brought down and load_save will behave as an input pin.
3.13.27.4 Loopback from PPS to LOAD_SAVE pin
When PPS_LOAD_SAVE_LPBK_EN bit enabled, output pps signal is taken as close to the I/O as
possible and looped back onto load_save input pin. This is to account for any delays from PPS
generation block to the PPS output pin.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
117
Functional Descriptions
3.13.28 IEEE 1588 Register Access using SMI (MDC/MDIO)
The SMI mechanism is an IEEE defined register access mechanism (refer to Clause 22 of IEEE 802.3).
The registers are arranged as 16 bits per register address with a 5 bit address field as defined by IEEE.
However Microsemi has extended this register address space by creating a register page key in register
31. When writing a particular key to register 31, a different set of 5 bit address space register bank can be
accessed through the SMI mechanism. (extended page, GPIO page, etc).
The IEEE 1588 registers are organized on page 4. Setting register 31 to 4 provides a window to CSR
registers through registers 16,17, and 18.
The IEEE 1588 IP registers are arranged as 32 bits of data. The access method through SMI is done by
breaking up the 32 bits of each IEEE 1588 register into the high 16 bits into register 18 and lower 16 bits
into register 17. Then register 16 is used as a command register. Phy0 and Phy2 automatically read/write
to engine A. Phy1 and Phy3 automatically read/write to engine B. For more information, see Figure 54,
page 62. 1588_DIFF_INPUT_CLK Configuration
Note: Contact Microsemi for an initialization script that supports the quick initialization of IEEE 1588 registers.
3.13.29 1588_DIFF_INPUT_CLK Configuration
The default configuration of the 1588_DIFF_INPUT_CLK_P/N pins sets the VSC8582-10 device to use
an internal clock for the LTC. To configure these pins correctly to use an external clock for LTC, write
0xb71c to register 30E4 and 0x7ae0 to register 29E4. Set these two registers to 0x0 when an internal
clock is used for LTC.
3.14
Daisy-Chained SPI Time Stamping
Registers 26E4–29E4 enable daisy-chaining multiple devices to reduce the number of pins required to
transmit time stamping information to system ASICs gathering IEEE 1588 time stamps.
The VSC8582-10 device captures frame time stamps on the 1588_SPI_IN signals, arbitrates with the
internal IEEE 1588 SPI time stamp outputs for the SPI output, and outputs the frame time stamps. Each
device output acts as the SPI master while the input acts as the SPI slave. Up to eight devices can be
daisy-chained to operate at up to 62.5 MHz. The following table shows the key throughput characteristics
for daisy-chained SPI time stamping.
Table 46 •
Daisy-Chain Parameters
SPI Bus Frequency
Maximum Time Stamps/Second
per Port
Maximum SPI Bus Utilization
31.25 MHz
256
5.69%
31.25 MHz
16
0.71%
The following illustration shows the SPI time stamping format for clock polarity and phase of 0.
Figure 100 • SPI Time Stamping Format
SPI_CS
SPI_CLK
SPI_DO
4 3 2 1 0
Port
3.15
9 8 7 6 5 4 3 2 1 0
Frame Identifier Data
(0 to 16 bytes)
12
9 8 7
6 5 4 3 2 1 00
Timestamp
(4 or 10 bytes)
SPI I/O Register Access
The VSC8582-10 device provides a bidirectional SPI I/O interface for register access to handle both
IEEE 1588 and MACsec communication to the device. The device uses one slave select (SS) per slave
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
118
Functional Descriptions
for a simple slave design, and to share the SCLK, MOSI, and MISO signals. The SPI I/O port is fully
independent of either the SPI time stamp input or output ports.
The following illustrations various write cycles with different endian and MSB/LSB-first settings. The read
cycle is shown with 1 byte of padding, configured for big endian mode and MSB-first operation.
Figure 101 • SPI Write Cycles
SPI_CS
SPI_Clk
Big endian mode (IF_CTRL[0]=1), Most significant bit first (IF_CTRL[1]=0)
2
1
SPI_DI
2 1
0 9
1
8
1
7
1
6
1 1
5 4
1
3
1
2
1 1
1 0
9
8
7 6
5
4
3
2 1
0
3
1
3 2
0 9
2
8
2
7
2 2
6 5
2
4
2
3
2
2
2 2
1 0
1
9
1
8
Serial Address (SI_ADDR)
1 1
7 6
1
5
1
4
1 1
3 2
1
1
1
0
9
8 7
6
5
4 3
2
1
0
1 1
0 1
1
2
1
3
1
4
1
0
5
1
2
3 4
5
6
7
2 2
1 0
1
9
1
8
1
7
1 3
6 1
3
0
2
9
2 2
8 7
2
6
2
5
2
4
1 1
8 9
2
0
2
1
2
2
2 2
3 4
2
5
2
6
2 2
7 8
2
9
3
0
3
1
Serial Data
SPI_DO
Big endian mode (IF_CTRL[0]=1), Least significant bit first (IF_CTRL[1]=1)
2
1
SPI_DI
2 1
0 9
1
8
1
7
1
6
1 1
5 4
1
3
1
2
1 1
1 0
9
8
7 6
5
4
3
2 1
0
2
4
2 2
5 6
2
7
2
8
2 3
9 0
3
1
1
6
1
7
1 1
8 9
2
0
2
1
Serial Address (SI_ADDR)
2 2
2 3
8
9
Serial Data
Little endian mode (IF_CTRL[0]=0), Most significant bit first (IF_CTRL[1]=0)
2
1
SPI_DI
2 1
0 9
1
8
1
7
1
6
1 1
5 4
1
3
1
2
1 1
1 0
9
8
7 6
5
4
3
2 1
0
7
6 5
4
3
2 1
1
5
0
1
4
1 1
3 2
1
1
1
0
Serial Address (SI_ADDR)
2
3
9 8
2
2
Serial Data
Little endian mode (IF_CTRL[0]=0), Least significant bit first (IF_CTRL[1]=1)
2
1
SPI_DI
2 1
0 9
1
8
1
7
1
6
1 1
5 4
1
3
1
2
1 1
1 0
9
8
7 6
5
4
3
2 1
0
0
1 2
3
4
5 6
7
8
9
1 1
0 1
1
2
1
3
Serial Address (SI_ADDR)
1 1
4 5
1
6
1
7
Serial Data
Figure 102 • SPI Read Cycle
SPI_CS
SPI_Clk
Big endian mode (IF_CTRL[0]=1), Most significant bit first (IF_CTRL[1]=0), no padding (IF_CFGSTAT.IF_CFG=1)
2
1
SPI_DI
2 1 1 1
0 9 8 7
1
6
1
5
1
4
1
3
1 1
2 1
1
9
0
8
7
6
5
4 3
2 1
0
Serial Address (SI_ADDR)
3
1
SPI_DO
3 2
0 9
2
8
2
7
2 2
6 5
2
4
2
3
2 2
2 1
2
0
1
9
1 1
8 7
padding (1 byte)
1
6
1
5
1 1
4 3
1
2
1
1
1
9
0
8
7 6
5
4
3
2
1 0
Serial Data
A 25 MHz SPI operating rate is used to access the CSR address space.
The 22-bit address (indicated as SI_ADDR), is composed of a 2-bit ring select, an 8-bit Target ID, and a
12-bit register address. This register address represents a word address where a word is 32 bits. The
SPI data is 32 bits and is consistent with this mapping.
Table 47 •
SI_ADDR Mapping
Bit
Description
21:20
CSR ring select
00: Ring 0
01: Reserved
10: Reserved
11: Reserved
19:14
Target ID[7:2]
13:12
Target ID [1:0] for most targets
CSR register address[13:12] for MACsec INGR/EGR Targets
11:0
CSR register address[11:0]
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
119
Functional Descriptions
The 2-bit ring select (SI_ADDR[21:20]) selects the CSR ring. A coding of 00 selects ring 0. Coding of 01,
10, and 11 are reserved.
SI_ADDR[19:14] maps to Target ID[7:2] and SI_ADDR[11:0] maps to CSR register address bits 11:0. The
Target ID[1:0] and CSR register address bits 13:12 depends on Target ID[5:3].
Target ID[5:3] bits set to 111 access the MACsec INGR or MACsec EGR registers. In this case, Target
ID[1:0] is hard-coded to 00 and the CSR address bits 13:12 is supplied by SI_ADDR[13:12]. In all other
cases, Target ID[1:0] is supplied by SI_ADDR[13:12] and the CSR address bits 13:12 is hard-coded to
00.
The default configuration values are LSB_FIRST=0, BIG_ENDIAN=1, and PADDING _BYTES=3. These
are the recommended operating values. Most CSR accesses will not work if the number of padding bytes
is less than 3.
The Chip ID, Extended Chip ID, and Revision Code can be read at Target ID 0x40, address 0xFFF.
3.16
Media Recovered Clock Outputs
For Synchronous Ethernet applications, the VSC8582-10 includes two recovered clock output pins,
RCVRDCLK1 and RCVRDCLK2, controlled by registers 23G and 24G, respectively. The recovered clock
pins are synchronized to the clock of the active media link.
To enable recovered clock output, set register 23G or 24G, bit 15, to 1. By default, the recovered clock
output pins are disabled and held low, including when NRESET is asserted. Registers 23G and 24G also
control the PHY port for clock output, the clock source, the clock frequency (either 25 MHz, 31.25 MHz,
or 125 MHz), and squelch conditions.
Note: When EEE is enabled on a link, the use of the recovered clock output is not recommended due to long
holdovers occurring during EEE Quiet/Refresh cycles.
3.16.1
Clock Selection Settings
On each pin, the recovered clock supports the following sources, as set by registers 23G or 24G, bits 2:0:
•
Fiber SerDes media
•
Copper media
•
Copper transmitter TCLK output (RCVRDCLK1 only)
Note: When using the automatic media sense feature, the recovered clock output cannot automatically change
between each active media. Changing the media source must be managed through the recovered clock
register settings.
Adjust the squelch level to enable 1000BASE-T master mode recovered clock for SyncE operation. This
is accomplished by changing the 23G and 24G register bits 5:4 to 01. This setting also provides clock out
for 10BASE-T operation. For 1000BASE-T master mode, the clock is based on the VSC8582-10
REFCLK input, which is a local clock.
3.16.2
Clock Output Squelch
Under certain conditions, the PHY outputs a clock based on the REFCLK_P and REFCLK_N pins, such
as when there is no link present or during autonegotiation. To prevent an undesirable clock from
appearing on the recovered clock pins, the VSC8582-10 squelches, or inhibits, the clock output based on
any of the following criteria:
•
•
•
•
No link is detected (the link status register 1, bit 2 = 0).
The link is found to be unstable using the fast link failure detection feature. The
GPIO9/FASTLINK-FAIL pin is asserted high when enabled.
The active link is in 10BASE-T or in 1000BASE-T master mode. These modes produce unreliable
recovered clock sources.
CLK_SQUELCH_IN is enabled to squelch the clock.
Use registers 23G or 24G, bits 5:4 to configure the clock squelch criteria. These registers can also
disable the squelch feature. The CLK_SQUELCH_IN pin controls the squelching of the clock. Both
RCVRDCLK1 and RCVRDCLK2 are squelched when the CLK_SQUELCH_IN pin is high.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
120
Functional Descriptions
3.17
Serial Management Interface
The VSC8582-10 device includes an IEEE 802.3-compliant serial management interface (SMI) that is
affected by use of its MDC and MDIO pins. The SMI provides access to device control and status
registers. The register set that controls the SMI consists of 32 16-bit registers, including all required
IEEE-specified registers. Also, there are additional pages of registers accessible using device register
31.
Energy efficient Ethernet control registers are available through the SMI using Clause 45 registers and
Clause 22 register access in registers 13 through 14. For more information, see Table 71, page 147 and
Table 147, page 188.
The SMI is a synchronous serial interface with input data to the VSC8582-10 on the MDIO pin that is
clocked on the rising edge of the MDC pin. It is a multiple-target bus that incorporates open-collector
drivers along with an external pull-up to share the MDIO data line between multiple PHY chips. The
output data is sent on the MDIO pin on the rising edge of the MDC signal. The interface can be clocked
at a rate from 0 MHz to 12.5 MHz, depending on the total load on MDIO. An external 2-kΩ pull-up resistor
is required on the MDIO pin.
3.17.1
SMI Frames
Data is transferred over the SMI using 32-bit frames with an optional, arbitrary-length preamble. Before
the first frame can be sent, at least two clock pulses on MDC must be provided with the MDIO signal at
logic one to initialize the SMI state machine. The following illustrations show the SMI frame format for
read and write operations.
Figure 103 • SMI Read Frame
Station manager drives MDIO
PHY drives MDIO
MDC
MDIO
Z
Z
1
0
1
Idle Preamble SFD
(optional)
1
0
Read
A4 A3 A2 A1 A0 R4 R3 R2 R1 R0 Z
PHY Address
Register Address
to PHY
0 D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0 Z
TA
Register Data
from PHY
Z
Idle
Figure 104 • SMI Write Frame
Station manager drives MDIO (PHY tri-states MDIO during the entire sequence)
MDC
MDIO
Z
Z
1
0
1
0
1
Idle Preamble SFD Write
(optional)
A4 A3 A2 A1 A0 R4 R3 R2 R1 R0
PHY Address
Register Address
to PHY
1
0 D15 D14 D13 D12 D11 D10 D9 D8 D7 D6 D5 D4 D3 D2 D1 D0 Z
TA
Register Data
to PHY
Z
Idle
The following list provides additional information about the terms used in the SMI read and write timing
diagrams.
•
•
•
Idle During idle, the MDIO node goes to a high-impedance state. This allows an external pull-up
resistor to pull the MDIO node up to a logical 1 state. Because the idle mode does not contain any
transitions on MDIO, the number of bits is undefined during idle.
Preamble By default, preambles are not expected or required. The preamble is a string of ones. If
it exists, the preamble must be at least 1 bit; otherwise, it can be of an arbitrary length.
Start of Frame (SFD) A pattern of 01 indicates the start of frame. If the pattern is not 01, all
following bits are ignored until the next preamble pattern is detected.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
121
Functional Descriptions
•
•
•
•
•
•
3.17.2
Read or Write Opcode A pattern of 10 indicates a read. A 01 pattern indicates a write. If the bits
are not either 01 or 10, all following bits are ignored until the next preamble pattern is detected.
PHY Address The particular VSC8582-10 responds to a message frame only when the received
PHY address matches its physical address. The physical address is 5 bits long (4:0).
Register Address The next five bits are the register address.
Turnaround The two bits used to avoid signal contention when a read operation is performed on
the MDIO are called the turnaround (TA) bits. During read operations, the VSC8582-10 drives the
second TA bit, a logical 0.
Data The 16-bits read from or written to the device are considered the data or data stream. When
data is read from a PHY, it is valid at the output from one rising edge of MDC to the next rising edge
of MDC. When data is written to the PHY, it must be valid around the rising edge of MDC.
Idle The sequence is repeated.
SMI Interrupt
The SMI includes an output interrupt signal, MDINT, for signaling the station manager when certain
events occur in the VSC8582-10.
The MDINT pin is configured for open-drain (active-low). Tie the pin to a pull-up resistor to VDDIO. The
following illustration shows the configuration.
Figure 105 • MDINT Configured as an Open-Drain (Active-Low) Pin
VDDIO
PHY_n
Interrupt Pin Enable
(Register 25.15)
External Pull-Up
Resistor at the
Station Manager
MDINT
(to the Station
Manager)
MDINT
Interrupt Pin Status
(Register 26.15)
When a PHY generates an interrupt, the MDINT pin is asserted by driving low if the interrupt pin enable
bit (MII register 25.15) is set.
3.18
LED Interface
The LED interface supports the following configurations: direct drive, basic serial LED mode, and
enhanced serial LED mode. The polarity of the LED outputs is programmable and can be changed
through register 17E2, bits 13:10. The default polarity is active low.
Direct drive mode provides four LED signals per port, LED0_[0:3] through LED3_[0:3]. The mode and
function of each LED signal can be configured independently. When serial LED mode is enabled, the
direct drive pins not used by the serial LED interface remain available.
In basic serial LED mode, all signals that can be displayed on LEDs are sent as LED_Data and
LED_CLK for external processing. In enhanced serial LED mode, up to four LED signals per port can be
sent as LED_Data, LED_CLK, LED_LD, and LED_Pulse. The following sections provide detailed
information about the various LED modes.
Note: LED number is listed using the convention, LED_.
The following table shows the bit 9 settings for register 14G that are used to control the LED behavior for
all the LEDs in VSC8582-10.
Table 48 •
LED Drive State
Setting
Active
Not Active
14G.9 = 1 (default)
Ground
Tristate
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
122
Functional Descriptions
Table 48 •
3.18.1
LED Drive State (continued)
Setting
Active
Not Active
14G.9 = 0 (alternate setting)
Ground
VDD
LED Modes
Each LED pin can be configured to display different status information that can be selected by setting the
LED mode in register 29. The modes listed in the following table are equivalent to the setting used in
register 29 to configure each LED pin. The default LED state is active low and can be changed by
modifying the value in register 17E2, bits 13:10. The blink/pulse-stretch is dependent on the LED
behavior setting in register 30.
The following table provides a summary of the LED modes and functions.
Table 49 •
LED Mode and Function Summary
Mode Function Name
LED State and Description
0
Link/Activity
1: No link in any speed on any media interface.
0: Valid link at any speed on any media interface.
Blink or pulse-stretch = Valid link at any speed on any media
interface with activity present.
1
Link1000/Activity
1: No link in 1000BASE-T or 1000BASE-X.
0: Valid 1000BASE-T or 1000BASE-X.
Blink or pulse-stretch = Valid 1000BASE-T or 1000BASE-X
link with activity present.
2
Link100/Activity
1: No link in 100BASE-TX or 100BASE-FX.
0: Valid 100BASE-TX or 100BASE-FX.
Blink or pulse-stretch = Valid 100BASE-TX or 100BASE-FX
link with activity present.
3
Link10/Activity
1: No link in 10BASE-T.
0: Valid 10BASE-T link.
Blink or pulse-stretch = Valid 10BASE-T link with activity
present.
4
Link100/1000/Activity
1: No link in 100BASE-TX, 100BASE-FX, 1000BASE-X, or
1000BASE-T.
0: Valid 100BASE-TX, 100BASE-FX, 1000BASE-X, or
1000BASE-T link. Blink or pulse-stretch = Valid 100BASE-TX,
100BASE-FX, 1000BASE-X, or 1000BASE-T link with activity
present.
5
Link10/1000/Activity
1: No link in 10BASE-T, 1000BASE-X, or 1000BASE-T.
0: Valid 10BASE-T, 1000BASE-X, or 1000BASE-T link.
Blink or pulse-stretch = Valid 10BASE-T, 1000BASE-X, or
1000BASE-T link with activity present.
6
Link10/100/Activity
1: No link in 10BASE-T, 100BASE-FX, or 100BASE-TX.
0: Valid 10BASE-T, 100BASE-FX, or 100BASE-TX link.
Blink or pulse-stretch = Valid 10BASE-T, 100BASE-FX, or
100BASE-TX link with activity present.
7
Link100BASE-FX/1000BAS 1: No link in 100BASE-FX or 1000BASE-X.
E-X/Activity
0: Valid 100BASE-FX or 1000BASE-X link.
Blink or pulse-stretch = Valid 100BASE-FX or 1000BASE-X
link with activity present.
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
123
Functional Descriptions
Table 49 •
Mode Function Name
LED State and Description
8
Duplex/Collision
1: Link established in half-duplex mode, or no link established.
0: Link established in full-duplex mode.
Blink or pulse-stretch = Link established in half-duplex mode
but collisions are present.
9
Collision
1: No collision detected.
Blink or pulse-stretch = Collision detected.
10
Activity
1: No activity present.
Blink or pulse-stretch = Activity present (becomes TX activity
present when register bit 30.14 is set to 1).
11
100BASE-FX/1000BASE-X 1: No 100BASE-FX or 1000BASE-X activity present.
Fiber Activity
Blink or pulse-stretch = 100BASE-FX or 1000BASE-X activity
present (becomes Rx activity present when register bit 30.14
is set to 1).
12
Autonegotiation Fault
1: No autonegotiation fault present.
0: Autonegotiation fault occurred.
13
Serial Mode
Serial stream. See Basic Serial LED Mode, page 125. Only
relevant on PHY port 0 and reserved in others.
14
Force LED Off
1: De-asserts the LED(1).
15
Force LED On
0: Asserts the LED(1).
1.
3.18.2
LED Mode and Function Summary (continued)
Setting this mode suppresses LED blinking after reset.
Extended LED Modes
In addition to the LED modes in register 29, there are also additional LED modes that are enabled on the
LED0_[1:0] pins whenever the corresponding register 19E1, bits 15 to 12 are set to 1. Each of these bits
enables extended modes on a specific LED pin and these extended modes are shown in the following
table. For example, LED0 = mode 17 means that register 19E1 bit 12 = 1 and register 29 bits 3 to
0 = 0001.
The following table provides a summary of the extended LED modes and functions.
Table 50 •
Extended LED Mode and Function Summary
Mode Function Name
LED State and Description
16
Link1000BASE-X Activity 1: No link in 1000BASE-X.
0: Valid 1000BASE-X link.
17
Link100BASE-FX Activity 1: No link in 100BASE-FX.
0: Valid 100BASE-FX link.
18
1000BASE-X Activity
1: No 1000BASE-X activity present.
Blink or pulse-stretch = 1000BASE-X activity present.
19
100BASE-FX Activity
1: No 100BASE-FX activity present.
Blink or pulse-stretch = 100BASE-FX activity present.
20
Force LED Off
1: De-asserts the LED.
21
Force LED On
0: Asserts the LED. LED pulsing is disabled in this mode.
22
Fast Link Fail
1: Enable fast link fail on the LED pin
0: Disable
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
124
Functional Descriptions
3.18.3
LED Behavior
Several LED behaviors can be programmed into the VSC8582-10. Use the settings in register 30 and
19E1 to program LED behavior, which includes the following.
LED Combine Enables an LED to display the status for a combination of primary and secondary
modes. This can be enabled or disabled for each LED pin. For example, a copper link running in
1000BASE-T mode and activity present can be displayed with one LED by configuring an LED pin to
Link1000/Activity mode. The LED asserts when linked to a 1000BASE-T partner and also blinks or
performs pulse-stretch when activity is either transmitted by the PHY or received by the Link Partner.
When disabled, the combine feature only provides status of the selected primary function. In this
example, only Link1000 asserts the LED, and the secondary mode, activity, does not display when the
combine feature is disabled.
LED Blink or Pulse-Stretch This behavior is used for activity and collision indication. This can be
uniquely configured for each LED pin. Activity and collision events can occur randomly and intermittently
throughout the link-up period. Blink is a 50% duty cycle oscillation of asserting and de-asserting an LED
pin. Pulse-stretch guarantees that an LED is asserted and de-asserted for a specific period of time when
activity is either present or not present. These rates can also be configured using a register setting.
Rate of LED Blink or Pulse-Stretch This behavior controls the LED blink rate or pulse-stretch length
when blink/pulse-stretch is enabled on an LED pin. The blink rate, which alternates between a high and
low voltage level at a 50% duty cycle, can be set to 2.5 Hz, 5 Hz, 10 Hz, or 20 Hz. For pulse-stretch, the
rate can be set to 50 ms, 100 ms, 200 ms, or 400 ms. The blink rate selection for PHY0 globally sets the
rate used for all LED pins on all PHY ports.
LED Pulsing Enable To provide additional power savings, the LEDs (when asserted) can be pulsed at
5 kHz, 20% duty cycle.
LED Blink After Reset The LEDs will blink for one second after power-up and after any time all resets
have been de-asserted. This can be disabled through register 19E1, bit 11 = 0.
Fiber LED Disable This bit controls whether the LEDs indicate the fiber and copper status (default) or
the copper status only.
Pulse Programmable Control These bits add the ability to width and frequency of LED pulses. This
feature facilitates power reduction options.
Fast Link Failure For more information about this feature, see Fast Link Failure Indication, page 126.
3.18.4
Basic Serial LED Mode
Optionally, the VSC8582-10 can be configured so that access to all its LED signals is available through
two pins. This option is enabled by setting LED0 on PHY0 to serial LED mode in register 29, bits 3:0 to
0xD. When serial LED mode is enabled, the LED0_0 pin becomes the serial data pin, and the LED1_0
pin becomes the serial clock pin. All other LED pins can still be configured normally. The serial LED
mode clocks the 48 LED status bits on the rising edge of the serial clock where bits 25:48 are ignored.
The LED behavior settings can also be used in serial LED mode. The controls are used on a per-PHY
basis, where the LED combine and LED blink or pulse-stretch setting of LED0_n for each PHY is used to
control the behavior of each bit of the serial LED stream for each corresponding PHY. To configure LED
behavior, set device register 30.
The following table shows the 48-bit serial output bitstream of each LED signal where bits 25:48 are
ignored. The individual signals can be clocked in the following order.
Table 51 •
LED Serial Bitstream Order
Output
PHY0
PHY1
Link/activity
1
13
Link1000/activity
2
14
Link100/activity
3
15
VMDS-10421 VSC8582-10 Datasheet Revision 4.3
125
Functional Descriptions
Table 51 •
3.18.5
LED Serial Bitstream Order (continued)
Output
PHY0
PHY1
Link10/activity
4
16
Fiber link/activity
5
17
Duplex/collision
6
18
Collision
7
19
Activity
8
20
Fiber activity
9
21
Tx activity
10
22
Rx activity
11
23
Autonegotiation fault
12
24
Enhanced Serial LED Mode
VSC8582-10 can be configured to output up to four LED signals per port on a serial stream that can be
de-serialized externally to drive LEDs on the system board. In enhanced serial LED mode, the port 0 and
port 1 LED output pins serve the following functions:
•
•
•
•
LED0_0/LED0_1: LED_DATA
LED1_0/LED1_1: LED_CLK
LED2_0/LED2_1: LED_LD
LED3_0/LED3_1: LED_PULSE
The serial LED_DATA is shifted out on the falling edge of LED_CLK and is latched in the external
serial-to-parallel converter on the rising edge of LED_CLK. The falling edge of LED_LD signal can be
used to shift the data from the shift register in the converter to the parallel output drive register. When a
separate parallel output drive register is not used in the external serial-to-parallel converter, the LEDs will
blink at a high frequency as the data bits are being shifted through, which may be undesirable. LED pin
functionality is controlled by setting register 25G, bits 7:1.
The LED_PULSE signal provides a 5 kHz pulse stream whose duty cycle can be modulated to turn on/off
LEDs at a high rate. This signal can be tied to the output enable signal of the serial-to-parallel converter
to provide the LED dimming functionality to save energy. The LED_PULSE duty cycle is controlled by
setting register 25G, bits 15:8.
3.18.6
LED Port Swapping
For additional hardware configurations, the VSC8582-10 can have its LED port order swapped. This is a
useful feature to help simplify PCB layout design. Register 25G bit 0 controls the LED port swapping
mode. LED port swapping only applies to the direct-drive LEDs and not to any serial LED output modes.
3.19
Fast Link Failure Indication
To aid Synchronous Ethernet applications, the VSC8582-10 can indicate the onset of a link failure in less
than 1 ms (worst-case
