VSC8257-01 Datasheet
Quad Channel 1G/10GBASE-KR to SFI Ethernet WIS
PHY with VeriTime™
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
©2017–2018 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-10486. 4.1 11/18
Contents
1 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1
1.2
1.3
1.4
Revision 4.1
Revision 4.0
Revision 2.1
Revision 2.0
.......................................................................
.......................................................................
.......................................................................
.......................................................................
1
1
1
1
2 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 2
2.1
2.2
2.3
2.4
Highlights . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.1
IEEE 1588v2 One-Step End-to-End Transparent Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2.4.2
IEEE 1588v2 Transparent Clock and Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
2
3
4
5
5
6
3 Functional Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1
3.2
3.3
3.4
3.5
3.6
Data Path Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
3.1.1
Ingress and Egress Operation: Repeater (or Pass-Through) Mode . . . . . . . . . . . . . . . . . . . . . 8
3.1.2
Ingress Operation: Ethernet Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
3.1.3
Egress Operation: Ethernet Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Physical Media Attachment (PMA) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.1
Reference Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.2
VScope™ Input Signal Monitoring Integrated Circuit . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
3.2.3
10GBASE-KR . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Wide Area Network Interface Sublayer (WIS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.1
Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
3.3.2
Section Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3.3.3
Frame Alignment (A1, A2) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.3.4
Loss of Signal (LOS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
3.3.5
Loss of Optical Carrier (LOPC) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.6
Severely Errored Frame (SEF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.7
Loss of Frame (LOF) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.8
Section Trace (J0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 20
3.3.9
Reserved for Section Growth (Z0) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.10 Scrambling/Descrambling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.11 Section Error Monitoring (B1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 21
3.3.12 Section Orderwire (E1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.13 Section User Channel (F1) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.14 Section Data Communication Channel (DCC-S) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.15 Reserved, National, and Unused Octets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.16 Line Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
3.3.17 SPE Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.18 Path Overhead . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.3.19 Overhead Serial Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
3.3.20 Pattern Generator and Checker . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
10G Physical Coding Sublayer (64b/66b PCS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.4.1
PCS Standard Test Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
1G Physical Coding Sublayer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
IEEE 1588 Block Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
3.6.1
IEEE 1588 Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.2
IEEE 1588v2 One-Step End-to-End Transparent Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
3.6.3
IEEE 1588v2 Transparent Clock and Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 46
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
iii
3.7
3.8
3.9
3.10
3.11
3.12
3.13
3.14
3.6.4
Enhancing IEEE 1588 Accuracy for CE Switches and MACs . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6.5
Supporting One-Step Boundary Clock/Ordinary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 47
3.6.6
Supporting Two-Step Boundary Clock/Ordinary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.6.7
Supporting One-Step End-to-End Transparent Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 51
3.6.8
Supporting One-Step Peer-to-Peer Transparent Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
3.6.9
Supporting Two-Step Transparent Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
3.6.10 Calculating OAM Delay Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.6.11 Supporting Y.1731 One-Way Delay Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.6.12 Supporting Y.1731 Two-Way Delay Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
3.6.13 Device Synchronization for IEEE 1588 Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
3.6.14 Time Stamp Update Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.6.15 Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 68
3.6.16 Time Stamp Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 89
3.6.17 Time Stamp FIFO . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
3.6.18 Rewriter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.6.19 Local Time Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
3.6.20 Serial Time of Day . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
3.6.21 Programmable Offset for LTC Load Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.6.22 Adjustment of LTC Counter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
3.6.23 Pulse per Second Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
3.6.24 Accuracy and Resolution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.6.25 Loopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
3.6.26 Accessing 1588 IP Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Flow Control Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Rate Compensating Buffers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Cross Connect . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Host-Side Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.12.1 Synchronous Ethernet Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Operating Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.13.1 10G LAN with 1588 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.13.2 10G WAN with 1588 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
3.13.3 1 GbE with 1588 and MACs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
Management Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.14.1 MDIO Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
3.14.2 SPI Slave Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
3.14.3 Two-Wire Serial (Slave) Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.14.4 Two-Wire Serial (Master) Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
3.14.5 Push Out SPI Master Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.14.6 JTAG . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
3.14.7 General Purpose I/O . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113
4 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
5 Electrical Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
5.1
5.2
DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.1
Low-Speed Inputs and Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.1.2
Reference Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.1
Receiver Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.2
Transmitter Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.3
Timing and Reference Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.4
Two-Wire Serial (Slave) Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.5
MDIO Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.6
Synchronous Time-of-Day Load/Save Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.2.7
SPI Slave Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
119
119
120
120
120
122
125
127
128
129
129
iv
5.3
5.4
Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Stress Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
6 Pin Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
6.1
6.2
Pin Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
Pins by Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
7 Package Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
7.1
7.2
7.3
Package Drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
Thermal Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
Moisture Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
8 Design Considerations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
8.1
8.2
8.3
8.4
8.5
8.6
8.7
8.8
8.9
8.10
8.11
SPI bus speeds . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Device clocking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
10GBASE-KR autonegotiation and link training . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Low-power mode and SerDes calibration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Low power mode with failover switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Flow control with failover switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
GPIO as TOSI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Limited 1G status reporting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
1G mode operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Loopbacks in 10G WAN mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Timestamp errors due to IEEE 1588 reference clock interruption . . . . . . . . . . . . . . . . . . . . . . . . . . . .
146
146
146
146
146
146
146
146
147
147
147
9 Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
v
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
Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
SFP+ Transceiver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Backplane Equalization Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Transparent Clock Line Card Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Boundary Clock Line Card Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
10GBASE-KR Output Driver . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
10GBASE-KR Test Pattern . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
WIS Transmit and Receive Functions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
eWIS Frame Structure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
STS-192c/STM-64 Section and Line Overhead in the WIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
STS-192c/STM-64 Path Overhead in the WIS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Synchronization State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Secondary SYNC State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 19
Pointer Interpretation States Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
TOSI Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 38
ROSI Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
PCS Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
IEEE 1588 Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
IEEE 1588 Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 45
IEEE 1588 Transparent Clock and Boundary Clock Line Card Application . . . . . . . . . . . . . . . . . . 46
One-Step End-to-End Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Two-Step End-to-End Boundary Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
One-Step End-to-End Transparent Clock Mode A . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
One-Step End-to-End Transparent Clock Mode B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
Delay Measurements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
One-Step Peer-to-Peer Transparent Clock Mode B . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
Two-Step End-to-End Transparent Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 59
Y.1731 1DM PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
Y.1731 One-Way Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 61
Y.1731 DMM PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
Y.1731 Two-Way Delay . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63
RFC6374 DMM/DMR OAM PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
Draft-bhh DMM/DMR/1DM OAM PDU Formats . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 64
PTP Packet Encapsulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
OAM Packet Encapsulations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
TSU Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 67
Analyzer Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 69
Type II Ethernet Basic Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Ethernet Frame with SNAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Ethernet Frame with VLAN Tag and SNAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Ethernet Frame with VLAN Tags and SNAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
PBB Ethernet Frame Format (No B-Tag) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
PBB Ethernet Frame Format (1 B-Tag) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
MPLS Label Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
MPLS Label Stack within an Ethernet Frame . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
MPLS Labels and Control Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
IPv4 with UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
IPv6 with UDP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
ACH Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
ACH Header with Protocol ID Field . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
IPSec Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
IPv6 with UDP and IPSec . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
PTP Frame Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
OAM 1DM Frame Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 82
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
vi
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
OAM DMM Frame Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
OAM DMR Frame Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
RFC6374 DMM/DMR OAM PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83
G8113.1/draft-bhh DMM/DMR/1DM OAM PDU Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
Serial Time Stamp/Frame Signature Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
Preamble Reduction in Rewriter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93
Local Time Counter Load/Save Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
Standard PPS and 1PPS with TOD Timing Relationship . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
ToD Octet Waveform . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Host-Side and Line-Side Loopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
Port Timing Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Per-Port Clock Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103
10G LAN with 1588 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
10G WAN with 1588 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 104
1 GbE with 1588 and MACs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 105
SPI Single Register Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
SPI Multiple Register Reads . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
SPI Multiple Register Writes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
SPI Read Following Write . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
SPI Write Following Read . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
SPI Slave Default Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
SPI Slave Fast Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
Two-Wire Serial Bus Reset Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Two-Wire Serial Slave Register Address Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Two-Wire Serial Write Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
Two-Wire Serial Read Instruction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 111
GPIO Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
Interrupt Scheme . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 117
SFI Datacom Sinusoidal Jitter Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
SFI Transmit Differential Output Compliance Mask . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
LREFCK/HREFCLK to Data Output Jitter Transfer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
Two-Wire Serial Interface Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
Timing with MDIO Sourced by STA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Timing with MDIO Sourced by MMD . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Load/Save AC Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
SPI Interface Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3-Pin Push-Out SPI Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Pin Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
VSC8257-01 Package . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 144
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
vii
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
Repeater (or Pass-through) Mode Interface Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Ethernet Mode Interface Data Rates . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
Selecting LREFCK Frequency . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Section Overhead Functions and Recommended Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
Framing Parameter Description and Values . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Line Overhead Octets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
K2 Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
SONET/SDH Pointer Mode Difference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
16-bit Designations within the Payload Pointer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
H1/H2 Pointer Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Concatenation Types . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
Pointer Interpreter State Transitions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
STS Path Overhead Octets . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
Path Status (G1) Byte for RDI-P Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
Path Status (G1) Byte for ERDI-P Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
RDI-P and ERDI-P Bit Settings and Interpretations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
PMTICK Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Defects and Anomalies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
TOSI/ROSI Addresses . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Flows Per Engine Type . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Ethernet Comparator: Next Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 70
Comparator ID Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 71
Ethernet Comparator (Next Protocol) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 72
Ethernet Comparator (Flow) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73
MPLS Comparator: Next Word . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 75
Next MPLS Comparator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
MPLS Comparator: Per-Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
MPLS Range_Upper/Lower Label Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 76
Next-Protocol Registers in OAM-Version of MPLS Block . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 77
Comparator Field Summary . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
IP/ACH Next-Protocol Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
IP/ACH Comparator Flow Verification Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 81
PTP Comparison . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 84
PTP Comparison: Common Controls . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
PTP Comparison: Additions for OAM-Optimized Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 86
Frame Signature Byte Mapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
Frame Signature Address Source . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 87
LTC Time Load/Save Options . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 96
Output Pulse Frequencies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Line-Side Loopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
Host-Side Loopbacks . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
MDIO Port Addresses Per Channel . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 106
SPI Slave Instruction Bit Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 107
JTAG Instructions and Register Codes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 112
Recommended GPIO Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 114
LVTTL Input and Push/Pull Output DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
LVTTLOD Input and Open-Drain Output DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Reference Clock DC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Host- and Line-Side 10G Receiver Input (SFI Point D) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Host- and Line-Side 10G Receiver Input (SFI Point C”) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Host- and Line-Side SONET 10G Input Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Host- and Line-Side 1.25 Gbps SFI Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
Host- and Line-Side 10G Transmitter Output (SFI Point A) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Host- and Line-Side 10G Transmitter Output (SFI Point B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
viii
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
Transmitter SFP+ Direct Attach Copper Output AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . 124
10 Gbps Transmitter 10GBASE-KR AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
Host- and Line-Side Optical 10G Output Jitter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Host- and Line-Side 1.25 Gbps SFI Output . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Reference Clock AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Two-Wire Serial Interface AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
MDIO Interface AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Clock Output AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Load/Save Setup and Hold Timing AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
SPI Slave Interface AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
3-Pin Push-Out SPI AC Characteristics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Recommended Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Stress Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
Thermal Resistances . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 145
Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
ix
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.1
Revision 4.1 was published in September 2018. In revision 4.1 of this document, the registers were
attached. For more information, see Registers, page 118.
1.2
Revision 4.0
Revision 4.0 was published in February 2018. The following is a summary of the changes in revision 4.0
of this document.
•
•
•
•
•
•
•
•
•
•
•
1.3
The framing parameter description and values table was updated. For more information, see
Table 5, page 17
Section overhead functions and recommended values were updated. For more information, see
Table 4, page 15.
Line overhead octets table was updated. For more information, see Table 6, page 22.
STS path overhead octets functions were updated. For more information, see Table 13, page 30.
TOSI/ROSI addresses were updated. For more information, see Table 19, page 39.
Cross connect information was updated to accurately reflect device functionality. For more
information, see Cross Connect, page 101.
Host- and line-side 10G receiver input characteristics were updated. For more information, see
Table 49, page 120 and Table 50, page 121.
Host- and line-side 10G transmitter output characteristics were updated. For more information, see
Table 53, page 123 and Table 54, page 123.
10 Gbps transmitter 10GBASE-KR AC characteristics were updated. For more information, see
Table 56, page 124.
Host- and line-side optical 10G output jitter specifications were updated. For more information, see
Table 57, page 125.
Recommended operating conditions and stress ratings were updated. For more information, see
Table 66, page 131 and Table 67, page 131.
Revision 2.1
Revision 2.1 was published in January 2018. The following is a summary of the changes in revision 2.1
of this document.
•
•
•
•
•
•
1.4
The two-wire serial slave interface register address illustrations and 24-bit addressing scheme
details were updated.
DC characteristics for low-speed inputs and outputs were updated.
Receiver and transmitter AC characteristics were updated.
Reference clock AC characteristics were updated.
The SPI interface timing diagram was updated.
Pin descriptions were updated to correctly reflect device functionality.
Revision 2.0
Revision 2.0 was published in September 2017. It was the first publication of the document.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
1
Overview
2
Overview
The VSC8257-01 device is part of Microsemi’s SynchroPHY™ product family. It is a four channel 1G/10G
serial-to-serial Ethernet PHY featuring Microsemi’s VeriTime™ (IEEE 1588v2) precision network timing
technology. It also supports dual-sided 10GBASE-KR functionality including auto-negotiation and training
in a small form factor, low-power FCBGA ideal for a wide array of board-level signal integrity designs and
system-level IEEE standard compliant (intelligent) Ethernet connectivity.
VeriTime™ is Microsemi’s patent-pending timing technology that delivers the industry’s most accurate
IEEE 1588v2 timing implementation. It is the only IEEE 1588v2 solution to be validated by major OEMs
in real-world tests and adopted as the preferred low-cost upgrade for meeting emerging requirements in
4G/LTE-Advanced (LTE-A). With its integration of VeriTime, VSC8257-01 delivers the quickest, lowest
cost method of implementing the network timing accuracy that is critical in maintaining existing service
levels as provider architectures migrate from TDM to packet-based technologies. The VSC8257-01
device supports both 1-step and 2-step PTP frames for ordinary clock, boundary clock, and transparent
clock modes of operation, along with complete Y.1731 OAM performance monitoring capabilities.
The VSC8257-01 device provides a complete suite of on-chip instrumentation including built-in self-test
(BIST) functions, line-side and client-side circuit loopbacks, pattern generation, and error detection. Its
highly flexible clocking options support LAN and WAN operation using a single 156.25 MHz reference
clock rate. Synchronous Ethernet (SyncE) and failover switching for protection routing are also
supported.
The VSC8257-01 device delivers excellent jitter attenuation with low power. It is well-suited for SFP+
based optical modules and direct-attach copper cabling as well as challenging backplane interface
applications. As a KR repeater it supports 10 GbE LAN, 10 Gb WAN, 40 GbE (4 x 10G), as well as 1 Gb
Ethernet.
2.1
Highlights
The following standards are supported by the device:
•
•
•
•
•
•
•
•
•
IEEE Standard 1588v2 (IEEE 1588-2008, Version 2), Precision Clock Synchronization Protocol for
Networked Measurement and Control Systems
ITU Recommendation G.8013/Y.1731, 2013, OAM Functions and Mechanisms for Ethernet-based
Networks
IEEE Standard 802.3ae-2002, Telecommunications and Information Exchange between Local and
Metropolitan Area Networks, 10 Gbps Ethernet over fiber for LAN (10GBASE-SR, -LR, -ER, -LX4)
and WAN (10GBASE-SW, -LW, and -EW)
IEEE Standard 802.3ap-2007, Backplane Ethernet (1 and 10 Gbps over printed circuit boards)
SFF-INF-8074i MSA for 1GbE SFP, Revision 1.0, 2001
SFF-INF-8077i MSA for XFP, 2005, Specification for 10 Gbps Small Form Factor 10G Pluggable
(XFP) Module supporting SONET OC-192 and G.709 (OTU-2), and 10 Gbps Ethernet
SFF-8431 MSA Specification for SFP+, 2009, High- and Low-speed electrical and management
interface specifications for enhanced Small Form Factor Pluggable modules and hosts
ITU-T G.8261/Y.1361, 2013, Timing and Synchronization Aspects in Packet Networks, Synchronous
Ethernet (SyncE)
ITU-T G.8262/Y.1362, 2012, Timing Characteristics of a Synchronous Ethernet (SyncE) Slave Clock
Data rates supported include:
•
•
•
Ethernet LAN 10.3125 Gbps, Ethernet WAN 9.95328 Gbps, and Ethernet 1.25 Gbps for line side
and 10.3125 Gbps and 1.25 Gbps for host side
OTN OTU2 (10.709 Gbps), OTU1e (11.049 Gbps), and OTU2e (11.095 Gbps) in repeater mode only
(each host side and line side)
Support for SFP+ I/O and auto-negotiation and training for 10GBASE-KR (IEEE 802.3-2012)
backplanes
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
2
Overview
2.2
Interfaces
The VSC8257-01 device provides multiple types of interfaces supporting IEEE 802.3ae, IEEE 1588v2,
and IEEE 802.3ap with hardware-based 10GBASE-KR auto-negotiation and training.
The device meets the 1 GbE SFP and SFP+ SR/LR/ER/ZR host requirements in accordance with the
SFF MSA specifications and compensates for optical impairments in SFP+ applications and
degradations of the PCB.
The high-speed serial input receiver compensates for loss of optical and copper media performance or
margin due to inter-symbol interference (ISI). The high-speed serial transmit output features a 3-tap FIR
filter output buffer fully compliant with the 10GBASE-KR standard to provide full 10GBASE-KR support,
including 10GBASE-KR state machine, for auto-negotiation and link optimization. The transmit path
incorporates a multitap output driver to provide flexibility to meet the demanding 10GBASE-KR (IEEE
802.3ap) Tx output launch requirements.
The serial ports support 1.25 Gbps and 10 Gbps modes. Each channel consists of a receiver (Rx) and a
transmitter (Tx) subsection. Programmable reference clock inputs (HREFCK, LREFCK, and SREFCK)
support the modes along with clock and data recovery (CDR) in the Rx and Tx subsections of all
channels. Each channel of the device can be in a different mode within the limitations of the available
reference clocks, while ensuring the Rx and Tx subsections within a channel are in the same mode.
The following illustration shows a high-level block diagram.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
3
Overview
Port 0
XFI/KR/1 GbE
Port 1
XFI/KR/1 GbE
SD10G
SD10G
SD10G
SWITCH
FC/
Rate
Comp.
Buffers
FC/
Rate
Comp.
Buffers
Port 0 & 1 : 2x 1G/10G
FC/
Rate
Comp.
Buffers
FC/
Rate
Comp.
Buffers
Line LCPLL
10G
PCS
WIS
SD10G
SD10G
Port 1
SFP+/KR/
1GbE SFP
Port 0
SFP+/KR/
1GbE SFP
1G PCS
Line
MAC
WIS
1G PCS
10G
PCS
WIS
WIS
SD10G
SD10G
Port 3
SFP+/KR/
1GbE SFP
Port 2
SFP+/KR/
1GbE SFP
Serial lanes
Line
MAC
10G
PCS
1G PCS
TWS
Line
MAC
1G PCS
4 x 10G
4 x 1G
10G
PCS
TWS Master
Line
MAC
Clocking Network for Timing and Retiming including SyncE support
Elastic
Buffer
Host
MAC
Host
MAC
Elastic
Buffer
Elastic
Buffer
Host
MAC
Host
MAC
TWS Slave
Port 2 & 3 : 2x 1G/10G
4
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
Host LCPLL
1G
PCS
10G
PCS
10G
PCS
1G
PCS
1G
PCS
10G
PCS
10G
PCS
Elastic
Buffer
MDIO Slave
1588
1588
4 x 10G
4 x 1G
Serial lanes
Port 2
XFI/KR/1 GbE
SD10G
1G
PCS
SPI Slave
Support for IEEE 1588v2/1731 OAM precision timing at 1G and 10G
Compliant with IEEE 802.3ae and SFF-8431 electrical (SFI) specifications
Support for 9.95 Gbps WAN, 10.3125 Gbps LAN, and 1.25 Gbps Ethernet
Support for standard SFP+ applications
Support for 10GBASE-KR (IEEE 802.3ap) for 10G backplanes
•
•
•
•
•
Port 3
XFI/KR/1 GbE
SPI / MDIO / TWS
Features
2.3
Block Diagram
Figure 1 •
HOST
LINE
The main features of the VSC8257-01 device include:
Overview
•
•
•
•
•
•
•
•
•
•
•
2.4
Support for ITU-T recommendation G.709 (OTN) OTU2, OTU1e, and OTU2e line ratesin repeater
mode only (also known as pass-through mode)
Adaptive equalization receiver and programmable multitap transmitter pre-emphasis
Support for Extended WAN interface sublayer (eWIS)
SPI (preferred), MDIO, and two-wire serial slave management interfaces
Failover switching for protection routing (non-hitless switching)
VScope™ input signal monitoring integrated circuitry
Host-side and line-side loopbacks with BIST functions
I/O programmability for each channel: invert, amplitude, slew, pre-emphasis, and equalization
Optional forward error correction (FEC)
Flexible clocking options that enable Layer 1 support for Synchronous Ethernet
Passive copper cable support for lowest connectivity cost
Applications
Target applications for the VSC8257-01 device include switching, IP edge router connectivity, rack mount
connectivity through backplane, fiber and copper cable connectivity, and standalone server access (in
LAN on motherboard designs or separate network adapters).
•
•
•
•
Multi-port serial-to-serial signal conditioning with cross-connect
10GBASE-KR-compliant backplane transceivers
Networks requiring high-accuracy time synchronization
Multi-port XFI/10GBASE-KR to SFI/SFP+ 10 GbE switch cards, router cards, and network adapters
The following figures illustrate various device applications.
SFP+ Transceiver
10 GbE
Figure 2 •
10 GbE Line Card or NIC
Quad
10 GbE
MAC/NIC
VSC8257-01
4 × 10G
4 × 1G
4 × 10G
Figure 3 •
SFP+/XFP
SFP+/XFP
SFP+/XFP
SFP+/XFP
Backplane Equalization Application
Switch Modules
VSC8257-01
10GBASE-KR
Backplane
2.4.1
4 × 10G
4 × 1G
10G
Switch
4 × 10G
4 × 1G
IEEE 1588v2 One-Step End-to-End Transparent Clock
The time stamp block is located in PHYs and MACs with integrated PHYs that are placed on line cards. If
Microsemi 1588 PHYs are used on all ports that support IEEE 1588 one- step end-to-end transparent
clocks, the rest of the system does not need to be 1588-aware, and there is no CPU maintenance
needed once the system is set up.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
5
Overview
As all the PHYs in a system can be configured the same way, the system supports failover of 1588
masters without any CPU intervention.
This solution works for both blade systems and pizza boxes, where the devices placed on the system
side of the PHYs don’t need to be 1588-aware. This allows an easy migration path for systems that do
not support IEEE 1588, as this feature can be added by replacing existing PHYs with Microsemi 1588
PHYs on all ports.
The requirements for the rest of the system are as follows:
•
•
•
Figure 4 •
Delivery of a synchronous global timetick clock (or reference clock) to ensure that the “local time” for
all PHYs in the system progresses at the same rate.
Delivery of a global timetick load to synchronize the local time counters in each PHY.
CPU access to each PHY to set up the required configuration. This can be through MDIO, two-wire
slave, or 4-pin SPI.
Transparent Clock Line Card Application
Ethernet Line Card
System Card
Linecard Control
Processor
System Control
Processor
1G
Ethernet Port SerDes PHY
MAC
Packet
Processing
Linecard Control
Processor
Ethernet Line Card
Linecard Control
Processor
Ethernet Port
2.4.2
MAC or
Switch
Ethernet Line Card
Fabric
Packet
Processing
MAC
10G
SerDes PHY
Ethernet Port
Fabric
Adapter
IEEE 1588v2 Transparent Clock and Boundary Clock
This system uses a central 1588 engine, most likely a CPU system, together with hardware support
functions to generate sync frames (for boundary clock and ordinary clock masters). The switch fabric
needs to have the ability to redirect (and copy) PTP frames to the 1588 Engine for processing. This
system also works for pizza boxes.
The requirements for the system are as follows:
•
•
•
Delivery of a synchronous global timetick clock (or reference clock).
Delivery of a global timetick load to synchronize 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 through MDIO, two-wire slave, or 4-pin SPI.
For two-step support, a dedicated “push-out” SPI might be required, depending on the number of time
stamps that are required to be read by the CPU. A blade system may require a local CPU/FPGA to
collect the information and send it to the 1588 engine using either the control plane or the data plane. In
advanced MAC/Switch devices, this may be accomplished using an internal CPU.
Fabric must be able to detect IEEE 1588 frames and redirect some of them to the central 1588 engine.
The same solution may also be used to add Y.1731 delay measurement support. This does not require a
local CPU on the blade, but the switch fabric must be able to redirect OAM frames to a local/central OAM
processor.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
6
Overview
Figure 5 •
Boundary Clock Line Card Application
Ethernet Port
Ethernet Line Card
System Card
Ethernet Line Card
Linecard Control
Processor
System Control
Processor
Linecard Control
Processor
1G
SerDes PHY
MAC
Packet
Processing
Fabric
Packet
MAC
Processing
10G
SerDes PHY
Ethernet Port
Boundary
Clock
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
7
Functional Descriptions
3
Functional Descriptions
This section includes a functional block diagram, information on the operating modes, and descriptions of
the major functional blocks of the VSC8257-01 device.
3.1
Data Path Overview
VSC8257-01 supports a protocol-aware Ethernet mode and a protocol agnostic Ethernet-bypass mode.
Ingress and egress data flow is relative to the line-side interface.
Both the host-side and the line-side interfaces are 10G SFI, 10GBASE-KR, or SGMII. Each lane has the
following main sections.
•
•
•
•
•
•
•
•
•
•
•
•
3.1.1
Line and host PMA: The PMA section contains the high speed serial I/O interfaces, an input
equalization circuit, a 10GBASE-KR compliant output buffer and a SerDes. Additionally, the PMAs
also generate all the clocks, including the clocks required for Synchronous Ethernet application.
WIS: Contains the framing and de-framing circuits and the control and status registers to convert the
data to be IEEE 802.3ae Clause 50 WIS-compliant.
Line and host side 10GBase-R PCS: The 10GBase-R PCS section is composed of the PCS
transmit, PCS receive, block synchronization, and BER monitor processes. The PCS functions can
be further broken down into encode or decode, scramble or descramble, and gearbox functions, as
well as various test and loopback modes.
1G PCS: Consists of the 1000BASE-X/SGMII coding and auto-negotiation processes. There are two
instances per channel, one for the host and one for the line.
IEEE 1588: Contains the local time counter, analyzer, time stamp FIFO, and rewriter to support both
1-step and 2-step clock timing. This section also performs 1588 frame detection, time stamp
appending, header removal, and frame processing.
MAC: Frames data for transmission over the network before passing the frame to the physical layer
interface where it is transmitted as a stream of bits.
FIFO: Contains a rate-compensating FIFO between the line rate and the host rate. The ratecompensating FIFO is used when the MACs are disabled.
Flow Control Buffer: Performs rate compensation between the host and line interfaces when the
device MACs are enabled.
Cross connect: This cross connect allows interconnection between any channel such that link state
is not affected by a switch. Also, it can be configured to switch based on a configurable set of events.
10GBASE-KR: Supports 10GBASE-KR training and auto-negotiation. The 10GBASE-KR driver
includes programmable equalization accomplished by a three-tap finite impulse response (FIR)
structure (IEEE 802.3ap compliant). Three-tap delays are achieved by three flip-flops clocked by the
high speed serial clock (10G in 10G mode, 1 GHz in 1G mode). 10GBASE-KR auto-negotiation is
supported on either the line side or the host side, but not both sides simultaneously.
Loopbacks: Includes both system and network loopbacks to enhance engineering debugging and
manufacturing testing capability.
Management: Contains status and configuration registers, and the serial management interface
logic to access them.
Ingress and Egress Operation: Repeater (or Pass-Through) Mode
In repeater mode, data is received by the line-side interface (SFP+/1 GbE), deserialized, and passed to
the host-side serializer through an elastic buffer that absorbs phase jitter/wander. In this mode, the
transmit (serializer) clock is required to be synchronous to the incoming recovered clock. A digital
synchronization block with filtering capabilities down to the khz range is used to align the receive and
transmit clocks. As a result, the input jitter is filtered completely. Each direction (ingress and egress) is
identical.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
8
Functional Descriptions
The following table lists the interface data rates for the device’s Ethernet mode.
Table 1 •
Repeater (or Pass-through) Mode Interface Data Rates
Operating Mode
Line-side Data Rate (Gbps)
Host-Side Interface
Host-Side Data Rate (Gbps)
10G LAN
1 x 10.3125
10G LAN
1 x 10.3125
1 GbE
1 x 1.25
1 GbE
1 x 1.25
10G OTU2
1 x 10.709
OTU2
1 x 10.709
10G OTU1e
1 x 11.049
OTU1e
1 x 11.049
10G OTU2e
1 x 11.095
OTU2e
1 x 11.095
3.1.2
Ingress Operation: Ethernet Mode
Data is received by the line-side interface (SFP+/1 GbE), processed by core logic, and transmitted from
the host-side interface (SFP+/1 GbE) in the ingress or line-side receive data path.
High-speed serial data is received by the PMA. Data can be equalized and is delivered to the clock
recovery unit (CRU). The received serial data must be a 66B/64B encoded Ethernet frame at
10.3125 Gbps in 10G LAN mode, a SONET/SDH STS-192c frame at 9.953 Gbps in 10G WAN mode, or
8B/10B encoded data at 1.25 Gbps in 1 GbE mode.
In 10G WAN mode, the CRU data is processed by the WIS where 66B/64B encoded Ethernet data is
extracted from SONET/SDH STS-192c frames and overhead bytes are processed. The extracted
payload data is then processed by the 10G PCS. In 10G LAN mode, the CRU data is processed by a
10G PCS. In 1G mode, the CRU data is processed by the line-side 1G PCS. The 1G/10G PCS data can
be optionally processed by the IEEE 1588 and two MAC logic blocks.
In 10G LAN and WAN modes, data from the core is 64B/66B decoded by the host side 10G PCS logic
and serialized in the host-side serdes. In 1 GbE mode, data from the core is 8B/10B encoded by the
host-side 1G PCS logic and serialized in the host-side serdes.
3.1.3
Egress Operation: Ethernet Mode
Data is received by the host-side interface (SFP+/1 GbE), processed by core logic, and transmitted from
the line-side interface (SFP+/1 GbE) in the egress or line-side transmit data path.
In 10G mode, a clock is recovered incoming data in the host-side serdes. The data deserialized in the
host PMA and then 64B/66B-decoded in the host 10G PCS. It is then optionally processed by the
IEEE 1588 and two MAC logic blocks. The data is then 66B/64B-encoded by the line 10G PCS logic. The
data is serialized by the PMA in 10G LAN mode and transmitted from the line interface at 10.3125 Gbps.
When the WIS logic is enabled in 10G WAN mode, a SONET/SDH STS-192c frame is created using the
66B/64B-encoded data as the frame's payload. The WIS data is serialized by the PMA and transmitted
from the line interface at 9.953 Gbps.
In 1G mode, a clock is recovered from 1 GbE data in the host-side serdes. The data is 8B/10B-decoded
by the host-side 1G PCS, then optionally processed by the IEEE 1588 and two MAC logic blocks. The
data is 8B/10B-encoded by the line-side 1G PCS logic. It is serialized by the PMA and transmitted from
the line interface at 1.25 Gbps.
The following table lists the interface data rates for the device’s Ethernet mode.
Table 2 •
Ethernet Mode Interface Data Rates
Operating Mode
Line-Side Data Rate (Gbps)
Host-side Interface
Host-side Data Rate (Gbps)
10G LAN
1 x 10.3125
10G LAN
1 x 10.3125
10G WAN
1 x 9.95328
10G LAN
1 x 10.3125
1 GbE
1 x 1.25
1 GbE
1 x 1.25
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
9
Functional Descriptions
3.2
Physical Media Attachment (PMA)
The PMA section consists of receiver (Rx) and transmitter (Tx) subsections. The receiver accepts data
from the serial data input RXIN and sends the parallel data to the elastic buffer. A data rate clock also
accompanies the parallel data. The transmitter accepts parallel data from the elastic buffer and transmits
at serial data output TXOUT. A loopback at the data path is also provided to connect the Rx and the Tx
subsections.
Serial data is pre-equalized in the input buffer, and clock and data are recovered in the deserializer. A
demux then deserializes the data into a parallel core data interface. An RC PLL in the Rx subsection is
used as reference for clock and data recovery. Locked to the incoming datastream, a lane sync signal is
derived from the PLL clock, which is used for source synchronous data transmission to one or multiple
transmitters.
The Tx subsection is made up of the serializer, the output buffer, and the RC PLL. A mux then serializes
the data from the PCS or WIS to a high-speed serial stream, which is forwarded to a 3-tap filter output
buffer. The RC PLL in the Tx subsection is used to generate the high-speed clock used in the serializer.
To support different data rates, each PMA contains a flexible frequency synthesizer that generates the
necessary clocks. The PMA also has four fully programmable clock outputs, CKOUT[0:3], that may be
used to output various clock domains from the PMA.
3.2.1
Reference Clock
The VSC8257-01 device uses three differential input CML level reference clocks: LREFCK, HREFCK,
and SREFCK. LREFCK and HREFCK are required at all times and have to be synchronous. They may
be 125 MHz or 156.25 MHz. This rate must be selected at power-up using the MODE[1:0] pins. LREFCK
and HREFCK are multiplied to generate the reference clocks for all the SerDes blocks in the line and
host-side interfaces respectively.
SREFCK may be used for Synchronous Ethernet applications.
The following table shows the MODE pin settings for the various LREFCK frequencies.
Table 3 •
3.2.2
Selecting LREFCK Frequency
MODE1 Pin
MODE0 Pin
Frequency
0
0
156.25 MHz (default)
1
0
125 MHz
VScope™ Input Signal Monitoring Integrated Circuit
The VScope™ input signal monitoring integrated circuit displays the input signal before it is digitized by
the CDR. The two primary configurations are as follows:
•
Unity Gain Amplifier monitors the 10 Gbps input signals before signal processing and equalization.
VScope input signal monitoring integrated circuit acts as a virtual scope to effectively observe the
received data signal before it has been processed. The autonomous adaptive filter taps must first be
disabled and the front-end receiver must be set for operation as a linear, unity gain amplifier. In this
mode, all DFE taps are set to zero. This mode does not require an adaptive algorithm.
•
Link Monitor provides the link margin. VScope input signal monitoring integrated circuit enables
design engineers and system developers to monitor signals remotely without disrupting the data
integrity of a live data path. By monitoring the health of a given link, optical or electrical, various
types of signal degradation can be identified and corrected.
Note: The VScope input signal monitoring integrated circuit feature is only available in the 10G operation
mode.
3.2.3
10GBASE-KR
The VSC8257-01 device implements the 10GBASE-KR standard in hardware with no additional firmware
requirement for 10GBASE-KR backplane rate auto-negotiation and link training per IEEE 802.3 clause
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
10
Functional Descriptions
72 and 73. The 10GBASE-KR output driver itself may be used outside the 10GBASE-KR backplane
application and is set by programming the registers.
3.2.3.1
Rate Auto-Negotiation
The VSC8257-01 device supports auto-detection between 1.25 Gbps and 10.3125 Gbps data rates,
according to the IEEE 802.3ap Clause 73. The auto-negotiation/auto-detection feature switches the CRU
rate selection to different rates.
Rate auto-negotiation enables devices at both ends of a link segment to advertise abilities, acknowledge
receipt, and discover the common modes of operation that both devices share, and to reject the use of
operational modes that are not shared by both devices. Where more than one common mode exists
between the two devices, a mechanism is provided to allow the devices to resolve to a single mode of
operation using a predetermined priority resolution function. The auto-negotiation function allows the
devices to switch between the various operational modes in an orderly fashion, permits management to
disable or enable the auto-negotiation function, and allows management to select a specific operational
mode. The auto-negotiation function also provides a parallel detection function to allow backplane
Ethernet devices to connect to other backplane Ethernet devices that have auto-negotiation disabled and
interoperate with legacy devices that do not support Clause 73 Auto-Negotiation.
3.2.3.2
Training
The purpose of training is to establish optimal settings for the VSC8257-01 device and the link partner.
For more information about the training function, see IEEE 802.3ap Clause 72.
3.2.3.3
Output Driver
The high-speed output driver includes programmable equalization accomplished by a three-tap finite
impulse response (FIR) structure. The three-tap delays are achieved by three flip-flops clocked by a
high-speed serial clock, as shown in the following illustration. Coefficients C(–1), C(0), and C(+1) adjust
the pre-cursor, main-cursor, and post-cursor of the output waveform. The three delayed data streams,
after being properly strength adjusted by their coefficients, are summed by a summing amplifier. The
output driver meets the requirements defined in IEEE 802.3ap Clause 72.
Figure 6 •
10GBASE-KR Output Driver
DIN
T
T
T
CKIN
C –1
decode
KR_COEFF_C–1
C +1
C0
decode
decode
KR_COEFF_C+1
KR_COEFF_C0
VDD18TX
Slew
Control
Summing
Junction
decode
50 Ω
50 Ω
KR_SLEW[3:0]
TXOUTP
TXOUTN
The final output stage has 50 Ω back-termination with inductor peaking. The output slew rate is
controlled by adjusting the effectiveness of the inductors.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
11
Functional Descriptions
The test pattern for the transmitter output waveform is the square wave test pattern with at least eight
consecutive 1s. The following illustration shows the transmitter output waveform test, based on voltages
V1 through V6, ΔV2, and ΔV5.
Figure 7 •
10GBASE-KR Test Pattern
The output waveform is manipulated through the state of the coefficient C(-1), C(0), and C(+1).
3.3
Wide Area Network Interface Sublayer (WIS)
The WAN interface sublayer (WIS) is defined in IEEE 802.3ae Clause 50. The WIS block is fully
compliant with this specification. Additionally, the VSC8257-01 device offers an extended set of controls,
ports, and registers, called eWIS, to allow integration into a wider array of SONET/SDH equipment.
In addition to the SONET/SDH features addressed by WIS as defined by IEEE, most SONET/SDH
framers/mappers contain additional circuitry for implementing operation, administration, maintenance,
and provisioning (OAM&P). These framers/mappers also support special features to enable compatibility
with legacy SONET/SDH solutions. Because the eWIS leverages Microsemi’s industry leading
framer/mapper technology, it contains suitable features for standard SONET/SDH equipment. This
includes the transmit/receive overhead serial interfaces (TOSI/ROSI) commonly used for network
customization and OAM&P, support for SONET/SDH errors not contained in the WIS standard, support
for common legacy SONET/SDH implementations, and SONET/SDH jitter and timing quality.
3.3.1
Operation
WAN mode is enabled by asserting 2x0007.0 (SPI/MDIO/TWS) or wis_ctrl2.wan_mode. Status register
bit Vendor_Specific_PMA_Status_2.WAN_ENABLED_status indicates whether WAN mode is enabled or
not. It is not possible to have WAN mode in the Tx path enabled while the Rx path is disabled, or vice
versa. An “X” in the table represents a don’t care state.
Note: After WAN mode is enabled, write both bit 2 and 1 of 1xAE00 to high to reset the Tx and Rx PCS blocks
and enable valid WAN data to pass through.
The transmit portion of the WIS does the following:
•
•
•
•
Maps data from the PCS through the WIS service interface and to the SONET/SDH synchronous
payload envelope (SPE)
Generates path, line, and section overhead octets
Scrambles the frame
Transmits the frame to the PMA service interface
The receive portion of the WIS does the following:
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
12
Functional Descriptions
•
•
•
•
•
•
Receives data from the PMA service interface
Delineates octet and frame boundaries
Descrambles the frame
Processes section, line, and path overhead information that contain alarms and parity errors
Interprets the pointer field
Extracts the payload for transmittal to the PCS through the WIS service interface
The following illustration shows the WIS block diagram.
WIS Transmit and Receive Functions
Figure 8 •
WIS Service Interface
tx_data-unit
TRANSMIT PAYLOAD
MAPPING
TRANSMIT
PROCESS
GENERATE PATH
OVERHEAD & FIXED
STUFF
INSERT PATH
OVERHEAD &
FIXED STUFF
RECEIVE
PROCESS
PROCESS
PATH
DEFECTS
RECEIVE PAYLOAD
MAPPING
PROCESS PATH
OVERHEAD
CHECK B3 (BIP-8)
REMOVE PATH
OVERHEAD &
FIXED STUFF
PROCESS H1, H2
POINTER
COMPUTE B3 (BIP-8)
GENERATE LINE
OVERHEAD
rx_data-unit
PROCESS
LINE
DEFECTS
PROCESS LINE
OVERHEAD
REMOVE LINE
OVERHEAD
INSERT LINE
OVERHEAD
INSERT
SECTION
OVERHEAD
COMPUTE B2 (BIP-N)
CHECK B2 (BIP-N)
GENERATE SECTION
OVERHEAD
PROCESS SECTION
OVERHEAD
X7 + X6 + 1
SCRAMBLER
X7 + X6 + 1
DESCRAMBLER
COMPUTE B1 (BIP-8)
tx_data-group
REMOVE
SECTION
OVERHEAD
CHECK B1 (BIP-8)
PMA Service Interface
sync_bits
The following illustration shows the WIS frame structure.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
13
Functional Descriptions
eWIS Frame Structure
Figure 9 •
16, 704 Octets
576 Octets
Section
Overhead
Line
Overhead
Payload
9.58464 Gb/s
Fixed Stuffing
Path Overhead
Pointer
63
Octets
16, 640 Octets
The following illustration shows the positions of the STS-192c/STM-64 section and line overhead octets
within the WIS frame.
Figure 10 • STS-192c/STM-64 Section and Line Overhead in the WIS
576 Octets
A1
9
Octets
A1
A1
A1
A1
A1
A2
A2
A2
A2
A2
A2
B1
E1
F1
D1
D2
D3
H1
H1
H1
H1
H1
H1
H2
B2
B2
B2
B2
B2
B2
K1
K2
D4
D5
D6
D7
D8
D9
D10
D11
D12
S1
Z2
E2
H2
H2
H2
H2
H2
Bytes reserved for national use
Z0
(C1)
J0
(C1)
H3
H3
H3
H3
H3
H3
Bytes undefined/unused by IEEE802.3ae
M0
M1
Z2
The following illustration shows the path overhead octet positions.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
14
Functional Descriptions
Figure 11 • STS-192c/STM-64 Path Overhead in the WIS
J1
B3
C2
G1
Nine
Octets
F2
H4
Z3/F3
Z4/K3
N1
3.3.2
Section Overhead
The section overhead portion of the SONET/SDH frame supports frame synchronization, a tandem
connection monitor (TCM) known as the Section Trace, a high-level parity check, and some OAM&P
octets. The following table lists each of the octets including their function, specification, and related
information.
The VSC8257-01 device provides a mechanism to transmit a static value as programmed by the MDIO
interface. However, by definition, MDIO is not fast enough to alter the octet on a frame-by-frame basis.
Table 4 •
Section Overhead Functions and Recommended Values
Overhead
Octet
Function
IEEE 802.3ae
WIS Use
Recommended
Value
A1
Frame alignment
Supported
0xF6
Register (EWIS_TX_A1_A2) TOSI and
ROSI access
A2
Frame alignment
Supported
0x28
Register (EWIS_TX_A1_A2) TOSI and
ROSI access
J0
Section trace
Specified value
For more
information, see
Section Trace
(J0), page 20.
A 1-byte, 16-byte, or 64-byte trace
message can be sent using registers
WIS_Tx_J0_Octets_1_0 to
WIS_Tx_J0_Octets_15_14,
EWIS_TX_MSGLEN, or
EWIS_Tx_J0_Octets_17_16 to
EWIS_Tx_J0_Octets_63_62 and
received using registers
Z0
Reserved for
section growth
Unsupported
0xCC
Register EWIS_TX_Z0_E1 TOSI and
ROSI access.
WIS Extension
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
15
Functional Descriptions
Table 4 •
Overhead
Octet
B1
Section Overhead Functions and Recommended Values (continued)
Function
IEEE 802.3ae
WIS Use
Section error
Supported
monitoring (Section
BIP-8)
Recommended
Value
Bit interleaved
parity - 8 bits, as
specified in
T1.416
WIS Extension
Using the TOSI, the B1 byte can be
masked for test purposes. For each B1
mask bit that is cleared to 0 on the TOSI
interface, the transmitted bit is left
unchanged. For each B1 mask bit that is
set to 1 on the TOSI interface, the
transmitted bit is inverted.
Using the ROSI, the B1 error locations
can be extracted. Periodically latched
counter (EWIS_B1_ERR_CNT1EWIS_B1_ERR_CNT0) is available.
E1
Orderwire
Unsupported
0x00
Register EWIS_TX_Z0_E1 TOSI and
ROSI access.
F1
Section user
channel
Unsupported
0x00
Register EWIS_TX_F1_D1 TOSI and
ROSI access.
D1 - D3
Section data
communications
channel (DCC)
Unsupported
0x00
Register EWIS-TX_F1_D1
to
EWIS_TX_D@_D3 TOSI and ROSI
access
3.3.3
Frame Alignment (A1, A2)
The SONET/SDH protocol is based upon a frame structure which is delineated by the framing octets A1
and A2. The framing octets are defined to be 0xF6 and 0x28 respectively. In the transmit direction, all
192 A1 octets are sourced from the TX_A1 (EWIS_TX_A1_A2.TX_A1) register while the A2 octets are
sourced from the TX_A2 (EWIS_TX_A1_A2.TX_A2) register.
In the receive direction, the frame aligner monitors the input bus from the PMA and performs word
alignment. The frame alignment architecture is composed of a primary and secondary state machine.
The selected frame alignment and synchronization pattern have implications on the tolerated input BER.
The higher the input BER, the less likely the frame boundary can be found. The chances of finding the
frame boundary are improved by reducing the number of A1/A2 bytes required to be detected (using a
smaller pattern width). According to the WIS specification, the minimum for all parameters allows a signal
with an error tolerance of 10-12 to be framed.
The following illustration shows the primary synchronization state diagram.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
16
Functional Descriptions
Figure 12 • Synchronization State Diagram
power_on = TRUE + signal_fail = TRUE
HUNT
sync_start
in_HUNT
FALSE
TRUE
found_Hunt = FALSE
found_Hunt = TRUE
A1_ALIGN
in_HUNT
FALSE
found_Presync = FALSE
found_Presync = TRUE
PRESYNC
sync_start
TRUE
bad_sync_cnt = 1
bad_sync_cnt = m
SYNC
sync_start
FALSE
bad_sync_cnt = n
The following table lists the variables for the primary state diagram. The variables are reflected in
registers (EWIS_RX_FRM_CTRL1 and EWIS_RX_FRM_CTRL2 that can be alternately reconfigured.
Table 5 •
Framing Parameter Description and Values
IEEE 802.3ae IEEE 802.3ae
Parameter
Range
Name
Description
Sync_Pattern
width
Sequence of f consecutive A1s
followed immediately by a
sequence of f
consecutive A2s.
If f = 2, Sync_Pattern is
A1A1A2A2
f
Hunt_Pattern
width
Sequence of i consecutive A1s
i
Range
Default
2 to 192
0 to 16
Exceptions:
If f = 0, Sync_Pattern is
A1 + 4 MSBs of A2.
If f = 1, Sync_Pattern is
A1A1A2
2
1 to 192
1 to 16
4
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
17
Functional Descriptions
Table 5 •
Name
Framing Parameter Description and Values (continued)
IEEE 802.3ae IEEE 802.3ae
Parameter
Range
Description
Range
Default
Presync_Patte Sequence of j consecutive A1s
rn A1 width
followed immediately by a
sequence of k
consecutive A2s
j
16 to 190
1 to 16
16
If set to 0, behaves as if
set to 1.
If set to 17 to 31, behaves
as if set to 16
Presync_Patte Sequence of j consecutive A1s
rn A2 width
followed immediately by a
sequence of k
consecutive A2s
k
16 to 192
16
0 to 16
0 means only 4 MSB of
A2 are used.
If set to 17 to 31, behaves
as if set to 16
SYNC state
entry
Number of consecutive frame
boundaries
needed to be found after
entering the
PRESYNC state in order to
enter the
SYNC state
m
4 to 8
1 to 15
If set to 0, behaves as if
set to 1
4
SYNC state
exit
Number of consecutive frame
boundary location
errors detected before exiting
the SYNC state
n
1 to 8
1 to 15
If set to 0, behaves as if
set to 1
4
The following diagram shows the secondary state.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
18
Functional Descriptions
Figure 13 • Secondary SYNC State Diagram
power_on = TRUE + reset = TRUE + signal_fail = TRUE
WAIT
good_sync_cnt
bad_sync_cnt
octet_cnt
0
0
0
sync_start = TRUE
DELAY_1
in_HUNT = TRUE
in_HUNT = FALSE *
octet_cnt = (155520+f–k) *
found_Sync = TRUE
in_HUNT = FALSE *
octet_cnt = (155520+f–k) *
found_Sync = FALSE
MISSED
FOUND
good_sync_cnt
0
bad_sync_cnt ++
0
octet_cnt
bad_sync_cnt
0
good_sync_cnt ++
octet_cnt
0
UCT
UCT
DELAY_2
in_HUNT = FALSE *
octet_cnt = 155520 *
found_Sync = TRUE
in_HUNT = FALSE *
octet_cnt = 155520 *
found_Sync = FALSE
in_HUNT = TRUE
3.3.4
Loss of Signal (LOS)
WIS_STAT3.LOS alarm status is a latch-high register; back-to-back reads provide both the event as well
as status information. The LOS event also asserts register EWIS_INTR_PEND1.LOS_PEND until read.
This event can propagate an interrupt to either WIS_INTA or WIS_INTB based upon mask enable bits
EWIS_INTR_MASKA_1.LOS_MASKA and EWIS_INTR_MASKB_1.LOS_MASK.
There is no hysteresis on the LOS detection, and so it is recommended to have the system software to
implement a sliding window to check on the LOS before qualifying the presence of a signal. As an
alternative, Rx_LOS can be used from the optical module (through LOPC) to qualify the input signal. In
addition to using analog detection, digital detection such as PCS_Rx_Fault is recommended to
determine if the input signal is good.
When the near-end device experiences LOS, it is possible to automatically transmit a remote defect
indication (RDI-L) to the far-end for notification purposes. The EWIS_RXTX_CTRL.TXRDIL_ON_LOS, if
asserted, overwrites the outgoing K2 bits with the RDI-L code. In the receive path, it is possible to trigger
an AIS-L state (alarm assertion plus forcing the payload to an all ones state) upon a detection of an LOS
condition. This is accomplished by asserting EWIS_RXTX_CTRL.RXAISL_ON_LOS.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
19
Functional Descriptions
3.3.5
Loss of Optical Carrier (LOPC)
The input pin LOPC can be used by external optic components to directly assert the loss of optical power
to the physical media device. Any change in level on the LOPC input asserts register
EWIS_INTR_PEND2.LOPC_PEND until read. The current status of the LOPC input pin can be read in
register EWIS_INTR_STAT2.LOPC_STAT. The LOPC input can be active high or active low by setting
the Vendor_Specific_LOPC_Control.LOPC_state_inversion_select bit appropriately. The LOPC_PEND
bit can propagate an interrupt to either WIS_INTA or WIS_INTB based upon mask enable bits
EWIS_INTR_MASKA_2.LOPC_MASKA and EWIS_INTR_MASKB_2.LOPC_MASKB.
When the near-end device experiences LOPC, it is possible to automatically transmit a remote defect
indication (RDI-L) to the far-end to notify it of a problem. The EWIS_RXTX_CTRL.TXRDIL_ON_LOPC
register bit, if asserted, overwrites the outgoing K2 bits with the RDI-L code. In the receive path, it is
possible to force the receive framer into an LOF state, thereby squelching subsequent alarms and invalid
payload data processing. This is accomplished by asserting EWIS_RX_ERR_FRC1.RXLOF_ON_LOPC.
Similar to the LOF condition forced upon an LOPC, the EWIS_RXTX_CTRL.RXAISL_ON_LOPC can
force the AIS-L alarm assertion, plus force the payload to an all ones state to indicate to the PCS the lack
of valid data, upon an LOPC condition.
3.3.6
Severely Errored Frame (SEF)
Upon reset, the Rx WIS enters the out of frame (OOF) state with both the severely errored frame (SEF)
and loss of frame (LOF) alarms active. The SEF state is terminated when the framer enters the SYNC
state. The framer enters the SYNC state after EWIS_RX_FRM_CTRL2.SYNC_ENTRY_CNT plus 1
consecutive frame boundaries are identified. An SEF state is declared when the framer enters the out-offrame (OOF) state. The frame changes from the SYNC state to the OOF state when
EWIS_RX_FRM_CTRL2.SYNC_EXIT_CNT consecutive frames with errored frame alignment words are
detected. The SEF alarm condition is reported in WIS_STAT3.SEF.
This register latches high providing a combination of interrupt pending and status information within
consecutive reads.
An additional bi-stable interrupt pending bit SEF_PEND (EWIS_INTR_PEND1.SEF_PEND) is provided
to propagate an interrupt to either WIS_INTA or WIS_INTB based upon mask enable bits SEF_MASKA
(EWIS_INTR_MASKA_1.SEF_MASKA) and SEF_MASKB (EWIS_INTR_MASKB_1.SEF_MASKB).
3.3.7
Loss of Frame (LOF)
An LOF occurs when an out of frame state persists for an integrating period of
EWIS_LOF_CTRL1.LOF_T1 frames. To provide for the case of intermittent OOFs, when not in the LOF
state, the integrating timer is not reset to zero until an in-frame condition persists continuously for
EWIS_LOF_CTRL1.LOF_T2 frames. The LOF state is exited when the in-frame state persists
continuously for EWIS_LOF_CTRL2.LOF_T3 frames. The LOF state is indicated by the
WIS_STAT3.LOF register being asserted. This register latches high, providing a combination of pending
and status information over consecutive reads.
An additional bi-stable interrupt pending bit, EWIS_INTR_PEND1.LOF_PEND, is provided to propagate
an interrupt to either WIS_INTA or WIS_INTB based upon mask enable bits
EWIS_INTR_MASKA_1.LOF_MASKA and EWIS_INTR_MASKB_1.LOF_MASKB.
When the near-end device experiences an LOF condition, it is possible to automatically transmit a
remote defect indication (RDI-L) to the far end to notify it of a problem. The
EWIS_RXTX_CTRL.TXRDIL_ON_LOF, if asserted, overwrites the outgoing K2 bits with the RDI-L code.
In the receive path, it is possible to force a AIS-L state (alarm assertion plus forcing the payload to an all
ones state) upon a detection of an LOF condition. This is accomplished by asserting
EWIS_RXTX_CTRL.RXAISL_ON_LOF.
3.3.8
Section Trace (J0)
The J0 octet often carries a repeating message called the Section Trace message. The default
transmitted message length is 16 octets whose contents are defined in WIS_TXJ0
(WIS_Tx_J0_Octets_1_0-WIS_Tx_J0_Octets_15_14). If no active message is being broadcast, a default
section trace message is transmitted. This section trace message consists of 15 octets of zeros and a
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
20
Functional Descriptions
header octet formatted according to Section 5 of ANSI T1.269-2000. The header octet for the 15-octets
of zero is 0x89. The default values of WIS_TXJ0 (WIS_Tx_J0_Octets_1_0-WIS_Tx_J0_Octets_15_14)
do not contain the 0x89 value of the header octet, so software must write this value.
The J0 octet in the receive direction is assumed to be carrying a 16-octet continuously repeating section
trace message. The message is extracted from the incoming WIS frames and stored in WIS_RXJ0
(WIS_Rx_J0_Octets_1_0-WIS_Rx_J0_Octets_15_14). The WIS receive process does not delineate the
message boundaries, thus the message might appear rotated between new frame alignment events.
The VSC8257-01 device supports two alternate message types, a single repeating octet and a 64-octet
message. The message type can be independently selected for the transmit and receive direction. The
transmit direction is configured using EWIS_TX_MSGLEN.J0_TXLEN while
EWIS_RX_MSGLEN.J0_RX_LEN configures the receive path.
When the transmit direction is configured for a 64-octet message, the first 16 octets are programmed in
WIS_TXJ0 (WIS_Tx_J0_Octets_1_0-WIS_Tx_J0_Octets_15_14), while the 48 remaining octets are
programmed in EWIS_TXJ0 (EWIS_Tx_J0_Octets_17_16-EWIS_Tx_J0_Octets_63_62). Likewise, the
first 16 octets of the receive message are stored in WIS_RXJ0 (WIS_Rx_J0_Octets_1_0WIS_Rx_J0_Octets_15_14), while the other 48 octets are stored in EWIS_RXJ0
(EWIS_Rx_J0_Octets_17_16-EWIS_Rx_J0_Octets_63_62). The receive message is updated every
125 µs with the recently received octet. Any persistency or message matching is expected to take place
within the station manager.
3.3.9
Reserved for Section Growth (Z0)
The WIS standard does not support the Z0 octet and requires transmission of 0xCC in the octet
locations. A different Z0 value can be transmitted by configuring EWIS_TX_Z0_E1.TX_Z0. The TX_Z0
default is 0xCC.
3.3.10
Scrambling/Descrambling
The transmit signal (except for row 1 of the section overhead) is scrambled according to the standards
when register bit EWIS_TXCTRL2.SCR is asserted, which is the default state. When deasserted, the
scrambler is disabled.
The receive signal descrambler is enabled by default. The descrambler can be bypassed by deasserting
register bit EWIS_RX_CTRL1.DSCR_ENA.
Enabling loopback H4 and turning off the WIS scrambler and descrambler may yield an interesting data
point when debugging board setups. The CRU in the ingress PMA path would not have enough edge
transitions in the data to reliably recover the clock if the chip were receiving non-scrambled data. The
same would be true for any far-end device connected to the egress PMA if the scrambler were turned off.
The WIS scrambler and descrambler should be left on under normal operating conditions.
3.3.11
Section Error Monitoring (B1)
The B1 octet is a bit interleaved parity-8 (BIP-8) code using even parity calculated over the previous
STS-192c frame, post scrambling. The computed BIP-8 is placed in the following outgoing SONET frame
before scrambling.
In the receive direction, the incoming frame is processed, and a BIP-8 is calculated. The calculated value
is then compared with the B1 value received in the following frame. The difference between the
calculated and received octets are accumulated into the WIS_B1_CNT register. This counter rolls over
after the maximum count. This counter is cleared upon device reset.
The EWIS_B1_ERR_CNT1 and EWIS_B1_ERR_CNT0 registers provide a count of the number of
received B1 parity errors. This register is updated with the internal count value upon a PMTICK condition,
after which the internal counter is reset to zero. When the counter is nonzero, the
EWIS_INTR_PEND2.B1_NZ_PEND event register is asserted until read. A non-latch high version of this
event, EWIS_INTR_STAT2.B1_NZ_STAT, is also available. This event can propagate an interrupt to
either WIS_INTA or WIS_INTB based upon mask enable bits EWIS_INTR_MASKA_2.B1_NZ_MASKA
and EWIS_INTR_MASKB_2.B1_NZ_MASKB.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
21
Functional Descriptions
The B1_ERR_CNT can optionally be configured to increment on a block count basis, a maximum
increment of 1 per errored frame regardless of the number of errors received. This mode is enabled by
asserting EWIS_CNT_CFG.B1_BLK_MODE.
3.3.12
Section Orderwire (E1)
The WIS standard does not support the E1 octet and requires transmission of 0x00 in the octet location.
A different E1 value can be transmitted by configuring EWIS_TX_Z0_E1.TX_E1 whose default is 0x00.
3.3.13
Section User Channel (F1)
The WIS standard does not support the F1 octet and requires transmission of 0x00 in the octet location.
A different F1 value can be transmitted by configuring EWIS_TX_F1_D1.TX_F1 whose default is 0x00.
3.3.14
Section Data Communication Channel (DCC-S)
The WIS standard does not support the DCC-S octets and requires transmission of 0x00 in the octet
locations. Different DCC-S values can be transmitted by configuring EWIS_TX_F1_D1.TX_D1,
EWIS_TX_D2_D3.TX_D2, and EWIS_TX_D2_D3.TX_D3, all of which default to 0x00.
3.3.15
Reserved, National, and Unused Octets
The VSC8257-01 device transmits 0x00 for all reserved, national, and unused overhead octets.
3.3.16
Line Overhead
The line overhead portion of the SONET/SDH frame supports pointer interpretation, a per channel parity
check, protection switching information, synchronization status messaging, far-end error reporting, and
some OAM&P octets.
The VSC8257-01 device provides a mechanism to transmit a static value as programmed by the MDIO
interface. However, by definition, MDIO is not fast enough to alter the octet on a frame-by-frame basis.
The following table lists each of the octets including their function, specification, and related information.
Table 6 •
Line Overhead Octets
Octet
Number
Function
IEEE 802.3AE
Recommended
Value
H1-H2
Pointer
Specified value
SONET mode:
STS-1: 0x62, 0x0A
STS-n: 0x93, 0xFF
SDH mode:
STS-1: 0x6A, 0x0A
STS-n: 0x9B, 0xFF
Registers
EWIS_TX_C2_H1.TX_H1 and
EWIS_TX_H2_H3.TX_H2 TOSI
and ROSI access.
H3
Pointer action
Specified value
0x00
Register
EWIS_TX_H2_H3.TX_H3 TOSI
and ROSI access
WIS Extension
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
22
Functional Descriptions
Table 6 •
Octet
Number
Line Overhead Octets (continued)
Function
IEEE 802.3AE
Recommended
Value
WIS Extension
B2
Line error monitoring (Line Supported
BIP-1536)
BIP-8, as specified
in T1.416
Using the TOSI, the B2 bytes can
be masked for test purposes.
For each B2 mask bit that is
cleared to 0 on the TOSI
interface,
the transmitted bit is left
unchanged.
For each B2 mask bit that is set
to 1 on the TOSI interface,
the transmitted bit is inverted.
Using the ROSI, the B2 error
locations can be extracted.
Periodically latched counter
(EWIS_B1_ERR_CNT1EWIS_B1_ERR_CNT0)
is available
K1, K2
Automatic protection
For more
information about
K2 encoding, see
Table 7, page 25.
Registers
EWIS_TX_G1_K1.TX_K1 and
EWIS_TX_K1_F2.TX_K2
TOSI and ROSI access
D4–D12
Line data communications Unsupported
channel (DCC)
0x00
Registers EWIS_TX_D4_D5 and
EWIS_TX_D6_H4 TOSI and
ROSI access
S1
Synchronization
messaging
Unsupported
0x00
Register
EWIS_TX_S1_Z1.TX_S1 TOSI
and ROSI access
Z1
Reserved for line growth
Unsupported
0x00
Register
EWIS_TX_S1_Z1.TX_Z1 TOSI
and ROSI access
M0/M1
STS-1/N line remote error M0: unsupported
M1: supported
0x00/number of
detected
B2 errors in the
receive path,
as specified in
T1.416
TOSI and ROSI access. The
device supports a mode that uses
only M1 to back report REI-L
(EWIS_MODE_CTR.REI_MODE
= 0), and another mode that uses
both M0 and M1 to back report
REI-L
(EWIS_MODE_CTR.REI_MODE
= 1)
E2
Orderwire
Unsupported
0x00
Register
EWIS_TX_Z2_E2.TX_E2 TOSI
and ROSI access
Z2
Reserved for line growth
Unsupported
0x00
Register
EWIS_TX_Z2_E2.TX_E2 TOSI
and ROSI access
3.3.16.1
Specified value
Line Error Monitoring (B2)
The B2 octet is a BIP-8 value calculated over each of the previous STS-1 channels excluding the section
overhead and pre-scrambling. As the B2 octet is calculated on an STS-1 basis, there are 192 B2 octets
within an STS-192/STM-64 frame. Each of the 192 calculated BIP-8 octets are then placed in the
outgoing SONET/SDH frame.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
23
Functional Descriptions
Note: For SONET mode, when the number of errors detected in the B2 octet of a receive frame is greater than
255, the total count of detected errors is transmitted in more than one frame. Even when no B2 errors are
detected in subsequent frames, the number of detected B2 errors going into an accumulator will be
limited to 255 if more than 255 errors are detected in a frame. The Tx framer pulls the REI-L count out of
the accumulator when REI-L is transmitted to be compliant with T1-105.
In the receive direction, the incoming frame is processed, a per STS-1 BIP-8 is calculated (excluding
section overhead and after descrambling), and then compared to the B2 value in the following frame.
Errors are accumulated in the WIS_B2_CNT1 and WIS_B2_CNT0 registers. This counter is nonsaturating and so rolls over after its maximum count. The counter is cleared only on device reset.
An additional 32-bit B2 error counter is provided in B2_ERR_CNT (EWIS_B2_ERR_CNT1 and
EWIS_B2_ERR_CNT0), which is a saturating counter and is latched and cleared based upon a PMTICK
event. Errors are accumulated from the previous PMTICK event. When the counter is nonzero, the
EWIS_INTR_PEND2.B2_NZ_PEND event register is asserted until read. A non-latch high version of this
event is available in EWIS_INTR_STAT2.B2_NZ_STAT. This event can propagate an interrupt to either
WIS_INTA or WIS_INTB, based on mask enable bits EWIS_INTR_MASKA_2.B2_NZ_MASKA and
EWIS_INTR_MASKB_2.B2_NZ_MASKB.
The B2_ERR_CNT can optionally be configured to increment on a block count basis, a maximum
increment of 1 per errored frame regardless of the number of errors received. This mode is enabled by
asserting EWIS_CNT_CFG.B2_BLK_MODE.
It is possible that two sets of B2 bytes (from two SONET/SDH frames) are received by the Rx WIS logic
in a period of time when only one M0/M1 octet is transmitted. In this situation, one of the two B2 error
counts delivered to the Tx WIS logic is discarded. This situation occurs when the receive data rate is
faster than the transmit data rate. Similarly, when the transmit data rate is faster than the receive data
rate, a B2 error count is not available for REI-L insertion into the M0/M1 octets of the transmitted
SONET/SDH frame. A value of zero is transmitted in this case. This behavior is achieved by using a
FIFO to transfer the detected B2 error count from the receive to transmit domains.
A FIFO overflow or underflow condition is not considered an error. A FIFO overflow or underflow
eventually occurs unless the transmit and receive interfaces are running at the same average data rate.
Because the received and transmitted frames can differ by, at most, 40 ppm (±20 ppm) and still meet the
industry standards, this “slip” can happen no more often than once every 3.1 seconds.
3.3.16.2
APS Channel and Line Remote Defect Identifier (K1, K2)
The K1 and K2 octets carry information regarding automatic protection switching (APS) and line remote
defect identifier (RDI-L). The K1 octet and the most significant five bits of the K2 octet contain the APS
channel information. The transmitted values can be configured at EWIS_TX_G1_K1.TX_K1 and
EWIS_TX_K2_F2.TX_K2. The default values of all zeros are compliant with the WIS standard.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
24
Functional Descriptions
The three least significant bits within the K2 octet carry the RDI-L encoding, as defined by section 7.4.1
of ANSI T1.416-1999 and as shown in the following table.
Table 7 •
K2 Encoding
Indicator
K2 Value for Bits
6, 7, and 8
Interpretation
RDI-L
110
Remote error indication.
For the receive process, an RDI-L defect occurs after a programmable number of
RDI-L signals are received in contiguous frames and is terminated when no RDIL is received for the same number of contiguous frames.
An RDI-L can be forced by asserting EWIS_RX_ERR_FRC1.FRC_RX_RDIL.
For the transmit process, the WIS standard does not indicate when or how to
transmit RDI-L. There is an option to transmit K2 by programming it through the
TOSI, by programming it using the K2_TX MDIO register, or by programming it
based on the contents of the K2_TX register with bits 6, 7, and 8 modified
depending on the status of the following:
LOPC, LOS, LOF, AIS-L and their associated transmit enable bits enable bits
TXRDIL_ON_LOPC, TXRDIL_ON_LOS, TXRDIL_ON_LOF and
TXRDIL_ON_AISL in register EWIS_RXTX_CTRL.
AIS-L
111
Alarm indication signal (line).
For the receive process, this is detected based on the settings of the K2 byte.
When AIS-L is detected, the WIS link status is down and WIS_STAT3.AISL is set
high.
This also contributes to errored second (ES) and severally errored second (SES)
reports.
For standard WIS operation, this is never transmitted.
Idle (normal)
000
Unless RDI-L exists, the standard WIS transmits IDLE.
Although the transmission of RDI-L is not explicitly defined within the WIS standard, the VSC8257-01
device allows the automatic transmission of RDI-L upon the detection of LOPC, LOS, LOF, or AIS-L
conditions. These features are enabled by asserting TXRDIL_ON_LOPC, TXRDIL_ON_LOS,
TXRDIL_ON_LOF and TXRDIL_ON_AISL in register EWIS_RXTX_CTRL.
Note: The RDI-L code of 110 is transmitted by the DUT only when Rx AIS-L is asserted. For example, if AIS-L
is detected by the DUT for five continuous frames in the Rx direction, then the RDI-L code is transmitted
for five frames in the Tx direction, not 20 frames as stated in the ANSI T1.105 specification.
The VSC8257-01 device can force an RDI-L condition independent of the K2 transmit value by asserting
EWIS_TXCTRL2.FRC_TX_RDI. Likewise, an AIS-L condition can be forced by asserting
EWIS_TXCTRL2.FRC_TX_AISL. If both conditions are forced, the AIS-L value is transmitted.
In the receive direction, the RDI-L alarm (K2[6:8] = 110, using SONET nomenclature) and the AIS-L
alarm (K2[6:8] = 111, using SONET nomenclature) are not asserted until the condition persists for a
programmable number of contiguous frames. This value is programmable at
EWIS_RX_ERR_FRC1.APS_THRES and is typically set to values of 5 or 10. The AIS-L is detected by
the receiver after the programmable number of frames is received, and results in the reporting of AIS-P.
The WIS standard defines WIS_STAT3.RDIL and WIS_STAT3.AISL as a read only, latch-high register, so
a read of a one in this register indicates that an error condition occurred since the last read. A second
read of the register provides the current status of the event as to whether the alarm is currently asserted.
EWIS_INTR_PEND1.RDIL_PEND and EWIS_INTR_PEND1.AISL_PEND assert whenever the RDI-L or
AIS-L state changes (assert or deassert). These interrupts have associated mask enable bits,
EWIS_INTR_MASKA_1.RDIL_MASKA, EWIS_INTR_MASKB_1.RDIL_MASKB,
EWIS_INTR_MASKA_1.AISL_MASKA and EWIS_INTR_MASKB_1.AISL_MASKB, which, if enabled,
propagate an interrupt to the WIS_INTA/B pins.
For test purposes, the VSC8257-01 device can induce an RDI-L condition in the receive direction
independent of the received K2 value by asserting EWIS_RX_ERR_FRC1.FRC_RX_RDIL. Likewise, an
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
25
Functional Descriptions
AIS-L condition can be forced in the receive direction by asserting
EWIS_RX_ERR_FRC1.FRC_RX_AISL.
3.3.16.3
Line Data Communications Channel (D4 to D12)
The WIS standard does not support Line Data Communications Channel (L-DCC) octets (D4-D12) and
recommends transmitting 0x00 within these octets. The D4-D12 transmitted values can be programmed
in registers EWIS_TX_D4_D5 - EWIS_TX_D12_Z4. The register defaults are all 0x00. The receive LDCC octets are only accessible through the ROSI port.
3.3.16.4
STS-1/N Line Remote Error Indication (M0 and M1)
The M0 and M1 octets are used for back reporting the number of B2 errors received, known as remote
error indication (REI-L). The value in this octet comes from the B2 error FIFO, as discussed with the B2
octet. The WIS standard does not support the M0 octet and recommends transmitting 0x00 in place of
the M0 octet. However, the WIS standard supports the M1 octet in accordance with T1.416.
Two methods for back-reporting exist and are controlled by EWIS_TXCTRL2.SDH_TX_MODE. Because
a single frame can contain up to 1536 B2 errors while the M1 byte alone can only back report a maximum
of 255 errors, a discrepancy exists. When G707_2000_REIL is deasserted, only the M1 byte is used and
a maximum of 255 errors are back-reported. When G707_2000_REIL is asserted, two octets per frame
are used for back reporting, the M1 octet and the M0 octet (not the first STS-1 octet, but the second STS1 octet). In this mode, a total of 1536 errors can be back-reported per frame.
In the receive direction the VSC8257-01 device detects and accumulates errors according to the
EWIS_MODE_CTRL.REI_MODE setting. The VSC8257-01 device deviates from the G.707 standard by
not interpreting REI-L values greater than 1536 as zero. The WIS standard defines a 32-bit REI-L
counter in registers WIS_REIL_CNT1 and WIS_REIL_CNT0. This counter is non-saturating and so rolls
over after its maximum count. The counter is cleared only on device reset.
An additional 32-bit REI-L counter is provided in registers EWIS_REIL_CNT1 and EWIS_REIL_CNT0,
which is a saturating counter and is latched and cleared based upon a PMTICK event. Errors are
accumulated since the previous PMTICK event. When the counter is nonzero, the
EWIS_INTR_PEND2.REIL_NZ_PEND event register is asserted until read. A non-latch high version of
this event EWIS_INTR_STAT2.REIL_NZ_STAT is also available. This event can propagate an interrupt
to either WIS_INTA or WIS_INTB based upon mask enable bits
EWIS_INTR_MASKA_2.REIL_NZ_MASKA and EWIS_INTR_MASKB_2.REIL_NZ_MASKB.
The REIL_ERR_CNT can optionally be configured to increment on a block count basis, a maximum
increment of 1 per errored frame regardless of the number of errors received. This mode is enabled by
asserting EWIS_CNT_CFG.REIL_BLK_MODE.
3.3.16.5
Synchronization Messaging (S1)
The S1 octet carries the synchronization status message and provides synchronization quality measures
of the transmission link in the least significant 4 bits. The WIS standard does not support the S1 octet and
requires the transmission of a 0x0F within the S1 octet. A value other than 0x0F can be programmed in
TX_S1 (2xE61F).
3.3.16.6
Reserved for Line Growth (Z1 and Z2)
The WIS standard does not support the Z1 or Z2 octets and requires the transmission of 0x00 in their
locations. Different Z1 and Z2 values can be transmitted by programming the values at
EWIS_TX_S1_Z1.TX_Z1 and EWIS_TX_Z2_E2.TX_Z2 respectively.
3.3.16.7
Orderwire (E2)
The WIS standard does not support the E2 octet and recommends transmitting 0x00 in place of the E2
octet. A value other than 0x00 can be transmitted by programming the intended value at
EWIS_TX_Z2_E2.TX_E2.
3.3.17
SPE Pointer
The H1 and H2 octets are used as a pointer within the SONET/SDH frame to locate the beginning of the
path overhead and the beginning of the synchronous payload envelope (SPE). Within SONET/SDH the
SPE can begin anywhere within the payload area, however IEEE 802.3ae specifies that a transmitted
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
26
Functional Descriptions
SPE must always be positioned solely within a single SONET/SDH frame. The constant pointer value of
522 decimal (0x20A) must be contained in the first channel’s H1 and H2 octets. Together these
conditions result in the H1 and H2 octets being 0x62 and 0x0A, respectively. These are the default
values of EWIS_TX_C2_H1.TX_H1 and EWIS_TX_H2_H3.TX_H2. Programming these registers with
alternate values does not alter the positioning of the SPE, but it might induce a loss of pointer (LOP-P) at
the far-end, or at least prevent the far-end from extracting the proper payload. Furthermore, the WIS
standard specifies the frame structure be a concatenated payload. For this reason, the H1 and H2 octets
in channels 2 through 192 contain the concatenation indicator.
The VSC8257-01 device supports forcing the loss of pointer (LOP-P) and path alarm indication signal
(AIS-P) state.
The WIS standard specifies that a 0×00 be transmitted in the H3 octet. An alternate value can be
transmitted by programming EWIS_TX_H2_H3.TX_H3.
The WIS specification does not limit the pointer position within the receive SONET/SDH frame to allow
interoperability to other SONET/SDH equipment. In addition to supporting the required SONET pointer
rules, the VSC8257-01 device pointer interpreter optionally supports SDH pointers. This is selectable
using the EWIS_MODE_CTRL.RX_SS_MODE bit. The following table shows the differences between
SONET and SDH modes.
SONET/SDH Pointer Mode Difference
Table 8 •
SONET
SDH
SS bits are ignored by the device
pointer interpreter and not used.
SS bits are set to 10 and are checked by the device
pointer interpreter to determine the pointer type
All 192 bytes of H1 and H2 are
checked by the pointer interpreter to
determine the pointer type.
The first 64 bytes are checked by the device pointer
interpreter to determine the pointer type (first Au-4 of
an AU-4-64c)
Uses '8 out of 10' GR-253-core
objective increment/decrement rule
Uses majority detect increment/decrement rule
The H1 and H2 octets combine to form a word with several fields as described in the following section.
3.3.17.1
Bit Designations within Payload Pointer
The N bits [15:12] carry a new data flag (NDF). This mechanism allows an arbitrary change in the
location of the payload. NDF is indicated by at least three out of the four N bits matching the code ‘1001’
(NDF enabled). Normal operation is indicated by three out of the four N bits matching the code ‘0110’
(normal NDF).
The last ten bits of the pointer word (D bits and I bits) carry the pointer value. The pointer value has a
range from 0 to 782 that indicates the offset between the first byte after the H3 byte and the first byte of
the SPE.
The SS bits are located in bits 11 and 10 and are unused in SONET mode. In SDH mode, these bits are
compared with pattern ‘10’, and the pointer is considered invalid if it does not match.
Because the VSC8257-01 device only supports concatenated frames, only the first pair of bytes (H1, H2)
are called the primary pointer and have a normal format. The rest of the H1/H2 bytes contain the
concatenation indication (CI). The format for the CI is NDF enabled with a pointer value of all ones.
Table 9 •
16-bit Designations within the Payload Pointer
H1
H2
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
N
N
N
N
S
S
I
D
I
D
I
D
I
D
I
D
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
27
Functional Descriptions
3.3.17.2
Pointer Types
The VSC8257-01 device supports five different pointer types as described in the following table. A
normal pointer indicates the current pointer, a new data flag indicates a new pointer location, and an AIS
pointer indicates AIS. The pointer increment and pointer decrement mechanism adjusts the frequency
offset between the frame overhead and SPE. A pointer increment is indicated by a normal NDF that has
the currently accepted pointer with the I bits inverted. A pointer decrement is indicated by a normal NDF
that has the currently accepted pointer with D bits inverted.
Table 10 •
H1/H2 Pointer Types
Pointer Type
nnnn Value
Pointer Value
SS Bits
Normal
Three out of the four bits
matching 0110
0 to 782
Matching in SDH mode,
ignored in SONET mode
New Data Flag (NDF)
Three out of the four bits
matching 1001
0 to 782
Matching in SDH mode,
ignored in SONET mode
AIS Pointer
1111
1111 1111 11
11
Pointer increment
Three out of the four bits
matching 0110
Current pointer with I bits
inverted
Matching in SDH mode,
ignored in SONET mode
Pointer decrement
Three out of the four bits
matching 0110
Current pointer with D bit
inverted
Matching in SDH mode,
ignored in SONET mode
The following table lists the concatenation types.
Table 11 •
Concatenation Types
Pointer Type
nnnn Value
Pointer Value
SS Bits
Normal
Three out of the four bits
matching 0110
1111 1111 11
Matching in SDH mode,
ignored in SONET mode
AIS
Pointer value, nnnn value, and SS bits are the same as the AIS pointer.
Invalid
Any other concatenation, other than normal CI, or AIS CI
3.3.17.3
Pointer Adjustment Rule
The pointer interpreter adjusts the current pointer value according to rules listed in Section 9.1.6 of ANSI
T1.105-1995. In addition, no increment/decrement is accepted for at least three frames following an
increment/decrement or NDF operation.
3.3.17.4
Pointer Increment/Decrement Majority Rules
In SONET mode, the pointer interpreter uses more restrictive GR-253-CORE objective rules, as follows:
•
•
An increment is indicated by eight or more bits matching non-inverted D bits and inverted I bits.
A decrement is indicated by eight or more bits matching non-inverted I bits and inverted D bits.
In SDH mode, the majority rules are:
•
•
•
3.3.17.5
An increment is indicated by three or more inverted I bits and two or fewer inverted D bits.
A decrement is indicated by three or more inverted D bits and two or fewer inverted I bits.
If three or more D bits are inverted and three or more I bits are inverted, no action is taken.
Pointer Interpretation States
The pointer interpreter algorithm for state transitions can be modeled as a finite state machine with three
states, as shown in the following figure. The three states are normal (NORM), loss of pointer (LOP), and
alarm indication state (AIS).
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
28
Functional Descriptions
Figure 14 • Pointer Interpretation States Diagram
a, b, e
NORM
a, b
b
c
d
c
AIS
LOP
d
The following table lists the pointer interpretation state transitions.
Table 12 •
Pointer Interpreter State Transitions
Transitions
State
Descriptions
Required Persistence
a
NORM to NORM
= .
NDF enabled with pointer in range (0 to 782). SS bit
match (if enabled).
1 Frame
b
NORM to NORM
LOP to NORM
AIS to NORM
=.
NDF disabled (NORM pointer) with the same pointer
value in range (0 to 782). SS bit match (if enabled).
3 Frames
c
NORM to AIS
LOP to AIS
=.
AIS pointer (0xFFFF).
3 Frames
d
NORM to LOP
AIS to LOP
Anything other than transitions b and c or NDF enabled 8 Frames
(transition a), or AIS pointer when not in AIS state, or
NORM pointer when not in NORM state, or NORM
pointer with pointer value not equal to current, or
increment/decrement, or CONC pointer, or SS bit
mismatch (if comparison is enabled).
e
Justification
Valid increment or decrement indication
3.3.17.6
1 Frame
Valid Pointer Definition for Interpreter State
During an AIS state, only an AIS pointer is a valid pointer. In NORM state, several definitions of “valid
pointer” for purpose of LOP detection are possible according to GR-253-CORE. The VSC8257-01 device
follows the GR-253-CORE intended definition, but adds a single normal pointer that exactly matches the
current valid pointer value.
Any change in the AIS state is reflected in the alarm bit WIS_STAT3.AISP. This latch-high register reports
both the event and status information in consecutive reads. The EWIS_INTR_PEND1.AISP_PEND bit
remains asserted until read. This event can propagate an interrupt to either WIS_INTA or WIS_INTB,
based on mask enable bits EWIS_INTR_MASKA_1.AISP_MASKA and
EWIS_INTR_MASKB_1.AISP_MASKB.
Similarly, any change in the LOP state is reflected in the alarm bit WIS_STAT3.LOPP. This latch-high
register reports both the event and status information in consecutive reads. The
EWIS_INTR_PEND1.LOPP_PEND bit remains asserted until read. This event can propagate an
interrupt to either WIS_INTA or WIS_INTB, based upon the mask enable bits
EWIS_INTR_MASKA_1.LOPP_MASKA and EWIS_INTR_MASKB_1.LOPP_MASKB.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
29
Functional Descriptions
3.3.18
Path Overhead
The path overhead portion of the SONET/SDH frame supports an end-to-end trace identifier, a payload
parity check, a payload type indicator, a status indicator, and a user channel. The following table lists
each of the octets, including their function.
Note: The VSC8257-01 device provides a mechanism to transmit a static value as programmed by the MDIO
interface. However, by definition, MDIO is not fast enough to alter the octet on a frame-by-frame basis.
Extended WIS TOSI and ROSI do not support path overhead.
Table 13 •
STS Path Overhead Octets
Overhead
Octet
Function
J1
Path trace message
Specified value See “Overhead
A 1-, 16-, or 64-byte trace message can
Octet (J1),” below. be sent using
registers
(EWIS_TX_MSGLEN.J1_TXLEN,
WIS_Tx_J1_Octets_1_0WIS_Tx_J1_Octets_15_14, and
EWIS_Tx_J1_Octets_17_16EWIS_Tx_J1_Octets_63_62);
and received using registers
(EWIS_RX_MSGLEN.J1_RX_LEN,
WIS_Rx_J1_Octets_1_0WIS_Rx_J1_Octets_15_14,
EWIS_Rx_J1_Octets_17_16EWIS_Rx_J1_Octets_63_62).
TOSI and ROSI access.
B3
Path error monitoring
(path BIP-8)
Supported
C2
Path signal label
Specified value 0x1A
Register (EWIS_TX_C2_H1.C2).
Supports persistency and mismatch
detection
(EWIS_MODE_CTRL.Cs_EXP).
G1
Path status
Supported
As specified in
T1.416
Ability to select between RDI-P and
ERDI-P formats.
F2
Path user channel
Unsupported
0x00
Register (EWIS_TX_K2_F2.TX_F2).
H4
Multiframe indicator
Unsupported
0x00
Register (WEIS_TX_D6_H4.TX_H4).
Z3 - Z4
Reserved for path
growth
Unsupported
0x00
Register (EWIS_TX_D9_Z3.TX_Z3,
EWIS_TX_D12_Z4.TX_Z4).
N1
Path error monitoring
(path BIP-8)
Unsupported
0x00
Register (WEIS_TX_N1.TX_N1).
TOSI and ROSI access.
3.3.18.1
IEEE 802.3ae
WIS Use
Recommended
Value
Bit interleaved
parity - 8 bits
as specified in
T1.416
WIS Extension
Both SONET and SDH mode B3
calculation is supported.
Overhead Octet (J1)
The J1 transmitted octet contains a 16-octet repeating path trace message whose contents are defined
in WIS Tx J1s (WIS_Tx_J1_Octets_1_0- WIS_Tx_J1_Octets_15_14). If no active message is being
broadcast, a default path trace message is transmitted, consisting of 15 octets of zeros and a header
octet formatted according to Section 5 of ANSI T1.269-2000. The header octet for the 15- octets of zero
is 0x89. The default values of WIS Tx J1s do not contain the 0x89 value of the header octet, thus
software must write this value.
The J1 octet in the receive direction by default is assumed to be carrying a 16-octet continuously
repeating path trace message. The message is extracted from the incoming WIS frames and presented
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
30
Functional Descriptions
in WIS Rx J1s (WIS_Rx_J1_Octets_1_0- WIS_Rx_J1_Octets_15_14). The WIS receive process does
not delineate the message boundaries, thus the message might appear rotated between new frame
alignment events.
The VSC8257-01 device supports two alternate message types, a single repeating octet and a 64-octet
message. The message type can be independently selected for the transmit and receive direction. The
transmit direction is configured using EWIS_TX_MSGLEN.J1_TXLEN while
EWIS_RX_MSGLEN.J1_RX_LEN configures the receive path.
When the transmit direction is configured for a 64-octet message, the first 16 octets are programmed in
WIS_Tx_J1_Octets_1_0-WIS_Tx_J1_Octets_15_14 while the 48 remaining octets are programmed in
EWIS_Tx_J1_Octets_17_16- EWIS_Tx_J1_Octets_63_62. Likewise, the first 16-octets of the receive
message are stored in J1_RXMSG (WIS_Rx_J1_Octets_1_0-WIS_Rx_J1_Octets_15_14), while the
other 48 octets are stored in EWIS_Rx_J1_Octets_17_16-EWIS_Rx_J1_Octets_63_62. The receive
message is updated every 125 µs with the recently received octet. Any persistence or message
matching is expected to take place within the station manager.
3.3.18.2
STS Path Error Monitoring (B3)
The B3 octet is a bit interleaved parity-8 (BIP-8) code, using even parity, calculated over the previous
STS-192c SPE before scrambling. The computed BIP-8 is placed in the B3 byte of the following frame
before scrambling.
In the receive direction, the incoming frame is processed and a B3 octet is calculated over the received
frame. The calculated value is then compared with the B3 value received in the following frame. The
difference between the calculated and received octets are accumulated in block (maximum increment of
1 per errored frame) fashion into a B3 error register, WIS_B3_CNT. This counter is non-saturating and so
rolls over. The counter is cleared upon a device reset.
An additional 32-bit B3 error counter is provided at B3_ERR_CNT (EWIS_B3_ERR_CNT1 and
EWIS_B3_ERR_CNT0), a saturating counter that is latched and cleared based upon a PMTICK event.
Errors are accumulated starting from the previous PMTICK event. When the counter is nonzero, the
EWIS_INTR_PEND2.B3_NZ_PEND event register is asserted until read. A non-latch high version of this
event EWIS_INTR_STAT2.B3_NZ_STAT is also available. This event may propagate an interrupt to
either WIS_INTA or WIS_INTB, based on the mask enable bits EWIS_INTR_MASKA_2.B3_NZ_MASKA
and EWIS_INTR_MASKB_2.B3_NZ_MASKB.
The B3_ERR_CNT may optionally be configured to increment on a block count basis, a maximum
increment of 1 per errored frame regardless of the number of errors received. The
EWIS_CNT_CFG.B3_BLK_MODE control bit, if asserted, places the B3_ERR_CNT counter in block
increment mode.
It is possible that two sets of B3 bytes (from two SONET/SDH frames) are received by the Rx WIS logic
in a period of time when only one G1 octet is transmitted. In this situation, one of the two B3 error counts
delivered to the Tx WIS logic is discarded. This situation occurs when the receive data rate is faster than
the transmit data rate. Similarly, when the transmit data rate is faster than the receive data rate, a B3
error count is not available for REI-P insertion into the G1 octets of the transmitted SONET/ SDH frame.
A value of zero is transmitted in this case. This behavior is achieved by using a FIFO to transfer the
detected B3 error count from the receive to transmit domains.
A FIFO overflow or underflow condition is not considered an error. A FIFO overflow or underflow
eventually occurs, unless the transmit and receive interfaces are running at the same average data rate.
Because the received and transmitted frames can differ by, at most, 40 ppm (±20 ppm) and still meet the
industry standards, this “slip” can happen no more often than once every 3.1 seconds.
3.3.18.3
STS Path Signal Label and Path Label Mismatch (C2)
The C2 octet contains a value intended to describe the type of payload carried within the SONET/SDH
frame. The WIS standard calls for a 0x1A to be transmitted. This is the default value of
EWIS_TX_C2_H1.TX_C2.
As specified in T1.416, a path label mismatch (PLM-P), register WIS_STAT3.PLMP, event occurs when
the C2 octet in five consecutive frames contain a value other than the expected one. The expected value
is set in EWIS_MODE_CTRL.C2_EXP, whose default value 0x1A is compliant with the WIS standard.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
31
Functional Descriptions
When a value of 0x00 is accepted (received for five or more consecutive frames) the unequipped path
pending, EWIS_INTR_PEND2.UNEQP_PEND, event is asserted until read. A non-latch high version of
this event EWIS_INTR_STAT2.UNEQP_STAT is also available. This event can propagate an interrupt to
either WIS_INTA or WIS_INTB, based on the mask enable bits
EWIS_INTR_MASKA_2.UNEQP_MASKA and EWIS_INTR_MASKB_2.UNEQP_MASKB.
If the accepted value is not an unequipped label (0x00) and it differs from the programmed expected
value, EWIS_MODE_CTRL.C2_EXP, then a path label mismatch, WIS_STAT3.PLMP, is asserted.
Similarly the EWIS_INTR_PEND1.PLMP_PEND event is asserted until read. This event can propagate
an interrupt to either WIS_INTA or WIS_INTB, based on the mask enable bits
EWIS_INTR_MASKA_1.PLMP_MASKA and EWIS_INTR_MASKB_1.PLMP_MASKB.
Although PLMP is not a path level defect, it does cause a change in the setting of one of the ERDI-P
codes.
3.3.18.4
Remote Path Error Indication (G1)
The most significant four bits of the G1 octet are used for back reporting the number of B3 block errors
received at the near-end. This is typically known as path remote error indication (REI-P). The value in
this octet comes from the B3 error FIFO. The WIS standard defines a 16-bit REI-P counter, register
WIS_REIP_CNT. The WIS standard defines this counter to operate as a block counter as opposed to an
individual errored bit counter. This counter is non-saturating and so rolls over after its maximum count.
The counter does not clear upon a read, but instead only upon reset as defined in the WIS specification.
When the counter is nonzero, the EWIS_INTR_PEND2.REIP_PEND event register is asserted until
read. A non-latch high version of this event EWIS_INTR_STAT2.REIP_STAT is also available. This event
may propagate an interrupt to either WIS_INTA or WIS_INTB, based on the mask enable bits
EWIS_INTR_MASKA_2.REIP_MASKA and EWIS_INTR_MASKB_2.REIP_MASKB, respectively.
An additional 32-bit REI-P counter is provided at REIP_ERR_CNT (EWIS_REIP_CNT1 and
EWIS_REIP_CNT0) which is a saturating counter and is latched and cleared based upon a PMTICK
event. Errors are accumulated since the previous PMTICK event. When the counter is nonzero, the
EWIS_INTR_PEND2.REIP_NZ_PEND event register is asserted until read. A non-latch high version of
this event EWIS_INTR_STAT2.REIP_NZ_STAT is also available. This event may propagate an interrupt
to either WIS_INTA or WIS_INTB, based on the mask enable bits
EWIS_INTR_MASKA_2.REIP_NZ_MASKA and EWIS_INTR_MASKB_2.REIP_NZ_MASKB,
respectively.
The REIP_ERR_CNT may optionally be configured to increment on a block count basis, a maximum
increment of 1 per errored frame regardless of the number of errors received. This mode is enabled by
asserting EWIS_CNT_CFG.REIP_BLK_MODE.
3.3.18.5
Path Status (G1)
In addition to back-reporting the far-end B3 BIP-8 error count, the G1 octet carries status information
from the far-end device known as path remote defect indicator (RDI-P). T1.416 allows either support of 1bit RDI-P or 3-bit ERDI-P, but indicates ERDI-P is preferred. The VSC8257-01 device supports both
modes and may be independently configured for the Rx and Tx directions by configuring
EWIS_MODE_CTRL.RX_ERDI_MODE and EWIS_TXCTRL2.ERDI_TX_MODE. ERDI-P is the default
for both directions.
Table 14 •
Path Status (G1) Byte for RDI-P Mode
G1 REI (B3)
1
2
3
Remote Error Indicator
count from B3 (0-8 value)
4
RDI-P
Reserved
Spare
5
6
Remote
Defect
Indicator
Set to 00 by transmitter Ignored by
receiver
7
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
8
32
Functional Descriptions
The following table lists the Path Status (G1) byte for ERDI-P mode.
Table 15 •
Path Status (G1) Byte for ERDI-P Mode
G1 REI (B3)
1
ERDI-P
2
3
4
Remote Error Indicator
count from B3 (0-8 value)
5
Spare
6
7
8
Enhanced Remote Defect Indicator Ignored by
(See next table)
receiver
Enhanced RDI is defined for SONET-based systems as listed in GR-253-CORE (Issue 3), reproduced
here in the following table, and as a possible enhancement of SDH-based systems (G.707/Y.1322
(10/2000) Appendix VII (not an integral part of that recommendation)). The following table lists the RDI-P
and ERDI-P Bit Settings and Interpretations.
Table 16 •
RDI-P and ERDI-P Bit Settings and Interpretations
G1 Bits 5, 6, and 7
Priority of ERDI-P Codes
Trigger
Interpretation
000/011
Not applicable
No defects
No RDI-P defect
100/111
Not applicable
Path alarm indication signal One-bit RDI-P defect
(AIS-P). The remote device
sends all ones for H1, H2,
H3, and the entire STS
SPE. Path loss of pointer
(LOP-P).
001
4
No defects
010
3
Path label mismatch (PLM- ERDI-P payload defect
P). Path loss of code group
delineation (LCD-P)
101
1
Path alarm indication signal ERDI-P server defect
(AIS-P). The remote device
sends all ones for H1, H2,
H3 and entire STS SPE.
Path loss of pointer (LOPP).
110
2
Path unequipped (UNEQERDI-P connectivity defect
P). The received C2 byte is
0x00. Path trace identifier
mismatch (TIM-P). This
error is not automatically
generated, but can be
forced using MDIO.
No ERDI-P defect
In the receive direction, with EWIS_MODE_CTRL.RX_ERDI_MODE = 0, an RDI-P defect is the
occurrence of the RDI-P signal in ten contiguous frames. An RDI-P defect terminates when no RDI-P
signal is detected in ten contiguous frames. An RDI-P event asserts
EWIS_INTR_PEND2.FERDIP_PEND until read. A non-latch high version of the far-end RDI-P status can
be found in EWIS_INTR_STAT2.FERDIP_STAT. This event may propagate an interrupt to either
WIS_INTA or WIS_INTB, based on the mask enable bits EWIS_INTR_MASKA_2.FERDIP_MASKA and
EWIS_INTR_MASKB_2.FERDIP_MASKB.
When EWIS_MODE_CTRL.RX_ERDI_MODE = 1, an ERDI-P defect is the occurrence of any one of
three ERDI-P signals in ten contiguous frames. An ERDI-P defect terminates when no ERDI-P signal is
detected in ten contiguous frames.
The 010 code triggers the latch high register bit WIS_STAT3.FEPLMP_LCDP. It also asserts
EWIS_INTR_PEND1.FEPLMP_LCDP_PEND until read. This event may propagate an interrupt to either
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
33
Functional Descriptions
WIS_INTA or WIS_INTB, based on the mask enable bits
EWIS_INTR_MASKA_1.FEPLMP_LCDP_MASKA and
EWIS_INTR_MASKB_1.FEPLMP_LCDP_MASKB, respectively.
The 101 code triggers the latch high register bit WIS_STAT3.FEAISP_LOPP. It also asserts
EWIS_INTR_PEND1.FEAISP_LOPP_PEND until read. This event may propagate an interrupt to either
WIS_INTA or WIS_INTB, based on the mask enable bits
EWIS_INTR_MASKA_1.FEAISP_LOPP_MASKA and EWIS_INTR_MASKB_1.FEAISP_LOPP_MASKB,
respectively.
The 110 code asserts the EWIS_INTR_PEND2.FEUNEQP_PEND until read. A non-latch- high version of
this register EWIS_INTR_STAT2.FEUNEQP_STAT is also available. This event may propagate an
interrupt to either WIS_INTA or WIS_INTB, based on the mask enable bits
EWIS_INTR_MASKA_2.FERDIP_MASKA and EWIS_INTR_MASKB_2.FERDIP_MASKB, respectively.
3.3.18.6
Path User Channel (F2)
The WIS standard does not support the F2 octet and recommends transmitting 0x00 in place of the F2
octet. A value other than 0x00 may be transmitted by programming the intended value at
EWIS_TX_K2_F2.TX_F2.
3.3.18.7
Multi-frame Indicator (H4)
The WIS standard does not support the H4 multi-frame octet and recommends transmitting 0x00 in place
of the H4 octet. A value other than 0x00 may be transmitted by programming the intended value at
EWIS_TX_D6_H4.TX_H4.
3.3.18.8
Reserved for Path Growth (Z3-Z4)
The WIS standard does not support the Z3-Z4 octets and recommends transmitting 0x00 in their place. A
value other than 0x00 may be transmitted by programming the intended value at
EWIS_TX_D9_Z3.TX_Z3 and EWIS_TX_D12_Z4.TX_Z4 respectively.
3.3.18.9
Tandem Connection Maintenance/Path Data Channel (N1)
The WIS standard does not support the N1 octet and recommends transmitting 0x00 in place of the N1
octet. A value other than 0x00 may be transmitted by programming the intended value at
EWIS_TX_N1.TX_N1.
3.3.18.10 Loss of Code Group Delineation
After the overhead is stripped, the payload is passed to the PCS. If the PCS block loses synchronization
and cannot delineate valid code groups, the PCS passes a loss of code group delineation (LCD-P) alarm
to the WIS. This alarm triggers the latch high register bit WIS_STAT3.LCDP. It also asserts
EWIS_INTR_PEND1.LCDP_PEND until read. This event may propagate an interrupt to either WIS_INTA
or WIS_INTB, based on the mask enable bits EWIS_INTR_MASKA_1.LCDP_MASKA and
EWIS_INTR_MASKB_1.LCDP_MASKB, respectively.
The WIS specification calls for a LCD-P defect persisting continuously for more than 3 ms to be back
reported to the far-end. Upon device reset, a LCD-P is back reported until the PCS signals that valid
code groups are being delineated. The LCD-P defect deasserts (and is not back-reported) after the
condition is absent continuously for at least 1 ms.
3.3.18.11 Reading Statistical Counters
The VSC8257-01 device contains several counters that may be read using the MDIO interface. For each
error count, there are two sets of counters. The first set is the standard WIS counter implemented
according to IEEE 802.3ae, and the second set is for statistical counts using PMTICK.
To read the IEEE 802.3ae counters, the station manager must read the most significant register of the
32-bit counter first. This read action latches the internal error counter value into the MDIO readable
registers. A subsequent read of the least significant register does not latch new values, but returns the
value latched at the time of the most significant register read.
It may be difficult to get a clear picture of the timeframes in which errors were received because the IEEE
802.3ae counters are independently latched. The PMTICK counters are all latched together, thereby
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
34
Functional Descriptions
providing a complete snapshot in time. When PMTICK is asserted, the internal error counter values are
copied into their associated registers and the internal counters are reset.
There are three methods of asserting PMTICK:
•
The station manager may asynchronously assert EWIS_PMTICK_CTRL.PMTICK_FRC to latch the
values at a given time, regardless of the EWIS_PMTICK_CTRL.PMTICK_ENA setting.
The device may be configured to latch and clear the statistical counters at a periodic interval as
determined by the timer (count) value in EWIS_PMTICK_CTRL.PMTICK_DUR. In this mode the
EWIS_PMTICK_CTRL.PMTICK_SRC must be configured for internal mode and the
EWIS_PMTICK_CTRL.PMTICK_ENA bit must be asserted. The receive path clock is used to drive
the PMTICK counter, thus the periodicity of the timer can vary during times of loss of lock and loss of
frame.
The device may be configured to latch and clear the statistical counters at the occurrence of a rising
edge detected at a GPIO pin configured as a PMTICK input pin. In this mode the
EWIS_PMTICK_CTRL.PMTICK_SRC bit must be deasserted, and the
EWIS_PMTICK_CTRL.PMTICK_ENA must be asserted. Corresponding GPIO must be configured
as the PMTICK input pin.
•
•
Regardless of EWIS_PMTICK_CTRL.PMTICK_SRC, when the PMTICK event occurs the
EWIS_INTR_PEND2.PMTICK_PEND is asserted until read. This event may propagate an interrupt to
either WIS_INTA or WIS_INTB, based on the mask enable bits
EWIS_INTR_MASKA_2.PMTICK_MASKA and EWIS_INTR_MASKB_2.PMTICK_MASKB, respectively.
Given the size of the error counters and the maximum allowable error counts per frame, care must be
taken in the frequency of polling the registers to ensure accurate values. All PMTICK counters saturate at
their maximum values.
Table 17 •
PMTICK Counters
Maximum
Increase
Counter per
Frame
Maximum
Increase Counter Time Until
per Second
Overflow
Counter Name
Description
Registers
B1_ERR_CNT
B1 section
error count
EWIS_B1_ERR_CNT1
EWIS_B1_ERR_CNT0
8
64,000
67,109
B2_ERR_CNT
B2 line
error count
EWIS_B2_ERR_CNT1
EWIS_B2_ERR_CNT0
1536
12,288,000
350
B3_ERR_CNT
B3 path
error count
EWIS_B3_ERR_CNT1
EWIS_B3_ERR_CNT0
8
64,000
67,109
EWIS_REIP_CNT Far-end B3
path error count
EWIS_REIP_CNT1
EWIS_REIP_CNT0
8
64,000
67,109
EWIS_REIL_CNT Far-end B2
line error count
EWIS_REIL_CNT1
EWIS_REIL_CNT0
1536
12,288,000
350
Both individual and block mode accumulation of B1, B2, and B3 error indications are supported and
selectable using the control bits EWIS_CNT_CFG.B1_BLK_MODE, EWIS_CNT_CFG.B2_BLK_MODE,
and EWIS_CNT_CFG.B3_BLK_MODE. In individual accumulation mode, 0, the counter is incremented
for each bit mismatch between the calculated B1, B2, and/or B3 error and the extracted B1, B2, and/or
B3. In block accumulation mode, 1, the counter is incremented only once for any nonzero number of bit
mismatches between the calculated B1, B2, and/or B3 and the extracted B1, B2, and/or B3 (maximum of
one error per frame).
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
35
Functional Descriptions
3.3.18.12 Defects and Anomalies
All defects and anomalies listed in the following table can be forced and masked by the user. The
VSC8257-01 device does not automatically generate TIM-P, but does support forcing defects using
MDIO.
Table 18 •
Defect or
Anomaly
Defects and Anomalies
Description
Type
Force Bit
Status Bit
Far-end
PLM-P or
LCD-P
These two errors are indistinguishable when reported Far-end
by the far end through the G1 octet (ERDI-P), because defect
the far end reports both PLM-P and LCD-P with the
same error code.
EWIS_RX_ERR WIS_STAT3.F
.FRC2.FRC_RX EPLMP_LCD
_FE_PLMP
P
Far-end
AIS-P or
LOP-P
These two errors are indistinguishable when reported Far-end
by the far end through the G1 octet (ERDI-P), because defect
the far end reports both AIS-P and LOP-P with the
same error code.
EWIS_RX_ERR WIS_STAT3.F
_FRC2.FRC_R EAISP_LOPP
X_FE_AISP
PLM-P
EWIS_RX_ERR WIS_STAT3.P
Path Label Mismatch.
Near-end
The detection and reporting of the PLM-P defect follows defect;
_FRC2.FRC_R LMP
section 7.5 of ANSI T1.416.1999
propagated X_PLMP
to PCS
AIS-L
Loss Alarm Indication Signal.
Generated on LOPC, LOS, LOF, if enabled by
EWIS_RXTX_CTRL.RXAISL_ON_LOPC,
EWIS_RXTX_CTRL.RXAISL_ON_LOS,
EWIS_RXTX_CTRL.RXAISL_ON_LOF, or
when forced by user.
Near-end
defect
AIS-P
Path Alarm Indication Signal.
EWIS_RX_ERR WIS_STAT3.A
Near-end
_FRC1.FRC_R ISP
defect;
propagated X_AISP
to PCS
LOP-P
Path Loss of Pointer.
Nine consecutive invalid pointers result in loss of
pointer detection.
Near-end
EWIS_RX_ERR WIS_STAT3.L
defect;
_FRC1.FRC_R OPP
propagated X_LOP
to PCS
LCD-P
Path Loss of Code Group Delineation.
This is also reported to the far end if it persists for at
least 3 ms. See Table 16, page 33.
Near-end
defect
EWIS_RX_ERR WIS_FRC2.FRC_LC STAT3.LCDP
DP
LOPC
Loss of Optical Carrier Alarm.
This is an input from the XFP module's loss of signal
output.
The polarity can be inverted for use with other module
types.
This defect can be used independently, or in place of
LOS.
Near-end
defect
EWIS_RX_ERR WIS_FRC1.FRC_L STAT3.LOPC
OPC
_STAT
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
The AIS-L
defect is only
processed and
reported by the
WIS Receive
process;
it is never
transmitted by
the WIS
Transmit
process, in
accordance with
IEEE 802.3ae.
EWIS_RX_E
RR_FRC1.FR
C_RX_AISL/
WIS_STAT3.A
ISL
36
Functional Descriptions
Table 18 •
Defect or
Anomaly
Defects and Anomalies (continued)
Description
Type
Force Bit
Status Bit
LOS
Loss of Signal.
Near-end
The PMA circuitry detects an LOS defect if the input
defect
signal falls below the assert threshold. When a PMA
LOS is declared, the framer is held in reset to prevent it
from looking for a frame boundary.
SEF
Severely Errored Frame.
Generated when the device cannot frame to A1 A2
pattern.
SEF indicates synchronization process is not in the
SYNC state as defined by the state diagram of IEEE
802.3ae, clause 50.4.2.
Near-end
EWIS_RX_ERR WISdefect;
_FRC2.FRC_R STAT3.SEF
propagated X_SEF
to PCS
LOF
Loss of Frame.
Generated when SEF condition persists for 3 ms.
Terminated when no SEF occurs for 1 ms to 3 ms.
Near-end
defect
EWIS_RX_ERR WIS_FRC2.FRC_R STAT3.LOF
X_LOF
B1 PMTICK
error count
is nonzero
BIP-N(S)
32-bit, near-end section BIP error counter is nonzero.
Near-end
anomaly
EWIS_RX_ERR EWIS_INTR_
_FRC2.FRC_R STAT2.B1_NZ
X_B1
_STAT
B2 PMTICK
error count
is nonzero
BIP-N(L)
32-bit, near-end line BIP error counter is nonzero.
Near-end
anomaly
EWIS_RX_ERR EWIS_INTR_
_FRC2.FRC_R STAT2.B2_NZ
_STAT
X_B2
B3 PMTICK
error count
is nonzero
BIP-N(P)
32-bit, near-end path BIP error counter is nonzero.
Near-end
anomaly
EWIS_RX_ERR EWIS_INTR_
_FRC2.FRC_R STAT2.B3_NZ
X_B3
_STAT
REI-L
Far-end BIP-N(L)
Line Remote Error Indicator octet is nonzero.
Far-end
anomaly
EWIS_RX_ERR EWIS_INTR_
_FRC2.FRC_R STAT2.REIL_
EIL
STAT
REI-L
PMTICK
error count
is nonzero
Far-end BIP-N(L)
Line Remote Error Indicator is nonzero.
Far-end
anomaly
EWIS_RX_ERR EWIS_INTR_
_FRC2.FRC_R STAT2.REIL_
NZ_STAT
EIL
RDI-L
Line Remote Defect Indicator
Far-end
defect
EWIS_RX_ERR WIS_STAT3.
_FRC1.FRC_R RDIL
X_RDIL
REI-P
Far-end BIP-N(P)
Path Remote Error Indicator octet is nonzero.
Far-end
anomaly
EWIS_RX_ERR EWIS_INTR_
_FRC2.FRC_R STAT2.REIP_
X_REIP
STAT
REI-P
PMTICK
error count
is nonzero
Far-end BIP-N(P)
Path Remote Error Indicator is nonzero.
Far-end
anomaly
EWIS_RX_ERR EWIS_INTR_
_FRC2.FRC_R STAT2.REIP_
EIP
NZ_STAT
UNEQ-P
Unequipped Path
Near-end
defect
EWIS_RX_ERR EWIS_INTR_
_FRC2.FRC_R STAT2.UNEQ
X_UNEQP
P_STAT
Far-end
UNEQ-P
Far-end Unequipped Path
Far-end
defect
EWIS_RX_ERR EWIS_INTR_
_FRC2.FRC_R STAT2.FEUN
EIP
EQP_STAT
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
EWIS_RX_ERR WIS_FRC1.FRC_L STAT3.LOS
OS
37
Functional Descriptions
3.3.19
Overhead Serial Interfaces
The VSC8257-01 device includes provisions for off-chip processing of the critical SONET/ SDH transport
overhead 9-bit words through two independent serial interfaces. The transmit overhead serial interface
(TOSI) is used to insert 9-bit words into the transmit frames, and the receive overhead serial interface
(ROSI) is used to recover the 9-bit words from the received frames. Each interface consists of three pins:
a clock output, a frame pulse output, and a data input (Tx) /output (Rx). These I/O are LVTTL-compatible
for easy connection to an external device such as an FPGA.
Note: Extended WIS TOSI and ROSI do not support path overhead bytes.
Each ROSI/TOSI interface consumes 6 GPIO pins. This may significantly impact the number of
remaining GPIO pins available for other functions. If the ROSI/TOSI interfaces are used for all four
channels, 16 GPIO pins are left available for any other functions.
All references to TCLKOUT, TFPOUT, TDAIN, RCLKOUT, RFPOUT and RDAOUT are the TOSI/ROSI
signals routed through GPIO package pins.
3.3.19.1
Transmit Overhead Serial Interface (TOSI)
The TOSI port enables the user to individually program 222 separate 9-bit words in the SONET/SDH
overhead. The SONET/SDH frame rate is 8 kHz as signaled by the frame pulse (TFPOUT) signal. The
TOSI port is clocked from a divided-down version of the WIS transmit clock made available on
TCLKOUT. To provide a more standard clock rate, 9-bit dummy words are added per frame resulting in a
clock running at one five-hundred-twelfth of the line rate, or 19.44 MHz. For each 9-bit word, the external
device indicates the desire to transmit that byte by using an enable indicator bit (EIB) that is appended to
the beginning of the 9-bit word. If EIB = 0, the data on the serial interface is ignored for that overhead 9bit word. If EIB = 1, the serial interface data takes precedence over the value generated within the
VSC8257-01 device.
The EIB is present before the 9-bit dummy words too, however its value has no effect as the 9-bit dummy
words are ignored within the device. The first EIB bit should be transmitted by the external device on the
first rising edge of TCLKOUT after TFPOUT, as illustrated in the following figure. The data should be
provided with the most significant bit (MSB) first. After reception of the TOSI data for a complete frame,
the values are placed in the overhead for the next transmitted frame.
Figure 15 • TOSI Timing
TCLKOUT
TFPOUT
TDAIN
Padding
Dummy Bits
A1
EIB
A1
Bit 1
A1
Bit 2
A1
Bit 3
Some 9-bit words are error masks, such that the transmitted 9-bit word is the XOR of the TOSI 9-bit word
and the pre-defined value within the chip if the EIB is enabled. This feature is best used for test purposes
only.
The order of the 9-bit word required by the TOSI port is summarized in the following table, where the
number of registers is the number of bytes on the serial interface, and the number of bytes is the number
of STS channels on which the byte is transmitted. For H1 and H2 pointers, bytes 2 to 192 are
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
38
Functional Descriptions
concatenation indication bytes consistent with STS-192c frames. There are not 192 different point
locations as in STS-192 frames.
Table 19 •
TOSI/ROSI Addresses
Byte Name
9-Bit
Word
TOSI/
ROSI
Byte
Order
Frame boundary
A1
0
1
192
Programmable byte that is
identical for all locations
Frame bou ndary
A2
1
1
192
Programmable byte that is
identical for all locations
Section trace
J0
2
1
1
Programmable byte
Section growth
Z0
3
1
191
Programmable byte that is
identical for all locations
4
1
1
Programmable byte
Dummy byte
Number of Number
Registers of Bytes
Type
Section BIP-8
B1
5
1
1
TOSI inserts error mask; ROSI
extracts XOR of B1 value and
received data
Orderwire
E1
6
1
1
Programmable byte
Section user channel
F1
7
1
1
Programmable byte
8
1
1
Programmable bytes
Section DCC 1
D1
9
1
1
Programmable byte
Section DCC 2
D2
10
1
1
Programmable byte
Section DCC 3
D3
11
1
1
Programmable byte
12
1
1
Programmable byte
Dummy byte
Dummy byte
Pointer 1
H1
13
1
1
Programmable byte affecting the
first H1 byte
Pointer 2
H2
14
1
1
Programmable byte affecting the
first H2 byte
Pointer action
H3
15
1
192
Programmable byte that is
identical for all locations
16
1
1
Programmable byte
17 to 208 192
192
TOSI inserts error mask for each
byte; ROSI extracts XOR of B2
value and received data for each
byte
Automatic protection K1
switching (APS)
channel and remote
defect indicator (RDI)
209
1
1
Programmable byte
Automatic protection K2
switching (APS)
channel and remote
defect indicator (RDI)
210
1
1
Programmable byte
Dummy byte
211
1
1
Programmable byte
212
1
1
Programmable byte
Dummy byte
Line BIP-8
Line DCC 4
B2
D4
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
39
Functional Descriptions
Table 19 •
TOSI/ROSI Addresses (continued)
Byte Name
9-Bit
Word
TOSI/
ROSI
Byte
Order
Line DCC 5
D5
213
1
1
Programmable byte
Line DCC 6
D6
214
1
1
Programmable byte
215
1
1
Programmable byte
Dummy byte
Number of Number
Registers of Bytes
Type
Line DCC 7
D7
216
1
1
Programmable byte
Line DCC 8
D8
217
1
1
Programmable byte
Line DCC 9
D9
218
1
1
Programmable byte
219
1
1
Programmable byte
Dummy byte
Line DCC 10
D10
220
1
1
Programmable byte
Line DCC 11
D11
221
1
1
Programmable byte
Line DCC 12
D12
222
1
1
Programmable byte
223
1
1
Programmable byte
Dummy byte
Synchronization
message
S1
224
1
1
Programmable byte
Growth 1
Z1
225
1
191
Programmable byte that is
identical for all locations
Growth 2
Z2
226
1
190/191
Programmable byte that is
identical for all locations;
dependent upon 2xEC40.12
STS-1 REI-L
M0
227
1
1
Programmable byte
STS-N REI-L
M1
228
1
1
Programmable byte
Orderwire 2
E2
229
1
1
Programmable byte
Dummy byte
230
1
1
Programmable byte
Padding dummy bytes
231 to
269
39
3.3.19.2
No function
Receive Overhead Serial Interface (ROSI)
The ROSI port extracts the same 222 overhead 9-bit words from the SONET/SDH frame, and consists of
the clock output (RCLKOUT), frame pulse output (RFPOUT), and data output (RDAOUT). The ROSI port
is clocked from a divided-down version of the WIS receive clock, and is valid during in-frame conditions
only. As with the TOSI port, 9-bit dummy words are provided each frame period resulting in a 19.44 MHz
RCLKOUT frequency. For each 9-bit word, including the 9-bit dummy words, an extra 0 bit is added at
the beginning of each byte so that the TOSI and ROSI clock rates are identical. The first stuff bit for each
frame is transmitted by RDAOUT on the first rising edge of RCLKOUT after the frame pulse (RFPOUT),
as illustrated in the following figure.
Because the receive path overhead can be split across two frames, the VSC8257-01 device buffers the
overhead for an additional frame time so that a complete path overhead is presented. Table 19, page 39
outlines the order for each of the 9-bit words presented on the ROSI port. With the exception of the
M0/M1 9-bit words, the extracted 9-bit words are from the first channel position. In place of parity and
error 9-bit words, the VSC8257-01 device outputs the result of an XOR between the calculated BIP and
the received value. Therefore, a count of ones within each of the BIP 9-bit words should correspond with
the internal error accumulators. The following figure shows the functional timing for the ROSI port.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
40
Functional Descriptions
Figure 16 • ROSI Timing
RCLKOUT
RFPOUT
RDAOUT
3.3.20
Padding
Dummy Bits
‘0’
Stuff
A1
Bit 1
A1
Bit 2
A1
Bit 3
Pattern Generator and Checker
The VSC8257-01 device implements the square wave, PRBS31, and mixed-frequency test patterns as
described in section 50.3.8 of IEEE 802.3ae, as well as the test signal structure (TSS) and continuous
identical digits (CID) pattern.
The square wave pattern is selected asserting WIS_CTRL2.TEST_PAT_SEL. and the generator is
enabled by asserting WIS_CTRL2.TEST_PAT_GEN. When WIS_CTRL2.TEST_PAT_SEL is deasserted,
the mixed frequency test pattern is selected. The square wave frequency is configured according to
EWIS_TXCTRL2.SQ_WV_PW. The WIS_CTRL2.TEST_PAT_ANA bit is used to enable the test pattern
checker in the receive path. The checker does not operate on square wave receive traffic. Error counts
from the mixed frequency pattern are presented in the SONET/SDH BIP-8 counters, B1_CNT
WIS_B1_CNT, WIS_B2_CNT, and WIS_B3_CNT.
The VSC8257-01 device supports the PRBS31 test pattern as reflected in
WIS_STAT2.PRBS31_ABILITY. The transmitter/generator is enabled by asserting
WIS_CTRL2.TEST_PRBS31_GEN, while the receiver/checker is enabled by asserting
WIS_CTRL2.TEST_PRBS31_ANA. Because the mixed frequency/square wave test patterns have
priority over the PRBS31 pattern, WIS_CTRL2.TEST_PAT_GEN must be disabled for the PRBS31 test
pattern to be sent. Error counts from the PRBS31 checker are available in WIS_TSTPAT_CNT. This
register does not roll over after reaching its maximum count, and is cleared after every read operation.
Two status bits are available from the PRBS checker. The EWIS_PRBS31_ANA_STAT.PRBS31_ERR bit
indicates whether the error counter is nonzero. The EWIS_PRBS31_ANA_STAT.PRBS31_ANA_STATE
bit, if asserted, indicates that checker is synchronized and actively checking received bits.
For test purposes, the PRBS generator can inject single bit errors. By asserting
EWIS_PMTICK_CTRL.PMTICK_SRC, a single bit error is injected, resulting in three bit errors being
detected within the checker. The value of three comes from the specification, which indicates one error
should be detected for each tap within the checker.
3.4
10G Physical Coding Sublayer (64b/66b PCS)
The 10G physical coding sublayer (PCS) is defined in IEEE 802.3ae, Clause 49. It is composed of the
PCS transmit, PCS receive, block synchronization, and BER monitor processes. The PCS functions can
be further broken down into encode or decode, scramble or descramble, and gearbox functions, as well
as various test and loopback modes.
The PCS is responsible for transferring data between the MAC and the WIS/PMA clock domain. In
addition, the PCS encodes and scrambles the data for efficient transport across the given medium.
The following illustration provides a block diagram of the 10G PCS block.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
41
Functional Descriptions
Figure 17 • PCS Block Diagram
WIS/PMA
MAC/1588/XGXS
Buffer
Buffer
3.4.1
PCS Standard Test Modes
The PCS block offers all of the standard defined test pattern generators and analyzers. In addition, the
VSC8257-01 device supports a 64-bit static user pattern and the optional PRBS31 pattern. Two error
counters are available. Each is a saturating counter that is cleared upon a read operation. The first,
PCS_ERR_CNT, is located in the IEEE Standard area while the 32-bit,
PCS_VSERR_CNT_0/PCS_VSERR_CNT_1, is located in the vendor specific area.
The IEEE specification defines two test pattern modes, a square wave generator and a pseudo-random
test pattern. The square wave generator is enabled by first selecting the square wave pattern by
asserting PCS_TSTPAT_SEL then enabling the test pattern generator PCS_TSTPAT_GEN. The period
of the square wave can be controlled in terms of bit times by writing to PCS_SQPW. There is no
associated square wave checker within the VSC8257-01 device. The pseudo-random test pattern is
selected by deasserting PCS_TSTPAT_SEL. The pseudo-random test pattern contains two data modes.
When PCS_TSTDAT_SEL is deasserted, the pseudo-random pattern is a revolving series of four blocks
with each block 128-bits in length. The four blocks are the resultant bit sequence produced by the PCS
scrambler when pre-loaded with the following seeds:
•
•
•
•
PCS_SEEDA_0, PCS_SEEDA_1, PCS_SEEDA_2, PCS_SEEDA_3
PCS_SEEDA invert
PCS_SEEDB_0, PCS_SEEDB_1, PCS_SEEDB_2, PCS_SEEDB_3
PCS_SEEDB invert
The pattern generator is enabled by asserting PCS_TSTPAT_GEN, while the analyzer is enabled, by
asserting PCS_TSTPAT_ANA. Errors are accumulated in the clear-on-read saturating counter,
PCS_ERR_CNT. In pseudo-random pattern mode, the error counter counts the number of errored
blocks.
Support for the optional PRBS31 pattern is indicated by PRBS31_pattern_testing_ability register whose
default is high. The PRBS31 test generator is selected by asserting PCS_PRBS31_GEN, while the
checker is enabled by asserting PCS_PRBS31_ENA. IEEE standards specify that the error counter
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
42
Functional Descriptions
should increment for each linear feedback shift register (LFSR) tap that a bit is in error. Therefore, a
single bit error increments the counter by three because there are three taps in the PRBS31 polynomial.
The user-defined 64-bit static pattern can be written to PCS_USRPAT registers and enabled by asserting
PCS_USRPAT_ENA and PCS_TSTPAT_GEN. Enabling the user- defined pattern enables both the
generator and analyzer.
3.5
1G Physical Coding Sublayer
The 1G physical coding sublayer implements 1000BASE-X as specified by IEEE 802.3, clause 36, and
auto-negotiation as specified by IEEE 802.3, clause 37. It provides for the encoding (and decoding) of
GMII data octets to (from) ten-bit code-groups (8B/10B) for communication with the underlying PMA. It
also manages link control and the auto-negotiation process.
In addition to these standard 1000BASE-X functions, the 1G PCS also includes a conversion function
that maps the standard GMII data to (from) an internal XGMII-like interface. This allows the processing
core to be largely agnostic to whether a channel is operating in 1G or 10G operation.
3.6
IEEE 1588 Block Operation
The VSC8257-01 device uses a second generation IEEE 1588 engine that is backward compatible with
the earlier version of VeriTime™, the Microsemi IEEE 1588 time stamping engine. 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.
•
•
•
•
•
•
•
•
•
Enhanced time stamp accuracy and resolution
Automatic 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
Independent control and bypass for each direction of IEEE 1588
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 second generation IEEE 1588 block 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 VSC8257-01 device.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
43
Functional Descriptions
Figure 18 • IEEE 1588 Architecture
Phy0
External
chip SPI
Phy1
Phy2
1588 engine A
Phy3
1588 engine B
PPS_0
1588 engine
(1)
PPS_2
Processor 1
Processor 0
LTC
Ingress
Registers
LTC
Egress
Ingress
Registers
Egress
SPI
Analyzer 0
Analyzer 0
Analyzer 1
Analyzer 1
Analyzer 2
Analyzer 2
TS
FIFO
Analyzer 0
Analyzer 0
Analyzer 1
Analyzer 1
Analyzer 2
Analyzer 2
TS
FIFO
Load/Store
(1) PPS_0 MUX control used to access PHY 0 through PHY3
The following sections list some of the major IEEE 1588 applications.
3.6.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
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 VSC8257-01 device. In addition, there is a LOAD/SAVE pin that
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
44
Functional Descriptions
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 (125 MHz or 250 MHz) from CLK1588P/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 19 • 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
Timing Card
Optional
frequency
conversion
Timing
Card
MAC
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 VSC8257-01 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.
The system card also provides a sync pulse to all PHYs, including the VSC8257-01 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 VSC8257-01 device supports a vast variety of IEEE 1588 applications. In simple one-step end-toend transparent clock applications, the VSC8257-01 device can be used without any central CPU
involvement except for initial configuration. The IEEE 1588 block inside the VSC8257-01 device forwards
Sync and Delay_req frames with automatic updates to the Correction field.
In other applications, the VSC8257-01 device enhances the performance by working with a central
processor that runs the IEEE 1588 protocol. The VSC8257-01 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
VSC8257-01 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 VSC8257-01
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-10486 VSC8257-01 Datasheet Revision 4.1
45
Functional Descriptions
PHY connected to the PTP master) to the other PHYs and sets the load bit in these VSC8257-01
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 VSC8257-01 device, to automatically add 1 ns or subtract
1 ns at specific time intervals.
3.6.2
IEEE 1588v2 One-Step End-to-End Transparent Clock
Unique advantages for implementing IEEE 1588-2008 are as follows:
•
•
•
When several VSC8257-01 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
VSC8257-01 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 as follows:
•
•
•
3.6.3
Delivery of a synchronous global timetick clock (or reference clock) to ensure that the “local time” for
all PHYs in the system progresses at the same rate.
Delivery of a global timetick load to synchronize the local time counters in each PHY.
CPU access to each PHY to set up the required configuration. This can be through MDIO, two-wire
slave, or 4-pin SPI.
IEEE 1588v2 Transparent Clock and Boundary Clock
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 20 • IEEE 1588 Transparent Clock and Boundary Clock Line Card Application
Ethernet Port
Ethernet Line Card
System Card
Ethernet Line Card
Linecard Control
Processor
System Control
Processor
Linecard Control
Processor
1G
SerDes PHY
MAC
Packet
Processing
Fabric
Packet
MAC
Processing
10G
SerDes 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-10486 VSC8257-01 Datasheet Revision 4.1
46
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.6.4
Enhancing IEEE 1588 Accuracy for CE Switches and MACs
Connecting VSC8257-01 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 SGMII/QSGMII interface. It will also add support for one-step TC and
BC on Microsemi’s Jaguar family of devices.
3.6.5
Supporting One-Step Boundary Clock/Ordinary Clock
In one-step boundary clock, the boundary clock 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 54.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
47
Functional Descriptions
Figure 21 • One-Step End-to-End Boundary Clock
PTP Sync or Delay_req Frame
Correction Field = A
Reserved Bytes = 0
IEEE 1588
PHY
PTP Pdelay_req Frame
Correction Field = C
PTP Sync or Delay_req Frame
Correction Field = A Reserved
Reserved Bytes = RxTimestamp
PTP Sync Frame
OriginTime = F
Correction Field = E
Packet Processing
And
Switching
PTP Pdelay_req Frame
Correction Field = C
PTP Sync Frame
Origin Time = F
Correction Field = E
Central
IEEE 1588
Engine
(CPU)
Engine recovers
frequency from Sync
frames, and
controls 1588
frequency
PTP Sync Frame
Correction Field = A
Reserved bytes = RxTimestamp + Peer Delay
IEEE 1588
PHY
PTP delay_req Frame
Correction Field = C
(TXTimestamp saved in FIFO)
3.6.5.1
PTP Sync Frame
Origin Time = Timestamp
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
checksum is 0. If the frame is IPv6 the rewriter keeps track of the modifications done to the frame and
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
48
Functional Descriptions
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.6.5.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.6.6
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 Clock/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 VSC8257-01 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-10486 VSC8257-01 Datasheet Revision 4.1
49
Functional Descriptions
Figure 22 • Two-Step End-to-End Boundary Clock
PTP Sync or Delay_req Frame
Correction Field = A
Reserved Bytes = 0
IEEE 1588
PHY
PTP Pdelay_req Frame
Correction Field = C
PTP Sync or Delay_req Frame
Correction Field = A Reserved
Reserved Bytes = RxTimestamp
PTP Sync Frame
OriginTime = F
Correction Field = E
Packet Processing
And
Switching
PTP Pdelay_req Frame
Correction Field = C
PTP Sync Frame
Origin Time = F
Correction Field = E
Central
IEEE 1588
Engine
(CPU)
Engine recovers
frequency from Sync
frames, and
controls 1588
frequency
PTP Sync Frame
Correction Field = A
Reserved bytes = RxTimestamp
IEEE 1588
PHY
PTP delay_req Frame
Correction Field = C
(TXTimestamp saved in FIFO)
3.6.6.1
PTP Sync Frame
Origin Time = 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.6.6.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)
Delay_req frames: FIFO = (Raw_Timestamp + Local_correction)
Correction field = Original Correction field – Asymmetry
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
50
Functional Descriptions
3.6.7
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 VSC8257-01 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-10486 VSC8257-01 Datasheet Revision 4.1
51
Functional Descriptions
Figure 23 • One-Step End-to-End Transparent Clock Mode A
PTP Sync or Delay_Req Frame
Correction Field = A
IEEE 1588
PHY
PTP Sync or Delay_Req Frame
Correction Field = A – RxTimestamp
Packet processing and
Switching
Central
IEEE 1588
Engine
(CPU)
PTP Sync or Delay_Req Frame
Correction Field = A – RxTimestamp
IEEE 1588
IEEE
1588
PHY
PHY
PTP Sync or Delay_Req Frame
Correction Field =
A – RxTimestamp + TxTimestamp
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.6.7.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:
•
•
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)
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
52
Functional Descriptions
3.6.7.2
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 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 (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 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 24 • One-Step End-to-End Transparent Clock Mode B
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
Central
IEEE 1588
Engine
(CPU)
Engine recovers
frequency from Sync
frames, and
controls 1588
frequency
PTP Sync Frame
Correction Field = A
Reserved bytes = RxTimestamp
IEEE 1588
PHY
PTP Sync or Delay_req Frame
Correction Field = A – RxTimestamp + TxTimestamp
Reserved Bytes = 0
3.6.7.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:
•
•
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
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
53
Functional Descriptions
3.6.7.4
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.6.8
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.6.8.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.
Figure 25 • Delay Measurements
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
54
Functional Descriptions
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 VSC8257-01 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.
3.6.8.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 the rewriter block writes the sub-second value to the reserved bytes in the PTP header.
The following full calculations are performed:
•
•
•
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
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
55
Functional Descriptions
3.6.8.3
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:
•
•
•
3.6.8.4
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
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:
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
56
Functional Descriptions
•
•
•
3.6.8.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 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 (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
Pdelay_resp frames: Correction field = Internal Correction field +
(Raw_Timestamp_ns + Local_correction)
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
57
Functional Descriptions
Figure 26 • One-Step Peer-to-Peer Transparent Clock Mode B
Correction Field = B
Reserved Bytes = 0
PTP Pdelay_req/resp Frame
Correction Field = B
Reserved bytes = RxTimestamp
Correction Field = A
Reserved Bytes = 0
Central
IEEE 1588
Engine
(CPU)
PTP Pdelay_req Frame
Correction Field = C
PTP Sync Frame
Correction Field = A
Reserved bytes = RxTimestamp +
Peer Delay
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)
Engine recovers frequency
from Sync frames , and
controls 1588 frequency
PTP Sync Frame
Correction Field = A
Reserved bytes = RxTimestamp + Peer Delay
PTP Pdelay_req/resp Frame
Correction Field = B
Reserved bytes = RxTimestamp
PTP Pdelay_req Frame
Correction Field = C
(TxTimestamp saved in FIFO )
PTP Pdelay_resp Frame
Correction Field = D + TxTimestamp
3.6.9
Central
IEEE 1588
Engine
(CPU)
PTP Sync Frame
Correction Field = A – RxTimestamp + Peer Delay
Reserved Bytes = 0
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-10486 VSC8257-01 Datasheet Revision 4.1
58
Functional Descriptions
Figure 27 • Two-Step End-to-End Transparent Clock
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
Reserved Bytes = RxTimestamp
Packet Processing
And
Switching
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
PTP Sync or Delay_req Frame
Correction Field = A
Reserved Bytes = RxTimestamp
IEEE 1588
PHY
PTP Sync or Delay_req Frame
Correction Field = A
Reserved Bytes = 0
Txtimestamp and RxTimestamp in FIFO
3.6.9.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:
•
•
3.6.9.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
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.
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:
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
59
Functional Descriptions
•
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.6.10
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.6.11
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 28 • Y.1731 1DM PDU Format
1
8
1
7
MEL
6
5
2
4
3
2
1
VERSION (0)
5
8
7
6
5
3
4
3
2
1
8
7
Opcode (1DM = 45)
6
5
4
4
3
2
Flags (0)
1
8
7
6
5
4
3
2
1
TLV Offset (16)
TxTimeStampf
19
13
Reserved for 1DM receiving equipment (0)
(for RxTimeStampf)
17
End TLV (0)
21
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-10486 VSC8257-01 Datasheet Revision 4.1
60
Functional Descriptions
Figure 29 • Y.1731 One-Way Delay
Y.1731 1DM Message
TxTimeStampf = A
RxTimeStampf = 0
IEEE 1588
PHY
Y.1731 1DM Message
TxTimeStampf = A
RxTimeStampf = RxTimeStamp
Y.1731 1DM Message
TxTimeStampf = 0
RxTimeStampf = 0
Packet Processing
And
Switching
Y.1731 1DM Message
TxTimeStampf = 0
RxTimeStampf = 0
Central
Y.1731
Engine
(CPU)
Y.1731 1DM Message
TxTimeStampf = A
RxTimeStampf = RxTimeStamp
IEEE 1588
PHY
Y.1731 1DM Message
TxTimeStampf = TxTimeStamp
RxTimeStampf = 0
3.6.11.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.6.11.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)
3.6.12
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.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
61
Functional Descriptions
Figure 30 • Y.1731 DMM PDU Format
1
8
1
7
MEL
6
5
2
4
3
2
1
Version (0)
5
8
7
6
5
3
4
3
2
1
8
7
OpCode (DMM = 47)
6
5
4
4
3
2
Flags (0)
1
8
7
6
5
4
3
2
1
TLV Offset (32)
TxTimeStampf
9
13
Reserved for DMM receiving equipment (0)
(for RxTimeStampf)
17
21
Reserved for DMR (0)
(for TxTimeStampb)
25
29
Reserved for DMR receiving equipment (0)
33
End TLV (0)
37
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-10486 VSC8257-01 Datasheet Revision 4.1
62
Functional Descriptions
Figure 31 • 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
Y.1731 DMM Message
TxTimeStampf = 0
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 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 = 0
RxTimeStampf = 0
TxTimeStampb = 0
RxTimeStampb = 0
Central
Y.1731
Engine
(CPU)
Y.1731 DMM Message
TxTimeStampf = A
RxTimeStampf = RxTimeStamp
TxTimeStampb = 0
RxTimeStampb = 0
IEEE 1588
PHY
Y.1731 DMR Message
Y.1731 DMM Message
TxTimeStampf = B
TxTimeStampf = TxTimeStamp
RxTimeStampf = C
RxTimeStampf = 0
TxTimeStampb = TxTimeStamp
TxTimeStampb = 0
RxTimeStampb = 0
RxTimeStampb = 0
3.6.12.1
Y.1731 DMR Message
TxTimeStampf = D
RxTimeStampf = E
TxTimeStampb = F
RxTimeStampb = RxTimeStamp
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:
•
•
3.6.12.2
DMM frames: RxTimeStampf = (Raw_Timestamp – Local_correction)
DMR frames: RxTimeStampb = (Raw_Timestamp – Local_correction)
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-10486 VSC8257-01 Datasheet Revision 4.1
63
Functional Descriptions
•
•
3.6.12.3
DMM frames: TxTimeStampf = (Raw_Timestamp + Local_correction)
DMR frames: TxTimeStampb = (Raw_Timestamp + Local_correction)
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 32 • 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 33 • 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.6.13
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-10486 VSC8257-01 Datasheet Revision 4.1
64
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.6.14
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
VSC8257-01 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-10486 VSC8257-01 Datasheet Revision 4.1
65
Functional Descriptions
Figure 34 • PTP Packet Encapsulations
ETH1
ETH2
MPLS
"PBB"
"ETH"
Untagged/Tagged
PB (Q-in-Q)
MAC-in-MAC
IP/UDP
IP/UDP
PTP
PTP
PTP
"PWE"
"IP-MPLS"
draft-ietf-tictoc1588overmpls
draft-ietf-tictoc1588overmpls
ETH2
IP/UDP
PTP
PTP
IP/UDP
PTP
PTP
The following illustration shows the same overview of the supported encapsulations with the focus on
OAM.
Figure 35 • OAM Packet Encapsulations
ETH1
MPLS
ETH2
"PBB"
"ETH"
MAC-in-MAC
Y.1731 OAM
"PWE"
"ACH"
ETH2
ACH
(RFC-5718)
Untagged/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 VSC8257-01 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
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
66
Functional Descriptions
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
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 36 • 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.
Analyzer
TS
Time stamp
Egress
timing
domain
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.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
67
Functional Descriptions
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
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 VSC8257-01 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 IEEE 802.3.
3.6.15
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.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
68
Functional Descriptions
Figure 37 • Analyzer Block Diagram
Data
Data
SOF
Analyzer
SOF
detect
Encap Engine A 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 B 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 C
A controller
Offsets &
Next protocol
Ethernet/SNAP
Comparator 1
Encap C
A
Aflow
Bflow
Ethernet/SNAP
Comparator 2
Encap C
A
(OAM optimized)
Aflow
Aflow
Aflow
Bflow
A-flow
B-flow
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.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
69
Functional Descriptions
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 71 and MPLS Comparator, page 75.
Table 20 •
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
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 21 •
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
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
70
Functional Descriptions
The following table shows the ID codes comparators use in the sequencing registers. The PTP packet
target encapsulations require only up to five comparators.
Comparator ID Codes
Table 22 •
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.6.15.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 ether-type
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.
3.6.15.1.1 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.
Figure 38 • Type II Ethernet Basic Frame Format
Destination Address (DA)
5
4
3
2
1
Source Address (SA)
0
5
Destination Address (DA)
5
4
3
2
1
0
5
0
5
Destination Address (DA)
5
4
3
2
1
4
3
2
1
Source Address (SA)
4
3
2
1
Etype
0
1
0
3
0
3
3
2
1
VLAN Tag
2
1
Etype
0
1
0
3
VLAN Tag 1
Source Address (SA)
4
Payload
0
2
1
Payload
0
VLAN Tag 2
2
1
Payload
Etype
0
1
0
3.6.15.1.2 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 39 • Ethernet Frame with SNAP
Destination Address (DA)
5
4
3
2
1
0
4
3
2
1
Protocol ID
Length DSAPSSAP Ctl
Source Address (SA)
5
0
1
0
A A/AB AA/AB 0x03
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
2
0x000000
1
0
EtherType
1
0
71
Functional Descriptions
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 40 • Ethernet Frame with VLAN Tag and SNAP
Destination Address (DA )
$
#
$
#
$
$
$
$
$
#
$
$
#
Protocol ID
DSAPSSAP Ctl
Length
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 41 • Ethernet Frame with VLAN Tags and SNAP
LLC
Destination Address (DA)
5
4
3
2
1
VLAN 1
EtherType
Source Address (SA)
0
5
4
3
2
1
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
3.6.15.1.3 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 42 • 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)
1
0
5
4
3
2
1
0
Rest of
E-net Header
Customer Source Address (C-SA)
5
4
3
2
1
0
Figure 43 • 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 Flags
88E7
1
0
0
SID
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
3.6.15.1.4 Ethernet Comparison
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.
3.6.15.1.5 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 23 •
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.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
72
Functional Descriptions
Table 23 •
Ethernet Comparator (Next Protocol)
Parameter
Width
Description
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.
3.6.15.1.6 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 24 •
Ethernet Comparator (Flow)
Parameter
Width
Eth_Flow_Enable
1 bit/flow 0 = Flow disabled
1 = Flow enabled
Description
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)
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.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
73
Functional Descriptions
Table 24 •
Ethernet Comparator (Flow)
Parameter
Width
Description
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 802.3
for more details.
0 = Match the full 48-bit address
1 = Match any unicast address
2 = Match any multicast address
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.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
74
Functional Descriptions
Ethernet Comparator (Flow)
Table 24 •
Parameter
Width
Description
Eth_Nxt_Prot_Grp_Sel
1 bit
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.
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.6.15.1.7 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 44 • MPLS Label Format
Label
19
18
17
16
15
14
13
12
11
10
Class
9
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 45 • MPLS Label Stack within an Ethernet Frame
CW=0
Destination Address (DA)
5
4
3
2
1
Source Address (SA)
0
5
Destination Address (DA)
CW=0
5
4
3
2
1
4
3
2
0
1
0
1
Source Address (SA)
0
5
4
3
2
Label (S=1)
Etype
1
0
3
1
Payload
0
Label (S=0)
Label (S=0)
Etype
1
2
0
3
2
1
0
3
2
Label (S=1)
1
0
3
2
1
Payload
0
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.
Figure 46 • MPLS Labels and Control Word
CW=1
Destination Address (DA)
5
4
3
2
1
0
Source Address (SA)
5
4
3
2
1
Label (S=0)
Etype
0
1
0
3
2
1
Label (S=0)
0
3
2
1
Label (S=1)
Label (S=0)
0
3
2
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.
MPLS Comparator: Next Word
Table 25 •
Parameter
Width
Description
MPLS_Nxt_Comparator
3 bit
Pointer to the next comparator
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
75
Functional Descriptions
Table 26 •
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 27 •
Allowed Stack Depth
1
2
3
4
MPLS Range_Upper/Lower Label Map
MPLS_REF_PNT = 0,
top-of-stack referenced
Parameter
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
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 28 •
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
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
76
Functional Descriptions
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.
Next-Protocol Registers in OAM-Version of MPLS Block
Table 29 •
Parameter
Width
Description
MPLS_Nxt_Prot_Grp_Sel 1 bit per flow
3.6.15.2
Maps each flow to next-protocol-register set A or B
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.6.15.3
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.
Figure 47 • IPv4 with UDP
Octet/Bit
0/0
3
15
IPv4
31
0
Version
Hdr Length
2
1
0
3
14
13
12
11
2
10
1
0
7
Identification
9
8
7
6
5
4
3
2
1
0
15
6
5
4
3
2
1
0
2
Time to Live
7
6
5
4
3
2
Total Length
Differentiated Services
14
Flags
1
13
12
11
10
9
0
12
11
10
9
Protocol
1
0
7
6
5
4
3
8
7
6
5
4
3
2
1
0
4
3
2
1
0
4
3
2
1
0
Fragment Offset
8
7
6
5
Header Checksum
2
1
0
15
14
13
12
11
10
9
8
7
6
5
Source Address
16/128
UDP
24/192
Destination Address
Source Port
Length
Destination Port
Checksum (over-write with 0)
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.6.15.4
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.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
77
Functional Descriptions
Figure 48 • IPv6 with UDP
31
0
Octet/Bit
0/0
Version
3
15
Traffic Class
2
1
0
7
6
14
13
12
11
10
5
4
3
Payload Length
9
8
7
2
1
0
19
18
17
16
15
14
13
6
5
4
3
2
1
0
7
6
5
12
Flow Label
9
8
7
6
5
4
11
3
10
2
1
0
7
6
5
Next Header
4
3
Hop Limit
4
3
2
1
0
2
1
0
Source Address
IPv6
Destination Address
24/288
Destination Port
Source Port
UDP
40/352
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
6
5
4
3
2
1
0
5
4
3
2
1
0
Checksum
7
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 must be updated so that the
checksum field does not have to be modified.
Note: IPv6 extension headers are not supported.
3.6.15.5
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
header can optionally have a Protocol ID field. The protocol is verified using the Version, Channel Type,
and optional Protocol ID field.
Figure 49 • ACH Header Format
31
0
Octet/Bit
0/0
4/32
3
15
2
0x1
14
Reserved
Version
1
13
0
12
3
11
2
1
0
7
6
Protocol ID or Payload
10
9
8
7
6
5
5
4
4
3
3
Channel Type
2
2
1
1
0
15
14
13
12
11
10
9
8
7
6
5
4
3
2
1
0
Payload
0
Figure 50 • ACH Header with Protocol ID Field
Octet /Bit
31
0
0/0
4/32
3.6.15.6
3
15
0x1
2
14
Version
1
13
0
12
3
11
2
10
1
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
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.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
78
Functional Descriptions
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 51 • IPSec Header Format
31
0
Octet/Bit
Next Header
0/0
Payload Length
7
6
5
4
3
2
1
0
7
6
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
Reserved
2
3
1
0
15
14
11
10
9
8
7
6
5
4
3
2
1
0
13
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
8/64
17
16
15
14
Integrity Check Value (ICV)
...
variable #
of octets
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.
Figure 52 • IPv6 with UDP and IPSec
Octet/Bit
0/0
31
0
Version
3
2
15
14
1
13
0
7
12
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
9
8
7
6
5
4
3
2
1
0
7
6
5
12
11
10
9
Next Header
5
2
1
0
4
4
3
3
2
1
0
Hop Limit
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
0
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
Source Port
15
UDP
0
14
13
12
11
10
9
8
7
Destination Port
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
3.6.15.7
14
13
12
11
10
9
8
7
7
6
Checksum
7
6
Comparator Field Summary
The following table shows a summary of the fields and widths to verify IPv4, IPv6, and ACH protocols.
Table 30 •
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
Entire ACH header
One 64-bit field
IPv6
ACH
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
79
Functional Descriptions
Table 30 •
Comparator Field Summary
Protocol
Next Protocol Fields
NPF Bit Widths
IPSec
Next Header/Payload Length/
SPI
One 64-bit field
Flow Fields
Flow Bit Widths
3.6.15.7.1 IP/ACH Comparator Next Protocol
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 31 •
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
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
80
Functional Descriptions
Table 31 •
IP/ACH Next-Protocol Comparison
Parameter
Width
Description
IP_Flow_Offset
5 bit
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.
IP_UDP_Checksum 1 bit
_Clear_Ena
If set, the 2-byte UDP checksum should be cleared (written with
zeros). 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 32 •
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.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
81
Functional Descriptions
IP/ACH Comparator Flow Verification Registers
Table 32 •
Parameter
Width
Description
IP_Channel_Mask
1 bit per
channel per
flow
Enable for this match set for this channel
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.6.15.8
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.6.15.9
PTP Frame Header
The following illustration shows the header of a PTP frame.
Figure 53 • PTP Frame Layout
Octet/Bit
31
0
0/0
3
Tspt Spcfc
2
7
6
1
0
Msg Type
3
2
Domain Number
5
4
3
2
Rsvd
1
0
3
1
0
7
2
Message Length
Vrsn PTP
1
0
3
2
1
0
15
14
13
12
11
10
9
8
2
1
0
15
14
13
12
11
10
9
8
7
Reserved
6
5
4
3
7
6
5
4
3
2
1
0
6
5
4
3
2
1
0
Flag Field
Correction Field
Reserved
Source Port Identity [79:48 ]
79
78
77
76
75
74
73
72
71
70
69
68
67
60
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
66
34
65
33
64
32
63
31
62
30
61
29
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
7
6
5
Source Port Identity [47:16 ]
Sequence ID
Source Port Identity [15 :0]
32/256
10
9
8
7
6
1
0
7
6
Control Field
4
3
2
5
Log Message Interval
5
4
3
2
1
8
7
6
0
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.6.15.10 Y.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 54 • 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
Flags (0)
Opcode (1DM=45)
1
0
7
6
5
4
TLV Offset (16)
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-10486 VSC8257-01 Datasheet Revision 4.1
82
Functional Descriptions
Figure 55 • 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
Flags (0)
Opcode (1DM=47)
0
7
6
5
4
3
2
1
0
7
6
5
4
TLV Offset (32)
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 56 • 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.6.15.11 Y.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 57 • 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-10486 VSC8257-01 Datasheet Revision 4.1
83
Functional Descriptions
Figure 58 • 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.6.15.12 PTP 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 33 •
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-10486 VSC8257-01 Datasheet Revision 4.1
84
Functional Descriptions
Table 33 •
PTP Comparison
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-10486 VSC8257-01 Datasheet Revision 4.1
85
Functional Descriptions
Table 33 •
PTP Comparison
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 34 •
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 35 •
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.6.15.13 Future 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-10486 VSC8257-01 Datasheet Revision 4.1
86
Functional Descriptions
at least one 64-bit word of separation between the start of the protocol and where the second starts to
operate.
3.6.15.14 Reconfiguration
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.6.15.15 Frame 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 36 •
Table 37 •
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 36, page 87 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-10486 VSC8257-01 Datasheet Revision 4.1
87
Functional Descriptions
Table 37 •
Frame Signature Address Source
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.6.15.16 Configuration 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.6.15.17 OAM-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-10486 VSC8257-01 Datasheet Revision 4.1
88
Functional Descriptions
3.6.16
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 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-10486 VSC8257-01 Datasheet Revision 4.1
89
Functional Descriptions
3.6.17
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.
3.6.17.1
Time Stamp FIFO CPU Access
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.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
90
Functional Descriptions
Note: Time stamp FIFO exists only in the Egress direction. There is no time stamp FIFO in the Ingress direction
3.6.17.2
Serial Time Stamp Output Interface
For each 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 FIFOs 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
CPU 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 90 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 90 and Figure 59, page 92.
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_CS negates after the last 1588_SPI_CLK
(SI_EN_OFF_CYCS). The number of clocks during which SI_CS 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-10486 VSC8257-01 Datasheet Revision 4.1
91
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 59 • Serial Time Stamp/Frame Signature Output
SPI_CS
SPI_Clk
SPI_ DO
4 3 2 1 0
Port
3.6.18
9 8 7
6 5 4
3 2 1 0
12
Fram e Identifier Data
(0 to 16 bytes)
9 8 7
6 5 4
3 2 1 00
Tim e stam p
(4 or 10 bytes)
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.6.18.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.6.18.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-10486 VSC8257-01 Datasheet Revision 4.1
92
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 60 • 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.6.19
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
CLK1588P/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 LTC_SEQUENCE.LTC_SEQUENCE_A
setting in femtoseconds. Register LTC_SEQ.LTC_SEQ_ADD_SUB indicates the direction of the error.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
93
Functional Descriptions
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 61 • Local Time Counter Load/Save Timing
LOAD_SAVE
CLK1588P
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-10486 VSC8257-01 Datasheet Revision 4.1
94
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.6.20
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 62 • 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
3.6.20.1
B
20 µs
C
160 µs
D
999819.0 µs
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.6.20.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.6.20.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-10486 VSC8257-01 Datasheet Revision 4.1
95
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 63 • ToD Octet Waveform
Transmitting 1 ToD Octet (10 µs)
LSB
0
High Voltage
MSB
0
1
0
1
0
1
1
Low Voltage
Start Bit
Stop 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.6.20.4
Idle Segment
Segment D is the Idle segment in Figure 62, page 95. 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 38 •
LTC Time Load/Save Options
LTC_CTRL.LOAD_EN SER_TOD_INTF.SER_TOD_INPUT_EN LTC_CTR.SAVE_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
1
0
1
Parallel Load and Save
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
96
Functional Descriptions
Table 38 •
LTC Time Load/Save Options (continued)
LTC_CTRL.LOAD_EN SER_TOD_INTF.SER_TOD_INPUT_EN LTC_CTR.SAVE_EN
Expected Operation
1
Serial Load and Save
1
1
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.6.21
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.6.22
Adjustment of LTC Counter
LTC counter value can be adjusted by about a second 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
109 – 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.
Subtraction operations should never be allowed because if the resultant subtraction is negative or
underflows, the LTC timer gets set to the wrong value.
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
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.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
97
Functional Descriptions
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.6.23
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 39 •
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
16
7.629394531 kHz
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
98
Functional Descriptions
Table 39 •
Output Pulse Frequencies (continued)
Nanosecond Counter Bit
Output Pulse Frequency
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.
3.6.24
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.
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.
Accuracy and Resolution
The IEEE 1588 processor achieves time stamp resolution in any mode of operation of 1 ns utilizing
special high-resolution circuitry. The accuracy of a device using high-resolution circuitry is improved
more than 100% over the first generation IEEE 1588 engine. High accuracy for these devices will be
supported regardless of the local time counter clock frequency supplied to the reference clock input. 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.
There are a total of five high resolution blocks per port to improve resolution for the following events:
•
•
•
•
•
One pulse-per-second (1PPS) output signal
1588_PPS_RI input signal
Start-of-frame in the egress direction
Start-of-frame in the ingress direction
1588_LOAD_SAVE input (strobe) signal direction
Each of these blocks can individually be enabled using ACC_CFG_STATUS. Contact Microsemi with any
questions regarding PTP accuracy calculations.
3.6.25
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.6.25.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.6.25.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.6.25.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.6.25.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-10486 VSC8257-01 Datasheet Revision 4.1
99
Functional Descriptions
3.6.26
Accessing 1588 IP Registers
Note: Contact Microsemi for an initialization script that supports the quick initialization of IEEE 1588 registers.
3.7
Flow Control Buffers
Flow control buffers are used in the data paths when the MACs are enabled. Ethernet frames are stored
in the buffers. When a buffer is close to being full, the MAC will issue a pause frame to the device
sending data to the VSC8257-01 device. This is done to prevent the data path's flow control buffer from
overflowing.
The flow control feedback is particularly common for the host interface when in 10G WAN mode due to
the transmitted line WAN data rate being less than the received host LAN data rate.
3.8
Rate Compensating Buffers
Rate compensating buffers are used in the data paths when the MACs are disabled. The rate
compensating buffers add and drop Idle characters between Ethernet packets when necessary to
address clock rate differences between the line-side and host-side interfaces. Rate offsets from ideal
frequencies measured in ppm (not MHz) can be tolerated.
The maximum data throughput on the line interface is less in 10G WAN mode than 10G LAN mode. The
line's data rate is reduced to 9.953 Gbps from 10.3125 Gbps. Part of that bandwidth includes
SONET/SDH frame overhead data. Care must be taken by the device sending data to the host interface
in the egress data path to ensure the rate compensating buffer does not overflow.
3.9
Loopback
The VSC8257-01 device has several options available to the user for routing traffic between the hostside and the line-side. The following table shows the name and location of the loopback modes. These
modes may be extremely useful for both test and debug purposes.
Note: When looping back the traffic from ingress of the PHY SFI input to egress of the PHY SFI output, the
jumbo frame will not work. If the application requires looping back the traffic external to the PHY on the
host side, the loopback has to contain the scheduler to throttle the egress traffic with the compliance of
the stretch ratio (13:1) required by WAN mode, as defined in the IEEE 802.3ae specification.
Line-Side Loopbacks
Table 40 •
Name
Location
L1
Host PCS after the gearbox (10G)
L2
XGMII interface (1G and 10G)
L2C
XGMII interface (1G and 10G)
L3
Line PMA interface (1G and 10G)
Table 41 •
Host-Side Loopbacks
Name
Location
H2
Host PMA interface (1G and 10G)
H3
Line PCS after the gearbox (10G)
H4
WIS-line PMA interface (10G)
The following illustration shows the host and line-side loopbacks.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
100
Functional Descriptions
Host
PMA
RX
Host
PCS
H2
RXOUT
3.10
Host
PMA
TX
L1
L2
Host
PCS
Host
MAC
1588
Line
MAC
Line
PCS
WIS
H3
L2C
Cross Connect
TXIN
Cross Connect
Figure 64 • Host-Side and Line-Side Loopbacks
Host
MAC
1588
Line
MAC
Line
PCS
H4
Line
PMA
TX
TXOUT
Line
PMA
RX
RXIN
L3
WIS
Cross Connect
Cross-connect is placed between the host PCS (and packet BIST) and the MAC/FIFOs. It interconnects
any of the 4 channels with one another, and each output is independently configurable. Since it switches
in the XGMII-64 interface layer, PCS link status is not affected by a switch (although corrupted packets
are certainly possible).
In addition to switching manually through the management interface, cross-connect allows for automatic
switching based on various events. To avoid false switching, it is highly recommended that customers
qualify the event and program the cross connect switching accordingly. For more information, contact a
Microsemi representative. The list of events includes PCS block-lock on both host and client in both 10G
and 1G mode, loss of alignment from the line side WIS, and external GPIO inputs (LOS from a module,
for example). The events that affect each mux, the assertion state of that event, and its priority are
configurable.
Because any of the four ports may be interconnected, 1:N protection may be possible.
Note: When cross connect is used, all ports should be sourced from the same local reference clock.
Note: The switching function is not hitless, and it will result in the momentary fragmentation of packets.
3.11
Host-Side Interface
The host interface of VSC8257-01 consists of the same PMA block utilized on the line side. This interface
has the same capabilities and feature set as the line side PMA discussed earlier.
3.12
Clocking
A flexible clocking architecture allows for various synchronous Ethernet (Sync-E) configurations as well
as per-port receive clock (repeater mode) timing. By default, the timing of each transmit interface is
based on the local oscillator (LREFCK). However, each transmit interface may be independently
synchronized to any one of several clock sources. The following illustration shows the port timing
architecture.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
101
Functional Descriptions
Figure 65 • Port Timing Architecture
PORT0
TXIN0
Deserializer
Data
Data
Rcvd Clk
Serializer
TXOUT0
Host 0 Rcvd
Host 3 Rcvd
Line 0 Rcvd
Synthesizer
Line 3 Rcvd
HRefck
HRefck
LRefck
SRefck
LRefck
SRefck
Host 3 Rcvd
Synthesizer
Host 0 Rcvd
Line 3 Rcvd
Line 0 Rcvd
Rcvd Clk
RXOUT0
Serializer
Data
Data
Deserializer
RXIN0
PORT1
PORT2
PORT3
Host 0 Rcvd
Host 3 Rcvd
Line 0 Rcvd
LREFCK
Synthesizer
Squelch
SCKOUT
Line 3 Rcvd
HREFCK
HRefck
SREFCK
SRefck
LRefck
Squelch Ctrl
Any individual transmitter can be synchronized to the recovered clock of any receiver, line or host sides.
In a typical Ethernet application, no special clocking configuration is required and all transmitters are
synchronized to the local reference clock, LREFCK.
In repeater mode, each individual transmitter must be synchronized to the recovered clock of the receiver
on the opposite side (for example, RXOUT0 output will be synchronized to the recovered clock from the
RXIN0 input). This is the Lane Sync feature described in Physical Media Attachment (PMA), page 10.
Note: Lane Sync cannot be enabled during either (dual sided) KR auto-negotiation (clause 73) and link training
(clause 72) operation or failover switching and cross connect operations (Cross Connect, page 101).
For Sync-E applications, additional circuitry is available to support multiple possible configurations.
3.12.1
Synchronous Ethernet Support
In addition to the local reference clock input, LREFCK (which is required in any case), a second, optional
reference clock, SREFCK, is available. SREFCK may be used as an alternate synchronization source
when LREFCK is a simple local oscillator. SREFCK includes filtering to smooth out changes in frequency
(on a clock source switch, for example). LREFCK does not include this capability; if using LREFCK as
the clock source in Sync-E applications, care must be taken to ensure that switching clock sources is
glitch-less.
3.12.1.1
SyncE Output Clock
Any recovered clock can be selected for the clock output from a dedicated Sync-E output clock,
SCKOUT. SCKOUT also includes a synthesizer that can be used to generate a Sync-E-friendly clock rate
regardless of the line-rate. In 10G LAN applications, for example, it can generate a 156.25 MHz clock
derived from the 10.3125 GHz recovered clock. It can also generate a 156.25 MHz clock derived from
the 9.95328 GHz recovered clock in a 10G WAN system.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
102
Functional Descriptions
SCKOUT also includes a squelch function that can be used to configure the device to squelch (drive to a
constant state) upon detecting certain conditions, such as loss of link on a PCS, or the state of a GPIO
input.
The device supports several synchronous Ethernet (SyncE) configurations. In SyncE applications,
typically a single master clock for all transmit interfaces is selected from multiple potential sources.
•
•
•
•
3.12.1.2
Single device, internal master: The line-side Rx captures the serial data input and generates a
clock signal that is then distributed to all ports of the line-side transmitter (Tx), creating a sourcesynchronous function.
Single clock LAN, external master: The LREFCK frequency is gradually changed to the externally
generated SyncE clock frequency using an external clock distribution chip. The change must be
hitless to avoid data corruption. The LREFCK source may come from one of the recovered clocks
using a CKOUT pin or SCKOUT.
Dual clock LAN, external master: The LREFCK remains connected to the stable 156.25 MHz
system clock or crystal. All line-side transmits are synchronized to SREFCK. One of the CKOUT
pins (161.13 MHz) or the SCKOUT pin (156.25 MHz) provides a recovered clock reference to the
external master.
Dual clock WAN, external master: LREFCK remains connected to the stable 156.25 MHz system
clock or crystal. All line side transmits are synchronized to SREFCK (155.52 MHz). SCKOUT
provides a recovered clock (156.25 MHz or 155.52 MHz) to be used as a reference to the external
master.
Output Clocks
In addition to the SCKOUT output, another clock output for each port, CKOUT[0:3], may be connected to
any port's transmit clock or recovered clock. When connected to a transmit clock, it may be used to drive
clocked optical modules. In Sync-E applications, it may be used (in lieu of SCKOUT) to provide a
recovered clock to an external timing master.
The following illustration shows the per-port clock outputs.
Figure 66 • Per-Port Clock Outputs
PORT0
TXIN0
Deserializer
Data
TXOUT0
Serializer
Data
Rcvd Clk
Line 0 Xmt
Line 3 Xmt
Host 0 Rcvd
Host 3 Rcvd
Host 0 Xmt
Host 3 Xmit
Line 0 Rcvd
Squelch
CKOUT0
Squelch Ctrl
Line 3 Rcvd
Rcvd Clk
RXOUT0
Serializer
Data
Data
Deserializer
RXIN0
PORT1
PORT2
PORT3
The rate of these clocks is the line rate divided by 32 or 64 (322.27 MHz or 161.13 MHz in 10G LAN
mode, for example).There is no provision to synthesize a Sync-E-friendly rate on CKOUT[0:3]. However,
should it be acceptable in a Sync-E application, the same clock squelching capability found on SCKOUT
is available.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
103
Functional Descriptions
3.13
Operating Modes
The VSC8257-01 device has three main operation modes: 10G LAN, 10G WAN, and 1 GbE. Each mode
may have the 1588 blocks on or off.
3.13.1
10G LAN with 1588
In 10G LAN mode with 1588, the host and line interfaces are LAN SFP+ (10.3125 Gbps). LREFCK and
HREFCK are used by the line-side and host-side interfaces respectively, to transmit appropriate rates.
For more information about supported reference clock frequencies, see Table 3, page 10. Rate
compensation is done in the FIFO.
Figure 67 • 10G LAN with 1588
TXIN
SerDes
Host
PCS
FIFO
1588
Line
PCS
WIS
HOST
SFP+/KR
LAN: 10.3125 Gbps
RXOUT
3.13.2
SerDes
SerDes
TXOUT
LINE
SFP+/KR
LAN: 10.3125 Gbps
Host
PCS
FIFO
1588
Line
PCS
WIS
SerDes
RXIN
10G WAN with 1588
In 10G WAN mode with 1588, the host interface is LAN SFP+ (10.3125 Gbps) and the line interface is
SONET/SDH STS-192c (9.95328 Gbps). LREFCK and HREFCK are used by the line-side and host-side
interfaces respectively, to transmit appropriate rates. For more information about supported reference
clock frequencies, see Table 3, page 10. A 622 MHz SREFCK reference frequency is not supported.
Rate compensation is done in the FIFO.
Figure 68 • 10G WAN with 1588
TXIN
SerDes
Host
PCS
FIFO
1588
Line
PCS
WIS
HOST
SFP+/KR
LAN: 10.3125 Gbps
RXOUT
3.13.3
SerDes
SerDes
TXOUT
LINE
SONET/SDH STS-192c
WAN: 9.95328 Gbps
Host
PCS
FIFO
1588
Line
PCS
WIS
SerDes
RXIN
1 GbE with 1588 and MACs
In 1 GbE mode with 1588 and MACs, the signal through the host and line interfaces is 1.25 Gbps.
LREFCK and HREFCK are used by the line-side and host-side interfaces respectively, to transmit
appropriate rates. For more information about supported reference clock frequencies, see Table 3,
page 10. MACs should be enabled to meet the pause turn around time spec as defined in the IEEE
specifications.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
104
Functional Descriptions
Figure 69 • 1 GbE with 1588 and MACs
TXIN
SerDes
Host
PCS
Host
MAC
Flow
Control
Buffer
1588
Line
MAC
Line
PCS
HOST
1 GbE
1G/SGMII 1.25 Gbps
RXOUT
3.14
SerDes
SerDes
TXOUT
LINE
1 GbE
1G/SGMII 1.25 Gbps
Host
PCS
Host
MAC
Flow
Control
Buffer
1588
Line
MAC
Line
PCS
SerDes
RXIN
Management Interfaces
This section contains information about the low-speed serial interfaces of the VSC8257-01 device. The
primary control and monitor interfaces in the design are as follows:
•
•
•
•
•
•
•
MDIO
SPI slave
Two-wire serial (slave)
Two-wire serial (master)
Push out SPI master for IEEE 1588 time stamp data
GPIO
JTAG
The VSC8257-01 device supports three different interfaces for accessing status and configuration
registers: MDIO, SPI slave, and two-wire serial slave. Only one of the interfaces can be active at a time.
The VSC8257-01 device doesn't arbitrate between these interfaces. Users must exercise caution and
ensure that multiple interfaces are not active at the same time.
The SPI slave interface is the recommended interface for accessing the status and configuration
registers of the 1588 block and the IEEE 1588 time stamp data
The VSC8257-01 device registers are arranged according to the MDIO devices as defined in IEEE 802.3
clause 45, as shown in the following list:
•
•
•
•
•
•
•
•
•
3.14.1
Device 1: Line PMA and line interface registers
Device 2: WIS registers
Device 3: Line 10G PCS, line 1G PCS, host 1G PCS, FC buffers, line MAC, and host MAC registers
Device 4: Rate compensating registers
Device 7: Line 10GBASE-KR registers
Device 9: Host PMA and host interface registers
Device B: Host 10G PCS registers
Device F: Host 10GBASE-KR registers
Device 1E: Global, SFP+, PLLs, GPIOs, cross-connect and 1588 registers
MDIO Interface
The MDIO interface in the VSC8257-01 device complies with IEEE 802.3ae Clause 45. For more
information, see the IEEE standard. The MDIO management interface consists of a bi-directional data
path (MDIO) and a clock reference (MDC).
MDIO instructions can be used to read registers, write registers, and perform
post-read-increment-address instructions. Due to its slow bandwidth and high latency, the MDIO
interface is not recommended as the only interface to access the VSC8257-01 device.
Note: The maximum data rate of the MDIO interface is 2.5 Mbps.
The PADDR[4:2] pins select the MDIO port addresses to which the VSC8257-01 device will respond. A
single VSC8257-01 device requires the use of four MDIO port addresses, one for each channel. The port
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
105
Functional Descriptions
address transmitted in MDIO read/write commands to access registers in a particular VSC8257-01
channel is shown in the following table. The port address is a function of the PADDR pins and a
pre-programmed number indicating the channel number. Up to eight VSC8257-01 devices can be
controlled by a single MDIO host.
Table 42 •
3.14.1.1
MDIO Port Addresses Per Channel
Channel Number
Channel’s Port Address
3
{PADDR[4:2], 11}
2
{PADDR[4:2], 10}
1
{PADDR[4:2], 01}
0
{PADDR[4:2], 00}
Accessing 32-Bit Data Registers
Even though the MDIO interface is defined to access 16-bit data registers, 32-bit configuration and status
registers are present in the line and host MACs in 1G mode, 1588, and line-side SerDes. Use the
following steps when accessing registers in 32-bit blocks.
3.14.1.1.1 Write to 32-Bit Register
1. Issue address instruction specifying the MDIO address for bits [31:16].
2. Issue write instruction to write data to register bits [31:16].
3. Issue address instruction specifying the MDIO address for bits [15:0].
4. Issue write instruction to write data to register bits [15:0].
Note: Writing to the two halves of the 32-bit register in the opposite order is not permitted. Nor is it possible to
write to only one-half of the register. All four MDIO instructions must be issued to write to a 32-bit
register.
3.14.1.1.2 Read 32-Bit Register
1. Issue address instruction specifying the MDIO address for bits [15:0].
2. Issue read-increment instruction. The data read is the contents of register bits [15:0].
3. Issue read instruction. The data read is the contents of register bits [31:16].
Note: Perform all three steps to read a 32-bit register even when reading consecutive addresses. Issuing backto-back read-increment instructions to read consecutive 32-bit register addresses is not supported.
Register addresses listed for the line and host MACs 1588, and SerDes apply to the SPI slave and twowire serial slave interfaces, which support direct access to 32-bit data registers. There are two MDIO
addresses for each of these 32-bit data registers: one address to access data bits [31:16] and one
address to access data bits [15:0]. Contact Microsemi for support using the MDIO interface to access line
and host MACs 1588, and SerDes registers.
3.14.2
SPI Slave Interface
The VSC8257-01 device supports the serial peripheral interface (SPI) for reading and writing registers for
high bandwidth tasks such as reading IEEE 1588 time stamp data. The SPI interface is also capable of
accessing all status and configuration registers. The SPI slave port consists of a clock input (SCK), data
input (MOSI), data output (MISO), and slave select input (SSN).
Note: The SPI slave interface is the recommended interface to access status and configuration registers for the
rest of the device.
Drive the SSN pin low to enable the interface. The interface is disabled when SSN is high and MISO is
placed into a high impedance state. The VSC8257-01 device captures the state of the MOSI pin on the
rising edge of SCK. 56 data bits are captured on the MOSI pin and transmitted on the MISO pin for each
SPI instruction. The serial data bits consist of 1 read/write command bit, 23 address bits, and 32 register
data bits.
The 23-bit addressing scheme consists of a 2-bit channel number, a 5-bit MDIO device number, and a
16-bit register number. For example, the 23-bit register address for accessing the
GPIO_0_Config_Status register in channel 1 (device number is 0x1E and register number is 0x0100) is
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
106
Functional Descriptions
0x3E0100. The notion of device number conforms to MDIO register groupings. For example, device 2 is
assigned to WIS registers.
The following table shows the order in which the bits are transferred on the interface. Bit 55 is transferred
first, and bit 0 is transferred last. This sequence applies to both the MOSI and MISO pins.
Table 43 •
SPI Slave Instruction Bit Sequence
Bit
Name
Description
55
Read/Write
0: Read
1: Write
54:53
Port/Channel Number
00: Port/Channel 0
01: Port/Channel 1
10: Port/Channel 2
11: Port/Channel 3
52:48
Device Number
5-bit device number
Bit 4 corresponds to SPI instruction bit 52
Bit 0 corresponds to SPI instruction bit 48
47:32
Register Number
16-bit register number
Bit 15 corresponds to SPI instruction bit 47
Bit 0 corresponds to SPI instruction bit 32
31:0
Data
32-bit data
Bit 31 corresponds to SPI instruction bit 31
Bit 0 corresponds to SPI instruction bit 0
The register data received on the MOSI pin during a write operation is the data value to be written to a
VSC8257-01 register. Register data received on the MOSI pin during a read operation is not used, but
must still be delivered to the device.
The VSC8257-01 device SPI slave has a pipelined read process. Two read instructions must be sent to
read a single register. The first read instruction identifies the register address to be read. The MISO data
transmitted on the second read instruction contains the register contents from the address specified in
the first instruction. While a pipelined read implementation is not the most efficient use of bandwidth to
read a single register, it is very efficient when performing multiple back-to-back reads as would be the
case when reading 1588's TSFIFO_* registers. The second read instruction contains the address for the
second register to be read plus the data read from the first register. The third read instruction contains the
address for the third register to be read plus the data read from the second register. Register reads can
continue in this fashion indefinitely. The following illustrations show the situations where back-to-back
read instructions are issued.
Figure 70 • SPI Single Register Read
MOSI
MISO
R
ADDR A
(Don t care)
R
ADDR B
(Don t care)
Depends on previous instruction
R
ADDR A
Read
DATA A
SPI Read
Instruction #1
SPI Read Instruction
#2
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
107
Functional Descriptions
Figure 71 • SPI Multiple Register Reads
MOSI
MISO
R
ADDR A
(Don t care)
Depends on previous instruction
R
ADDR B
(Don t care)
R
ADDR C
(Don t care)
R
ADDR D
(Don t care)
R
ADDR A
Read
DATA A
R
ADDR B
Read
DATA B
R
ADDR C
Read
DATA C
The SPI read instruction figures also point out the read/write state and address bits on the MISO output
match the information received in the previous instruction. The SPI master could use this data to verify
the device captured the previous instruction properly, or simply ignore the data. The following illustration
shows the MISO output during write instructions reporting the previous instruction's read/write state,
address, and register write data.
Figure 72 • SPI Multiple Register Writes
MOSI
W
ADDR A
Write
DATA A
Depends on previous instruction
MISO
W
ADDR B
Write
DATA B
W
ADDR C
Write
DATA C
W
ADDR A
Write
DATA A
W
ADDR B
Write
DATA B
The following illustration shows that when a read instruction follows a write instruction, the MISO data
during the read instruction is the data field from the previous write.
Figure 73 • SPI Read Following Write
MOSI
W
ADDR A
Write
DATA A
Depends on previous
instruction
MISO
W
ADDR B
Write
DATA B
R
ADDR C
(Don t
care)
W
ADDR A
Write
DATA A
W
ADDR B
Write
DATA B
The following illustration shows that when a write instruction followings a read instruction, the MISO data
during the write instruction is not pipelined read data. MISO contains all 0's in the data field.
Figure 74 • SPI Write Following Read
MOSI
MISO
R
ADDR A
(Don t care)
Depends on previous instruction
R
ADDR B
(Don t care)
W
ADDR C
Write
DATA C
R
ADDR A
Read
DATA A
R
ADDR B
Read
DATA B
Some VSC8257-01 registers are made up of less than 32 data bits. Any bits not defined for a register will
return a 0 when the register is read. Reading an invalid register address will return 0x0.
There is one hazard condition to be aware of when issuing two read instructions to read a single clearon-read register. Issuing two read instructions internally fetches data twice even though valid read data is
present only in the second instruction. Fetching data also resets a clear-on-read register. The address
specified in the second read instruction should be something other than the clear-on-read register
address. This prevents an event causing register re-assertion occurring between the two read
instructions from being cleared and never detected. The address in the second instruction can be any
register not having a clear-on-read function. Device_ID is one example. The same address can be used
in each read instruction when continuously polling a clear-on-read register. This works because
subsequently fetched data is transmitted from the interface allowing assertion between reads to be
detected. Only the last read instruction where fetched data is not transmitted should some other address
in the instruction be used.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
108
Functional Descriptions
3.14.2.1
MISO Output Timing Modes
MISO changes state when SCK transitions from high to low in the default SPI operating mode. This aids
in meeting hold time at the SPI master assuming the master captures the data on the rising SCK edge.
The SPI port can run up to a maximum of 30 Mbps depending upon the VSC8257-01 device SCK-toMISO timing, MISO loading SCK duty cycle, the board layout, and the external SPI master's interface
timing requirements. For more information about SPI timing, see Table 64, page 129.
The SPI slave port has an alternate operating mode that allows the interface to run faster. Setting register
bit SPI_CTRL.FAST_MODE=1 configures the SPI slave such that MISO changes state when SCK
transitions from low to high. Thus, data is both transmitted from the SPI slave and captured by the SPI
master on a rising SCK edge. The interface can run faster in this mode by using the entire SCK clock
period instead of half the period to transfer data from the slave to the master. Care must be taken to
ensure the SPI master's hold time requirement is met. The following illustrations show MISO timing in the
default and slave modes.
Figure 75 • SPI Slave Default Mode
SSN
MOSI
R/W
...
ADDR[22]
...
DATA[31]
R/W
ADDR[22]
DATA[1]
DATA[0]
...
...
SCK
MISO
ADDR[0]
...
ADDR[21]
DATA[31]
...
DATA[30]
DATA[0]
R/W
MISO data based on previous
instruction
R/W data matches this instruction and carries over to next instruction
Figure 76 • SPI Slave Fast Mode
SSN
MOSI
R/W
ADDR[22]
ADDR[0]
DATA[31]
...
SCK
MISO
...
R/W
ADDR[22]
ADDR[21]
...
DATA[1]
DATA[0]
...
...
DATA[31]
DATA[30]
...
DATA[0]
R/W
MISO data based on previous
instruction
R/W data matches this instruction and carries over to next instruction
MISO output timing is the only difference between the two SPI modes. Sampling of MOSI on the rising
SCK clock edge remains the same so writing to the VSC8257-01 device registers is identical in both
modes. Thus the SPI_CTRL.FAST_MODE register setting may be modified using the SPI slave port to
change the port's MISO output timing.
3.14.3
Two-Wire Serial (Slave) Interface
The VSC8257-01 device registers may be read and written using a two-wire serial slave interface. The
two-wire serial slave SCL and SDA pins are multifunction general purpose I/O (GPIO) pins, GPIO_33
and GPIO_32, respectively. The GPIO pins are configured to serve SCL and SDA functions following
device reset.
The slave address assigned to the VSC8257-01 device. is a function of four fixed values and the MDIO
port address pins. The 7-bit slave address is {1000, PADDR4, PADDR3, PADDR2}. The use of the port
address pins allows multiple VSC8257-01 devices to be serviced by a single two-wire serial (master).
The maximum data transfer rate for the interface is 400 kbps.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
109
Functional Descriptions
Note: The two-wire serial slave interface does not work with two-wire serial masters using 10-bit slave
addresses.
A valid START condition is generated by a two-wire serial master device by transitioning the SDA line
from high to low while the SCL line is high. Data is then transferred on the SDA line, most significant bit
(MSB) first, with the SCL line clocking data. Data transitions during SCL low periods are valid (read) or
latched (write) when SCL pulses high then low. Data transfers are acknowledged (ACK) by the receiving
device for data writes and by the master for data reads. An acknowledge is signaled by holding the SDA
signal low while pulsing SCL high then low. The master terminates data transfer by generating a STOP
condition by transitioning SDA low to high while SCL is high.
Note: If the external two-wire serial master device gets out of sync with the two-wire serial slave interface, the
master device must issue a bus reset sequence. This puts the two-wire serial slave interface back into a
state that allows it to receive future two-wire serial instructions. The external two-wire serial master
device and the two-wire serial slave interface can become out-of-sync and freeze the bus if either device
is reset during an instruction.
The following illustration shows a two-wire serial bus reset sequence. The reset sequence consists of a
START symbol, nine SCK clock pulses while SDA is high, another START symbol, and a STOP symbol.
Figure 77 • Two-Wire Serial Bus Reset Sequence
Nine Clock Pulse
START
START
1
2
8
STOP
9
Registers in the VSC8257-01 device are accessed using the 24-bit addressing scheme. The first 8 bits
consist of one logic LOW, the channel number (00, 01, 10, 11), and the 5-bit MDIO device number of the
register to be accessed. The next 16 bits are the register number. For example, the 24-bit register
address for accessing the GPIO_0_Config_Status register in channel 1 (device number 0x1E and
register number 0x0100) is 0x3E0100. The notion of device number conforms to MDIO register
groupings. For example, device 2 is assigned to WIS registers. The following illustration shows the 24-bit
addressing scheme used to access registers.
Figure 78 • Two-Wire Serial Slave Register Address Format
S
slv_addr[6:0], W
“0”, ch[1:0], dev[4:0]
reg_addr[15:9]
reg_addr[7:0]
An illegal two-wire serial slave read instruction to an invalid channel number, device number, or register
address will return a read value of 0x0000 when the slave address matches this device.
Four bytes of data are transferred on the two-wire serial bus after the address when a register is read or
written. Data register bits [31:24] are transferred first, followed by bits [23:16], bits [15:8], and finally bits
[7:0]. An ACK symbol is sent between each byte of data. Any bits not defined in a register will return a 0
when the register is read.
The following illustration shows the data transferred on the SDA pin during a register write operation. The
R/W bit following the slave address is set to logic low to specify a write operation.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
110
Functional Descriptions
Figure 79 • Two-Wire Serial Write Instruction
S
T
A
R
T
W
R
I
T
E
Slave Address
1 0 0
0
Register Address
0
0
A
C
K
R A
/ C
W K
A
C
K
A
C
K
S
T
O
P
B
I
T
A
C
K
A
C
K
B A
I C
T K
A
C
K
0
3
1
Data Written to Register
The register address to be accessed is specified by initiating a write operation. After the slave address
and three register address bytes are sent to the VSC8257-01 device, a START condition must be resent, followed by the slave address with the read/write bit set to logic high. The four-byte data register
contents are then transmitted from the VSC8257-01 device. The two-wire serial (master) sends NO ACK
after the fourth data byte to indicate it has finished reading data. The following illustration shows data
transferred on the SDA pin during a register read operation.
Figure 80 • Two-Wire Serial Read Instruction
S
T
A
R
T
Slave Address
1 0 0 0
W
R
I
T
E
0
S
T
A
R
T
Register Address
Slave Address
1 0 0
0
A
C
K
R A
/ C
W K
A
C
K
0
R
E
A
D
1
R A
/ C
W K
A
C
K
Dummy Write to set Read Address
S
T
O
P
B
I
T
A
C
K
A
C
K
A
C
K
3
1
B N
I O
T
A
0 C
K
Data Read from Register
The two-wire serial slave interface supports sequential read and sequential write instructions.
3.14.4
Two-Wire Serial (Master) Interface
A two-wire serial master interface in the VSC8257-01 channel is available for SFP+/XFP module
management. A two-wire serial master interface per channel is required because the slave address in
the optics modules are identical. Two-wire serial interface instructions used to access optics module
registers are initiated by writing to VSC8257-01 registers. The two-wire serial interface busses are
brought out through GPIO pins by configuring the desired GPIO pins to function as SDA and SCL.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
111
Functional Descriptions
The two-wire serial master interface must be configured before initiating any instructions. The slave ID to
be transmitted in the first byte of every instruction is selectable in the SLAVE_ID register. The default
setting is 0x50. The interface's data rate is determined by the PRESCALE register. The default data rate
is 400 kbps.
The two-wire serial master transmits instructions for slave devices with 8-bit data registers and 256
register addresses per slave ID. Always read register I2C_BUS_STATUS.I2C_BUS_BUSY or
I2C_READ_STATUS_DATA.I2C_BUS_BUSY to verify the previous instruction has finished prior to
initiating a new instruction. Instructions initiated when the interface is busy will be ignored. Both registers
report the same interface busy status. The same busy status is reported in two registers for user
convenience.
The two-wire serial master initiates a write instruction when the I2C_WRITE_CTRL register is written.
The value written to I2C_WRITE_CTRL.WRITE_ADDR is the register address to be modified in the slave
device. The value written to I2C_WRITE_CTRL.WRITE_DATA is the data to be written to the slave
device's register. The I2C_BUS_STATUS register reports the status of the write instruction.
I2C_BUS_STATUS.I2C_BUS_BUSY indicates when the instruction has finished.
I2C_BUS_STATUS.I2C_WRITE_ACK=1 means the two-wire serial master received ACKs from the slave
at appropriate times. I2C_BUS_STATUS.I2C_WRITE_ACK is cleared each time a new instruction is
issued. If the two-wire serial master did not receive ACKs from the slave at appropriate times
(I2C_BUS_STATUS.I2C_WRITE_ACK=0), the interface is likely stuck in a state waiting for the ACK.
Writing a 1 to the BLOCK_LEVEL_RESET1.I2CM_RESET register will reset the two-wire serial master
and release it from its stuck state. The slave device should then be put into a known state by writing any
value to the I2C_RESET_SEQ register. The two-wire serial master issues a bus reset sequence when
this register is written. For more information, see Two-Wire Serial (Slave) Interface, page 109.
The two-wire serial master initiates a read instruction when the I2C_READ_ADDR register is written. The
value written to I2C_READ_ADDR.READ_ADDR is the register address to be accessed in the slave
device. I2C_READ_STATUS_DATA.READ_DATA contains the data read from the slave device.
READ_DATA is not valid until I2C_READ_STATUS_DATA.I2C_BUS_BUSY=0 to indicate the instruction
completed. The two-wire serial master does not support read-increment instructions.
3.14.5
Push Out SPI Master Interface
To overcome MDIO speed limitations for faster or large amounts of time stamp reads, the VSC8257-01
device supports a push out SPI master interface. The SPI output is used to push out time stamp
information to an external device only and does not provide read/write to the rest of the status and
configuration registers. For more information, see Serial Time Stamp Output Interface, page 91.
The push out SPI master interface consist of SPI_CLK_01, SPI_DO_01 and SPI_CS_01 to generate
1588 times tamps for channels 0 and 1, and SPI_CLK_23, SPI_DO_23 and SPI_CS_23 to generate
1588 time stamps for channels 2 and 3.
3.14.6
JTAG
The VSC8257-01 device has an IEEE 1149.1–2001 compliant JTAG interface. The following table shows
the supported instructions and corresponding instruction register codes. The code's least significant bit is
shifted into TDI first when loading an instruction (the 0 is shifted in first when loading the IDCODE
instruction).
Table 44 •
JTAG Instructions and Register Codes
Instruction
Register Code
IDCODE
1111111111111111111111110
BYPASS
1111111111111111111111111
EXTEST
1111111111111111111101000
EXTEST_PULSE
1111111101111111111101000
EXTEST_TRAIN
1111111011111111111101000
SAMPLE
1111111111111111111111000
Notes
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
112
Functional Descriptions
Table 44 •
JTAG Instructions and Register Codes (continued)
Instruction
Register Code
PRELOAD
1111111111111111111111000
LV_HIGHZ
1111111111111111111001111
Provides the ability to place outputs in a high
impedance state to facilitate manufacturing
test and PC board diagnostics. The SFP+
serial data outputs are not put into the high
impedance state when this instruction is
loaded in the JTAG TAP controller.
CLAMP
1111111111111111111101111
Provides the ability to place all outputs in a
predefined state when the scan process is
being used to test other devices on a PC
board.
3.14.7
Notes
General Purpose I/O
The general purpose I/O (GPIO) functions are organized into 2 groups: per-channel functions and global
functions. Per-channel functions include an I2C master (often used for communicating with a module),
host and line link status indications, activity LEDs, and WAN interface sublayer (WIS), and ROSI/TOSI
interface functions. Global functions include interrupt generation logic, an I2C slave interface, and other
miscellaneous I/O configuration and control.
The 40 pins associated with the GPIO functionality are configurable; any function can be mapped to any
GPIO pin. The only restriction is that for each channel, only 8 of the per-channel GPIO output functions
may be used at a time (note that the ROSI/TOSI interface requires 5 outputs and 1 input).
All GPIOs are configured for open-drain operation, so if used as an output, they must have pull-up
resistors connected.
The following block diagram shows the GPIO scheme.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
113
Functional Descriptions
Figure 81 • GPIO Block Diagram
Channel 3
Channel 2
Channel 1
Channel 0
I2c_mstr_data_o
Tosi_sclk_o
I2c_mstr_clk_o
Rosi_sdat_o
Led _tx_o
Pcs_block_lock
CSR
Target
Ch0_tosi_sdat_i
Ch0_lopc_i
Ch3_i2c_mstr_data_i
Chip level inputs
Chip level outputs
CSR Target
+
associated
logic
GPIO
Output
Inverts
GPIO
Output
enables
0
0
TRI
TRI
GPIO[0]
0
TRI
GPIO[1]
GPIO[37]
The following table shows the recommended GPIO pin configurations. Contact Microsemi applications
support for recommendations on alternative GPIO configurations.
Table 45 •
Recommended GPIO Configurations
GPIO
Configuration
GPIO_0
CH0_RATESEL0
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
114
Functional Descriptions
Table 45 •
Recommended GPIO Configurations (continued)
GPIO
Configuration
GPIO_1
CH0_MOD_ABS
GPIO_2
CH0_I2C_MST_SCL
GPIO_3
CH0_I2C_MST_SDA
GPIO_4
CH0_TX_DIS
GPIO_5
CH0_TX_FAULT
GPIO_6
CH0_RXLOS(1)
GPIO_7
CH0_LINK_UP
GPIO_8
CH1_RATESEL0
GPIO_9
CH1_MOD_ABS
GPIO_10
CH1_I2C_MST_SCL
GPIO_11
CH1_I2C_MST_SDA
GPIO_12
CH1_TX_DIS
GPIO_13
CH1_TX_FAULT
GPIO_14
CH1_RXLOS
GPIO_15
CH1_LINK_UP
GPIO_16
CH2_RATESEL0
GPIO_17
CH2_MOD_ABS
GPIO_18
CH2_I2C_MST_SCL
GPIO_19
CH2_I2C_MST_SDA
GPIO_20
CH2_TX_DIS
GPIO_21
CH2_TX_FAULT
GPIO_22
CH2_RXLOS
GPIO_23
CH2_LINK_UP
GPIO_24
CH3_RATESEL0
GPIO_25
CH3_MOD_ABS
GPIO_26
CH3_I2C_MST_SCL
GPIO_27
CH3_I2C_MST_SDA
GPIO_28
CH3_TX_DIS
GPIO_29
CH3_TX_FAULT
GPIO_30
CH3_RXLOS
GPIO_31
CH3_LINK_UP
GPIO_32
I2C_SLAVE_SDA
GPIO_33
I2C_SLAVE_SCL
GPIO_34
INTR_A
GPIO_35
INTR_B
GPIO_36
CH0_ACTIVITY
GPIO_37
CH1_ACTIVITY
GPIO_38
CH2_ACTIVITY
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
115
Functional Descriptions
Table 45 •
GPIO
Configuration
GPIO_39
CH3_ACTIVITY
1.
3.14.7.1
Recommended GPIO Configurations (continued)
Optional wire-or between RXLOS and LINK_UP
Inputs
The input state of the GPIO pins can be routed to any of GPIO input functions in each channel, or to any
of the global functions. The multiplexors for each of these functions may select any of the GPIOs, or a “0”
or “1” to force the function input to a known state.
By default, GPIO32 and GPIO33 are routed to the I2C slave input data and input clock, respectively.
The current state of each GPIO input can be read, and a sticky bit corresponding to each GPIO input
indicates if it has changed state. These may be useful for monitoring module status signals such as
MOD_ABS, TWS_INTERRUPT, and so on.
3.14.7.2
Outputs
A set of eight multiplexors in each channel select the per-channel output functions that are routed out to
each of the eight per-channel virtual GPIO outputs. These multiplexors are configured using the
configuration/status module in the channel. A second level of multiplexing occurs at the GPIO pin itself,
where the individual per-channel virtual outputs, as well as chip level output functions, are associated
with a particular GPIO output.
There are additional chip-level functions (such as interrupts) that may also be assigned to a GPIO pin.
Each output may also be configured to drive a static low or static high.
All outputs are initially disabled except for GPIO32, which is by default assigned as the I2C slave output
data.
3.14.7.3
Interrupts and Interrupt Masking
The VSC8257-01 has configurable interrupt generators that can be used to flag error or alarm conditions
which can, in turn, be used to prompt external controllers to take action upon certain events. Multiple
blocks in a given channel contain these maskable interrupts (including line and host PMAs, line and host
PCSs, the WIS, and rate-adaptation FIFOs). Each of the channel interrupt sources is routed to 2 interrupt
generators per channel. For each per-channel interrupt generator, the sources that contribute to that
interrupt are independently maskable using channel interrupt enables. Also, the status of each masked
interrupt source is always readable in the channel so that the source of the interrupt can be determined
quickly.
At the chip level, each ip1588 instance generates 2 interrupts and 2 time stamp FIFO status indicators.
There is also an interrupt produced by the cross-connect. Finally, any GPIO input can be configured to
produce an interrupt upon state change.
All the chip-level interrupts, as well as the 8 channel interrupts, are routed to each of 4 aggregate
interrupt generators. The source of the interrupts for each aggregator is independently maskable (see
note) using global interrupt enables, and the masked status of each interrupt is readable in the global
target for quick determination of the source of the interrupt.
Note: While there are four interrupt generators, in the case of GPIO input state change detection, there is only
one mask shared among all four interrupt aggregators.
Any GPIO may be configured to output the state of any of the 4 interrupts.
The following figure shows an overview of the interrupt blocks.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
116
Functional Descriptions
Figure 82 • Interrupt Scheme
Channel 3
Channel 2
Channel 1
Channel 0
Host_pma_intr
Line_pcs10g_intr
Wis_intr1
Channel
Interrupt
enables
CSR Target
and
Associated
Logic
Read back
of masked
interrupt
status
Cross_connect
intr0
intr1
Ip1588_0
Ip1588_1
Global
Interrupt
enables
GPIO D detect
Global
CSR Target
and
Associated
Logic
Read back
of masked
interrupt
status
Agg_intr[0]
Agg_intr[3]
To GPIO outputs
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
From GPIO inputs
117
Registers
4
Registers
Information about the registers for this product is available in the attached Adobe Acrobat file. To view or
print the information, double-click the attachment icon.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
118
Electrical Specifications
5
Electrical Specifications
This section provides the DC characteristics, AC characteristics, recommended operating conditions,
and stress ratings for the VSC8257-01 device.
5.1
DC Characteristics
This section contains the DC specifications for the VSC8257-01 device.
5.1.1
Low-Speed Inputs and Outputs
The following tables list the DC specifications for the LVTTL inputs and outputs for the VSC8257-01
device. LVTTL inputs are 3.3 V tolerant when VDDTTL is 2.5 V.
Table 46 •
LVTTL Input and Push/Pull Output DC Characteristics
Parameter
Symbol
Minimum
Maximum
Unit
Condition
Output high voltage,
LVTTL
VOH_TTL
1.8
VDDTTL
V
VDDTTL = 2.5 V and
IOH = –4 mA
Output low voltage,
LVTTL
VOL
0.5
V
VDDTTL/VDDMDIO = 2.5 V
and IOL = 4 mA
Input high voltage
VIH
VDDTTL
V
VDDTTL/VDDMDIO = 2.5 V
Input low voltage
VIL
0.8
V
VDDTTL/VDDMDIO = 2.5 V
Input high current
IIH
500
µA
VIH = VDDTTL/VDDMDIO
Input low current
IIL
µA
VIL = 0 V
Table 47 •
1.7
–100
LVTTLOD Input and Open-Drain Output DC Characteristics
Parameter
Symbol
Minimum
Output high voltage,
open drain
VOH_OD
note1
Maximum
Unit
Condition
VDDTTL
V
VDDTTL/VDDMDIO = 2.5 V
and IOH = –4 mA
Input high leakage
current, open drain
IOZH
100
µA
Output low voltage
(open drain)
VOL
0.5
V
See
Input high voltage
VIH
VDDTTL
V
VDDTTL/VDDMDIO = 2.5 V
Input low voltage
VIL
0.8
V
VDDTTL/VDDMDIO = 2.5 V
Input high current
IIH
500
µA
VIH = VDDTTL/VDDMDIO
Input low current
IIL
µA
VIL = 0 V
1.
1.7
VDDTTL/VDDMDIO = 2.5 V
and IOL = 4 mA
–100
Determined by the loading current of the other devices connecting to this pin, the IOZH current of this pin, and
the value of the pull-up resistor used.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
119
Electrical Specifications
5.1.2
Reference Clock
The following table lists the DC specifications for the reference clock for the VSC8257-01 device.
Table 48 •
Reference Clock DC Characteristics
Parameter
Symbol
Maximum
Unit
HREFCK/LREFCK differential ∆VI_DIFF_HIGH 1100
input swing, high1
2400
mVP-P LVPECL
reference clock
input
HREFCK/LREFCK differential ∆VI_DIFF_LOW 200
input swing, low1
1200
mVP-P CML reference
clock input
2400
mVP-P
SREFCK differential input
swing
1.
5.2
∆VI_DIFF
Minimum
200
Condition
An API call is used to set the input swing to be high or low.
AC Characteristics
This section contains the AC specifications for the VSC8257-01 device. The specifications apply to all
channels. All SFI inputs and outputs should be AC-coupled, and should work in differential.
5.2.1
Receiver Specifications
The specifications in the following table correspond to line-side 10G receiver input, SFI point D. Point D
assumes that the input is from a compliant point C output and a compliant SFI or XFI channel according
to the SFP+ standard (SFF-8431) or the XFP multisource agreement (INF-8077i). The measurement is
done with a 9 dB channel loss unless stated otherwise.
The SFI and XFI input of the 10G receiver are tested and characterized to support the ITU-T
recommendation G.709 (OTN) OTU2, OTU1e, and OTU2e line rates (10.709 Gbps, 11.049 Gbps, and
11.095 Gbps) with a channel loss of 6.5 dB or less.
Note: OTN rates and 10/100M rates under SGMII are only supported in repeater mode. For additional details
regarding OTN line rates and the corresponding electrical characteristics, contact your Microsemi
representative.
The CDR lock time at the 10G input to the PMA is 5 µs, maximum.
Table 49 •
Host- and Line-Side 10G Receiver Input (SFI Point D)
Parameter
Symbol
Input data rate
Minimum
Typical
Maximum
Unit
Condition
9.95328 –
100 ppm
10.3125
10.3125 +
100 ppm
Gbps
10 Gbps LAN/WAN
Input linear mode
differential input data
swing
∆VRXINLINEAR
180
600
mV
Voltage modulation
amplitude (VMA)
Input limiting mode
differential input data
swing
∆VRXINLIMITING 300
850
mV
Measured peak-to-peak
Input AC
VCM
common-mode voltage
15
mVRMS
Differential return loss
RLSDD11
–12
dB
0.01 GHz to 2.8 GHz
Differential return loss
RLSDD11
–8.15 +
13.33 x
log10(f/5.5
GHz)
dB
2.8 GHz to 11.1 GHz
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
120
Electrical Specifications
Table 49 •
Host- and Line-Side 10G Receiver Input (SFI Point D) (continued)
Parameter
Symbol
Minimum
Typical
Reflected differential to RLSCD11
common-mode
conversion
Table 50 •
Maximum
Unit
Condition
–15
dB
0.01 GHz to 11.1 GHz
Condition
Host- and Line-Side 10G Receiver Input (SFI Point C”)
Parameter
Symbol
Maximum
Unit
99% jitter
99%JIT_p-p
Minimum
Typical
0.42
UI
Pulse width shrinkage
jitter
DDPWSJIT_p-p
0.3
UI
Total jitter tolerance
TOLJIT_P-P
0.70
UI
Eye mask X1
X1
0.35
UI
Eye mask Y1
Y1
Eye mask Y2
Y2
425
mV
Waveform distortion
penalty
WDPc
9.3
dBe
BER 1E–12. This
parameter of DAC is
measured with 7dB SFI
channel loss.
Voltage modulation
amplitude
VMA
mV
BER 1E–12. This
parameter of DAC is
measured with 7dB SFI
channel loss.
Optical sensitivity
(ROP), back-to-back,
10.3 Gbps
SB2B
–24
dBm
BER 1E–12, PRBS31
and 10 GbE frame.
5.76 dB SFI channel loss.
Optical sensitivity
SFIBER
(ROP), with fiber plant,
10.3 Gbps
–21
dBm
95 km single-mode fiber,
BER 1E–12, PRBS31
and 10 GbE frame.
5.76 dB SFI channel loss.
Chromatic dispersion
penalty
FCDP
3
dB
1600 ps/nm. 5.76 dB SFI
channel loss.
OSNR vs BER with
fiber plant, 10.7 Gbps
OSNRFEC
dB
95 km single-mode fiber,
BER 7E–4, 5.76 dB SFI
channel loss.
150
mV
180
16
The following illustration shows the sinusoidal jitter tolerance for the SFI datacom.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
121
Electrical Specifications
Sinusoidal Jitter Tolerance (UIp-p)
Figure 83 • SFI Datacom Sinusoidal Jitter Tolerance
–20 dB/Dec
5.0
0.05
0.04
0.4
4
40
Frequency (MHz)
The following table lists the 10G input jitter specifications for the VSC8257-01 device.
Table 51 •
Host- and Line-Side SONET 10G Input Jitter
Parameter
Symbol
Minimum
Typical
Maximum
Unit
Input data rate, 10 Gbps
WAN
9.95328 –
100 ppm
9.95328
9.95328 +
100 ppm
Gbps
Sinusoidal jitter tolerance, SJT
9.95 Gbps
2x jitter mask
Condition
GR-253 according to
SONET OC-192 standard
The following table lists the line-side 1.25 Gbps SFI input specifications for the VSC8257-01 device.
Table 52 •
Host- and Line-Side 1.25 Gbps SFI Input
Parameter
Symbol
Input data rate, 1.25 Gbps
Minimum
Typical
Maximum
Unit
Condition
1.25 –
100 ppm
1.25
1.25 +
100 ppm
Gbps 1.25 Gbps mode
Differential input return loss
RLISDD11
–10
dB
50 MHz to 625 MHz
Differential input return loss
RLISDD11
–10 + 10 x log
(f/625 MHz)
dB
625 MHz to 1250 MHz
Total jitter tolerance
TJT
0.749
UI
Jitter above 637 kHz
(IEEE 802.3 clause 38.5)
Deterministic jitter
DJ
0.462
UIP-P Jitter above 637 kHz
(IEEE 802.3 clause 38.5)
Eye mask Y1
Y1
Eye mask Y2
Y2
5.2.2
125
mV
600
mV
Transmitter Specifications
This section includes the transmitter specifications.
The specifications in the following table correspond to line-side 10G transmitter output, SFI point B. Point
B is after a standard-compliant SFI or XFI channel, as defined in the SFP+ standard (SFF-8431) or the
XFP multisource agreement (INF-8077i). The measurement is done with a 9 dB channel loss unless
stated otherwise.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
122
Electrical Specifications
The SFI and XFI output of the 10G transmitter are tested and characterized to support ITU-T
recommendation G.709 (OTN) OTU2, OTU1e, and OTU2e line rates (10.709 Gbps, 11.049 Gbps, and
11.095 Gbps) with a channel loss of 6.5 dB or less.
Note: OTN rates and 10/100M rates under SGMII are only supported in repeater mode. For additional details
regarding OTN line rates and the corresponding electrical characteristics, contact your Microsemi
representative.
Table 53 •
Host- and Line-Side 10G Transmitter Output (SFI Point A)
Parameter
Symbol
Termination mismatch
Maximum
Unit
∆ZM
5
%
Differential return loss
SDD22
–12
dB
0.01 GHz to 2.8 GHz
Differential return loss
SDD22
–8.15 +
13.33 x
log10(f/5.5
GHz)
dB
2.8 GHz to 11.1 GHz
Common-mode return loss
SCC22
–9
dB
0.01 GHz to 4.74 GHz
Common-mode return loss
SCC22
–8.15 +
13.33 x
log10(f/5.5
GHz)
dB
4.74 GHz to 11.1 GHz
Maximum
Unit
Condition
Table 54 •
Minimum
Condition
Host- and Line-Side 10G Transmitter Output (SFI Point B)
Parameter
Symbol
Minimum
AC common-mode voltage
VOCM_AC
15
mVRMS
Total jitter
TJ
0.28
UI
Data-dependant jitter
DDJ
0.1
UI
Pulse shrinkage jitter
DDPWS
0.055
UI
Uncorrelated jitter
UJ
0.023
UIRMS
Eye mask X1
X1
0.12
UI
Eye mask X2
X2
0.33
UI
Eye mask Y1
Y1
Eye mask Y2
Y2
95
mV
350
Tested at 7 dB SFI
channel loss.
mV
The following illustration shows the compliance mask associated with the Tx SFI transmit differential
output.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
123
Electrical Specifications
Figure 84 • SFI Transmit Differential Output Compliance Mask
Y2
Voltage
Y1
0
–Y1
–Y2
0.0
X1
X2
1–X2
1–X1
1.0
Normalized Time (UI)
The following table shows the transmit path output specifications for SFI point B. These DAC parameters
are measured with 7 dB SFI channel loss.
Table 55 •
Transmitter SFP+ Direct Attach Copper Output AC Characteristics
Parameter
Symbol
Minimum
SFP+ direct attach
copper voltage
modulation
amplitude, peak-topeak
VMA
300
SFP+ direct attach
copper transmitter
QSQ
QSQ
63.1
SFP+ direct attach
copper output AC
common-mode
voltage
SFP+ direct attach
copper output
TWDPc
TWDPc
Maximum
Unit
Condition
mV
See SFF-8431 section D.7.
See SFF-8431 section D.8.
12
mV
See SFF-8431 section D.15.
(RMS)
10.7
dB
Electrical output measured
using SFF-8431 Appendix G,
including copper direct attach
stressor.
The following table shows that the 10 Gbps transmitter operating in 10GBASE-KR mode complies with
IEEE 802.3 clause 72.7.
Table 56 •
10 Gbps Transmitter 10GBASE-KR AC Characteristics
Parameter
Symbol
Minimum
Maximum
Signalling speed
TBAUD
10.3125 – 100 ppm
10.3125 + 100 ppm Gbps
Differential output
return loss
RLOSDD22
–9
–9 + 12 x log
(f/2.5 GHz)
dB
50 MHz to 2.5 GHz
2.5 GHz to 7.5 GHz
RL = 100 Ω ± 1%
Common mode
return loss
RLOCM
–6
–6 + 12 x log
(f/2.5 GHz)
dB
50 MHz to 2.5 GHz
2.5 GHz to 7.5 GHz
RL = 100 Ω ± 1%
Transition time
TR, TF
47
ps
20% to 80%
24
Unit
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
Condition
124
Electrical Specifications
Table 56 •
10 Gbps Transmitter 10GBASE-KR AC Characteristics (continued)
Parameter
Symbol
Random jitter
Deterministic jitter
Minimum
Maximum
Unit
Condition
RJ
0.16
UI
BER 1E–12, 0.151 UI for
junction
temperature ≤ 100 °C
DJ
0.15
UI
Duty cycle distortion DCD
(part of DJ)
0.035
UI
Total jitter
0.28
UI
TJ
The following table shows the transmit path optical jitter specifications for point A, measured using COTS
SFP-10G module.
Host- and Line-Side Optical 10G Output Jitter
Table 57 •
Parameter
Symbol
Maximum
Unit
Condition
Total jitter, 20 kHz to 80 MHz
TJ
180
mUIP-P
60 second gating time
Total jitter, 4 MHz to 80 MHz
TJ
100
mUIP-P
60 second gating time
The following table lists the line-side 1.25 Gbps SFI output specifications for the VSC8257-01 device.
Table 58 •
Host- and Line-Side 1.25 Gbps SFI Output
Parameter
Symbol
Differential output
return loss
Maximum
Unit
Condition
RLOSDD22
–10
dB
50 MHz to 625 MHz
Differential output
return loss
RLOSDD22
–10 + 10 x
log(f/625 MHz)
dB
625 MHz to 1250 MHz
Common mode
return loss
RLOCM
–6
dB
50 MHz to 625 MHz
Deterministic jitter
DJ
0.1
UI
Measured according to
IEEE 802.3 clause 38.5
Total jitter
TJ
0.24
UI
Measured according to
IEEE 802.3 clause 38.5
Eye mask Y1
Y1
mV
SFF-8431 1G
specification
Eye mask Y2
Y2
mV
SFF-8431 1G
specification
5.2.3
Minimum
150
500
Timing and Reference Clock
The following table lists the reference clock specifications (LREFCK, SREFCK, and HREFCK, and
CLK1588) for the VSC8257-01 device.
Table 59 •
Reference Clock AC Characteristics
Parameter
Symbol
Minimum
Reference clock frequency
ƒREFCLK
Reference clock frequency
accuracy
ƒR
Typical
Maximum
Unit
125
156.25
MHz
– 100 ppm
100 ppm
MHz
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
Condition
125
Electrical Specifications
Table 59 •
Reference Clock AC Characteristics (continued)
Parameter
Symbol
Rise time and fall time
tR, tF
Reference clock duty cycle
DC
Minimum
40
Jitter tolerance for LREFCLK and JTLLREF/HREF
HREFCLK
Jitter tolerance for CLK1588
JTLCLK_1588
Frequency for CLK1588
ƒCLK_1588
Duty cycle for CLK1588
DCCLK_1588
Typical
Maximum
Unit
Condition
0.4
ns
Within ± 200 mV
relative to
VDD x 2/3
60
%
0.7
40
ps
100
ps
125
250
MHz
50
60
%
For 2 KHz to
20 MHz
The following illustration shows the worst-case clock jitter transfer characteristic for the LREFCK input.
Figure 85 • LREFCK/HREFCLK to Data Output Jitter Transfer
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
126
Electrical Specifications
5.2.4
Two-Wire Serial (Slave) Interface
This section contains information about the AC specifications for the two-wire serial slave interface for
the VSC8257-01 device.
Table 60 •
Two-Wire Serial Interface AC Characteristics
Standard
Parameter
Symbol
Serial clock frequency
ƒSCL
Minimum
Fast Mode
Maximum
Minimum
100
Maximum
Unit
400
kHz
Hold time START condition tHD:STA
after this period, the first
clock pulse is generated
4.0
0.6
µs
Low period of SCL
tLOW
4.7
1.3
µs
High period of SCL
tHIGH
4.0
0.6
µs
Data hold time
tHD:DAT
0
Data setup time
tSU:DAT
250
3.45
0
0.9
µs
100
ns
Rise time for SDA and SCL tR
1000
300
ns
Fall time for SDA and SCL tF
300
300
ns
Setup time for STOP
condition
tSU:STO
4.0
0.6
µs
Bus free time between a
STOP and START
tBUF
4.7
1.3
µs
Capacitive load for SCL
and SDA bus line
CB
External pull-up resistor1
RP
1.
400
8 x 10–7/CB
900
900
330
pF
3 x 10–7/CB
Ω
Minimum value is determined from IOL and internal reliability requirements. Maximum value is determined by
load capacitance. Microsemi recommends 10 kΩ for typical applications in which capacitance loads are
below the specified minimums.
Figure 86 • Two-Wire Serial Interface Timing
SDA
tF
tLOW
tR
tF
tSU;DAT
tHD;STA
tR
tBUF
SCL
S
tHD;STA
tHD;DAT
tHIGH
tSU;STA
Sr
tSU;STO
P
S
S = START, P = STOP, and Sr = repeated START .
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
127
Electrical Specifications
5.2.5
MDIO Interface
This section contains information about the AC specifications for the MDIO interface for the VSC8257-01
device.
MDIO Interface AC Characteristics
Table 61 •
Parameter
Symbol
Minimum
Maximum
Unit
MDIO data hold time
tHOLD
10
MDIO data setup time
tSU
10
Delay from MDC rising edge to MDIO data change
tDELAY
300
ns
MDC clock rate
ƒ
2.5
MHz
ns
ns
The following illustration shows the timing with the MDIO sourced by STA.
Figure 87 • Timing with MDIO Sourced by STA
VIH (MIN)
MDC
VIH (MIN)
VIH (MIN)
MDIO
VIH (MIN)
10 ns minimum
10 ns minimum
The following illustration shows the timing with the MDIO sourced by MMD.
Figure 88 • Timing with MDIO Sourced by MMD
VIH (MIN)
MDC
VIH (MIN)
VIH (MIN)
MDIO
VIH (MIN)
0 ns Minimum
300 ns Maximum
The following table lists the clock output specifications the device.
Table 62 •
Clock Output AC Characteristics
Parameter
Symbol
CKOUT[0:3]N/P jitter generation
JGC64
CKOUT[0:3]N/P differential output ∆V
swing
Minimum
650
Maximum
Unit
15
psRMS 10 kHz to 10 MHz
900
mVP-P
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
Condition
128
Electrical Specifications
5.2.6
Synchronous Time-of-Day Load/Save Timing
When the 1588 Load/Save strobe pin, LS, is applied to the device synchronous to CLK1588P/N, the
setup and hold (minimum) times shown in the following table must be satisfied.
Load/Save Setup and Hold Timing AC Characteristics
Table 63 •
Parameter
Symbol
Minimum
Unit
1588 LOAD/SAVE setup time
tSETUP
1.0
ns
1588 LOAD/SAVE hold time
tHOLD
0.7
ns
The following illustration shows the LOAD/SAVE AC timing.
Figure 89 • Load/Save AC Timing
CLK1588P
CLK1588P
LS (Load/
Save)
LS (Load/
Save)
thold
5.2.7
tsetup
SPI Slave Interface
This section contains information about the AC specifications for the four-pin SPI slave interface used to
read and write registers. The maximum clock rate is 30 MHz, and it is configurable.
Table 64 •
SPI Slave Interface AC Characteristics
Parameter
Symbol
Minimum
MOSI data setup time
tSU, MOSI
10
ns
MOSI data hold time
tHD, MOSI
10
ns
SSN data setup time
tSU, SSN
15
ns
SSN transition low to
enable interface
SSN data hold time
tHD, SSN
SCK clock
period + 15
ns
SSN transition high to
enable interface
SSN transition low to
MISO valid
tON, MISO
2
ns
SSN transition high to
MISO high impedance
tOFF, MISO
Falling SCK to valid MISO tDLY, NORM 14
data, normal mode
Rising SCK to valid MISO tDLY, FAST
data, fast mode
14
Maximum
Unit
Condition
10
ns
30
ns
Maximum capacitance
loading of 5 pF
35
ns
Maximum capacitance
loading of 50 pF
36
ns
Maximum capacitance
loading of 100 pF
30
ns
Maximum capacitance
loading of 5 pF
35
ns
Maximum capacitance
loading of 50 pF
36
ns
Maximum capacitance
loading of 100 pF
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
129
Electrical Specifications
The following illustration shows the SPI interface timing.
Figure 90 • SPI Interface Timing
tSU,SSN
tHD,SSN
SSN
MOSI
tHD,MOSI
tSU,MOSI
SCK
tDLY,NORM
MISO,
Normal
Mode
tDLY,FAST
tON,MISO
tOFF,MISO
MISO,
Fast
Mode
The following table lists the AC characteristics for the 3-pin push-out SPI.
Table 65 •
3-Pin Push-Out SPI AC Characteristics
Parameter
Symbol
Minimum
Maximum
Unit
SPI_DO to
tDO, CLK
SPI_CLK delay
–2
5
ns
SPI_CS to
tCS, CLK
SPI_CLK delay
–2
5
ns
The following illustration shows the 3-pin push-out SPI timing.
Figure 91 • 3-Pin Push-Out SPI Timing
SPI_CLK
SPI_DO
SPI_CS
5.3
Operating Conditions
To ensure that the control pins remain set to the desired configured state when the device is powered up,
perform a reset using the reset pin after power-up and after the control pins are steady for 1 ms.
It is recommended to have all the 1 V power rails move together.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
130
Electrical Specifications
Recommended Operating Conditions
Table 66 •
Parameter
Symbol
Minimum
Typical Maximum Unit
Condition
1.0 V power supply voltage
VDDLR
VDDL
VDDAH
VDDAL
0.94575
0.975
1.00425
V
Power rail at 0.975 V ±3%
0.97
1.0
1.03
V
Power rail at 1.0 V ±3%
VDDHSL
VDDHSH
1.14
1.26
V
±5%
2.375
2.625
V
±5%
7
W
VDDL = VDDLR= VDDAH= VDDAL=
1.0042 V, maximum1
VDDHSH = VDDHSL = 1.26 V
VDDTTL = VDDMDIO = 2.625 V
Per clock output
1.2 V power supply voltage
2.5 V TTL I/O power supply VDDTTL
voltage
VDDMDIO
Power consumption
PDD
Clock output power
PDD_CLK
0
40
mW
SREFCK input power
PDD_SREFCK 0
60
mW
T
110
°C
Operating
1.
2.
temperature2
–40
Device can be run at 1 V +3% with a worst case power of 7.8 W.
Minimum specification is ambient temperature, and the maximum is junction temperature.
5.4
Stress Ratings
This section contains the stress ratings for the device.
Warning Stresses listed in the following table may be applied to devices one at a time without causing
permanent damage. Functionality at or exceeding the values listed is not implied. Exposure to these
values for extended periods may affect device reliability.
Table 67 •
Stress Ratings
Parameter
Symbol
Minimum
Maximum
Unit
1.0 V power supply voltage, potential to ground
VDDAH
VDDAL
VDDL
VDDLR
–0.3
1.1
V
1.2 V power supply voltage, potential to ground
VDDHSL
VDDHSH
–0.3
1.32
V
2.5 V TTL I/O power supply voltage
VDDTTL
VDDMDIO
–0.3
2.75
V
Storage temperature
TS
–55
125
°C
Electrostatic discharge voltage, charged device
model
VESD_CDM –250
250
V
Electrostatic discharge voltage, human body model,
CLK1588N and CLK1588P pins
VESD_HBM –1750
1750
V
Electrostatic discharge voltage, human body model,
all pins except the CLK1588N and CLK1588P pins
VESD_HBM See note1
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
V
131
Electrical Specifications
1.
This device has completed all required testing as specified in the JEDEC standard JESD22-A114,
Electrostatic Discharge (ESD) Sensitivity Testing Human Body Model (HBM), and complies with a Class 2
rating. The definition of Class 2 is any part that passes an ESD pulse of 2000 V, but fails an ESD pulse of
4000 V.
Warning This device can be damaged by electrostatic discharge (ESD) voltage. Microsemi
recommends that all integrated circuits be handled with appropriate precautions. Failure to observe
proper handling and installation procedures may adversely affect reliability of the device.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
132
Pin Descriptions
6
Pin Descriptions
The VSC8257-01 device has 256 pins, which are described in this section.
The pin information is also provided as an attached Microsoft Excel file, so that you can copy it
electronically. In Adobe Reader, double-click the attachment icon.
6.1
Pin Diagram
The following illustration shows the pin diagram for the device.
Figure 92 • Pin Diagram
1
2
3
4
A GND GND GND SSN
B
6
7
8
9
10
11
12
13
14
15
16
TRSTB
SCK
TDO
TDI
RESETN
CLK1588P
CLK1588N
NC
CKOUT0P
GND
GND
GND
GPIO_4 GPIO_5
MODE0
MODE1
NC
CKOUT0N
GND
RXIN0P RXIN0N
SPI_DO_01
SPI_CS_01
NC
GND GND
GND MOSI TMS MISO TCK
C GND GND GND
TDION
D
GPIO_0 GPIO_1 GPIO_2 GPIO_3 GPIO_6 GPIO_7 GPIO_8 GPIO_9 GPIO_10 CKOUT1P
GND
E GND GND GND
GPIO_11
GPIO_12
GPIO_13
GPIO_14
GPIO_15
GPIO_17
GPIO_18
GPIO_19
CKOUT1N
GND
F
GND
VDDAH
GND
GND
VDDTTL
VDDL GND VDDL
VDDAL
GND
GND GND
G GND GND GND
VDDHSH
VDDAH
GND
VDDLR
VDDLR
GND
VDDAL
VDDHSL
GND
CKOUT3P
GND
H
GND
VDDHSH
VDDAH
GND
VDDLR
VDDLR
GND
VDDAL
VDDHSL
GND
CKOUT3N
GND
J GND GND GND
VDDHSH
VDDAH
GND
VDDLR
VDDLR
GND
VDDAL
VDDHSL
GND
GND GND
K
GND
VDDHSH
VDDAH
GND
VDDLR
VDDLR
GND
VDDAL
VDDHSL
GND
CKOUT2P
GND
RXIN2P RXIN2N
L GND GND GND
VDDAH
VDDMDIO
GND
VDDTTL
VDDL GND VDDL
VDDAL
GND
CKOUT2N
GND
GND
M
GND
GPIO_20
GPIO_21
GPIO_22
GPIO_23
GPIO_24
GPIO_25
GPIO_26
GPIO_27
NC
GND GND
N GND GND GND
GPIO_28
GPIO_29
GPIO_30
GPIO_31
GPIO_32/I2C_SDA
GPIO_33/I2C_SCL
GPIO_34
GPIO_35
NC
SCKOUTP
GND
GND
NC
GPIO_36
GPIO_37
GPIO_38
GPIO_39
SPI_CLK_23
SPI_DO_23
SPI_CS_23
NC
SCKOUTN
GND
RXIN3P RXIN3N
P
6.2
RXOUT0N RXOUT0P
5
TXIN0N
TXIN0P
RXOUT1N RXOUT1P
TXIN1N
TXIN1P
RXOUT2N RXOUT2P
TXIN2N
TXIN2P
RXOUT3N RXOUT3P
GND
GND
TDIOP
LS
PPS_RI
PPS
SPI_CLK_01
GPIO_16
R GND GND GND GND MDIO
MODE2 HREFCKP PADDR3 LREFCKP MODE3 SREFCKP RCOMPN
T GND
PADDR4
TXIN3N
TXIN3P
GND MDC
HREFCKN PADDR2
LREFCKN
NC
SREFCKN RCOMPP
GND GND
GND
GND
GND
TXOUT0P TXOUT0N
GND
GND
RXIN1P RXIN1N
GND
GND
TXOUT1P TXOUT1N
GND
GND
GND
TXOUT2P TXOUT2N
GND
TXOUT3P TXOUT3N
GND
GND
GND
Pins by Function
This section contains the functional pin descriptions for the VSC8257-01 device.
Note: All differential data or clock signals should be AC-coupled. A cap of 0.1 µF would be sufficient.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
133
Pin Descriptions
Functional Group
Name
Number Type Level
Description
1588
CLK1588N
A11
I
CML
1588 local time counter clock
input, complement
1588
CLK1588P
A10
I
CML
1588 local time counter clock
input, true
1588
LS
C6
B
LVTTL
1588 load/save input.
Internally pulled low.
1588
PPS
C8
B
LVTTL
1588 pulse per second (output)
1588
PPS_RI
C7
I
LVTTL
1588 pulse per second return
input signal. Internally pulled
low.
1588
SPI_CLK_01
C9
O
LVTTL
Pushout SPI clock output for
1588 timestamp (channel 0
and channel 1)
1588
SPI_CLK_23
P9
O
LVTTL
Pushout SPI clock output for
1588 timestamp (channel 2
and channel 3)
1588
SPI_CS_01
C11
O
LVTTL
Pushout SPI chip select output
for 1588 timestamp (channel 0
and channel 1)
1588
SPI_CS_23
P11
O
LVTTL
Pushout SPI chip select output
for 1588 timestamp (channel 2
and channel 3)
1588
SPI_DO_01
C10
O
LVTTL
Pushout SPI data output for
1588 timestamp (channel 0
and channel 1)
1588
SPI_DO_23
P10
O
LVTTL
Pushout SPI data output for
1588 timestamp (channel 2
and channel 3)
Clock Signal
CKOUT0N
B13
O
CML
Selectable clock output
channel 0, complement
Clock Signal
CKOUT0P
A13
O
CML
Selectable clock output
channel 0, true
Clock Signal
CKOUT1N
E13
O
CML
Selectable clock output
channel 1, complement
Clock Signal
CKOUT1P
D13
O
CML
Selectable clock output
channel 1, true
Clock Signal
CKOUT2N
L13
O
CML
Selectable clock output
channel 2, complement
Clock Signal
CKOUT2P
K13
O
CML
Selectable clock output
channel 2, true
Clock Signal
CKOUT3N
H13
O
CML
Selectable clock output
channel 3, complement
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
134
Pin Descriptions
Clock Signal
CKOUT3P
G13
O
CML
Selectable clock output
channel 3, true
Clock Signal
HREFCKN
T7
I
CML
Host reference clock input,
complement. Must be
frequency locked to
LREFCKP/N.
Clock Signal
HREFCKP
R7
I
CML
Host reference clock input,
true. Must be frequency locked
to LREFCKP/N.
Clock Signal
LREFCKN
T9
I
CML
Line reference clock input,
complement
Clock Signal
LREFCKP
R9
I
CML
Line reference clock input, true
Clock Signal
SCKOUTN
P13
O
CML
SyncE recovered clock output,
complement
Clock Signal
SCKOUTP
N13
O
CML
SyncE recovered clock output,
true
Clock Signal
SREFCKN
T11
I
CML
SyncE reference clock input,
complement
Clock Signal
SREFCKP
R11
I
CML
SyncE reference clock input,
true
JTAG
TCK
B7
I
LVTTL
Boundary scan, test clock
input. Internally pulled high.
JTAG
TDI
A8
I
LVTTL
Boundary scan, test data input.
Internally pulled high.
JTAG
TDO
A7
O
LVTTL
Boundary scan, test data
output.
JTAG
TMS
B5
I
LVTTL
Boundary scan, test mode
select. Internally pulled high.
JTAG
TRSTB
A5
I
LVTTL
Boundary scan, test reset
input. Internally pulled high.
MDIO
MDC
T5
I
LVTTL
MDIO clock input
MDIO
MDIO
R5
B
LVTTLOD MDIO data I/O
Miscellaneous
GPIO_0
D4
B
LVTTLOD General purpose I/O 0
Miscellaneous
GPIO_1
D5
B
LVTTLOD General purpose I/O 1
Miscellaneous
GPIO_2
D6
B
LVTTLOD General purpose I/O 2
Miscellaneous
GPIO_3
D7
B
LVTTLOD General purpose I/O 3
Miscellaneous
GPIO_4
B8
B
LVTTLOD General purpose I/O 4
Miscellaneous
GPIO_5
B9
B
LVTTLOD General purpose I/O 5
Miscellaneous
GPIO_6
D8
B
LVTTLOD General purpose I/O 6
Miscellaneous
GPIO_7
D9
B
LVTTLOD General purpose I/O 7
Miscellaneous
GPIO_8
D10
B
LVTTLOD General purpose I/O 8
Miscellaneous
GPIO_9
D11
B
LVTTLOD General purpose I/O 9
Miscellaneous
GPIO_10
D12
B
LVTTLOD General purpose I/O 10
Miscellaneous
GPIO_11
E4
B
LVTTLOD General purpose I/O 11
Miscellaneous
GPIO_12
E5
B
LVTTLOD General purpose I/O 12
Miscellaneous
GPIO_13
E6
B
LVTTLOD General purpose I/O 13
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
135
Pin Descriptions
Miscellaneous
GPIO_14
E7
B
LVTTLOD General purpose I/O 14
Miscellaneous
GPIO_15
E8
B
LVTTLOD General purpose I/O 15
Miscellaneous
GPIO_16
E9
B
LVTTLOD General purpose I/O 16
Miscellaneous
GPIO_17
E10
B
LVTTLOD General purpose I/O 17
Miscellaneous
GPIO_18
E11
B
LVTTLOD General purpose I/O 18
Miscellaneous
GPIO_19
E12
B
LVTTLOD General purpose I/O 19
Miscellaneous
GPIO_20
M4
B
LVTTLOD General purpose I/O 20
Miscellaneous
GPIO_21
M5
B
LVTTLOD General purpose I/O 21
Miscellaneous
GPIO_22
M6
B
LVTTLOD General purpose I/O 22
Miscellaneous
GPIO_23
M7
B
LVTTLOD General purpose I/O 23
Miscellaneous
GPIO_24
M8
B
LVTTLOD General purpose I/O 24
Miscellaneous
GPIO_25
M9
B
LVTTLOD General purpose I/O 25
Miscellaneous
GPIO_26
M10
B
LVTTLOD General purpose I/O 26
Miscellaneous
GPIO_27
M11
B
LVTTLOD General purpose I/O 27
Miscellaneous
GPIO_28
N4
B
LVTTLOD General purpose I/O 28
Miscellaneous
GPIO_29
N5
B
LVTTLOD General purpose I/O 29
Miscellaneous
GPIO_30
N6
B
LVTTLOD General purpose I/O 30
Miscellaneous
GPIO_31
N7
B
LVTTLOD General purpose I/O 31
Miscellaneous
GPIO_32/I2C_SDA N8
B
LVTTLOD
General purpose I/O 32 (also
I2C data)
Miscellaneous
GPIO_33/I2C_SCL N9
B
LVTTLOD
General purpose I/O 33 (also
I2C clock)
Miscellaneous
GPIO_34
N10
B
LVTTLOD General purpose I/O 34
Miscellaneous
GPIO_35
N11
B
LVTTLOD General purpose I/O 35
Miscellaneous
GPIO_36
P5
B
LVTTLOD General purpose I/O 36
Miscellaneous
GPIO_37
P6
B
LVTTLOD General purpose I/O 37
Miscellaneous
GPIO_38
P7
B
LVTTLOD General purpose I/O 38
Miscellaneous
GPIO_39
P8
B
LVTTLOD General purpose I/O 39
Miscellaneous
MODE0
B10
I
LVTTL
Mode select input bit 0.
Internally pulled low.
Miscellaneous
MODE1
B11
I
LVTTL
Mode select input bit 1.
Internally pulled low.
Miscellaneous
MODE2
R6
I
LVTTL
Mode select input bit 2.
Internally pulled low. Do not
connect.
Miscellaneous
MODE3
R10
I
LVTTL
Mode select input bit 3.
Internally pulled low. Do not
connect.
Miscellaneous
PADDR2
T8
I
LVTTL
Port address bit 2. Internally
pulled low.
Miscellaneous
PADDR3
R8
I
LVTTL
Port address bit 3. Internally
pulled low.
Miscellaneous
PADDR4
T6
I
LVTTL
Port address bit 4. Internally
pulled low.
Miscellaneous
RCOMPN
R12
Analog
Resistor comparator,
complement
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
136
Pin Descriptions
Miscellaneous
RCOMPP
T12
Analog
Resistor comparator, true
Miscellaneous
RESETN
A9
LVTTL
Reset. Low= Reset. Internally
pulled high.
Miscellaneous
TDION
C4
Analog
Temperature diode,
complement.
Miscellaneous
TDIOP
C5
Analog
Temperature diode, true.
Power and Ground
GND
A1
P
GND
Ground
Power and Ground
GND
A2
P
GND
Ground
I
Power and Ground
GND
A3
P
GND
Ground
Power and Ground
GND
A14
P
GND
Ground
Power and Ground
GND
A15
P
GND
Ground
Power and Ground
GND
A16
P
GND
Ground
Power and Ground
GND
B3
P
GND
Ground
Power and Ground
GND
B14
P
GND
Ground
Power and Ground
GND
C1
P
GND
Ground
Power and Ground
GND
C2
P
GND
Ground
Power and Ground
GND
C3
P
GND
Ground
Power and Ground
GND
C13
P
GND
Ground
Power and Ground
GND
C14
P
GND
Ground
Power and Ground
GND
C15
P
GND
Ground
Power and Ground
GND
C16
P
GND
Ground
Power and Ground
GND
D3
P
GND
Ground
Power and Ground
GND
D14
P
GND
Ground
Power and Ground
GND
E1
P
GND
Ground
Power and Ground
GND
E2
P
GND
Ground
Power and Ground
GND
E3
P
GND
Ground
Power and Ground
GND
E14
P
GND
Ground
Power and Ground
GND
E15
P
GND
Ground
Power and Ground
GND
E16
P
GND
Ground
Power and Ground
GND
F3
P
GND
Ground
Power and Ground
GND
F5
P
GND
Ground
Power and Ground
GND
F6
P
GND
Ground
Power and Ground
GND
F9
P
GND
Ground
Power and Ground
GND
F12
P
GND
Ground
Power and Ground
GND
F13
P
GND
Ground
Power and Ground
GND
F14
P
GND
Ground
Power and Ground
GND
G1
P
GND
Ground
Power and Ground
GND
G2
P
GND
Ground
Power and Ground
GND
G3
P
GND
Ground
Power and Ground
GND
G6
P
GND
Ground
Power and Ground
GND
G9
P
GND
Ground
Power and Ground
GND
G12
P
GND
Ground
Power and Ground
GND
G14
P
GND
Ground
Power and Ground
GND
G15
P
GND
Ground
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
137
Pin Descriptions
Power and Ground
GND
G16
P
GND
Ground
Power and Ground
GND
H3
P
GND
Ground
Power and Ground
GND
H6
P
GND
Ground
Power and Ground
GND
H9
P
GND
Ground
Power and Ground
GND
H12
P
GND
Ground
Power and Ground
GND
H14
P
GND
Ground
Power and Ground
GND
J1
P
GND
Ground
Power and Ground
GND
J2
P
GND
Ground
Power and Ground
GND
J3
P
GND
Ground
Power and Ground
GND
J6
P
GND
Ground
Power and Ground
GND
J9
P
GND
Ground
Power and Ground
GND
J12
P
GND
Ground
Power and Ground
GND
J13
P
GND
Ground
Power and Ground
GND
J14
P
GND
Ground
Power and Ground
GND
J15
P
GND
Ground
Power and Ground
GND
J16
P
GND
Ground
Power and Ground
GND
K3
P
GND
Ground
Power and Ground
GND
K6
P
GND
Ground
Power and Ground
GND
K9
P
GND
Ground
Power and Ground
GND
K12
P
GND
Ground
Power and Ground
GND
K14
P
GND
Ground
Power and Ground
GND
L1
P
GND
Ground
Power and Ground
GND
L2
P
GND
Ground
Power and Ground
GND
L3
P
GND
Ground
Power and Ground
GND
L6
P
GND
Ground
Power and Ground
GND
L9
P
GND
Ground
Power and Ground
GND
L12
P
GND
Ground
Power and Ground
GND
L14
P
GND
Ground
Power and Ground
GND
L15
P
GND
Ground
Power and Ground
GND
L16
P
GND
Ground
Power and Ground
GND
M3
P
GND
Ground
Power and Ground
GND
M13
P
GND
Ground
Power and Ground
GND
M14
P
GND
Ground
Power and Ground
GND
N1
P
GND
Ground
Power and Ground
GND
N2
P
GND
Ground
Power and Ground
GND
N3
P
GND
Ground
Power and Ground
GND
N14
P
GND
Ground
Power and Ground
GND
N15
P
GND
Ground
Power and Ground
GND
N16
P
GND
Ground
Power and Ground
GND
P3
P
GND
Ground
Power and Ground
GND
P14
P
GND
Ground
Power and Ground
GND
R1
P
GND
Ground
Power and Ground
GND
R2
P
GND
Ground
Power and Ground
GND
R3
P
GND
Ground
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
138
Pin Descriptions
Power and Ground
GND
R4
P
GND
Ground
Power and Ground
GND
R13
P
GND
Ground
Power and Ground
GND
R14
P
GND
Ground
Power and Ground
GND
R15
P
GND
Ground
Power and Ground
GND
R16
P
GND
Ground
Power and Ground
GND
T1
P
GND
Ground
Power and Ground
GND
T4
P
GND
Ground
Power and Ground
GND
T13
P
GND
Ground
Power and Ground
GND
T16
P
GND
Ground
Power and Ground
VDDAH
F4
P
Supply
1.0 V power supply for host
side analog
Power and Ground
VDDAH
G5
P
Supply
1.0 V power supply for host
side analog
Power and Ground
VDDAH
H5
P
Supply
1.0 V power supply for host
side analog
Power and Ground
VDDAH
J5
P
Supply
1.0 V power supply for host
side analog
Power and Ground
VDDAH
K5
P
Supply
1.0 V power supply for host
side analog
Power and Ground
VDDAH
L4
P
Supply
1.0 V power supply for host
side analog
Power and Ground
VDDAL
F11
P
Supply
1.0 V power supply for line side
analog
Power and Ground
VDDAL
G10
P
Supply
1.0 V power supply for line side
analog
Power and Ground
VDDAL
H10
P
Supply
1.0 V power supply for line side
analog
Power and Ground
VDDAL
J10
P
Supply
1.0 V power supply for line side
analog
Power and Ground
VDDAL
K10
P
Supply
1.0 V power supply for line side
analog
Power and Ground
VDDAL
L11
P
Supply
1.0 V power supply for line side
analog
Power and Ground
VDDHSH
G4
P
Supply
1.2 V power supply for host
side IOs
Power and Ground
VDDHSH
H4
P
Supply
1.2 V power supply for host
side IOs
Power and Ground
VDDHSH
J4
P
Supply
1.2 V power supply for host
side IOs
Power and Ground
VDDHSH
K4
P
Supply
1.2 V power supply for host
side IOs
Power and Ground
VDDHSL
G11
P
Supply
1.2 V power supply for line side
IOs
Power and Ground
VDDHSL
H11
P
Supply
1.2 V power supply for line side
IOs
Power and Ground
VDDHSL
J11
P
Supply
1.2 V power supply for line side
IOs
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
139
Pin Descriptions
Power and Ground
VDDHSL
K11
P
Supply
1.2 V power supply for line side
IOs
Power and Ground
VDDL
F8
P
Supply
1.0 V power supply for chip
core
Power and Ground
VDDL
F10
P
Supply
1.0 V power supply for chip
core
Power and Ground
VDDL
L8
P
Supply
1.0 V power supply for chip
core
Power and Ground
VDDL
L10
P
Supply
1.0 V power supply for chip
core
Power and Ground
VDDLR
G7
P
Supply
1.0 V power supply for chip
core
Power and Ground
VDDLR
G8
P
Supply
1.0 V power supply for chip
core
Power and Ground
VDDLR
H7
P
Supply
1.0 V power supply for chip
core
Power and Ground
VDDLR
H8
P
Supply
1.0 V power supply for chip
core
Power and Ground
VDDLR
J7
P
Supply
1.0 V power supply for chip
core
Power and Ground
VDDLR
J8
P
Supply
1.0 V power supply for chip
core
Power and Ground
VDDLR
K7
P
Supply
1.0 V power supply for chip
core
Power and Ground
VDDLR
K8
P
Supply
1.0 V power supply for chip
core
Power and Ground
VDDMDIO
L5
P
Supply
MDIO power supply
Power and Ground
VDDTTL
F7
P
Supply
LVTTL power supply
Power and Ground
VDDTTL
L7
P
Supply
LVTTL power supply
Receive and Transmit Path RXIN0N
B16
I
CML
Line receive channel 0 input
data, complement
Receive and Transmit Path RXIN0P
B15
I
CML
Line receive channel 0 input
data, true
Receive and Transmit Path RXIN1N
F16
I
CML
Line receive channel 1 input
data, complement
Receive and Transmit Path RXIN1P
F15
I
CML
Line receive channel 1 input
data, true
Receive and Transmit Path RXIN2N
K16
I
CML
Line receive channel 2 input
data, complement
Receive and Transmit Path RXIN2P
K15
I
CML
Line receive channel 2 input
data, true
Receive and Transmit Path RXIN3N
P16
I
CML
Line receive channel 3 input
data, complement
Receive and Transmit Path RXIN3P
P15
I
CML
Line receive channel 3 input
data, true
Receive and Transmit Path RXOUT0N
B1
O
CML
Host transmit channel 0 output
data, complement
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
140
Pin Descriptions
Receive and Transmit Path RXOUT0P
B2
O
CML
Host transmit channel 0 output
data, true
Receive and Transmit Path RXOUT1N
F1
O
CML
Host transmit channel 1 output
data, complement
Receive and Transmit Path RXOUT1P
F2
O
CML
Host transmit channel 1 output
data, true
Receive and Transmit Path RXOUT2N
K1
O
CML
Host transmit channel 2 output
data, complement
Receive and Transmit Path RXOUT2P
K2
O
CML
Host transmit channel 2 output
data, true
Receive and Transmit Path RXOUT3N
P1
O
CML
Host transmit channel 3 output
data, complement
Receive and Transmit Path RXOUT3P
P2
O
CML
Host transmit channel 3 output
data, true
Receive and Transmit Path TXIN0N
D1
I
CML
Host receive channel 0 input
data, complement
Receive and Transmit Path TXIN0P
D2
I
CML
Host receive channel 0 input
data, true
Receive and Transmit Path TXIN1N
H1
I
CML
Host receive channel 1 input
data, complement
Receive and Transmit Path TXIN1P
H2
I
CML
Host receive channel 1 input
data, true
Receive and Transmit Path TXIN2N
M1
I
CML
Host receive channel 2 input
data, complement
Receive and Transmit Path TXIN2P
M2
I
CML
Host receive channel 2 input
data, true
Receive and Transmit Path TXIN3N
T2
I
CML
Host receive channel 3 input
data, complement
Receive and Transmit Path TXIN3P
T3
I
CML
Host receive channel 3 input
data, true
Receive and Transmit Path TXOUT0N
D16
O
CML
Line transmit channel 0 output
data, complement
Receive and Transmit Path TXOUT0P
D15
O
CML
Line transmit channel 0 output
data, true
Receive and Transmit Path TXOUT1N
H16
O
CML
Line transmit channel 1 output
data, complement
Receive and Transmit Path TXOUT1P
H15
O
CML
Line transmit channel 1 output
data, true
Receive and Transmit Path TXOUT2N
M16
O
CML
Line transmit channel 2 output
data, complement
Receive and Transmit Path TXOUT2P
M15
O
CML
Line transmit channel 2 output
data, true
Receive and Transmit Path TXOUT3N
T15
O
CML
Line transmit channel 3 output
data, complement
Receive and Transmit Path TXOUT3P
T14
O
CML
Line transmit channel 3 output
data, true
Reserved/No Connect
A12
NC
No connect
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
141
Pin Descriptions
Reserved/No Connect
NC
B12
No connect
Reserved/No Connect
NC
C12
No connect
Reserved/No Connect
NC
M12
No connect
Reserved/No Connect
NC
N12
No connect
Reserved/No Connect
NC
P4
No connect
Reserved/No Connect
NC
P12
No connect
Reserved/No Connect
NC
T10
No connect
SPI
MISO
B6
O
LVTTL
SPI slave data output
SPI
MOSI
B4
I
LVTTL
SPI slave data input. Internally
pulled low.
SPI
SCK
A6
I
LVTTL
SPI slave clock input. Internally
pulled low.
SPI
SSN
A4
I
LVTTL
SPI slave chip select input.
Internally pulled high.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
142
Package Information
7
Package Information
The VSC8257-01YMR package is a lead-free (Pb-free), 256-pin, flip chip ball grid array (FCBGA) with a
17 mm × 17 mm body size, 1 mm pin pitch, and 2.7 mm maximum height.
Lead-free products from Microsemi comply with the temperatures and profiles defined in the joint IPC
and JEDEC standard IPC/JEDEC J-STD-020. For more information, see the IPC and JEDEC standard.
7.1
Package Drawing
The following illustration shows the package drawing for the VSC8257-01 device. The drawing contains
the top view, bottom view, side view, detail views, dimensions, tolerances, and notes.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
143
Package Information
Figure 93 • VSC8257-01 Package
Top View
Bottom View
Pin A1 corner
Pin A1 corner
2.00
16 15 14 13 12 11 10 9 8 7 6 5 4 3 2 1
A
B
C
D
E
F
G
H
J
K
L
M
N
P
R
T
2.00
16.60 ±0.05
e
E
E1
1.00
(3×)
1.00 (3×)
e
Y
D1
16.60 ±0.05
D
X
0.10 (4×)
Øb
2.
Ø 0.10 M
Ø 0.25 M
Z
Z
X
Y
Side View
Lid
0.35 Z
0.15 Z
Z
Seating plane
A1 A
Dimensions and Tolerances
Notes
1. All dimensions and tolerances are in millimeters (mm).
2. Dimension is measured at the maximum solder ball
diameter, parallel to primary datum Z.
3. Radial true position is represented by typical values.
7.2
Reference
A
A1
D
E
D1
E1
e
b
Minimum
2.20
0.31
0.44
Nominal
2.45
17.00 BSC
17.00 BSC
15.00 BSC
15.00 BSC
1.00 BSC
0.54
Maximum
2.70
0.41
0.64
Thermal Specifications
Thermal specifications for this device are based on the JEDEC JESD51 family of documents. These
documents are available on the JEDEC Web site at www.jedec.org. The thermal specifications are
modeled using a four-layer test board with two signal layers, a power plane, and a ground plane (2s2p
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
144
Package Information
PCB). For more information about the thermal measurement method used for this device, see the
JESD51-1 standard.
Table 68 •
Thermal Resistances
Symbol
°C/W
Parameter
θJCtop
0.7
Die junction to package case top
θJB
13
Die junction to printed circuit board
θJA
18
Die junction to ambient
θJMA at 1 m/s
14.5
Die junction to moving air measured at an air speed of 1 m/s
θJMA at 2 m/s
11.9
Die junction to moving air measured at an air speed of 2 m/s
To achieve results similar to the modeled thermal measurements, the guidelines for board design
described in the JESD51 family of publications must be applied. For information about applications using
BGA packages, see the following:
•
•
•
•
7.3
JESD51-2A, Integrated Circuits Thermal Test Method Environmental Conditions, Natural Convection
(Still Air)
JESD51-6, Integrated Circuit Thermal Test Method Environmental Conditions, Forced Convection
(Moving Air)
JESD51-8, Integrated Circuit Thermal Test Method Environmental Conditions, Junction-to-Board
JESD51-9, Test Boards for Area Array Surface Mount Package Thermal Measurements
Moisture Sensitivity
This device is rated moisture sensitivity level 4 as specified in the joint IPC and JEDEC standard
IPC/JEDEC J-STD-020. For more information, see the IPC and JEDEC standard.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
145
Design Considerations
8
Design Considerations
This section provides information about design considerations for the VSC8257-01 device.
8.1
SPI bus speeds
The maximum speed enabled on the 4-pin slave SPI bus is 15.4 MHz in normal mode and 30 MHz in fast
mode. The maximum speed for the 3-pin push out only SPI is 40 MHz.
8.2
Device clocking
Use the LREFCLK and the HREFCK inputs for the line-side and host-side PLLs, respectively. Both
LREFCLK and HREFCK inputs are required at all times and must be synchronous. They can be
125 MHz or 156.25 MHz
Use the API call to set up the HREFCLK and LREFCLK pins for low swing or high swing clock inputs.
8.3
10GBASE-KR autonegotiation and link training
10GBASE-KR autonegotiation and link training (per IEEE 802.3, clauses 72 and 73) are only supported
in 10G mode. Autonegotiation and link training is not supported in 1G backplane applications.
For compatibility reasons, the 10GBASE-KR autonegotiation and link training function must be disabled
when the device is in repeater mode. While in this mode, the host-side transmitter clock is set during
initialization to synchronize to the line-side receiver clock, and the line-side transmitter clock is set to
synchronize to the host-side receiver clock.
Any cross-connect operation should be avoided under all circumstances during the process of KR
autonegotiation and link training.
8.4
Low-power mode and SerDes calibration
SerDes re-initialization and re-calibration is required when the PHY comes out of the low power mode.
Use the API to enable the required low power and re-calibration functionality instead of the low power
enabling bits at 1x0000.11, 2x0000.11, 3x0000.11, or 4x0000.11, which force a reset of the SerDes
registers
8.5
Low power mode with failover switching
Do not enable the low power mode when the failover switch is enabled.
The device is not intended to support the low power mode of operation when the failover switch is
enabled. When low power mode is enabled in one channel, the data flow of the other channel could be
adversely affected if the failover switch is enabled.
8.6
Flow control with failover switching
Both Tx and Rx data paths of the channel have to be switched at the same time when flow control is
enabled. The Tx data path of one channel in one direction and the Rx data path of another channel in the
opposite direction cannot be mixed.
8.7
GPIO as TOSI
A small value pull-up is needed when a GPIO pin is used as TOSI. For more information, contact your
Microsemi representative.
8.8
Limited 1G status reporting
In 1G mode, the 1G status signal from the 1G PCS block is driven by a sticky bit rather than a latched bit,
and so is useful only for link down (and not useful for link up conditions). Also, in 1000BASE-X mode, the
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
146
Design Considerations
link up indicator does not include AN done status. This does not apply to 1G bypass mode because the
PCS block is bypassed and there is no 1G status at all.
8.9
1G mode operation
Designers should be aware of the following restrictions when operating the device in 1G mode.
•
•
•
8.10
The 1G physical coding sublayer (PCS) implements 1000BASE-X (as specified by IEEE 802.3,
clause 36) and autonegotiation (as specified by IEEE 802.3, clause 37). Clause 37 autonegotiation
only applies to 1000BASE-SX and -LX optical modules.
In non-repeater mode, CuSFP (SGMII) with a 1G rate could be supported in the data path, but all
autonegotiation features must be disabled by the user. 10/100 Mbps intermediary line rates of those
modules are not supported by the PHY data path.
In repeater mode, CuSFP (SGMII) with a 10/100M data rate through oversampling in 1G mode
would work through the data path. In this configuration, autonegotiation is performed between the
host MAC and the SFP+ module, without the intervention of the repeater.
Loopbacks in 10G WAN mode
Loopbacks L1, L2, and L2C are not available in 10G WAN mode if jumbo frames are used.
8.11
Timestamp errors due to IEEE 1588 reference clock
interruption
After 1588 clock interruption, a local time counter reload using the Unified API is required.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
147
Ordering Information
9
Ordering Information
The VSC8257YMR-01 package is a lead-free (Pb-free), 256-pin, flip chip ball grid array (FCBGA) with a
17 mm × 17 mm body size, 1 mm pin pitch, and 2.7 mm maximum height.
Lead-free products from Microsemi comply with the temperatures and profiles defined in the joint IPC
and JEDEC standard IPC/JEDEC J-STD-020. For more information, see the IPC and JEDEC standard.
The following table lists the ordering information for the VSC8257-01 device.
Table 69 •
Ordering Information
Part Order Number
Description
VSC8257YMR-01
Lead-free, 256-pin FCBGA with a 17 mm × 17 mm body size, 1 mm
pin pitch, and 2.7 mm maximum height.
VMDS-10486 VSC8257-01 Datasheet Revision 4.1
148
工商网监
湘ICP备2023018690号
