VSC7513 Datasheet
8-Port L2 Gigabit Ethernet Switch
Microsemi Headquarters
One Enterprise, Aliso Viejo,
CA 92656 USA
Within the USA: +1 (800) 713-4113
Outside the USA: +1 (949) 380-6100
Sales: +1 (949) 380-6136
Fax: +1 (949) 215-4996
Email: sales.support@microsemi.com
www.microsemi.com
©2019 Microsemi, a wholly owned
subsidiary of Microchip Technology Inc. All
rights reserved. Microsemi and the
Microsemi logo are registered trademarks of
Microsemi Corporation. All other trademarks
and service marks are the property of their
respective owners.
Microsemi makes no warranty, representation, or guarantee regarding the information contained herein or the suitability of
its products and services for any particular purpose, nor does Microsemi assume any liability whatsoever arising out of the
application or use of any product or circuit. The products sold hereunder and any other products sold by Microsemi have
been subject to limited testing and should not be used in conjunction with mission-critical equipment or applications. Any
performance specifications are believed to be reliable but are not verified, and Buyer must conduct and complete all
performance and other testing of the products, alone and together with, or installed in, any end-products. Buyer shall not
rely on any data and performance specifications or parameters provided by Microsemi. It is the Buyer’s responsibility to
independently determine suitability of any products and to test and verify the same. The information provided by Microsemi
hereunder is provided “as is, where is” and with all faults, and the entire risk associated with such information is entirely
with the Buyer. Microsemi does not grant, explicitly or implicitly, to any party any patent rights, licenses, or any other IP
rights, whether with regard to such information itself or anything described by such information. Information provided in this
document is proprietary to Microsemi, and Microsemi reserves the right to make any changes to the information in this
document or to any products and services at any time without notice.
About Microsemi
Microsemi, a wholly owned subsidiary of Microchip Technology Inc. (Nasdaq: MCHP), offers a comprehensive portfolio of
semiconductor and system solutions for aerospace & defense, communications, data center and industrial markets.
Products include high-performance and radiation-hardened analog mixed-signal integrated circuits, FPGAs, SoCs and
ASICs; power management products; timing and synchronization devices and precise time solutions, setting the world's
standard for time; voice processing devices; RF solutions; discrete components; enterprise storage and communication
solutions, security technologies and scalable anti-tamper products; Ethernet solutions; Power-over-Ethernet ICs and
midspans; as well as custom design capabilities and services. Learn more at www.microsemi.com.
VMDS-10490 4.2 5/19
Contents
1 Revision History . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 1
1.1
1.2
1.3
1.4
1.5
Revision 4.2
Revision 4.1
Revision 4.0
Revision 2.1
Revision 2.0
.......................................................................
.......................................................................
.......................................................................
.......................................................................
.......................................................................
1
1
1
1
2
2 Product Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1
2.2
2.3
General Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.1
Layer 2 Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3
2.1.2
Layer 2 Multicast . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.3
Quality of Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.4
Security . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4
2.1.5
Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
2.1.6
Product Parameters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5
Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
Functional Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 6
2.3.1
Frame Arrival . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
2.3.2
Basic and Advanced Frame Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
2.3.3
Versatile Content Aware Processor (VCAP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 9
2.3.4
Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
2.3.5
Layer-2 Forwarding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.6
Shared Queue System and Egress Scheduler . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11
2.3.7
Rewriter and Frame Departure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
2.3.8
CPU Port Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.9
Synchronous Ethernet and Precision Time Protocol . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
2.3.10 CPU System and Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15
3 Functional Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1
3.2
3.3
3.4
Port Numbering and Mappings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16
3.1.1
Supported SerDes Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.2
Dual-Media Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.3
QSGMII . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.4
PCIe Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
3.1.5
Logical Port Numbers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 17
Port Modules . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.1
MAC . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 18
3.2.2
PCS . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 22
SERDES1G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 25
3.3.1
SERDES1G Basic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.2
SERDES1G Loopback Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 26
3.3.3
Synchronous Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.4
SERDES1G Deserializer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
3.3.5
SERDES1G Serializer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.6
SERDES1G Input Buffer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 28
3.3.7
SERDES1G Output Buffer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.8
SERDES1G Clock and Data Recovery (CDR) in 100BASE-FX . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.9
Energy Efficient Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
3.3.10 SERDES1G Data Inversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 29
SERDES6G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
3.4.1
SERDES6G Basic Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 30
VMDS-10490 VSC7513 Datasheet Revision 4.2
iii
3.5
3.6
3.7
3.8
3.9
3.10
3.11
3.4.2
SERDES6G Loopback Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
3.4.3
Synchronous Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.4
SERDES6G Deserializer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 32
3.4.5
SERDES6G Serializer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.6
SERDES6G Input Buffer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.7
SERDES6G Output Buffer Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 33
3.4.8
SERDES6G Clock and Data Recovery (CDR) in 100BASE-FX . . . . . . . . . . . . . . . . . . . . . . . 34
3.4.9
Energy Efficient Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.10 SERDES6G Data Inversion . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.11 SERDES6G Signal Detection Enhancements . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.4.12 High-Speed I/O Configuration Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
Copper Transceivers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 35
3.5.1
Register Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.2
Cat5 Twisted Pair Media Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
3.5.3
Wake-On-LAN and SecureOn . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.4
Ethernet Inline Powered Devices . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
3.5.5
IEEE 802.3af PoE Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5.6
ActiPHY™ Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
3.5.7
Testing Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 42
3.5.8
VeriPHY™ Cable Diagnostics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.1
Port Statistics . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 44
3.6.2
Accessing and Clearing Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 48
Basic Classifier . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.7.1
General Data Extraction Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
3.7.2
Frame Acceptance Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 50
3.7.3
QoS, DP, and DSCP Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53
3.7.4
VLAN Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
3.7.5
Link Aggregation Code Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
3.7.6
CPU Forwarding Determination . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 58
VCAP . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
3.8.1
Port Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 62
3.8.2
VCAP IS1 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 65
3.8.3
VCAP IS2 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 78
3.8.4
VCAP ES0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 92
3.8.5
Range Checkers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.8.6
VCAP Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 94
3.8.7
Advanced VCAP Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 99
Analyzer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.9.1
MAC Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 101
3.9.2
VLAN Table . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 108
3.9.3
Forwarding Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 109
3.9.4
Analyzer Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
Policers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 118
3.10.1 Policer Allocation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
3.10.2 Policer Burst and Rate Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 120
Shared Queue System . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
3.11.1 Buffer Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 122
3.11.2 Frame Reference Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
3.11.3 Resource Depletion Condition . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
3.11.4 Configuration Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 124
3.11.5 Watermark Programming and Consumption Monitoring . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
3.11.6 Advanced Resource Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
3.11.7 Ingress Pause Request Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 126
3.11.8 Tail Dropping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.11.9 Test Utilities . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
3.11.10 Energy Efficient Ethernet . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 127
VMDS-10490 VSC7513 Datasheet Revision 4.2
iv
3.12
3.13
3.14
3.15
3.16
3.17
3.18
Scheduler and Shapers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
3.12.1 Scheduler Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
3.12.2 Egress Shapers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3.12.3 Deficit Weighted Round Robin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 131
3.12.4 Round Robin . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
3.12.5 Shaping and DWRR Scheduling Examples . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 132
Rewriter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
3.13.1 VLAN Editing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133
3.13.2 DSCP Remarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
3.13.3 FCS Updating . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 137
3.13.4 PTP Time Stamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 138
3.13.5 Special Rewriter Operations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 140
CPU Port Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
3.14.1 Frame Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 142
3.14.2 Frame Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143
3.14.3 Node Processor Interface (NPI) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 146
3.14.4 Frame Generation Engine for Periodic Transmissions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
VRAP Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 148
3.15.1 VRAP Request Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
3.15.2 VRAP Response Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3.15.3 VRAP Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3.15.4 VRAP READ Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
3.15.5 VRAP WRITE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
3.15.6 VRAP READ-MODIFY-WRITE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
3.15.7 VRAP IDLE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
3.15.8 VRAP PAUSE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Layer 1 Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Hardware Time Stamping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
3.17.1 Time Stamp Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
3.17.2 Time of Day Generation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154
3.17.3 Hardware Time Stamping Module . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 156
3.17.4 Configuring I/O Delays . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
Clocking and Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
3.18.1 Pin Strapping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 157
4 VCore-III System and CPU Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
4.1
4.2
4.3
4.4
4.5
4.6
VCore-III Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
Clocking and Reset . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 160
4.2.1
Watchdog Timer . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
Shared Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 161
4.3.1
VCore-III Shared Bus Arbitration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
4.3.2
Chip Register Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 163
4.3.3
SI Flash Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
4.3.4
DDR3/DDR3L Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
4.3.5
PCIe Region . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
VCore-III CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.4.1
Little Endian and Big Endian Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.4.2
Software Debug and Development . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
External CPU Support . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165
4.5.1
Register Access and Multimaster Systems . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
4.5.2
Serial Interface in Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
4.5.3
MIIM Interface in Slave Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 169
4.5.4
Access to the VCore Shared Bus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 171
4.5.5
Mailbox and Semaphores . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 172
PCIe Endpoint Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
4.6.1
Accessing Endpoint Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
VMDS-10490 VSC7513 Datasheet Revision 4.2
v
4.7
4.8
4.6.2
Enabling the Endpoint . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 173
4.6.3
Base Address Registers Inbound Requests . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
4.6.4
Outbound Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 175
4.6.5
Outbound Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 176
4.6.6
Power Management . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 178
4.6.7
Device Reset Using PCIe . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
Frame DMA . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 179
4.7.1
DMA Control Block Structures . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 180
4.7.2
Enabling and Disabling FDMA Channels . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
4.7.3
Channel Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
4.7.4
FDMA Events and Interrupts . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 183
4.7.5
FDMA Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
4.7.6
FDMA Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
4.7.7
Manual Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
VCore-III System Peripherals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
4.8.1
SI Boot Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
4.8.2
SI Master Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 189
4.8.3
DDR3/DDR3L Memory Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 193
4.8.4
Timers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 198
4.8.5
UARTs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
4.8.6
Two-Wire Serial Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 200
4.8.7
MII Management Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
4.8.8
GPIO Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 205
4.8.9
Serial GPIO Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 207
4.8.10 Fan Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
4.8.11 Temperature Sensor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
4.8.12 Memory Integrity Monitor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 214
4.8.13 Interrupt Controller . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 217
5 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.1
5.2
5.3
5.4
5.5
5.6
Switch Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.1.1
Switch Initialization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
Port Module Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.2.1
Port Reset Procedure . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 222
5.2.2
Port Counters . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 223
Layer-2 Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
5.3.1
Basic Switching . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 226
5.3.2
Standard VLAN Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 229
5.3.3
Provider Bridges and Q-in-Q Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 232
5.3.4
Private VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 236
5.3.5
Asymmetric VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
5.3.6
Spanning Tree Protocols . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 240
5.3.7
IEEE 802.1X: Network Access Control . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 245
5.3.8
Link Aggregation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 247
5.3.9
Simple Network Management Protocol (SNMP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
5.3.10 Mirroring . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 250
IGMP and MLD Snooping . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
5.4.1
IGMP and MLD Snooping Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 252
5.4.2
IP Multicast Forwarding Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
Quality of Service (QoS) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 253
5.5.1
Basic QoS Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 254
5.5.2
IPv4 and IPv6 DSCP Remarking . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 255
5.5.3
Voice over IP (VoIP) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 256
VCAP Applications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
5.6.1
Notation for Control Lists Entries . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 257
5.6.2
Ingress Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 258
5.6.3
Access Control Lists . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 259
VMDS-10490 VSC7513 Datasheet Revision 4.2
vi
5.7
5.6.4
Source IP Filter (SIP Filter) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.5
DHCP Application . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.6
ARP Filtering . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.7
Ping Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.6.8
TCP SYN Policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
CPU Extraction and Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.1
Forwarding to CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.2
Frame Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.3
Frame Injection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
5.7.4
Frame Extraction and Injection Using An External CPU . . . . . . . . . . . . . . . . . . . . . . . . . . . .
260
262
263
263
264
264
265
266
267
267
6 Registers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 268
7 Electrical Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
7.1
7.2
7.3
7.4
7.5
DC Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
7.1.1
Internal Pull-Up or Pull-Down Resistors . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
7.1.2
Reference Clock Inputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
7.1.3
PLL Clock Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 269
7.1.4
DDR3 SDRAM Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
7.1.5
DDR3L SDRAM Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 270
7.1.6
SERDES1G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
7.1.7
SERDES6G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 271
7.1.8
GPIO, SI, JTAG, and Miscellaneous Signals . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 272
7.1.9
Thermal Diode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
AC Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
7.2.1
REFCLK Reference Clock (1G and 6G Serdes) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 273
7.2.2
PLL Clock Outputs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 274
7.2.3
SERDES1G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 275
7.2.4
SERDES6G . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 276
7.2.5
Reset Timing Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 279
7.2.6
MIIM Timing Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 280
7.2.7
SI Boot Timing Master Mode Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
7.2.8
SI Timing Master Mode Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 281
7.2.9
SI Timing Slave Mode Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 282
7.2.10 DDR3/DDR3L SDRAM Input Signal Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
7.2.11 DDR3/DDR3L SDRAM Output Signal Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 284
7.2.12 JTAG Interface Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 285
7.2.13 Serial I/O Timing Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
7.2.14 Recovered Clock Outputs Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
7.2.15 Two-Wire Serial Interface Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 286
7.2.16 IEEE1588 Time Tick Output Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Current and Power Consumption . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 288
Operating Conditions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
7.4.1
Power Supply Sequencing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
Stress Ratings . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 289
8 Pin Descriptions . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
8.1
8.2
Pin Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 291
Pins by Function . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 292
9 Package Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
9.1
9.2
9.3
Package Drawing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 310
Thermal Specifications . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 311
Moisture Sensitivity . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 312
10 Design Guidelines . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
VMDS-10490 VSC7513 Datasheet Revision 4.2
vii
10.1
10.2
10.3
Power Supplies . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Power Supply Decoupling . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
10.2.1 Reference Clock . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
10.2.2 Single-Ended REFCLK Input . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 313
Interfaces . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
10.3.1 General Recommendations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 314
10.3.2 SerDes Interfaces (SGMII, 2.5G, QSGMII) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
10.3.3 Serial Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
10.3.4 PCI Express Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 315
10.3.5 Two-Wire Serial Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
10.3.6 DDR3 SDRAM Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 316
10.3.7 Thermal Diode External Connection . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 317
11 Ordering Information . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 319
VMDS-10490 VSC7513 Datasheet Revision 4.2
viii
Figures
Figure 1
Figure 2
Figure 3
Figure 4
Figure 5
Figure 6
Figure 7
Figure 8
Figure 9
Figure 10
Figure 11
Figure 12
Figure 13
Figure 14
Figure 15
Figure 16
Figure 17
Figure 18
Figure 19
Figure 20
Figure 21
Figure 22
Figure 23
Figure 24
Figure 25
Figure 26
Figure 27
Figure 28
Figure 29
Figure 30
Figure 31
Figure 32
Figure 33
Figure 34
Figure 35
Figure 36
Figure 37
Figure 38
Figure 39
Figure 40
Figure 41
Figure 42
Figure 43
Figure 44
Figure 45
Figure 46
Figure 47
Figure 48
Figure 49
Figure 50
Figure 51
Figure 52
Figure 53
Figure 54
Block Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7
Basic and Advanced Frame Classification . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8
Versatile Content Aware Processor . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10
Default Egress Scheduler and Shaper Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12
Alternative Egress Scheduler and Shaper Configuration . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 13
Advanced Frame Rewriting . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14
SERDES1G Loopback Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 27
SERDES6G Loopback Modes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31
Register Space Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 36
Cat5 Media Interface . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 37
Low Power Idle Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Wake-On-LAN Functionality . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 39
Inline Powered Ethernet Switch . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 40
ActiPHY State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 41
Far-End Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Near-End Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Connector Loopback . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 43
Counter Layout (SYS:STAT:CNT) Per View . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 49
VLAN Acceptance Filter . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 52
QoS and DP Basic Classification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 54
Basic DSCP Classification Flow Chart . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 55
Basic VLAN Classification Flow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 57
VCAP Functional Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 60
IS1 Entry Type Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 66
IS2 Half Entry Type Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 79
IS2 Half Entry Type Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 80
SMAC_SIP Entry Type Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 90
VCAP Configuration Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 95
Entry Layout in Register Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 97
Entry Layout in Register using Subwords Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Action Layout in Register Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 98
Move Down Operation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 100
MAC Table Organization . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 102
Analysis Steps . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 110
Policer Pool Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 119
Queue System Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 121
Frame Reference . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 123
Watermark Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 125
Low Power Idle Operation . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 128
Egress Scheduler Port 0 . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 129
Scheduler Element . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 130
Tagging Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 134
Tag Construction (port tag, ES0 tag A, ES0 tag B) . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 136
CPU Injection and Extraction . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 141
CPU Injection and Extraction Prefixes . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 147
VRAP Request Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 149
VRAP Response Frame Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
VRAP Header Format . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 150
READ Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
WRITE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
READ-MODIFY-WRITE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
IDLE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 151
PAUSE Command . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 152
Timing Distribution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155
VMDS-10490 VSC7513 Datasheet Revision 4.2
ix
Figure 55
Figure 56
Figure 57
Figure 58
Figure 59
Figure 60
Figure 61
Figure 62
Figure 63
Figure 64
Figure 65
Figure 66
Figure 67
Figure 68
Figure 69
Figure 70
Figure 71
Figure 72
Figure 73
Figure 74
Figure 75
Figure 76
Figure 77
Figure 78
Figure 79
Figure 80
Figure 81
Figure 82
Figure 83
Figure 84
Figure 85
Figure 86
Figure 87
Figure 88
Figure 89
Figure 90
Figure 91
Figure 92
Figure 93
Figure 94
Figure 95
Figure 96
Figure 97
Figure 98
Figure 99
Figure 100
Figure 101
Figure 102
Figure 103
Figure 104
Figure 105
Figure 106
Figure 107
Figure 108
Figure 109
Figure 110
Figure 111
VCore-III System Block Diagram. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 159
Shared Bus memory . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 162
Chip Registers Memory Map . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 164
SI Slave Mode Register . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 166
Write Sequence for SI . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 167
Read Sequence for SI_CLK Slow . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Read Sequence for SI_CLK Pause . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
Read Sequence for One-Byte Padding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 168
MIIM Slave Write Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
MIIM Slave Read Sequence . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 170
FDMA DCB Layout . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 181
FDMA Channel States . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 182
FDMA Channel Interrupt Hierarchy . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 184
Extraction Status Word Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 185
Injection Status Word Encoding . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 186
SI Boot Controller Memory Map in 24-Bit Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
SI Boot Controller Memory Map in 32-Bit Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 187
SI Read Timing in Normal Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
SI Read Timing in Fast Mode . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 188
SIMC SPI Clock Configurations . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
SIMC SPI 3x Transfers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 191
Memory Controller ODT Hookup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 196
UART Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 199
Two-Wire Serial Interface Timing for 7-bit Address Access . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 202
MII Management Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 203
SIO Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
SIO Timing with SGPIOs Disabled . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 209
SGPIO Output Order . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 210
Link Activity Timing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 212
Monitor State Diagram . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 215
Memory Detection Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 216
Interrupt Source Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 219
Interrupt Destination Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 220
Port Module Interrupt Logic . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 221
MAN Access Switch Setup . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 234
ISP Example for Private VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 237
DMZ Example for Private VLAN . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 238
Asymmetric VLANs . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 239
Spanning Tree Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 241
Multiple Spanning Tree Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 243
Link Aggregation Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 249
Port Mirroring Example . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 251
Resulting ACL for Lookup with PAG = (A) and IGR_PORT_MASK = (10. This FID
takes precedence.
Per IS1 entry
ANA::FID_MAP.FID_C_VAL
VID-to-FID mapping table. 64 FIDs are
programmable. FID_C_VAL=0 effectively
disables the mapping implying that
FID_C_VAL=VID.
Per VID
AGENCTRL.FID_MASK
Combines multiple VIDs in the MAC table.
None
In the default configuration, the device is set up to do Independent VLAN Learning (IVL), that is, MAC
addresses are learned separately on each VLAN. The device also supports Shared VLAN Learning
(SVL), where a MAC table entry is shared among a group of VLANs. For shared VLAN learning, a MAC
address and a Filter Identifier (FID) define each MAC table entry. A set of VIDs then map to the FID.
The device supports shared VLAN learning in three ways:
•
•
•
Through the IS1 actions FID_SEL and FID_VAL specifying the FID to use.
Through the per-VID mapping table FID_MAP.
Through the AGENCTRL.FID_MASK, which controls a general mapping between FID and VIDs.
VMDS-10490 VSC7513 Datasheet Revision 4.2
106
Functional Descriptions
The IS1 action FID_SEL selects whether to use the FID_VAL for the DMAC lookup, for the SMAC lookup
(learning), or for both lookups. If set for a lookup, the FID_VAL replaces the VID when calculating the
hash key into the MAC table and when comparing with the entry’s VID. If used during the SMAC lookup,
new entries are learned using the FID_VAL. If an IS1 action returns a FID_SEL > 0, it overrules the use
of the FID mapping table for the frame. In addition, FID_SEL > 0 overrules the use of the FID_MASK for
the MAC table lookups specified in FID_SEL.
The FID mapping table, FID_MAP, maps the frame’s classified VID to a FID. If the returned FID is larger
than 0, then the FID overrules the use of the FID_MASK for both the DMAC and SMAC lookups in the
MAC table. Learning is done using the returned FID.
If neither IS1 nor the FID_MAP table have instructed changes to the FID, then the FID_MASK is applied.
The 12-bit FID_MASK masks out the corresponding bits in the VID. The FID used for learning and lookup
is therefore calculated as FID = VID AND (NOT FID_MASK). The FID used in the MAC table is 13 bits so
the calculated FID is prepended with 0. Bit 13 in the FID in the MAC table is only selectable through the
FID_ENA action out of IS1.
All VIDs mapping to the same FID share the same MAC table entries.
Example: Configure all MAC table entries to be shared among all VLANs.
This is done by setting FID_MASK to 111111111111.
Example: Split the MAC table into two separate databases: one for even VIDs and one for odd VIDs.
This is done by setting FID_MASK to 111111111110.
3.9.1.8
Learn Limit
The following table lists the registers associated with controlling the number of MAC table entries per
port.
Table 81 •
Learn Limit Definition Registers
Register
Description
Replication
ENTRYLIM
Configures maximum number of unlocked entries in the Per port
MAC table per ingress port.
PORT_CFG.LIMIT_CPU
If set, learn frames exceeding the limit are copied to the Per port
CPU.
PORT_CFG.LIMIT_DROP If set, learn frames exceeding the limit are discarded.
Per port
LEARNDISC
None
The number of MAC table entries that could not be
learned due to a lack of storage space.
The ENTRYLIM.ENTRYLIM register specifies the maximum number of unlocked entries in the MAC table
that a port is allowed to use. Locked and IPMC entries are not taken into account.
After the limit is reached, both auto-learning and CPU-based learning on unlocked entries are denied. A
learn frame causing the limit to be exceeded can be copied to the CPU (PORT_CFG.LIMIT_CPU) and
the forwarding to other front ports can be denied (PORT_CFG.LIMIT_DROP).
The ENTRYLIM.ENTRYSTAT register holds the current number of entries in the MAC table. MAC table
aging and manual removing of entries through the CPU cause the current number to be reduced. If a
MAC table entry moves from one port to another port, this is also reduces the current number. If the
move causes the new port’s limit to be exceeded, the entry is denied and removed from the MAC table.
The LEARNDISC counts all events where a MAC table entry is not created or updated due to a learn
limit.
VMDS-10490 VSC7513 Datasheet Revision 4.2
107
Functional Descriptions
3.9.2
VLAN Table
The following table lists the registers associated with the VLAN Table.
Table 82 •
VLAN Table Access
Register
Description
Replication
VLANTIDX
VID to access, and VLAN flags.
None
VLANACCESS
VLAN port mask for VID and command for access.
None
The analyzer has a VLAN table that contains information about the members of each of the 4096 VLANs.
The following table lists fields for each entry in the VLAN table.
Table 83 •
Fields in the VLAN Table
Field
Bits
Description
VLAN_PORT_MASK
11
One bit for each port. Set if port is member of VLAN.
The CPU port is always a member of all VLANs.
VLAN_MIRROR
1
Mirror frames received in the VLAN. See Mirroring,
page 117.
VLAN_SRC_CHK
1
VLAN ingress filtering. If set, frames classified to this VLAN
are dropped if PPORT is not member of the VLAN.
VLAN_LEARN_DISABLED
1
Disable learning in the VLAN.
VLAN_PRIV_VLAN
1
Set VLAN to private.
By default, all ports are members of all VLANs. This default can be changed through a CPU command.
The following table lists the set of commands that a CPU can issue to access the VLAN table. The VLAN
table command is written to VLANACCESS.VLAN_TBL_CMD.
Table 84 •
VLAN Table Commands
Command
Purpose
Use
INIT
Initialize the table
Issue command. When VLAN_TBL_CMD changes to
IDLE, initialization has completed and all ports are
member of all VLANs. All flags are cleared.
READ
Read VLAN table entry
for specific VID.
Configure the VLAN to read from in
VLANTIDX.V_INDEX.
When VLAN_TBL_CMD changes to IDLE,
VLANACCESS, and VLANTIDX contain the information
read.
WRITE
Write VLAN table entry
for specific VID.
Configure the VLAN to write to in VLANTIDX.V_INDEX.
Configure the content of the VLAN record in
VLANACCESS.VLAN_PORT_MASK
VLANTIDX.VLAN_MIRROR
VLANTIDX.VLAN_SRC_CHK
VLANTIDX.VLAN_LEARN_DISABLED
VLANTIDX.VLAN_PRIV_VLAN
IDLE
Indicate that VLAN table No preload required.
is ready for new
command.
VMDS-10490 VSC7513 Datasheet Revision 4.2
108
Functional Descriptions
3.9.3
Forwarding Engine
The analyzer determines the set of ports to which each frame is forwarded, in several configurable steps.
The resulting destination port set can include any number of front ports, excluding the CPU port. The
CPU port is handled through te CPU extraction queue mask.
The analyzer request from the port modules is passed through all the processing steps of the forwarding
engine. As each step is carried out, the destination port set (DEST) and CPU extraction queue mask
(CPUQ) are built up.
In addition to the forwarding decision, the analyzer determines which frames are subject to learning (also
known as learn frames). Learn frames trigger insertion of a new entry in the MAC table or update of an
existing entry. Learning is presented as part of the forwarding, because in some cases, learning changes
the normal forwarding of a frame, such as secure learning.
During the processing, the analyzer determines a local frame property. The learning-disabled flag,
LRN_DIS is used in the SMAC Learning step:
•
•
If the learning-disabled flag is set, learning based on (SMAC, VID) is disabled.
If the learning-disabled flag is cleared, learning is conducted according to the configuration in the
SMAC learning step.
The following illustration shows the configuration steps in the analyzer.
VMDS-10490 VSC7513 Datasheet Revision 4.2
109
Functional Descriptions
Figure 34 • Analysis Steps
Analyzer Request
DMAC Analysis
Forward to known destinations or flood
MAC
Table
CPUQ DEST
VLAN Analysis
Check VLAN membership
LRN_DIS
VLAN
Table
CPUQ DEST
Aggregation
Select one port per aggregation group
LRN_DIS
CPUQ DEST
VCAP-II IS2
Apply IS2 actions
LRN_DIS
IS2
CPUQ DEST
SMAC Analysis
Perform learning
MAC
Table
CPUQ DEST
Storm Policers
Limit rate of specific frame types
CPUQ DEST
sFlow Sampling
Perform statistical sampling
Analyzer Reply
3.9.3.1
DMAC Analysis
During the DMAC analysis step, the (DMAC, VID) pair is looked up in the MAC table to get the first input
to the calculation of the destination port set. For more information about the MAC table, see MAC Table,
page 101.
VMDS-10490 VSC7513 Datasheet Revision 4.2
110
Functional Descriptions
The following table lists the registers associated with the DMAC analysis step.
Table 85 •
DMAC Analysis Registers
Register
Description
Replication
FLOODING.FLD_UNICAST
Index into the PGID table used for flooding
of unicast frames.
None
FLOODING.FLD_BROADCAST
Index into the PGID table used for flooding
of broadcast frames.
None
FLOODING.FLD_MULTICAST
Index into the PGID table used for flooding None
of multicast frames, not flooded by the IPMC
flood masks.
FLOODING_IPMC.FLD_MC4_CTRL
Index into the PGID table used for flooding
of IPv4 multicast control frames.
None
FLOODING_IPMC.FLD_MC4_DATA
Index into the PGID table used for flooding
of IPv4 multicast data frames.
None
FLOODING_IPMC.FLD_MC6_CTRL
Index into the PGID table used for flooding
of IPv6 multicast control frames.
None
FLOODING_IPMC.FLD_MC6_DATA
Index into the PGID table used for flooding
of IPv6 multicast data frames.
None
PGID[63:0]
Destination and flooding masks table.
64
AGENCTRL.
IGNORE_DMAC_FLAGS
Controls the use of MAC table flags from
(DMAC, VID) entry and flooding flags.
None
CPUQ_CFG
Configuration of CPU extraction queues
None
The (DMAC, VID) pair is looked up in the MAC table. A match is found when the (DMAC, VID) pair
matches that of an entry.
If a match is found, the entry is returned and DEST is determined based on the MAC table entry. For
more information, see MAC Table, page 101.
If an entry is found in the MAC table entry of ENTRY_TYPE 0 or 1 and the CPU port is set in the PGID
pointed to by the MAC table entry, CPU extraction queue PGID.DST_PGID is added to the CPUQ.
If an entry is not found for the (DMAC, VID) in the MAC table, the frame is flooded. The forwarding
decision is set to one of the seven flooding masks defined in ANA::FLOODING or
ANA::FLOODING_IPMC, based on one of the flood type definitions listed in the following table.
Table 86 •
Forwarding Decisions Based on Flood Type
Frame Type
Condition
IPv4 multicast data
DMAC = 0x01005E000000 to 0x01005E7FFFFF
EtherType = IPv4
IP protocol is not IGMP
IPv4 DIP outside 224.0.0.x
IPv6 multicast data
DMAC = 0x333300000000 to 0x3333FFFFFFFFF
EtherType = IPv6
IPv6 DIP outside 0xFF02::/16
IPv4 multicast control
DMAC = 0x01005E000000 to 0x01005E7FFFFF
EtherType = IPv4
IP protocol is not IGMP
IPv4 DIP inside 224.0.0.x
VMDS-10490 VSC7513 Datasheet Revision 4.2
111
Functional Descriptions
Table 86 •
Forwarding Decisions Based on Flood Type (continued)
Frame Type
Condition
IPv6 multicast control
DMAC = 0x333300000000 to 0x3333FFFFFFFFF
EtherType = IPv6
IPv6 DIP inside 0xFF02::/16
Broadcast
DMAC = 0xFFFFFFFFFFFFFF
non-IPv4-multicast-data
non-IPv6-multicast-data
non-IPv4-multicast-control
non-IPv6-multicast-control
Multicast
Bit 40 in DMAC = 1
non-broadcast
non-IPv4-multicast-data
non-IPv6-multicast-data
non-IPv4-multicast-control
non-IPv6-multicast-control
Unicast
Bit 40 in DMAC = 0
In addition, the MAC table flag MAC_CPU_COPY is processed. If MAC_CPU_COPY is set, the
CPUQ_CFG.CPUQ_MAC is added to CPUQ.
The processing of this flag can be disabled through AGENCTRL.IGNORE_DMAC_FLAGS.
Next, CPU-forwarding from the basic classifier, and the IS2 SMAC_SIP lookup is processed if:
•
•
•
•
The basic classifier decided to copy the frame to the CPU, the corresponding CPU extraction queue
is added to CPUQ.
The basic classifier decided to redirect the frame to the CPU, DEST is cleared and the
corresponding CPU extraction queue is added to CPUQ.
The IS2 SMAC_SIP result decided to copy the frame to the CPU
(SMAC_SIP_ACTION.CPU_COPY_ENA), the corresponding CPU extraction queue,
SMAC_SIP_ACTION.CPU_QU_NUM is added to CPUQ.
The IS2 SMAC_SIP result decided to discard the frame (SMAC_SIP_ACTION.FWD_KILL_ENA
set), DEST is cleared.
For more information about frame type definitions for CPU forwarding in the basic classifier, see
Table 33, page 59.
3.9.3.2
VLAN Analysis
During the VLAN analysis step, VLAN configuration is taken into account. As a result, ports can be
removed from the forwarding decision. For more information about VLAN configuration, see VLAN Table,
page 108.
The following table lists the registers associated with VLAN analysis.
Table 87 •
VLAN Analysis Registers
Register
Description
Replication
VLANMASK
If PPORT is set in this mask, and PPORT is not member
of the VLAN to which the frame is classified, DEST is
cleared. This is also called VLAN ingress filtering.
None
PORT_CFG.RECV_ENA If this bit is cleared for PPORT, forwarding from this port to Per port
other front ports is disabled, and DEST is cleared.
PGID[91:80]
Source port mask. Port mask per port, which specifies
Per port
allowed destination ports for frames received on PPORT.
By default, a port can forward to all other ports except
itself.
VMDS-10490 VSC7513 Datasheet Revision 4.2
112
Functional Descriptions
Table 87 •
VLAN Analysis Registers (continued)
Register
Description
Replication
ISOLATED_PORTS
Private VLAN mask. Isolated ports are cleared in this
mask.
None
COMMUNITY_PORTS
Private VLAN mask. Community ports are cleared in this
mask.
None
ADVLEARN.VLAN_CHK
If set and VLAN ingress filtering clears DEST, then SMAC None
learning is disabled.
The frame’s VID is used as an address for lookup in the VLAN table and the returned VLAN information
is processed as follows:
•
•
•
All ports that are not members of the VLAN are removed from DEST, except if the (DMAC, VID)
match in the MAC table has VLAN_IGNORE set, or if there is no match in the MAC table and
AGENCTRL.FLOOD_IGNORE_VLAN is set.
Note These two exceptions are skipped if AGENCTRL.IGNORE_DMAC_FLAGS is set.
If the VLAN_PRIV_VLAN flag in the VLAN table is set, the VLAN is private, and isolated and
community ports must be treated differently. An isolated port is identified as an ingress port for which
PPORT is cleared in the ISOLATED_PORTS register. An community port is identified as an ingress
port for which PPORT is cleared in the COMMUNITY_PORTS register. For frames received on an
isolated port, all isolated and community ports are removed from the forwarding decision. For frames
received on a community port, all isolated ports are removed from the forwarding decision.
If VLAN ingress filtering is enabled, it is checked whether PPORT is member of the VLAN
(VLAN_PORT_MASK). If this is not the case, DEST is cleared.
VLAN ingress filtering is enabled per port in the VLANMASK register or per VLAN in the
VLAN_SRC_CHK flag in the VLAN table. If either is set, VLAN ingress filtering is performed.
Next, it is checked whether the ingress port is enabled to forward frames to other front ports and the
source mask (PGID[80+PPORT]) is processed as follows:
•
•
If PORT_CFG.RECV_ENA for PPORT is 0, DEST is cleared.
Any ports, which are cleared in PGID[80+PPORT], are removed from DEST.
Finally, SMAC learning is disabled by setting the LRN_DIS flag when either of the following two
conditions is fulfilled as follows:
•
•
3.9.3.3
VLAN_LEARN_DISABLED is set in the VLAN table for the VLAN.
A frame is subject to VLAN ingress filtering (frame dropped due to PPORT not being member of
VLAN), and ADVLEARN.VLAN_CHK is set.
Aggregation
During the aggregation step, link aggregation is handled. The following table lists the registers
associated with aggregation.
Table 88 •
Analyzer Aggregation Registers
Register
Description
Replication
PGID[79:64]
Aggregation mask table.
16
The aggregation step ensures that when a frame is destined for an aggregation group, it is forwarded to
exactly one of the group’s member ports.
For non-aggregated ports, there is a one-to-one correspondence between logical port (LPORT) and
physical port (PPORT). The aggregation step does not change the forwarding decision.
For aggregated ports, all physical ports in the aggregation group map to the same logical port, and the
entry in the destination mask table for the logical port includes all physical ports, which are members of
VMDS-10490 VSC7513 Datasheet Revision 4.2
113
Functional Descriptions
the aggregation group. As a result, all but one member port must be removed from the destination port
set.
The link aggregation code generated in the classifier is used to look up an aggregation mask in the
aggregation masks table. Finally, ports that are cleared in the selected aggregation mask are removed
from DEST.
For more information about link aggregation, see Link Aggregation, page 247.
3.9.3.4
VCAP Action Handling
VCAP IS2 actions are processed during the VCAP IS2 action handling step. The following table lists the
processing of the VCAP actions. The order of processing is from top to bottom.
Table 89 •
VCAP IS2 Action Processing
IS2 Action Field
Description
CPU_COPY_ENA
CPU_QU_NUM
If CPU_COPY_ENA is set, the CPU_QU_NUM bit is set in CPUQ.
HIT_ME_ONCE
CPU_QU_NUM
If HIT_ME_ONCE is set and the HIT_CNT counter is zero, the
CPU_QU_NUM bit is set in CPUQ.
LRN_DIS
If set, learning is disabled (LRN_DIS flag is set).
POLICE_ENA
POLICE_IDX
If POLICE_ENA is set (only applies to first lookup), the POLICE_IDX
instructs which policer to use for this frame. See Policers, page 118.
POLICE_VCAP_ONLY
If POLICE_VCAP_ONLY is set (only applies to first lookup), the only active
policer for this frame is the VCAP policer. Other policers (QoS, port) are
disabled. See Policers, page 118.
MASK_MODE
PORT_MASK
The following actions are defined for MASK_MODE.
0: No action.
1: Permit. Ports cleared in PORT_MASK are removed from DEST.
2: Policy. DEST from the DMAC analysis step is replaced with
PORT_MASK.
3: Redirect. DEST as the outcome of the DMAC, VLAN, service, and
aggregation analysis steps is replaced with PORT_MASK.
MIRROR_ENA
If MIRROR_ENA is set, mirroring is enabled. This is used in the mirroring
step. See Mirroring, page 117.
3.9.3.5
SMAC Analysis
During the SMAC analysis step, the MAC table is searched for a match against the (SMAC, VID), and the
MAC table is updated due to learning. Either the B-MAC table or the C-MAC table is searched. The
learning part is skipped if the LRN_DIS flag was set by any of the previous steps.
The following table lists the registers associated with SMAC learning.
Table 90 •
SMAC Learning Registers
Register
Description
Replication
PORT_CFG.LEARN_ENA
If cleared for PPORT, learning is skipped (that is,
LEARNAUTO, LEARNCPU, LEARNDROP,
LIMIT_CPU, LIMIT_DROP,
LOCKED_PORTMOVE_CPU, and
LOCKED_PORTMOVE_DROP are ignored).
Per port
PORT_CFG.LEARNAUTO
If set for PPORT, hardware-based learning is
performed.
Per port
PORT_CFG.LEARNCPU
If set for PPORT, learn frames are copied to the
CPU.
Per port
VMDS-10490 VSC7513 Datasheet Revision 4.2
114
Functional Descriptions
SMAC Learning Registers (continued)
Table 90 •
Register
Description
Replication
PORT_CFG.LEARNDROP
If set for PPORT, the CPU drops or forwards learn Per port
frames.
PORT_CFG.LIMIT_CPU
If set for PPORT, learn frames for which PPORT
exceeds the port’s limit are copied to the CPU.
Per port
PORT_CFG.LIMIT_DROP
If set for PPORT, learn frames for which PPORT
exceeds the port’s limit are discarded.
Per port
PORT_CFG.LOCKED_PORTMOVE_CPU
If set for PPORT, frames triggering a port move of Per port
a locked entry are copied to the CPU.
PORT_CFG.LOCKED_PORTMOVE_DROP If set for PPORT, frames triggering a port move of Per port
a locked entry are discarded.
AGENCTRL.IGNORE_SMAC_FLAGS
Controls the use of the MAC table flags from
(SMAC, VID) entry.
None
Three different type of learn frames are identified:
•
•
•
Normal learn frames. Frames for which an entry for the (SMAC, VID) is not found in the MAC table
or the (SMAC, VID) entry in the MAC table is unlocked and has a DEST_IDX different from LPORT.
In addition, the learn limit for the LPORT must not be exceeded (ENTRYLIM).
Learn frames exceeding the learn limit. Same condition as for normal learn frames except that the
learn limit for the LPORT is exceeded (ENTRYLIM)
Learn frames triggering a port move of a locked MAC table entry. Frames for which the (SMAC,
VID) entry in the MAC table is locked and has a DEST_IDX different from LPORT.
For all learn frames, the following must apply before learning related processing is applied.
•
•
Learning is enabled by PORT_CFG.LEARN_ENA.
The LRN_DIS flag from previous processing steps must be cleared, which implies the following:
Learning is not disabled due to VLAN ingress filtering
Learning is not disabled due to VCAP IS2 action
Learning is enabled for the VLAN (VLAN_LEARN_DISABLED is cleared in the VLAN table)
In addition, learning must not be disabled due to the ingress policer having policed the frame. For more
information, see Policers, page 118.
If learning is enabled, learn frames are processed according to the setting of the following configuration
parameters.
3.9.3.5.1
Normal Learn Frames
•
•
•
3.9.3.5.2
Learn Frames Exceeding the Learn Limit
•
•
3.9.3.5.3
Automatic learning. If PORT_CFG.LEARNAUTO is set for PPORT, the (SMAC, VID) entry is
automatically added to the MAC table in the domain being searched.
Drop learn frames. If PORT_CFG.LEARNDROP is set for PPORT, DEST is cleared for learn frames.
Therefore, learn frames are not forwarded on any ports. This is used for secure learning, where the
CPU must verify a station before forwarding is allowed.
Copy learn frames to the CPU. If PORT_CFG.LEARNCPU is set for PPORT, the CPU port is added
to DEST for learn frames and CPUQ_CFG.CPUQ_LRN is set in CPUQ. This is used for CPU based
learning.
Drop learn frames. If PORT_CFG.LIMIT_DROP is set for PPORT, DEST is cleared for learn frames.
As a result, learn frames are not forwarded on any ports.
Copy learn frames to the CPU – If PORT_CFG.LIMIT_CPU is set for PPORT, the CPU port is added
to DEST and CPUQ_CFG.CPUQ_LRN is set in CPUQ for learn frames.
Learn Frames Triggering a Port Move of a Locked MAC Table Entry
•
Drop learn frames. If PORT_CFG.LOCKED_PORTMOVE_DROP is set for PPORT, DEST is cleared
for learn frames. Therefore, learn frames are not forwarded on any ports.
VMDS-10490 VSC7513 Datasheet Revision 4.2
115
Functional Descriptions
•
Copy learn frames to the CPU. If PORT_CFG.LOCKED_PORTMOVE_CPU is set for PPORT, the
CPU port is added to DEST and CPUQ_CFG.CPUQ_LOCKED_PORTMOVE is added to CPUQ.
Finally, if a match is found in the MAC table for the (SMAC, VID), adjustments can be made to the
forwarding decision.
•
•
If the (SMAC, VID) match in the MAC table has SRC_KILL set, DEST is cleared.
If the (SMAC, VID) match in the MAC table has MAC_CPU_COPY set,
CPUQ_CFG.CPUQ_MAC_COPY is added to CPUQ.
The processing of the MAC table flags from the (SMAC, VID) match can be disabled through
AGENCTRL.IGNORE_SMAC_FLAGS.
3.9.3.6
Storm Policers
The storm policers are activated during the storm policers step. The following table lists the registers
associated with storm policers.
Table 91 •
Storm Policer Registers
Register
Description
Replication
STORMLIMIT_CFG
Enables policing of various frame types.
4
STORMLIMIT_BURST Configures maximum allowed rates of the different frame types.
None
The analyzer contains four storm policers that can limit the maximum allowed forwarding frame rate for
various frame types. The storm policers are common to all ports and, as a result, measure the sum of
traffic forwarded by the switch. A frame can activate several policers, and the frame is discarded if any of
the activated policers exceed a configured rate.
Each policer can be configured to a frame rate ranging from 1 frame per second to 1 million frames per
second.
The following table lists the available policers.
Table 92 •
Storm Policers
Policer
Description
Broadcast
Flooded frames with DMAC = 0xFFFFFFFFFFFF.
Multicast
Flooded frames with DMAC bit 40 set, except broadcasts.
Unicast
Flooded frames with DMAC bit 40 cleared.
Learn
Learn frames copied or redirected to the CPU due to learning
(LOCKED_PORTMOVE_CPU, LIMIT_CPU, LEARNCPU).
For each of the policers, a maximum rate is configured in STORMLIMIT_CFG and
STORMLIMIT_BURST:
•
•
•
•
STORM_UNIT chooses between a base unit of 1 frame per second or 1 kiloframes per second.
STORM_RATE sets the rate to 1, 2, 4, 8, …, 1024 times the base unit (STORM_UNIT).
STORM_BURST configures the maximum number of frames in a burst.
STORM_MODE specifies how the policer affects the forwarding decision. The options are:
•
When policing, clear CPUQ.
•
When policing, clear DEST.
•
When policing, clear DEST and CPUQ.
Frames where the DMAC lookup returned a PGID with the CPU port set are always forwarded to the
CPU even when the frame is policed by the storm policers. For more information, see DMAC Analysis,
page 110.
VMDS-10490 VSC7513 Datasheet Revision 4.2
116
Functional Descriptions
3.9.3.7
sFlow Sampling
This process step handles sFlow sampling. The following table lists the registers associated with sFlow
sampling.
Table 93 •
sFlow Sampling Registers
Register
Description
Replication
SFLOW_CFG
Configures sFlow samplers (type and rates).
Per port
CPUQ_CFG.CPUQ_SFLOW CPU extraction queue for sFLow sampled frames.
None
sFlow is a standard for monitoring high-speed switch networks through statistical sampling of incoming
and outgoing frames. Each port in the device can be setup as an sFlow agent monitoring the particular
link and generating sFlow data. If a frame is sFlow sampled, it is copied to the sFlow CPU extraction
queue (CPUQ_SFLOW).
An sFlow agent is configured through SFLOW_CFG with the following options:
•
•
•
SF_RATE specifies the probability that the sampler copies a frame to the CPU. Each frame being
candidate for the sampler has the same probability of being sampled. The rate is set in steps of
1/4096.
SF_SAMPLE_RX enables incoming frames on the port as candidates for the sampler.
SF_SAMPLE_TX enables outgoing frames on the port as candidates for the sampler.
The Rx and Tx can be enabled independently. If both are enabled, all incoming and outgoing traffic on
the port is subject to the statistical sampling given by the rate in SF_RATE.
3.9.3.8
Mirroring
This processing step handles mirroring. The following table lists the registers associated with mirroring.
Table 94 •
Mirroring Registers
Register
Description
Replication
ADVLEARN.LEARN_MIRROR
For learn frames, ports in this mask (mirror
ports) are added to DEST.
None
AGENCTRL.MIRROR_CPU
Mirror all frames forwarded to the CPU port
module.
None
PORT_CFG.SRC_MIRROR_ENA
Mirror all frames received on an ingress port
(ingress port mirroring).
Per port
EMIRRORMASK
Mirror frames that are to be transmitted on any None
ports set in this mask (egress port mirroring).
VLANTIDX.VLAN_MIRROR
Mirror all frames classified to a specific VID.
Per VLAN
IS2_ACTION.MIRROR_ENA
Mirror when an IS2 action is hit.
Per VCAP IS2
entry
MIRRORPORTS
When mirroring a frame, ports in this mask are None
added to DEST.
AGENCTRL.CPU_CPU_KILL_ENA Clear the CPU port if source port is the CPU
port and the CPU port is set in DEST.
None
Frames subject to mirroring are identified based on the following mirror probes:
•
•
•
•
•
•
Learn mirroring if ADVLEARN.LEARN_MIRROR is set and frame is a learn frame.
CPU mirroring if AGENCTRL.MIRROR_CPU is set and the CPU port is set in DEST.
Ingress mirroring if PORT_CFG.SRC_MIRROR_ENA is set.
Egress mirroring if any port set in EMIRRORMASK is also set in DEST.
VLAN mirroring if VLAN_MIRROR set in the VLAN table entry.
VCAP mirroring if an action is hit that requires mirroring.
VMDS-10490 VSC7513 Datasheet Revision 4.2
117
Functional Descriptions
The following adjustment is made to the forwarding decision for frames subject to mirroring:
•
Ports set in MIRRORPORTS are added to DEST.
If the CPU port is set in the MIRRORPORTS, CPU extraction queue CPUQ_CFG.CPUQ_MIRROR is
added to the CPUQ.
For learn frames with learning enabled, all ports in ADVLEARN.LEARN_MIRROR are added to DEST.
For more information, see SMAC Analysis, page 114.
For more information about mirroring, see Mirroring, page 250.
Finally, if AGENCTRL.CPU_CPU_KILL_ENA is set, the CPU port is removed if the ingress port is the
CPU port itself. This is similar to source port filtering done for front ports and prevents the CPU from
sending frames back to itself.
3.9.4
Analyzer Monitoring
Miscellaneous events in the analyzer can be monitored, which can provide an understanding of the
events during the processing steps. The following table lists the registers associated with analyzer
monitoring.
Table 95 •
Analyzer Monitoring
Register
Description
Replication
ANMOVED
ANMOVED[n] is set when a known station has moved to port n.
None
ANEVENTS
Sticky bit register for various events.
None
LEARNDISC
The number of learn events that failed due to a lack of storage
space in the MAC table.
None
Port moves, defined as a known station moving to a new port, are registered in the ANMOVED register.
A port move occurs when an existing MAC table entry for (MAC, VID) is updated with new port
information (DEST_IDX). Such an event is registered in ANMOVED by setting the bit corresponding to
the new port.
Continuously occurring port moves may indicate a loop in the network or a faulty link aggregation
configuration.
A list of events, such as frame flooding or policer drop, can be monitored in ANEVENTS.
The LEARNDISC counter registers every time an entry in the MAC table cannot be made or if an entry is
removed due to lack of storage.
3.10
Policers
The device has 192 policers that can be allocated to ingress ports, QoS classes per port, and VCAP IS2
entries. The policers limit the bandwidth of received frames by discarding frames exceeding configurable
rates. All policers are MEF compliant dual leaky bucket policers that are capable of handling committed
and excess peak information rates.
Each frame can hit up to three policers: One port policer, one VCAP policer and one QoS policer. The
order in which the policers are applied to a frame is programmable.
In addition to the policers, the device also supports a number of storm policers and an egress scheduler
with shaping capabilities. For more information, see Storm Policers, page 116 and Scheduler and
Shapers, page 128.
The following table lists the registers associated with policer control.
Table 96 •
Policer Control Registers
Register
Description
Replication
ANA:PORT:POL_CFG
Enables use of port and QoS policers
Per port
VMDS-10490 VSC7513 Datasheet Revision 4.2
118
Functional Descriptions
Table 96 •
Policer Control Registers (continued)
Register
Description
Replication
ANA:POL:POL_PIR_CFG
Configures the policer’s peak information rate
384
ANA:POL:POL_CIR_CFG
Configures the policer’s committed information rate
384
ANA:POL:POL_MODE_CFG
Configures the policer’s mode of operation
384
ANA:POL:POL_PIR_STATE
Current state of the peak information rate bucket
384
ANA:POL:POL_CIR_STATE
Current state of the committed information rate bucket
384
ANA:PORT:POL_FLOWC
Flow control settings
Per port
ANA::POL_HYST
Hysteresis settings
None
3.10.1
Policer Allocation
The different policer types are assigned a policer from the pool of policers the following ways:
•
•
•
Port policers. Frames received on physical port ‘p’ use policer ‘p’. Each of physical ports can be
assigned to its own policer.
QoS policers. Frames classified to QoS class ‘q’ on physical port ‘p’ use policer 32 + 8x ‘p’ + ‘q’.
Each of the eight per-port QoS classes per port can be assigned to its own policer.
VCAP IS2 policers. Policers 128 through 191 can be allocated to VCAP policing. The action
IS2_ACTION.POLICE_IDX points to the policer that is used.
The policer pool layout is illustrated in the following drawing.
Figure 35 • Policer Pool Layout
0
11
12
31
32
Port Policers (12)
Unused
QoS Policers (96)
127
128
VCAP Policers (64)
191
By default, none of the policers from the pool are allocated.
Port policers are allocated through ANA:PORT:POL_CFG.PORT_POL_ENA per port and QoS policers
are allocated through ANA:PORT:POL_CFG.QUEUE_POL_ENA per QoS class per port.
Finally, VCAP IS2 policers are allocated by creating IS2 rules with POLICE_ENA and POLICE_IDX
actions. IS2 policers actions are only valid in the first lookup in IS2. The VCAP can point to any unused
policer in addition to the dedicated VCAP policers.
Any frame received by the MAC and forwarded to the classifier is applicable to policing. Frames with
errors, pause frames, or MAC control frames are not forwarded by the MAC and, as a result, they are not
accounted for in the policers. That is, they are not policed and are not adding to the rate measured by the
policers.
In addition, the following special frame types can bypass the policers:
VMDS-10490 VSC7513 Datasheet Revision 4.2
119
Functional Descriptions
•
•
If ANA:PORT:POL_CFG.POL_CPU_REDIR_8021 is set, frames being redirected to the CPU due to
the classifier detecting the frames as being BPDU, ALLBRIDGE, GARP, or CCM/Link trace frames
are not policed.
If ANA:PORT:POL_CFG.POL_CPU_REDIR_IP is set, frames being redirected to the CPU due to the
classifier detecting the frames as being IGMP or MLD frames are not policed.
These frames are still considered part of the rates being measured so the frames add to the relevant
policer buckets but they are never discarded due to policing.
The VCAP IS2 has the option to disable the port policing and QoS class policing. This is done with the
action POLICE_VCAP_ONLY. If POLICE_VCAP_ONLY is set, only a VCAP assigned policer can police
the frame. The other policers are inactive meaning the frame does not add to the policers’ buckets and
the frame is never discarded due to policing by the policers.
The order in which the policers are executed is controlled through ANA:PORT:POL_CFG.POL_ORDER.
The order can take the following main modes:
•
•
•
3.10.2
Serial The policers are checked one after another. If a policer is closed, the frame is discarded and
the subsequent policer buckets are not updated with the frame. The serial order is programmable.
Parallel with independent bucket updates The three policers are working in parallel
independently of each other. Each frame is added to a policer bucket if the policer is open, otherwise
the frame is discarded. A frame may be added to one policer although another policer is closed.
Parallel with dependent bucket updates The three policers are working in parallel but dependent
on each other with respect to bucket updates. A frame is only added to the policer buckets if all three
policers are open.
Policer Burst and Rate Configuration
Each of the policers is MEF-compliant dual leaky bucket policers. This implies that each policer supports
the following configurations:
•
•
•
•
•
•
Committed Information Rate (CIR). Specified in POL_CIR_CFG.CIR_RATE in steps of 33.3 kbps.
Maximum rate is 1.09 Gbps. If higher bandwidths are required, the policer for 2.5G ports must be
disabled.
Committed Burst Size (CBS). Specified in POL_CIR_CFG.CIR_BURST in steps of 4 kilobytes.
Maximum is 252 kilobytes.
Excess Information Rate (EIR). Specified in POL_PIR_CFG.PIR_RATE in steps of 33.3 kbps.
Maximum rate is 1.09 Gbps. If higher bandwidths are required, the policer for 2.5G ports must be
disabled.
Excess Burst Size (EBS). Specified in POL_PIR_CFG.PIR_BURST in steps of 4 kilobytes. Maximum
is 252 kilobytes.
Coupling flag. If POL_MODE_CFG.DLB_COUPLED is set, frames classified as yellow (DP level = 1)
are allowed to use of the committed information rate when not fully used by frames classified as
green (DP level = 0). If cleared, the rate of frames classified as yellow are bounded by EIR.
Color mode. Color-blind or color-aware. A policer always obey the frame color assigned by the
classifier. To achieve color-blindness, the classifier must be set up to classify all incoming frames to
DP level = 0.
The following parameters can also be configured per policer:
•
•
•
The leaky bucket calculation can be configured to include or exclude preamble and inter-frame gap
through configuration of POL_MODE_CFG.IPG_SIZE.
Each policer can be configured to measure frame rates instead of bit rates
(POL_MODE_CFG.FRM_MODE). The rate unit can be configured to 100 frames per second or 1
frame per second.
Each policer can operate as a single leaky bucket by disabling POL_MODE_CFG.CIR_ENA. When
operating as a single leaky bucket, the POL_PIR_CFG register controls the rate and burst of the
policer.
By default, a policer discards frames while the policer is closed. A discarded frame is neither forwarded
to any ports (including the CPU) nor is it learned.
Each port policer, however, has the option to run in flow control where the policer instructs the MAC to
issue flow control pause frames instead of discarding frames. This is enabled in
VMDS-10490 VSC7513 Datasheet Revision 4.2
120
Functional Descriptions
ANA:PORT:POL_FLOWC. Common for all port policers, POL_HYST.POL_FC_HYST specifies a
hysteresis, which controls when the policer can re-open after having closed.
To improve fairness between small and large frames being policed by the same policer,
POL_HYST.POL_DROP_HYST specifies a hysteresis that controls when the policer can re-open after
being closed. By setting it to a value larger than the maximum transmission unit, it guarantees that when
the policer opens again, all frames have the same chance of being accepted. This setting only applies to
policers working in drop mode.
The current fill level of the dual leaky buckets can be read in POL_PIR_STATE and POL_CIR_STATE.
The unit is 0.5 bits.
3.11
Shared Queue System
The device includes a shared queue system with one ingress queue per ingress port and one egress
queue per QoS class per egress port per ingress port. The queue system has 224 kilobytes of buffer.
Frames are linked into the ingress queues after frame analysis. Each egress port module selected by the
frame analysis receives a link to the frame and stores the link in the appropriate egress queue selected
by mapping various frame properties to a queue number. The transfer from ingress to egress is
extremely efficient with a transfer time of 12.8 ns per frame copy (equivalent to a transfer rate from
ingress to egress of about 50 Gbps for 64-byte frames and about 1 terabit per second (Tbps) for
1518-byte frames). Each egress port module has a scheduler that selects between the egress queues
when transmitting frames.
The following illustration shows the shared queue system.
Figure 36 • Queue System Overview
Rx
MAC
Rx
RxMAC
MAC
Frame Analysis
(Find QoS class and
set of destination
ports)
Ingress Queues
(1 per port)
Ingr. Queue 0
Egress Queues
One or multiple copies
or discard
Egress Transmitter
Egress Port Module (1 per port)
Queue 0.0
Ingr. Queue 11
Queue 95.11
Scheduler
Queue 0.1
Queue Map
Ingr. Queue 1
MAC Tx
Resource depletion can prevent one or more of the frame copies from the ingress queue to the egress
queues. If a frame copy cannot be made due to lack of resources, the ingress port’s flow control mode
determines the behavior as follows:
•
•
Ingress port is in drop mode: The frame copy is discarded.
Ingress port is in flow control mode: The frame is held back in the ingress queue and the frame copy
is made when the congestion clears.
For more information about special configurations of the shared queue system with respect to flow
control, see Ingress Pause Request Generation, page 126.
VMDS-10490 VSC7513 Datasheet Revision 4.2
121
Functional Descriptions
3.11.1
Buffer Management
A number of watermarks control how much data can be pending in the egress queues before the
resources are depleted. There are no watermarks for the ingress queues, except for flow control,
because the ingress queues are empty most of the time due to the fast transfer rates from ingress to
egress. For more information, see Ingress Pause Request Generation, page 126. When the watermarks
are configured properly, congested traffic does not influence the forwarding of non-congested traffic.
The memory is split into two main areas:
•
•
A reserved memory area. The reserved memory area is subdivided into areas per port per QoS
class per direction (ingress/egress).
A shared memory area, which is shared by all traffic.
For setting up the reserved areas, egress watermarks exist per port and per QoS class for both ingress
and egress. The following table lists the reservation watermarks.
Table 97 •
Reservation Watermarks
Register
Description
Replication
BUF_Q_RSRV_E Configures the reserved amount of egress buffer per QoS Per QoS class per
class per egress port.
egress port
BUF_P_RSRV_E Configures the reserved amount of egress buffer shared
among the egress port’s allocated egress queues.
Per egress port
BUF_Q_RSRV_I
Configures the reserved amount of egress buffer per
ingress port per QoS class across all egress ports.
Per ingress port per
QoS class
BUF_P_RSRV_I
Configures the reserved amount of egress buffer per
ingress port shared among the eight QoS classes.
Per ingress port
All the watermarks, including the ingress watermarks, are compared against the memory consumptions
in the egress queues. For example, the ingress watermarks in BUF_Q_RSRV_I compare against the
total consumption of frames across all egress queues received on the specific ingress port and classified
to the specific QoS class. The ingress watermarks in BUF_P_RSRV_I compare against the total
consumption of all frames across all egress queues received on the specific ingress port.
The reserved areas are guaranteed minimum areas. A frame cannot be discarded or held back in the
ingress queues if the frame’s reserved areas are not yet used.
The shared memory area is the area left when all the reservations are taken out. The shared memory
area is shared between all ports, however, it is possible to configure a set of watermarks per QoS class
and per drop precedence level (green/yellow) to stop some traffic flows before others. The following table
lists the sharing watermarks.
Table 98 •
Sharing Watermarks
Register
Description
BUF_PRIO_SHR_E
Configures how much of the shared memory area that egress Per QoS class
frames with the given QoS class are allowed to use.
BUF_COL_SHR_E
Configures how much of the shared memory area that egress Per drop
frames with the given drop precedence level are allowed to
precedence
use.
level
BUF_PRIO_SHR_I
Configures how much of the shared memory area that
ingress frames with the given QoS class are allowed to use.
Per QoS class
BUF_COL_SHR_I
Configures how much of the shared memory area that
ingress frames with the given drop precedence level are
allowed to use.
Per drop
precedence
level
VMDS-10490 VSC7513 Datasheet Revision 4.2
Replication
122
Functional Descriptions
The sharing watermarks are maximum areas in the shared memory that a given traffic flow can use.
They do not guarantee anything.
When a frame is enqueued into the egress queue system, the frame first consumes from the queue’s
reserved memory area, then from the port’s reserved memory area. When all the frame’s reserved
memory areas are full, it consumes from the shared memory area.
The following provides some simple examples on how to configure the watermarks and how that
influences the resource management.
•
•
•
•
•
3.11.2
Setting BUF_Q_RSRV_E(egress port = 7, QoS class = 4) to 2 kilobytes guarantees that traffic
destined for port 7 classified to QoS class 4 have room for 2 kilobytes of frame data before frames
can get discarded.
Setting BUF_Q_RSRV_I(ingress port = 7, QoS class = 4) to 2 kilobytes guarantees that traffic
received on port 7 classified to QoS class 4 have room for 2 kilobytes of frame data before frames
can get discarded.
Setting BUF_P_RSRV_I(ingress port 7) to 10 kilobytes guarantees that traffic received on port 7
have room for 10 kilobytes of data before frames can get discarded.
The three reservations above reserve 14 kilobytes of memory in total (2 + 2+ 10 kilobytes) for port 7.
If the same reservations are made for all ports, there are 224 – 11 × 14 = 70 kilobytes left for
sharing. If the sharing watermarks are all set to 70 kilobytes, all traffic groups can consume memory
from the shared memory area without restrictions.
If, instead, setting BUF_PRIO_SHR_E(QoS class = 7) to 70 kilobytes and the other watermarks
BUF_PRIO_SHR_E(QoS class = 0:6) to 20 kilobytes guarantees that traffic classified to QoS
class 7 has 50 kilobytes extra buffer. The buffer is shared between all ports.
The BUF_PRIO_SHR_I, BUF_PRIO_SHR_E, REF_PRIO_SHR_I, and REF_PRIO_SHR_E
watermarks can be used for guaranteeing shared resources for each individual QoS class. This is
done by setting QSYS::RES_QOS_MODE so that the watermarks operate on the current
consumption of each QoS class instead of the total use of the shared resources.
Frame Reference Management
Each frame in an egress queue consumes a frame reference, which is a pointer element that points to
the frame’s data in the memory and to the pointer element belonging to the next frame in the queue. The
following illustrations shows how the frame references are used for creating the queue structure.
Figure 37 • Frame Reference
Frame Reference Pointer
Memory Pointer
Buffer Memory
Egress queue, port 7, QoS class 4
Head
Tail
Frame References
The shared queue system holds a table of 1911 frame references. The consumption of frame references
is controlled through a set of watermarks. The set of watermarks is the exact same as for the buffer
control. The frame reference watermarks are prefixed REF_. Instead of controlling the amount of
consumed memory, they control the number of frame references. Both reservation and sharing
watermarks are available. For more information, see Table 97, page 122 and Table 98, page 122.
VMDS-10490 VSC7513 Datasheet Revision 4.2
123
Functional Descriptions
When a frame is enqueued into the shared queue system, the frame consumes first from the queue’s
reserved frame reference area, then from the port’s reserved frame reference area. When all the frame’s
reserved frame reference areas are full, it consumes from the shared frame reference area.
3.11.3
Resource Depletion Condition
A frame copy is made from an ingress port to an egress port when both a memory check and a frame
reference check succeed. The memory check succeeds when at least one of the following conditions is
met.
•
•
•
Ingress memory is available: BUF_Q_RSRV_I or BUF_P_RSRV_I are not exceeded.
Egress memory is available: BUF_Q_RSRV_E or BUF_P_RSRV_E are not exceeded.
Shared memory is available: None of BUF_PRIO_SHR_E, BUF_COL_SHR_E, BUF_PRIO_SHR_I,
or BUF_COL_SHR_I are exceeded.
The frame reference check succeeds when at least one of the following conditions is met.
•
•
•
3.11.4
Ingress frame references are available: REF_Q_RSRV_I or REF_P_RSRV_I are not exceeded.
Egress frame references are available: REF_Q_RSRV_E or REF_P_RSRV_E are not exceeded.
Shared frame references are available: None of REF_PRIO_SHR_E, REF_COL_SHR_E,
REF_PRIO_SHR_I, or REF_COL_SHR_I are exceeded.
Configuration Example
This section provides an example of how the watermarks can be configured for a QoS-aware switch with
no color handling and the effects of the settings.
Table 99 •
Watermark Configuration Example
Watermark
Value
Comment
BUF_Q_RSRV_I
500 bytes
Guarantees that a port is capable of receiving at least one
frame in all QoS classes.
Note It is not necessary to assign a full MTU, because the
watermarks are checked before the frame is added to the
memory consumption.
BUF_P_RSRV_I
0
No additional guarantees for the ingress port.
BUF_Q_RSRV_E
200 bytes
Guarantees that all QoS classes are capable of sending a
non-congested stream of traffic through the switch.
BUF_P_RSRV_E
10 kilobytes
Guarantees that all egress ports have 10 kilobytes of
buffer, independently of other traffic in the switch. This is
the most demanding reservation in this setup, reserving
110 kilobytes of the total 224 kilobytes.
BUF_COL_SHR_E
BUF_COL_SHR_I
Maximum
Effectively disables frame coloring as watermark is never
reached.
BUF_PRIO_SHR_E 42 kilobytes to
BUF_PRIO_SHR_I 63 kilobytes
The different QoS classes are cut-off with 3 kilobytes
distance (42, 45, 48, 51, 54, 57, 60, and 63 kilobytes). This
gives frames with higher QoS classes a larger part of the
shared buffer area. Effectively, this means that the burst
capacity is 52 kilobytes for frames belonging to QoS
class 0 and up to 73 kilobytes for frame belonging to QoS
class 7.
REF_Q_RSRV_E
REF_Q_RSRV_I
4
For both ingress and egress, this guarantees that four
frames can be pending from and to each port.
REF_P_RSRV_E
REF_P_RSRV_I
20
For both ingress and egress, this guarantees that an extra
20 frames can be pending, shared between all QoS
classes within the port.
VMDS-10490 VSC7513 Datasheet Revision 4.2
124
Functional Descriptions
Table 99 •
Watermark Configuration Example (continued)
Watermark
Value
Comment
REF_COL_SHR_E
REF_COL_SHR_I
Maximum
Effectively disables frame coloring as watermark is never
reached.
REF_PRIO_SHR_E 1350 - 1700
REF_PRIO_SHR_I
3.11.5
The different QoS classes are cut-off with a distance of
50 frame references (1350, 1400, 1450, 1500, 1550, 1600,
1650, and 1700). This gives frames with higher QoS
classes a larger part of the shared reference area.
Watermark Programming and Consumption Monitoring
The watermarks previously described are all found in the SYS::RES_CFG register. The register is
replicated 1024 times. The following illustration the organization.
Figure 38 • Watermark Layout
0
8
0
Port and QoS class
reservation
watermarks
(xxx = Q_RSRV)
0
BUF_xxx_I
256
REF_xxx_I
216
512
BUF_xxx_E
768
224
REF_xxx_E
QoS class sharing
watermarks
(xxx = PRIO_SHR)
Port reservation
watermarks
(xxx = P_RSRV)
QoS
QoS
QoS
QoS
QoS
QoS
QoS
QoS
Port 0
Port 1
Port 2
...
88
class
class
class
class
class
class
class
class
0
1
2
3
4
5
6
7
Port 10
Port 11
QoS
QoS
QoS
QoS
QoS
QoS
QoS
QoS
class
class
class
class
class
class
class
class
0
1
2
3
4
5
6
7
Port 0
Port 1
Port 2
...
254
Color Sharing
watermarks
(xxx = COL_SHR)
Port 10
Port 11
DP 1 (yellow)
DP 0 (green)
The illustration shows the watermarks available for the BUF_xxx_I group of watermarks. For the other
groups of watermarks (BUF_xxx_I, REF_xxx_I, BUF_xxx_E, and REF_xxx_E), the exact same set of
watermarks are available.
For monitoring the consumption of resources, SYS::RES_STAT provides information about current use
and the maximum use since the last read of the register. The information is available for each of the
watermarks listed and the layout of the RES_STAT register follows the layout of the watermarks.
SYS::MMGT.FREECNT holds the amount of free memory in the shared queue system and
SYS::EQ_CTRL.FP_FREE_CNT holds the number of free frame references in the shared queue system.
VMDS-10490 VSC7513 Datasheet Revision 4.2
125
Functional Descriptions
3.11.6
Advanced Resource Management
A number of additional handles into the resource management system are available for special use of
the device. They are described in the following table.
Table 100 • Resource Management
Resource Management
Description
Forced drop of egress and QSYS::EGR_DROP_MODE
ingress frames
QSYS::SWITCH_PORT_MODE.INGRESS_DROP_MODE.
If either an ingress port or an egress port in a frame transfer are configured for drop
mode, congestion results in frame discards. Otherwise frames are held back in the
ingress queues with potential head-of-line blocking effects.
Normally all egress ports are set to non-drop-mode while the ingress drop mode
reflects whether or not the port is configured for flow control.
Prevent ingress port from
using of the shared
resources.
QSYS::IGR_NO_SHARING.
For frames received on ports set in this mask, the shared watermarks are
considered exceeded. This prevents the port from using more resources than
allowed by the reservation watermarks.
Prevent egress port from
using of the shared
resources.
QSYS::EGR_NO_SHARING.
For frames switched to ports set in this mask the shared watermarks are considered
exceeded. This prevents the port from using more resources than allowed by the
reservation watermarks.
Weighted Random Early
Detection (WRED)
QSYS::RED_PROFILE.
It is possible to discard frames with increasing probability as the consumption of
shared resources per QoS class per drop precedence level increases.
QSYS::RED_PROFILE configures a low and a high watermark per QoS class per
drop precedence level. The probability of discarding a frame increases linearly from
0% when the consumption is at the low watermark to 100% when the consumption
exceeds the high watermark.
Prevent dequeuing
QSYS::PORT_MODE.DEQUEUE_DIS.
Each egress port can disable dequeuing of frames from the egress queues.
3.11.7
Ingress Pause Request Generation
During resource depletion, the shared queue system either discards frames when the ingress port
operates in drop mode, or holds back frames when the ingress port operates in flow control mode. The
following describes special configuration for the flow control mode.
The shared queue system is enabled for holding back frames during resource depletion in
SYS:PORT:PAUSE_CFG.PAUSE_ENA. In addition, this enables the generation of pause requests to the
port module based on memory consumptions. The MAC uses the pause request to generate pause
frames or create back pressure collisions to halt the link partner. This is done according to the MAC
configuration. For more information about MAC configuration, see MAC, page 18.
The shared queue system generates the pause request based on the ingress port’s memory
consumption and also based on the total memory consumption in the shared queue system. This
enables a larger burst capacity for a port operating in flow control while not jeopardizing the non-dropping
flow control.
Generating the pause request partially depends on a memory consumption flag, TOT_PAUSE, which is
set and cleared under the following conditions:
•
•
The TOT_PAUSE flag is set when the total consumed memory in the shared queue system exceeds
the SYS:PORT:PAUSE_TOT_CFG.PAUSE_TOT_START watermark.
The TOT_PAUSE flag is cleared when the total consumed memory in the shared queue system is
below the SYS:PORT:PAUSE_TOT_CFG.PAUSE_TOT_STOP watermark.
The pause request is asserted when both of the following conditions are met.
VMDS-10490 VSC7513 Datasheet Revision 4.2
126
Functional Descriptions
•
•
The TOT_PAUSE flag is set.
The ingress port memory consumption exceeds the SYS:PORT:PAUSE_CFG.PAUSE_START
watermark.
The pause request is deasserted the following condition is met:
•
3.11.8
The ingress port’s consumption is below the SYS:PORT:PAUSE_CFG.PAUSE_STOP watermark.
Tail Dropping
The shared queue system implements a tail dropping mechanism where incoming frames are discarded
if the port’s memory consumption and the total memory consumption exceed certain watermarks. Tail
dropping implies that the frame is discarded unconditionally. All ports in the device are subject to tail
dropping. It is independent of whether the port is in flow control mode or in drop mode.
Tail dropping can be effective under special conditions. For example, tail dropping can prevent an ingress
port from consuming all the shared memory when pause frames are lost or when the link partner is not
responding to pause frames.
The shared queue system initiates tail dropping by discarding the incoming frame if the following two
conditions are met at any point while writing the frame data to the memory.
•
•
3.11.9
If the Ingress port memory consumption exceeds the SYS:PORT:ATOP_CFG.ATOP watermark
If the total consumed memory in the shared queue system exceeds the
SYS:PORT:ATOP_TOT_CFG.ATOP_TOT watermark
Test Utilities
This section describes some of test utilities that are built into the shared queue system.
Each egress port can enable a frame repeater (SYS::REPEATER), which means that the head-of-line
frames in the egress queues are transmitted but not dequeued after transmission. As a result, the
scheduler sees the same frames again and again while the repeater function is active.
The SYS:PORT:PORT_MODE.DEQUEUE_DIS disables both transmission and dequeuing from the
egress queues when set.
3.11.10 Energy Efficient Ethernet
This section provides information about the functions of Energy Efficient Ethernet in the shared queue
system. The following table lists the registers associated with Energy Efficient Ethernet.
Table 101 • Energy Efficient Ethernet Control Registers
Register
Description
Replication
DEV::EEE_CFG
Enables configuration of Energy Efficient Ethernet. Status Per port
bit indicating that egress port is in the LPI state.
QSYS::EEE_CFG
Configures fast queues.
Per port
QSYS::EEE_THRES
Configures bytes and frame thresholds.
None
The shared queue system supports Energy Efficient Ethernet (EEE) as defined by IEEE Draft P802.3az
by initiating the Low Power Idle (LPI) mode during periods of low link use. EEE is controlled per port by
an egress queue state machine that monitors the queue fillings and ensures correct wake-up and sleep
timing. The egress queue state machine is responsible for informing the PCS in the port module of
changes in EEE states (active, sleep, low power idle, and wake up).
VMDS-10490 VSC7513 Datasheet Revision 4.2
127
Functional Descriptions
Figure 39 • Low Power Idle Operation
Active
Low-Power Idle
Active
TQ
Quiet
Wake
TS
Refresh
Refresh
Sleep
Active
Quiet
Active
Quiet
TR
Energy Efficient Ethernet is enabled per port through DEV::EEE_CFG.EEE_ENA.
By default, the egress port is transmitting enqueued data. This is the active state. If none of the port’s
egress queues have enqueued data for the time specified in DEV::EEE_CFG.EEE_TIMER_HOLDOFF,
the egress port instructs the PCS to enter the EEE sleep state.
When data is enqueued in any of the port’s egress queues, a timer (DEV::EEE_CFG.EEE_TIMER_AGE)
is started. If one of the following conditions is met, the port enters the wake up state.
•
•
•
•
A queue specified as high priority (QSYS:PORT:EEE_CFG.EEE_FAST_QUEUES) has any data to
transmit.
The total number of frames in the port’s egress queues exceeds
QSYS::EEE_THRES.EEE_HIGH_FRAMES.
The total number of bytes in the port’s egress queues exceeds
QSYS::EEE_THRES.EEE_HIGH_FRAMES.
The time specified in DEV::EEE_CFG.EEE_TIMER_AGE has passed. PCS is instructed to wake up.
To ensure that PCS, PHY, and link partner are resynchronized after waking up; the egress port holds
back transmission of data until the time specified in DEV::EEE_CFG.EEE_TIMER_WAKEUP has
passed. After this time interval, the port resumes transmission of data.
The status bit DEV::EEE_CFG.PORT_LPI is set while the egress port holds back data due to LPI (from
the sleep state to the wake up state, both included).
3.12
Scheduler and Shapers
The following table lists the registers associated with the scheduler and egress shaper control.
Table 102 • Scheduler and Egress Shaper Control Registers
Register
Description
Replication
QSYS::SHAPER_CFG
Configuration of egress shaper’s rate and burst.
158
QSYS::SE_CFG
Configuration of the scheduling algorithm.
158
QSYS::SE_DWRR_CFG
Configuration of DWRR scheduler’s costs.
158
QSYS::SHAPER_STATE
Status of the shaper bucket.
158
Each egress port contains a two-level priority-fair egress scheduler. The first scheduler level towards the
egress port schedules between QoS classes while the second scheduler level towards the egress
queues schedules between the ingress ports.
An egress scheduler is constructed using 9 scheduler elements. Each scheduler elements has 12 inputs
and 1 output. It contains a scheduler, which can be strict or mixed with a round robin based scheduling
algorithm. The round robin based scheduling algorithm can either be frame-based round robin or bytebased deficit weighted round robin. The output port of a scheduler elements contains a dual leaky bucket
shaper.
The following illustration provides an overview of the egress scheduling system for egress port 0.
VMDS-10490 VSC7513 Datasheet Revision 4.2
128
Functional Descriptions
Figure 40 • Egress Scheduler Port 0
SE #7
Q95
Q94
Q93
Q84
Port11 QoS class 7
Port10 QoS class 7
Port9 QoS class 7
R
R
S
High
Port0 QoS class 7
SE #146
S
T
R
I
C
T
S
SE #0
Q11
Q10
Q9
Q0
Low
Port11 QoS class 0
Port10 QoS class 0
Port9 QoS class 0
R
R
S
Port0 QoS class 0
QoS Class
Level 1
Port
Level 2
Each egress port features a similar egress scheduler. The following table lists which scheduler elements
are used by the different ports.
Table 103 • Scheduler Elements Numbering
Egress Port
Scheduler Elements - Level 1
Scheduler Elements - Level 2
0
146
0 through 7
1
147
8 through 15
2
148
16 through 23
3
149
24 through 31
4
150
32 through 39
5
151
40 through 47
6
152
48 through 55
7
153
56 through 63
8
154
64 through 71
9
155
72 through 79
VMDS-10490 VSC7513 Datasheet Revision 4.2
129
Functional Descriptions
Table 103 • Scheduler Elements Numbering (continued)
3.12.1
Egress Port
Scheduler Elements - Level 1
Scheduler Elements - Level 2
10
156
80 through 87
11 (CPU)
157
88 through 95
Scheduler Element
The following illustration shows the scheduler element.
Figure 41 • Scheduler Element
11
Scheduler
N-Strict
Byte-based
DWRR
Inputs
S
Output
Shaper
Frame-based
RR
0
By default, the scheduler operates in strict priority between all 12 inputs. The inputs are searched in the
following prioritized order: Input 11 has highest priority followed by 10, 9, 8, 7, 6, 5, 4, 3, 2, 1, and 0.
In addition, the scheduler can operate either in a byte-based deficit weighted round robin (DWRR) mode
or a frame-based round robin (RR) mode. This is an overall configuration for the scheduler element and
cannot be selected per input. In DWRR mode, the participating inputs are given a weight and the
scheduler selects frames from these inputs according to the weights. The DWRR is byte-based and
takes the lengths of the frames into account. In RR mode, the participating inputs are selected one after
another. The RR is frame-based and does not take the length of the frames into account.
The scheduler supports a mixed mode where some inputs operate in strict priority and others operate in
either DWRR or RR. Any number of inputs can be assigned to either group but strict priority inputs must
always be selected from highest numbered inputs.
Each scheduler element has an associated leaky-bucket shaper at the output. The shaper limits the
overall transmission bandwidth from the scheduler element. Frames are only scheduled if the shaper is
open.
Each scheduling element determines whether it has a frame ready for scheduling based on status
information of the scheduling element’s inputs. For each input, the scheduling element knows if the input
has a frame ready for transmission and if the frame is ready due to a work conservation mode. The
overall scheduling algorithm within a scheduling element is as follows:
1.
2.
3.
If the output shaper is closed, frames are only scheduled from the element if the element is enabled
for work conservation. Otherwise, frames are held back until the shaper opens.
If the output shaper is open or in work conservation mode, the scheduling element schedules
between inputs that are not work conserving by following the rules for the scheduler configuration:
strict inputs are scheduled first then round robin based inputs are scheduled according to either the
DWRR algorithm or the RR algorithm.
If no frames are scheduled during step 2, a second round of scheduling is performed. Inputs that are
work conserving become candidates for the second round of scheduling.
The hierarchy of scheduling elements is traversed from the element connected to the egress port through
to the element that connects to an egress queue by recursively deciding which input should be
scheduled.
VMDS-10490 VSC7513 Datasheet Revision 4.2
130
Functional Descriptions
3.12.2
Egress Shapers
Each of the scheduling elements contain an output shaper with the following configurations:
•
•
Maximum rate – Specified in SHAPER_CFG.RATE in steps of 100160 bps. Maximum is 3.282 Gbps.
Maximum burst size – Specified in SHAPER_CFG.BURST in steps of 4 kilobytes. Maximum is
252 kilobytes.
The shaper can operate byte-based or frame-based (SE_CFG.SE_FRM_MODE). When operating as
byte-based, the frame adjustment value HSCH_MISC.FRM_ADJ can be used to program the fixed
number of extra bytes to add to each frame transmitted (irrespective of QoS class) in the shaper and
DWRR calculations. A value of 20 bytes corresponds to line-rate calculation and accommodates for 12
bytes of inter-frame gap and 8 bytes of preamble. Data-rate based shaping and DWRR calculations are
achieved by programming 0 bytes.
Each shaper implements two burst modes. By default, a leaky bucket is continuously assigned new
credit according to the configured shaper rate. This implies that during idle periods, credit is building up,
which allows for a burst of data when there are again data to transmit. This is not convenient in an
Audio/Video Bridging (AVB) environment where this behavior enforces a requirement for larger buffers in
end-equipment. To circumvent this, each shaper can enable an AVB mode (SE_CFG.SE_AVB_ENA) in
which credit is only assigned during periods where the scheduler element has data to transmit and is
waiting for another scheduler element to finish a transmission. This AVB mode prevents the
accumulation of large amount of credits.
3.12.3
Deficit Weighted Round Robin
The DWRR uses a cost-based algorithm compared to a weight-based algorithm. A high cost implies a
small share of the bandwidth. DWRR is enabled when SE_CFG.SE_DWRR_CFG>0 and
SE_CFG.RR_ENA = 0. The participating inputs are then inputs 0 through SE_CFG.SE_DWRR_CFG-1.
Anything from 0 to 12 weighted inputs can participate.
Each input is programmed with a cost (SE_DWRR_CFG.DWRR_COST). A cost is a number between 1
and 32. The programmable DWRR costs determine the behavior of the DWRR algorithm. The costs
result in weights for each input to the scheduler element. The weights are relative to one another, and the
resulting share of the egress bandwidth for a particular input is equal to the input’s weight divided by the
sum of all the inputs’ weights. The algorithm is byte-based and takes the frame lengths into account.
Costs are easily converted to weights and vice versa given the following two algorithms. The following
algorithms are shown with six participating inputs but can be applied to other configurations as well.
Weights to Costs Given a desired set of weights (W0, W1, W2, W3, W4, W5), the costs can be
calculated using the following algorithm.
1.
2.
Set the cost of the queue with the smallest weight (Wsmallest) to cost 32.
For any other queue Qn with weight Wn, set the corresponding cost Cn to
Cn = 32 × Wsmallest/Wn
Costs to Weights: Given a set of costs for all queues (C0, C1, C2, C3, C4, C5), the resulting weights
can be calculated using the following algorithm:
1.
2.
Set the weight of the queue with the highest cost (Chighest) to 1.
For any other queue Qn with cost Cn, set the corresponding weight Wn to Wn = Chighest/Cn
Cost and Weight Conversion Examples
Implement the following bandwidth distributions.
•
•
•
•
•
•
Input 0: 5% (W0 = 5)
Input 1: 10% (W1 = 10)
Input 2: 15% (W2 = 15)
Input 3: 20% (W3 = 20)
Input 4: 20% (W4 = 20)
Input 5: 30% (W5 = 30)
Given the algorithm to get from weights to costs, the following costs are calculated:
•
C0 = 32 (Smallest weight)
VMDS-10490 VSC7513 Datasheet Revision 4.2
131
Functional Descriptions
•
•
•
•
•
C1 = 32∗5/10 = 16
C2 = 32*5/15 = 10.67 (rounded up to 11)
C3 = 32*5/20 = 8
C4 = 32*5/20 = 8
C5 = 32*5/30 = 5.33 (rounded down to 5)
Due to the rounding off, these costs result in the following bandwidth distribution, which is slightly off
compared to the desired distribution:
•
•
•
•
•
•
3.12.4
Input 0: 4.92%
Input 1: 9.85%
Input 2: 14.32%
Input 3: 19.70%
Input 4: 19.70%
Input 5: 31.51%
Round Robin
The round robin (RR) uses a simple round robin algorithm where each participating input is served one
after another. RR is enabled when SE_CFG.SE_DWRR_CFG>0 and SE_CFG.RR_ENA = 1. The
participating inputs are then inputs 0 through SE_CFG.SE_DWRR_CFG-1. Anything from 0 to 12
weighted inputs can participate.
The RR algorithm is frame-based and does not take the frame lengths into account.
3.12.5
Shaping and DWRR Scheduling Examples
This section provides examples and additional information about the use of the egress shapers and
scheduler. The following assumes a scheduler element is connected to the egress queues.
3.12.5.1
Mixing DWRR and Shaping Example
•
•
•
•
•
•
Output from scheduler element is shaped down to 500 Mbps.
Queues 7 and 6 are strict and queues 5 through 0 are weighted.
Queue 7 is shaped to 100 Mbps.
Queue 6 is shaped to 50 Mbps.
The following traffic distribution is desired for queue 5 through 0:
Q0: 5%, Q1: 10%, Q2: 15%, Q3: 20%, Q4: 20%, Q5: 30%.
Each queue receives 125 Mbps of incoming traffic.
The following table lists the DWRR configuration and the resulting egress bandwidth for the various
queues.
Table 104 • Example of Mixing DWRR and Shaping
Queue
Distribution
of Weighted
Traffic
Configuration
Costs/Weights
(Cn/Wn)
Result: Egress Bandwidth
Q0
5%
32 / 1
1/(1+2+2.9+4+4+6.4) × (500 – Mbps – 150 Mbps) = 17.2 Mbps
Q1
10%
16 / 2
2/(1+2+2.9+4+4+6.4) × (500 – Mbps – 150 Mbps) = 34.5 Mbps
Q2
15%
11 / 2.9
2.9/(1+2+2.9+4+4+6.4) × (500 – Mbps – 50 Mbps) = 50.1 Mbps
Q3
20%
8/4
4/(1+2+2.9+4+4+6.4) × (500 – Mbps – 150 Mbps) = 68.9 Mbps
Q4
20%
8/4
4/(1+2+2.9+4+4+6.4) × (500 – Mbps – 150 Mbps) = 68.9 Mbps
Q5
30%
5 / 6.4
6.4/(1+2+2.9+4+4+6.4) × (500 – Mbps – 150 Mbps) = 110.3 Mbps
Q6
50 = Mbps
Q7
100 = Mbps
Sum:
100%
500 = Mbps
VMDS-10490 VSC7513 Datasheet Revision 4.2
132
Functional Descriptions
3.12.5.2
Strict and Work-Conserving Shaping Example
•
•
•
•
•
Output from scheduler element is shaped down to 500 Mbps.
All queues are strict.
All queues are shaped to 50 Mbps.
Queues 6 and 7 are work-conserving (allowed to use excess bandwidth).
All queues receive 125 Mbps of traffic each.
The following table lists the resulting egress bandwidth for the various queues.
Table 105 • Example of Strict and Work-Conserving Shaping
3.13
Queue
Result: Egress Bandwidth
Q0
50 Mbps
Q1
50 Mbps
Q2
50 Mbps
Q3
50 Mbps
Q4
50 Mbps
Q5
50 Mbps
Q6
75 Mbps (Gets the last 25 Mbps of the 100 Mbps in excess not used by queue 7)
Q7
125 Mbps (Gets 75 Mbps of the 100 Mbps in excess limited only by the received rate)
Sum:
500 Mbps
Rewriter
The device includes a rewriter common for all ports that determines how the egress frame is edited
before transmission. The rewriter performs the following editing:
•
•
•
•
VLAN editing; tagging of frames and remapping of PCP and DEI.
DSCP remarking; rewriting the DSCP value in IPv4 and IPv6 frames based on classified DSCP
value.
FCS updating.
Precision Time Protocol time stamp updating.
Each port module including the CPU port module (CPU port 11 and CPU port 12) has its own set of
configuration in the rewriter. Each frame is handled by the rewriter one time per destination port.
Most rewriting functions in the rewriter are independent of each other and can co-exist. For instance, a
frame can be VLAN tagged while at the same time being DSCP remarked. However, precision time
protocol time stamp updating and DSCP remarking are mutually exclusive with the former taking
precedence. If an IS2 action returns any PTP actions then DSCP remarking is automatically disabled for
the frame.
3.13.1
VLAN Editing
The following table lists the registers associated with VLAN editing.
Table 106 • VLAN Editing Registers
Register
Description
Replication
PORT_VLAN_CFG
Port VLAN for egress port. Used for untagged set
Per port
TAG_CFG
Tagging rules for port tag
Per port
PORT_CFG.ESO_ENA
Enable lookups in ES0
Per port
PCP_DEI_QOS_MAP_CFG
Mapping table
Maps DP level and QoS class to new PCP and DEI values
Per port per
QoS per DP
VMDS-10490 VSC7513 Datasheet Revision 4.2
133
Functional Descriptions
The rewriter performs five steps related to VLAN editing for each frame and destination:
1.
2.
3.
4.
5.
3.13.1.1
VLAN popping - Zero, one, or two VLAN tags are popped from the frame.
ES0 lookup - ES0 is looked up for each of the frame’s destination ports. The action from ES0
controls the pushing of VLAN tags.
VLAN push decision - Deciding the number of new tags to push and which tag source to use for
each tag. Tag sources are: Port and ES0 (tag A and tag B).
Constructing the VLAN tags - The new VLAN tags are constructed based on the tag sources’
configuration.
VLAN pushing - the new VLAN tags are pushed.
VLAN Popping
The rewriter initially pops the number of VLAN tags specified by the VLAN_POP_CNT parameter
received with the frame from the classifier or VCAP IS1. Up to two VLAN tags can be popped. The
rewriter itself does not influence the number VLAN tags being popped.
3.13.1.2
ES0 Lookup
For each of the frame’s destination ports, VCAP ES0 is looked up using the ES0 key. See VCAP ES0,
page 92 for more information about ES0. The action from an ES0 hit is used in the following to determine
the frame’s VLAN editing.
3.13.1.3
VLAN Push Decision
After popping the VLAN tags, the rewriter decides whether to push zero, one, or two new VLAN tags to
the outgoing frame according to the port’s tagging configuration in register TAG_CFG and the action from
a potential VCAP ES0 hit. The up to two tags can originate from either the port (port tag) or ES0 (ES0 tag
A and ES0 tag B).
By default, the port can push one tag according to the port’s configuration in TAG_CFG. If the ES0 lookup
results in an entry being hit, the ES0 action can overrule the port configuration and push two tags by itself
(ES0 tag A and ES0 tag B) or it can combine port tagging and ES0 tagging.
The following illustration shows an overview of the available tagging options.
Figure 42 • Tagging Overview
DMAC
SMAC
Outer tag
Inner tag
EtherType
Payload
Optional port tag(1)
ES0 tag A
No tag
Force port tag
No tag
ES0 tag B
(1) Port tag is controlled by REW:PORT:TAG_CFG.TAG_CFG.
VMDS-10490 VSC7513 Datasheet Revision 4.2
134
Functional Descriptions
The following table lists all combinations of port tagging configuration and ES0 actions that control the
number of tags to push and which tag source to use (port, ES0 tag A, or ES0 tag B):
Table 107 • Tagging Combinations
ES0_ACTION
TAG_CFG
Tagging action
No ES0 hit
Controls
port tag
Port tag is pushed according to TAG_CFG as outer tag.
Available options are:
Tag all frames with port tag.
Tag all frames with port tag, except if classified VID=0
or classified VID=PORT_VLAN.PORT_VID.
Tag all frames with port tag, except if classified VID=0
No port tag
No inner tag.
PUSH_OUTER_TAG=0 Controls
PUSH_INNER_TAG=0 port tag
Port tag is pushed according to TAG_CFG as outer tag.
Available options are:
Tag all frames with port tag.
Tag all frames with port tag, except if classified VID=0
or classified VID=PORT_VLAN.PORT_VID.
Tag all frames with port tag, except if classified VID=0
No port tag
No inner tag.
PUSH_OUTER_TAG=1 Don’t care
PUSH_INNER_TAG=0
ES0 tag A is pushed as outer tag.
No inner tag.
PUSH_OUTER_TAG=2 Don’t care
PUSH_INNER_TAG=0
Port tag is pushed as outer tag. This overrules port settings
in TAG_CFG.
No inner tag.
PUSH_OUTER_TAG=3 Don’t care
PUSH_INNER_TAG=0
No tags are pushed. This overrules port settings in
TAG_CFG.
PUSH_OUTER_TAG=0 Controls
PUSH_INNER_TAG=1 port tag
Port tag is pushed according to TAG_CFG as outer tag.
The following options are available:
Tag all frames with port tag.
Tag all frames with port tag, except if classified VID=0
or classified VID=PORT_VLAN.PORT_VID.
Tag all frames with port tag, except if classified VID=0
No port tag
ES0 tag B is pushed as inner tag.
ES0 tag B is effectively the outer tag if the port tag is not
pushed.
PUSH_OUTER_TAG=1 Don’t care
PUSH_INNER_TAG=1
ES0 tag A is pushed as outer tag.
ES0 tag B is pushed as inner tag.
PUSH_OUTER_TAG=2 Don’t care
PUSH_INNER_TAG=1
Port tag is pushed as outer tag. This overrules port settings
in TAG_CFG.
ES0 tag B is pushed as inner tag.
PUSH_OUTER_TAG=3 Don’t care
PUSH_INNER_TAG=1
No outer tag is pushed. This overrules port settings in
TAG_CFG.
ES0 tag B is pushed as inner tag.
ES0 tag B is effectively the outer tag, because no outer tag
is pushed.
3.13.1.4
Constructing VLAN Tags
When pushing a VLAN tag, the contents of the tag header, including the TPID, are highly programmable.
The starting point is the classified tag header coming from the analyzer containing the PCP, DEI, VID and
VMDS-10490 VSC7513 Datasheet Revision 4.2
135
Functional Descriptions
tag type. For each of the fields in the resulting tag, it is programmable how the value is determined. For
more information, see .
Figure 43 • Tag Construction (port tag, ES0 tag A, ES0 tag B)
TPID
PCP
D
E
I
VID
0x8100
Classified
Classified + fixed(*1)
0x88A8
Fixed
Fixed
Custom
Mapped (DP, QoS)
Classified(*2)
QoS class
Classified
Fixed
Mapped (DP, QoS)
DP level
(*1) For port tag, this is classified only.
(*2) Use 0x8100 if classified tag type is 0x8100, otherwise custom.
The port tag, ES0 tag A, and ES0 tag B have individual configurations. For the port tag, the available tag
field options are:
Port tag: PCP
•
•
•
•
Use the classified PCP.
Use the egress port’s port VLAN (PORT_VLAN.PORT_PCP).
Map the DP level and QoS class to a new PCP value using the per-port table
PCP_DEI_QOS_MAP_CFG.
Use the QoS class directly.
Port tag: DEI
•
•
•
•
Use the classified DEI.
Use the egress port’s port VLAN (PORT_VLAN.PORT_DEI).
Map the DP level and QoS class to a new DEI value using the per-port table
PCP_DEI_QOS_MAP_CFG.
Use the DP level directly.
Port tag: VID
•
•
Use the classified VID.
Use the egress port’s port VLAN (PORT_VLAN.PORT_VID).
Port tag: TPID
•
•
•
•
Use Ethernet type 0x8100 (C-tag).
Use Ethernet type 0x88A8 (S-tag).
Use custom Ethernet type programmed in PORT_VLAN.PORT_TPID.
Use custom Ethernet type programmed in PORT_VLAN.PORT_TPID unless the incoming tag was a
C-tag in which case Ethernet type 0x8100 is used.
Similar options for the ES0 tag A and ES0 tag B are available:
ES0 tag: PCP
•
•
•
•
Use the classified PCP.
Use ES0_ACTION.PCP_A_VAL for ES0 tag A and use ES0_ACTION.PCP_B_VAL for ES0 tag B.
Map the DP level and QoS class to a new PCP using the per-port table PCP_DEI_QOS_MAP_CFG.
Use the QoS class directly.
ES0 tag: DEI
•
•
•
•
Use the classified DEI.
Use ES0_ACTION.DEI_A_VAL for ES0 tag A and use ES0_ACTION.DEI_B_VAL for ES0 tag B.
Map the DP level and QoS class to a new DEI using the per-port table PCP_DEI_QOS_MAP_CFG.
Use the DP level directly.
VMDS-10490 VSC7513 Datasheet Revision 4.2
136
Functional Descriptions
ES0 tag: VID
•
•
Use the classified VID incremented with ES0_ACTION.VID_A_VAL for ES0 tag A and use the
classified VID incremented with ES0_ACTION.VID_B_VAL for ES0 tag B.
Use ES0_ACTION.VID_A_VAL for ES0 tag A and use ES0_ACTION.VID_B_VAL for ES0 tag B.
ES0 tag: TPID
•
•
•
•
3.13.1.5
Use Ethernet type 0x8100 (C-tag).
Use Ethernet type 0x88A8 (S-tag).
Use custom Ethernet type programmed in PORT_VLAN.PORT_TPID.
Use custom Ethernet type programmed in PORT_VLAN.PORT_TPID unless the incoming tag was a
C-tag in which case Ethernet type 0x8100 is used.
VLAN Pushing
In the final VLAN editing step, the VLAN tags derived from the previous steps are pushed to the frame.
3.13.2
DSCP Remarking
The following table lists the registers associated with DSCP remarking.
Table 108 • DSCP Remarking Registers
Register
Description
Replication
DSCP_CFG
Selects how the DSCP remarking is done
Per port
DSCP_REMAP_CFG
Mapping table from DSCP to DSCP for DP level = 0.
None
DSCP_REMAP_DP1_CFG Mapping table from DSCP to DSCP for DP level = 1.
None
The rewriter can remark the DSCP value in IPv4 and IPv6 frames, that is, write a new DSCP value to the
DSCP field in the frame.
If a port is enabled for DSCP remarking (DSCP_CFG.DSCP_REWR_CFG), the new DSCP value is
derived by using the classified DSCP value from the analyzer (the basic classification or the VCAP IS1)
in the ingress port. This DSCP value can be mapped before replacing the existing value in the frame.
The following options are available:
•
•
•
•
No DSCP remarking - Leave the DSCP value in the frame untouched.
Update the DSCP value in the frame with the value received from the analyzer
Update the DSCP value in the frame with the value received from the analyzer remapped through
DSCP_REMAP_CFG. This is done independently of the value of the drop precedence level.
Update the DSCP value in the frame with the value received from the analyzer remapped through
DSCP_REMAP_CFG or DSCP_REMAP_DP1_CFG dependent on the drop precedence level. This
enables one mapping for green frames and another for yellow frames so that the resulting DSCP
value can reflect the color of the frame.
In addition, the IP checksum is updated for IPv4 frames. Note that the IPv6 header does not contain a
checksum. As a result, checksum updating does not apply for IPv6 frames.
DSCP remarking is not possible for frames where PTP time stamps are also generated and is
automatically disabled.
3.13.3
FCS Updating
The following table lists the registers associated with FCS updating.
Table 109 • FCS Updating Registers
Register
Description
Replication
PORT_CFG.FCS_UPDATE_NONCPU_CFG
FCS update configuration for non-CPU
injected frames.
Per port
VMDS-10490 VSC7513 Datasheet Revision 4.2
137
Functional Descriptions
Table 109 • FCS Updating Registers (continued)
Register
Description
Replication
PORT_CFG.FCS_UPDATE_CPU_ENA
FCS update configuration for CPU
injected frames.
Per port
The rewriter updates a frame’s FCS when required or instructed to do so. Different handling is available
for frames injected by the CPU and for all other frames.
For non-CPU injected frames, the following update options are available:
•
•
•
Never update the FCS.
Conditional update: Update the FCS if the frame was modified due to PTP time stamping, VLAN
tagging, or DSCP remarking.
Always update the FCS.
In addition, the rewriter can update the FCS for all frames injected from the CPU through the CPU
injection queues in the CPU port module:
•
•
3.13.4
Never update the FCS.
Always update the FCS.
PTP Time Stamping
The following table lists the registers associated with PTP time stamping.
Table 110 • PTP Time Stamping Registers
Register
Description
Replication
REW:PORT:PTP_CFG
PTP Configuration of egress port
Per port
REW:PORT:PTP_DLY1_CFG
Egress delay configuration
Per port
The rewriter can do various different PTP time stamping in the egress frame:
Residence time. Adds the frame’s residence time through the switch to the PTP correction field (byteoffset 8).
Add/subtract. Adds the frame’s Tx time to the correction field (byte-offset 8) or subtract the frame’s Rx
time from the correction field.
Time-of-day. Samples and writes the 80-bit time-of-day into the PTP origin time stamp (byte-offset 34).
Set reserved bytes. Writes the RxTime into the PTP reserved bytes (byte-offset 16).
Clear reserved bytes. Writes zero into the PTP reserved bytes (byte-offset 16).
This can be done for PTP frames over IEEE802.3/Ethernet, PTP frames over UDP over IPv4, and PTP
frames over UDP over IPv6. In addition, frames can be VLAN tagged. The rewriter automatically finds the
correct location of the PTP header in the frame.
The rewriter takes the following frame properties from the analyzer as input.
•
•
•
•
IS2 rewriter action (IS2_ACTION.REW_OP[2:0]), which can be either one-step, two-step, or origin.
The frame’s Rx time stamp, adjusted for I/O path delays and ingress delays according to ingress
actions.
IS2 rewriter actions for one-step PTP: Add/subtract mode, egress delay adjustment.
Ingress backplane mode ANA:PORT:PTP_CFG.PTP_BACKPLANE_MODE from the frame’s
ingress port.
In addition, the following egress port properties are used.
•
•
Egress port delay (REW:PORT:PTP_DLY1_CFG).
Egress backplane mode (REW:PORT:PTP_CFG.PTP_BACKPLANE_MODE).
VMDS-10490 VSC7513 Datasheet Revision 4.2
138
Functional Descriptions
The following table shows the resulting rewriter actions for the one-step PTP action, depending on the
add/subtract mode and ingress and egress backplane mode settings.
Table 111 • PTP Time Stamping for One-step PTP
PTP Action
(from IS2)
Add/Subtract
Ingress
Backplane
Egress
Backplane
One-step
Disabled
Disabled
Disabled
Residence time: Adds frame’s residence
time to PTP correction field.
Egress port delay is added to correction
field if specified by IS2.
One-step
Disabled
Disabled
Enabled
Sets reserved bytes: Writes frame’s Rx
time stamp into the reserved bytes.
One-step
Disabled
Enabled
Disabled
Residence time: Adds frame’s residence
time to PTP correction field.
Egress port delay is added to correction
field if specified by IS2.
Clear reserved bytes.
One-step
Disabled
Enabled
Enabled
Does not apply.
One-step
Enabled
Disabled
Disabled
Residence time: Adds frame’s residence
time to PTP correction field.
Egress port delay is added to correction
field if specified by IS2.
One-step
Enabled
Disabled
Enabled
Add/subtract: Subtracts frame’s Rx time
stamp from PTP correction field.
One-step
Enabled
Enabled
Disabled
Add/subtract: Adds frame’s Tx time stamp
to PTP correction field.
Egress port delay is added to correction
field if specified by IS2.
Clear reserved bytes.
One-step
Enabled
Enabled
Enabled
Does not apply.
PTP time stamp Rewriter Actions
All actions associated with one-step or origin can be disabled per egress port through
REW:PORT:PTP_CFG.PTP_1STEP_DIS.
The following table shows the resulting rewriter actions for the two-step PTP action, depending on the
ingress and egress backplane mode settings.
Table 112 • PTP Time Stamping for Two-step PTP
PTP action
(from IS2)
Ingress
Backplane
Egress
Backplane
PTP time stamp Rewriter Actions
Two-step
Disabled
Disabled
Saves Tx time stamp in PTP time stamp queue.
Two-step
Disabled
Enabled
Sets reserved bytes: Write the frame’s Rx time stamp
into the reserved bytes.
Two-step
Enabled
Disabled
Saves Tx time stamp in PTP time stamp queue.
Clear reserved bytes.
Two-step
Enabled
Enabled
Does not apply.
All actions associated with two-step can be disabled per egress port through
REW:PORT:PTP_CFG.PTP_2STEP_DIS.
VMDS-10490 VSC7513 Datasheet Revision 4.2
139
Functional Descriptions
The following table shows the resulting rewriter actions for the origin PTP action, depending on the
ingress and egress backplane mode settings.
Table 113 • PTP Time Stamping for Origin PTP
PTP Action
(from IS2)
Ingress
Backplane
Egress
Backplane
Origin
Disabled
Disabled
Time-of-day: Write the time-of-day into the PTP origin
time stamp field.
Origin
Disabled
Enabled
None.
Origin
Enabled
Disabled
Time-of-day: Write the time-of-day into the PTP origin
time stamp field.
Origin
Enabled
Enabled
Does not apply.
PTP time stamp Rewriter Actions
The following describes each of the PTP time stamping rewriter actions.
Residence Time. The frame’s residence time is calculated as Tx time stamp - Rx time stamp. For
information about how the Rx and Tx time stamps are derived, see Rx and Tx Time Stamps, page 22.
The residence time is adjusted for an optional egress delay (REW:PORT:PTP_DLY1_CFG) enabled
through IS2_ACTION.REW_OP[5] = 1. The resulting residence time is added to the correction field value
in the PTP header. The result is written back into the frame.
Add/subtract. Add the frame’s Tx time to the correction field or subtract the frame’s Rx time from the
correction field. This is used in backplane applications. This mode requires a rollover protection mode to
handle the situation where the nanosecond counter rolls over during the backplane transfer. The rollover
protection mode is configured in SYS::PTP_CFG.PTP_CF_ROLL_MODE and must be the same in both
the ingress and the egress backplane unit.
Time-of-Day. The time-of-day consists of a 48-bit seconds part and a 32-bit nanoseconds part. The
current time-of-day is derived by sampling the time-of-day seconds counter (SYS::PTP_TOD_LSB,
SYS::PTP_TOD_MSB) and the nanoseconds counter (Tx time stamp) at the time of the frame’s
departure from the switch. Note that the time-of-day value is adjusted for I/O path delay. For more
information, see Rx and Tx Time Stamps, page 22.
Set Reserved Bytes. This action write the frame’s Rx time stamp into the reserved bytes of the PTP
header.
Clear Reserved Bytes. This action clears the reserved byte of the PTP header by setting the four bytes
to 0.
In addition, the UDP checksum is handled for IPv4 frames and IPv6 frames after any PTP modifications
by the rewriter. For IPv4, the UDP checksum is cleared while for IPv6, the two bytes immediately
following the PTP header are updated so that the UDP checksum remains correct.
All internal calculations on nanoseconds time stamps are signed and use 48 bits of precision. When
enabling a port for backplane mode, it is possible specify the number of bits to use from the 48-bit
counter. This is specified in SYS::PTP_CFG.PTP_STAMP_WID. This means that the time stamp values
carried in the reserved bytes or in the correction field in the PTP header can be for instance 30 bits
instead of the default 32 bits.
3.13.5
Special Rewriter Operations
VCAP IS2 can trigger a special rewriter operation through IS2_ACTION.REW_OP[3:0] = 8 (rewriter
special), where the frame’s MAC addresses are swapped:
•
•
The original destination MAC address becomes the new source MAC address.
The original source MAC address becomes the new destination MAC address.
Bit 40 is cleared in the new source MAC address to prevent the possibility of transmitting an illegal frame
with a multicast source MAC address.
VMDS-10490 VSC7513 Datasheet Revision 4.2
140
Functional Descriptions
The swapping of MAC addresses is useful when implementing a general hairpinning functionality where
an IS2-identified flow is hardware looped back to the source port while swapping the MAC addresses.
In addition, VCAP IS2 can trigger replacement of the source MAC address by setting
IS2_ACTION.SMAC_REPLACE_ENA = 1. The new source MAC address is configurable per egress port
through SYS::REW_MAC_LOW_CFG and SYS::REW_MAC_HIGH_CFG.
The operations of swapping of MAC addresses and replacing the source MAC address are mutually
exclusive and must not be enabled at the same time.
3.14
CPU Port Module
The CPU port module connects the switch core to the CPU system so that frames can be injected from or
extracted to the CPU. It is also possible to use a regular front port as a CPU port. This is known as a
Node Processor Interface (NPI).
The following illustration shows how the switch core interfaces to the CPU system through the CPU port
module for injection and extraction of frames.
Figure 44 • CPU Injection and Extraction
Register
access
FDMA
Extraction
VRAP
Engine
Switch Core
Device CPU
Injection
Switch Core
Switch port 11
Injection
Group 0
Injection
Group 1
CPU extraction queues
CPU
Port 12
Injection header included?
(SYS::PORT_MODE.INCL_INJ_HDR)
CPU Port Module
CPU
Port 11
Analyzer
Switch port 11, QoS class 0-7
Strict/Round robin/Weighted
(Scheduler Element configuration)
CPU
Port 11
CPU
Port 12
Rewriter
Rewriter
Extraction header included?
(SYS::PORT_MODE.INCL_XTR_HDR)
Switch port 11
Device CPU
Switch Core
CPU Port Module
Queue to port mapping
(QSYS::CPU_GROUP_MAP)
Extraction
Group 0
Extraction
Group 1
Fixed per channel
FDMA
Register
access
VMDS-10490 VSC7513 Datasheet Revision 4.2
VRAP
Engine
141
Functional Descriptions
3.14.1
Frame Extraction
The following table lists the registers associated with frame extraction.
Table 114 • Frame Extraction Registers
Register
Description
Replication
QSYS::CPU_GROUP_MAP
Configuration of mapping of extraction
queues to CPU ports.
None
SYS::PORT_MODE.INCL_XTR_HDR
Enables insertion of extraction header.
Configures formatting of outgoing
frames.
Per CPU port
(ports 11 and 12)
In the switch core, CPU extracted frames are forwarded to one of the eight CPU extraction queues. Each
of these queues is mapped to one of two CPU ports (port 11 and port 12) through
QSYS::CPU_GROUP_MAP. For each CPU port, there is a scheduler working either in strict mode or
round robin, which selects between the CPU extraction queues mapped to the same CPU port. In strict
mode, higher queue numbers are preferred over smaller queue numbers. In round robin, all queue are
serviced one after another.
The two CPU ports contain the same rewriter as regular front ports. The rewriter modifies the frames
before sending them to the CPU. In particular, the rewriter inserts an extraction header
(SYS::PORT_MODE.INCL_XTR_HDR), which contains relevant side band information about the frame
such as the frame’s classification result (VLAN tag information, DSCP, QoS class), ingress time stamp,
and the reason for sending the frame to the CPU. For more information about the rewriter, see Rewriter,
page 133.
The device CPU contains the functionality for reading out the frames. This can be done through the
frame DMA or regular register access. The Versatile Register Access Protocol (VRAP) Engine can also
be attached to one of the CPU extraction groups. This allows an external device to access internal
registers through Ethernet frames.
The following table lists the contents of the CPU extraction header.
Table 115 • CPU Extraction Header
Field
Bit
Width
Description
RESERVED
127
1
Reserved.
REW_OP
117
9
Rewriter operation command.
REW_OP[2:0] = 3 implies two-step PTP where REW_OP[8:3]
contains the PTP time stamp identifier.
Other settings do not apply.
REW_VAL
85
32
This field contains the Rx time when the frame was received.
LLEN
79
6
Frame length in bytes: 60 × WLEN + LLEN – 80.
WLEN
71
8
See LLEN.
RESERVED
47
24
Reserved.
SRC_PORT
43
4
The port number where the frame was received (0-11).
ACL_ID
37
6
If ACL_HIT is set, this value is the combined ACL_ID action of
the rules hit in IS2.
RESERVED
36
1
Reserved.
VMDS-10490 VSC7513 Datasheet Revision 4.2
142
Functional Descriptions
Table 115 • CPU Extraction Header (continued)
Field
Bit
Width
Description
SFLOW_ID
32
4
sFlow sampling ID.
0-11: Frame was sFlow sampled by a Tx sampler on port given
by SFLOW_ID.
12: Frame was sFlow sampled by an Rx sampler on port given
by SRC_PORT.
13-14: Reserved.
15: Frame was not sFlow sampled.
ACL_HIT
31
1
Set if frame has hit a rule in IS2, which copies the frame to the
CPU (IS2 actions CPU_COPY_ENA or HIT_ME_ONCE).
DP
30
1
The frame’s drop precedence (DP) level after policing.
LRN_FLAGS
28
2
The source MAC address learning action triggered by the frame.
0: No learning.
1: Learning of a new entry.
2: Updating of an already learned unlocked entry.
3: Updating of an already learned locked entry.
CPUQ
20
8
CPU extraction queue mask (one bit per CPU extraction queue).
Each bit set implies the frame was subjected to CPU forwarding
to the specific queue.
QOS_CLASS
17
3
The frame’s classified QoS class.
TAG_TYPE
16
1
The tag information’s associated Tag Protocol Identifier (TPID).
The definitions are:
0: C-tag: EtherType = 0x8100.
1: S-tag: EtherType = 0x88A8 or custom value.
PCP
13
3
The frame’s classified PCP.
DEI
12
1
The frame’s classified DEI.
VID
0
12
The frame’s classified VID.
3.14.2
Frame Injection
The following table lists the registers associated with frame injection.
Table 116 • Frame Injection Registers
Register
Description
Replication
SYS::PORT_MODE.INCL_INJ_HDR Enable parsing of injection header.
Per CPU port
Configures formatting of incoming frames. (ports 11 and 12)
QSYS::EQ_PREFER_SRC
Enable preferred arbitration of the CPU
port (port 11) over front ports.
CPU port (port 11
only)
The CPU injects frames through the two CPU injection groups that are independent of each other. The
injection groups connect to the two CPU ports (port 11 and port 12) in the CPU port module. In CPU port
module, each of the two CPU ports have dedicated access to the switch core. Inside the switch core, all
CPU injected frames are seen as coming from CPU port (port 11). This implies that both CPU injection
groups consume memory resources from the shared queue system for port 11 and that analyzer
configuration for port 11 are applied to all frames.
In the switch core, the CPU port can be preferred over other ingress ports when transferring frames to
egress queues by enabling precedence of the CPU port (QSYS::EQ_PREFER_SRC).
VMDS-10490 VSC7513 Datasheet Revision 4.2
143
Functional Descriptions
The first 20 bytes of a frame written to a CPU injection group is an injection header containing relevant
side band information about how the frame must be processed by the switch core. The CPU ports must
be enabled to expect the CPU injection header (SYS::PORT_MODE.INCL_INJ_HDR).
On a per-frame basis, the CPU controls whether frames injected through the CPU port module are
processed by the analyzer. If the frame is processed by the analyzer, it is sent through the processing
steps to calculate the destination ports for the frame. If analyzer processing is not selected, the CPU can
specify the destination port set and related information to fully control the forwarding of the frame. For
more information about the analyzer’s processing steps, see Forwarding Engine, page 109.
The contents of the CPU injection header is listed in the following table.
Table 117 • CPU Injection Header
Field
Bit
Width
Description
BYPASS
127
1
When this bit is set, the analyzer processing is skipped for this
frame. The destination set is specified in DEST and
CPU_QUEUE. Forwarding uses the QOS_CLASS, and the
rewriter uses the tag information (POP_CNT, TAG_TYPE, PCP,
DEI, VID) for rewriting actions.
When this bit is cleared, the analyzer determines the destination
set, QoS class, and VLAN classification for the frame through
normal frame processing including lookups in the MAC table and
VLAN table.
MASQ
126
1
When this bit is set, masquerading is enabled. The classifier,
analyzer, and queue system handle the frame as if it was
received by the ingress port specified in MASQ_PORT. This field
overloads the REW_OP field and should only be used when
BYPASS = 0.
MASQ_PORT
122
4
Masquerading port used when MASQ is set. This field overloads
the REW_OP field and should only be used when BYPASS = 0.
REW_OP
126
1
If set, frame’s source MAC address is replaced with source MAC
address configured per egress port
(SYS::REW_MAC_LOW_CFG, SYS::REW_MAC_HIGH_CFG).
VMDS-10490 VSC7513 Datasheet Revision 4.2
144
Functional Descriptions
Table 117 • CPU Injection Header (continued)
Field
Bit
Width
Description
REW_OP
117
9
Rewriter operation command. Used when BYPASS = 1. The
following commands are supported:
No operation: REW_OP[3:0] = 0.
No operation.
Special Rewrite: REW_OP[3:0] = 8.
Swap the MAC addresses and clear bit 40 in the new SMAC
when transmitting the frame.
DSCP remark: REW_OP[2:0] = 1.
REW_OP[8:3] contains the frame’s classified DSCP to be used
at egress for remarking.
One-step PTP: REW_OP[2:0] = 2.
The frame’s residence time is added to the correction field in the
PTP frame. The following sub-commands can be encoded:
REW_OP[5]: Set if egress delay must be added to residence
time.
Two-step PTP: REW_OP[2:0] = 3.
The frame’s departure time stamp is saved in the time stamp
FIFO queue at egress. REW_OP[8:3] contains the PTP time
stamp identifier used by the time stamp FIFO queue. Identifiers
0 through 3 are pre-allocated to be used by CPU injected
frames.
Origin PTP: REW_OP[2:0] = 5.
The time of day at the frame's departure time is written into the
origintime stamp field in the PTP frame.
Unspecified bits must be set to 0.
REW_VAL
85
32
By default, this field contains the frame’s receive time stamp. For
injected frames, this can be set by the CPU to indicate when the
injection started. The rewriter can then calculate a residence
time based on REW_VAL and the frame’s transmission time
stamp.
If TFRM_TIMER > 0, then REW_VAL contains the transmission
slot for periodic frame transmission (0 through 1023).
RESERVED
69
17
Reserved.
DEST
56
12
This is the destination set for the frame. DEST[11] is the CPU.
Used when BYPASS = 1.
RESERVED
47
9
Reserved.
SRC_PORT
43
4
The port number where the frame was injected (0-12).
RESERVED
41
2
Reserved.
TFRM_TIMER
37
4
Selects timer for periodic transmissions (1 through 8). If
TFRM_TIMER=0 then normal injection.
RESERVED
31
6
Reserved.
DP
30
1
The frame’s drop precedence (DP) level after policing. Used
when BYPASS = 1.
VMDS-10490 VSC7513 Datasheet Revision 4.2
145
Functional Descriptions
Table 117 • CPU Injection Header (continued)
3.14.3
Field
Bit
Width
Description
POP_CNT
28
2
Number of VLAN tags that must be popped in the rewriter before
adding new tags. Used when BYPASS = 1.
0: No tags must be popped.
1: One tag must be popped.
2: Two tags must be popped.
3: Disable all rewriting of the frame. The rewriter can still update
the FCS.
CPUQ
20
8
CPU extraction queue mask (one bit per CPU extraction queue).
Each bit set implies the frame must be forwarded by the CPU to
the specific queue.
Used when BYPASS = 1 and DEST[11] = 1.
QOS_CLASS
17
3
The frame’s classified QoS class.
Used when BYPASS = 1.
TAG_TYPE
16
1
The tag information’s associated Tag Protocol Identifier (TPID).
Used when BYPASS = 1.
0: C-tag: EtherType = 0x8100.
1: S-tag: EtherType = 0x88A8 or custom value.
PCP
13
3
The frame’s classified PCP. Used when BYPASS = 1.
DEI
12
1
The frame’s classified DEI. Used when BYPASS = 1.
VID
0
12
The frame’s classified VID. Used when BYPASS = 1.
Node Processor Interface (NPI)
The following table lists the registers associated with the NPI.
Table 118 • Node Processor Interface Registers
Register
Description
Replication
QSYS::EXT_CPU_CFG
Configuration of the NPI port number and
None
configuration of which CPU extraction queues
are redirected to the NPI.
SYS::PORT_MODE.INCL_XTR_HDR Enables insertion of extraction header.
Per port
SYS::PORT_MODE.INCL_INJ_HDR
Per port
Configuration of NPI ingress mode.
Any front port can be configured as an NPI through which frames can be injected from and extracted to
an external CPU. Only one port can be an NPI at the same time.
QSYS::EXT_CPU_CFG.EXT_CPU_PORT holds the port number of the NPI.
A dual CPU system is possible where both the internal and the external CPU are active at the same time.
Through QSYS::EXT_CPU_CFG.EXT_CPUQ_MSK, it is configurable to which of the eight CPU
extraction queues are directed to the internal CPU and which are directed to external CPU. A frame can
be extracted to both the internal CPU and the external CPU if the frame is extracted for multiple reasons.
Frames being extracted by the external CPU can have the CPU extraction header inserted in front of the
frame (SYS::PORT_MODE.INCL_XTR_HDR). Similarly, frames being injected into the switch core by the
external CPU can have the CPU injection header inserted in front of the frame
(SYS::PORT_MODE.INCL_INJ_HDR). In addition, there three different options in terms of inserting a
prefix in front of the CPU injection or extraction header. The following illustration shows the different
frame formats supported.
VMDS-10490 VSC7513 Datasheet Revision 4.2
146
Functional Descriptions
Figure 45 • CPU Injection and Extraction Prefixes
Extraction with long prefix:
FF-FF-FF-FF-FF-FF
48 bits
FE-FF-FF-FF-FF-FF
48 bits
8880 000A
16 bits 16 bits
CPU Extraction header
128 bits
Original frame
Extraction with short prefix:
8880 000A
16 bits 16 bits
CPU Extraction header
128 bits
Original frame
Extraction with no prefix:
CPU Extraction header
128 bits
Original frame
Injection with long prefix:
Any DMAC
48 bits
Any SMAC
48 bits
8880 000A
16 bits 16 bits
CPU Injection header
128 bits
Original frame
Injection with short prefix:
8880 000A
16 bits 16 bits
CPU Injection header
128 bits
Original frame
Injection with no prefix:
CPU Injection header
128 bits
Original frame
Start-of-frame
Note that inserting a CPU extraction header in front of a frame disables all other frame modifications
done in the rewriter.
When injecting frames with an CPU injection header all incoming frames are expected to adhere to the
configured prefix mode. The following parsing of the frames takes place:
•
•
•
No prefix. All incoming frames are parsed as if they have a CPU injection header in front of the
frame. Forwarding is based on the instructions in the CPU injection header.
Short prefix. Incoming frames are checked against the expected format (start of frame must include
0x8880000A). If the prefix does not match then an error indication is set
(SYS::PORT_MODE.INJ_HDR_ERR). Compliant frames are forwarded based on the instructions in
the CPU injection header. Non-compliant frames are forwarded as normal frames where the prefix
and CPU injection header equaling the first 20 bytes of the frame are skipped.
Long prefix. All incoming frames are parsed as if they have a long prefix followed by the CPU
injection header in front of the frame. The incoming frames are checked against the expected format
(start of frame must include 12 bytes of MAC addresses followed by 0x8880000A). If the prefix does
not match then an error indication is set (SYS::PORT_MODE.INJ_HDR_ERR). Both compliant and
non-compliant frames are forwarded based on the instructions in the CPU injection header.
The external CPU can control forwarding of injected frames by either letting the frame analyze and
forward accordingly or directly specifying the destination set. This is controlled through the BYPASS field
in the CPU injection header.
3.14.4
Frame Generation Engine for Periodic Transmissions
The following table lists the registers associated with the frame generation engine.
Table 119 • Frame Generation Engine
Register
Description
Replication
QSYS::TFRM_MISC
Configuration to cancel ongoing periodic transmissions.
None
QSYS::TFRM_PORT_DLY_ENA
Enable spaced-out transmissions when multiple periodic Per port
transmissions are scheduled at the same time.
QSYS::TFRM_TIMER_CFG_x
Period configuration. These registers configure the
transmission period between frames.
VMDS-10490 VSC7513 Datasheet Revision 4.2
8
147
Functional Descriptions
The device contains a frame generation engine that can periodically transmit frames on a port with a
programmable transmission period. The transmission period can be as low as 200 ns, which implies
wire-speed back-to-back transmissions, or as high as several minutes. Up to 1024 periodic
transmissions can coexist with up to eight different transmission periods.
To set up a periodic transmission, the CPU must inject a setup frame using the following settings in the
injection header:
•
•
•
•
•
REW_VAL set to the selected transmission slot (0 through 1023).
ACL_ID set to the selected timer (1 through 8). The transmission period is programmed in steps of
198.2 ns in TFRM_TIMER_CFG_x, where x = ACL_ID. Note that injecting a frame with ACL_ID > 0
effectively enables the periodic transmissions. To inject a normal frame, ACL_ID must be set to 0.
BYPASS set to 1.
DEST set to the Tx port to which the periodic transmission applies. Only one Tx port per
transmission is possible.
Other fields in the injection header are applicable the same way as for normal injections. Note, that
the periodic transmissions are subject to normal rewriter operations before being transmitted on the
Tx port. For more information, see Rewriter, page 133.
After the injection, the setup frame is placed into the selected transmission slot and it is periodically
transmitted using the transmission period defined by the selected timer. Every time the transmission
period has passed since the last transmission, the frame is scheduled for a new transmission on the
associated port. The periodic frame transmission takes precedence over other transmissions on the port,
and as a consequence the frame is transmitted immediately after a potential ongoing transmission has
ended.
If multiple periodic transmissions on a Tx port use the same timer, multiple frames are scheduled for
transmission at the same time when the period has passed. By default, these frames are transmitted in a
burst, back-to-back. However, it is also possible to space-out these frames over time and thereby
allowing the normal data traffic to be interleaved the periodic transmissions. If the spacing is enabled
(TFRM_PORT_DLY), timer 8 defines the period between frames in the burst.
Periodic transmissions are cancelled again by programming the slot number in
TFRM_MISC.TIMED_CANCEL_SLOT and setting TFRM_MISC.TIMED_CANCEL_1SHOT. This
removes the injected frame from the transmission slot.
Transmission slots 0 through 15 support any transmission periods including back-to-back transmissions
while slots 16 through 1023 support transmission periods larger than 30 µs.
Frames transmitted from the frame generation engine are counted by the Tx counters just like normal
frames using the QoS class specified in the injection header by the setup frame.
3.15
VRAP Engine
The Versatile Register Access Protocol (VRAP) engine allows external equipment to access registers in
the device through any of the Ethernet port’s on the device. The VRAP engine interprets incoming VRAP
requests, and executes read, write, and read-modify-write commands contained in the frames. The
results of the register accesses are reported back to the transmitter through automatically generated
VRAP response frames.
The device supports version 1 of VRAP. All VRAP frames, both requests and responses, are standard
Ethernet frames. All VRAP protocol fields are big-endian formatted.
The registers listed in the following table control the VRAP engine.
Table 120 • VRAP Registers
Target:Register_group:Register.field
Description
ANA:CPU_FWD_CFG:CPU_VRAP_REDIR_ENA Enable redirection of VRAP frames
to CPU.
ANA:CPUQ_CFG2:CPUQ_VRAP
Replication
Per port
Configure the CPU extraction queue None
for VRAP frames.
VMDS-10490 VSC7513 Datasheet Revision 4.2
148
Functional Descriptions
Table 120 • VRAP Registers (continued)
Target:Register_group:Register.field
Description
Replication
QSYS:CPU_GROUP_MAP:CPU_GROUP_MAP
Map VRAP CPU extraction queue to None
a CPU port. One CPU port must be
reserved for VRAP frames.
DEVCPU_QS:XTR_GRP_CFG:MODE
Enable VRAP mode for reserved
CPU port.
Per CPU port
DEVCPU_QS:INJ_GRP_CFG:MODE
Enable VRAP mode injection for
reserved CPU port.
Per CPU port
SYS:PORT_MODE:INCL_INJ_HDR
The injection header is not present
for VRAP response frames.
Per port
SYS:PORT_MODE:INCL_XTR_HDR
The extraction header is not present Per port
for redirected VRAP frames.
DEVCPU_GCB:VRAP_ACCESS_STAT
VRAP access status.
None
The VRAP engine processes incoming VRAP frames that are redirected to the VRAP CPU extraction
queue by the basic classifier. For more information about the VRAP filter in the classifier, see CPU
Forwarding Determination, page 58.
The VRAP engine is enabled by allocating one of the two CPU ports as a dedicated VRAP CPU port
(DEVCPU_QS:XTR_GRP_CFG:MODE and DEVCPU_QS:INJ_GRP:MODE). The VRAP CPU
extraction queue (ANA:CPUQ_CFG2:CPUQ_VRAP) must be mapped as the only CPU extraction queue
to the VRAP CPU port (QSYS:CPU_GROUP_MAP:CPU_GROUP_MAP). In addition, the VRAP CPU
port must disable the use of CPU injection and CPU extraction headers
(SYS:PORT_MODE:INCL_INJ_HDR and SYS:PORT_MODE:INCL_XTR_HDR).
The complete VRAP functionality can be enabled automatically at chip startup by the use of special chip
boot modes. For more information, see VCore-III Configurations, page 160.
The following describes the VRAP frame formats.
3.15.1
VRAP Request Frame Format
The following illustration shows the format of a VRAP request frame.
Figure 46 • VRAP Request Frame Format
DMAC
SMAC
EtherType
VRAP Commands
EPID
Any valid DMAC
Any valid SMAC
0x8880
0x0004
VRAP HDR
(Request)
48 bits
48 bits
16 bits
16 bits
32 bits
#1
FCS
#n
variable length
Valid FCS
32 bits
VRAP request frames can optionally be VLAN tagged with one VLAN tag.
The EtherType = 0x8880 and the Ethernet Protocol Identifier (EPID) = 0x0004 identify the VRAP frames.
The subsequent VRAP header is used in both request and response frames.
The VRAP commands included in the request frame are the actual register access commands. The
VRAP engine supports the following five VRAP commands:
•
•
•
•
•
READ: Returns the 32-bit contents of any register in the device.
WRITE: Writes a 32-bit value to any register in the device.
READ-MODIFY-WRITE: Does read/modify/write of any 32-bit register in the device.
IDLE: Does not access registers but is useful for padding and identification purposes.
PAUSE: Does not access registers but causes the VRAP engine to pause between register access.
Each of the VRAP commands are described in the following sections. Each VRAP request frame can
contain multiple VRAP commands. Commands are processed sequentially starting with VRAP command
#1, #2, and so on. For more information, see . There are no restrictions on the order or
number of commands in the frame.
VMDS-10490 VSC7513 Datasheet Revision 4.2
149
Functional Descriptions
3.15.2
VRAP Response Frame Format
Having processed a VRAP request frame by executing the register access commands contained in the
frame, the VRAP engine generates a VRAP response frame. The response frame uses the swapped
DMAC and SMAC addresses in the VRAP request frame and it is transmitted on port where the VRAP
request frame was received. If the DMAC in the VRAP request frame is a multicast DMAC, then bit 40 is
cleared before using the DMAC as the SMAC in the VRAP response frame. The results of the VRAP
commands are inserted into the response frame in the same order as the VRAP commands were
processed.
The following illustration shows the format of a VRAP response frame.
Figure 47 • VRAP Response Frame Format
DMAC
SMAC from
VRAP request frame
SMAC
DMAC from VRAP
request frame
EtherType
0x8880
0x0004
VRAP HDR
(Response)
48 bits
48 bits
16 bits
16 bits
32 bits
READ and IDLE results
EPID
#1
FCS
#n
Valid FCS
variable length
32 bits
The VRAP response frame follows the VRAP request frame in terms of VLAN tagging: If the VRAP request was
tagged, the VRAP response is also tagged using the same VLAN.
Only the READ and IDLE commands require data to be returned to the transmitter of the VRAP request
frame. However, even if the VRAP request frame does not contain READ and IDLE commands, a VRAP
response frame is generated with enough padding data (zeros) to fulfill the minimum transfer unit size.
3.15.3
VRAP Header Format
Both VRAP request and VRAP response frames contain a 32-bit VRAP header. The VRAP header is
used to identify the protocol version and to differentiate between VRAP requests and VRAP response
frames. The device supports VRAP version 1. The following illustration shows the VRAP header.
Figure 48 • VRAP Header Format
4 bits
4 bits
24 bits
Version
Flags
Reserved
31
28 27
24 23
0
Version:
Set to 0x1 in VRAP response frames.
VRAP request frames are ignored if Version 1
Flags:
4 bits are used for Flags. Only one flag is defined:
R
Rsv
3
0
R: 0=Request, 1=Response
Rsv: Set to 0 in VRAP response frames and ignored in VRAP
request frames.
Reserved:
Set to 0 in VRAP response frames and ignored in VRAP
request frames.
A valid VRAP request frame must use Version = 1 and Flags.R = 1. Frames with an invalid VRAP header
are discarded and not processed by the VRAP engine.
3.15.4
VRAP READ Command
The VRAP READ command returns the contents of any 32-bit register inside the device. The 32-bit readdata result is put into the VRAP response frame.
VMDS-10490 VSC7513 Datasheet Revision 4.2
150
Functional Descriptions
The READ command is 4 bytes wide and consists of one 32-bit address field, which is 32-bit aligned. The
2 least significant bits of the address set to 01. The following illustration shows the request command and
the associated response result.
Figure 49 • READ Command
Request:
3.15.5
Response:
Register address, bits 31:2 01
Register read data
32 bits
32 bits
VRAP WRITE Command
The WRITE command writes a 32-bit value to any register inside the device.
The WRITE command is 8 bytes wide and consists of one 32-bit address field, which is 32-bit aligned.
The two least significant bits of the address set to 10, followed by one 32-bit write-data field. The
following illustration shows the command.
Figure 50 • WRITE Command
Request:
3.15.6
Register address, bits 31:2 10
Register write data
32 bits
32 bits
VRAP READ-MODIFY-WRITE Command
The READ-MODIFY-WRITE command does read/modify/write-back on any 32-bit register inside the
device.
The READ-MODIFY-WRITE command is 12 bytes wide and consists of one 32-bit address field, which is
32-bit aligned. The two least significant bits of the address set to 11 followed by one 32-bit write-data field
followed by one 32-bit overwrite-mask field. For bits set in the overwrite mask, the corresponding bits in
the write data field are written to the register while bits cleared in the overwrite mask are untouched when
writing to the register. The following figure shows the command.
Figure 51 • READ-MODIFY-WRITE Command
Request:
3.15.7
Register address, bits 31:2 11
Register write data
Overwrite mask
32 bits
32 bits
32 bits
VRAP IDLE Command
The IDLE command does not access registers in the device. Instead it just copies itself (the entire
command) into the VRAP response. This can be used for padding to fulfill the minimum transmission unit
size, or an external CPU can use it to insert a unique code into each VRAP request frame so that it can
separate different replies from each other.
The IDLE command is 4 bytes wide and consists of one 32-bit code word with the four least significant
bits of the code word set to 0000. The following illustration depicts the request command and the
associated response.
Figure 52 • IDLE Command
Request:
Response:
Any 28-bit value
32 bits
0000
Copy of value
0000
32 bits
VMDS-10490 VSC7513 Datasheet Revision 4.2
151
Functional Descriptions
3.15.8
VRAP PAUSE Command
The PAUSE command does not access registers in the device. Instead, it causes the VRAP engine to
enter a wait state and remain there until the pause time has expired. This can be used to ensure
sufficient delay between VRAP commands when this is needed.
The PAUSE command is 4 bytes wide and consists of one 32-bit code word with the four least significant
bits of the code word set to 0100. The wait time is controlled by the 28 most significant bits of the wait
command. The time unit is 1 us. The following illustration depicts the PAUSE command.
Figure 53 • PAUSE Command
Request:
Pause value (µs)
0100
32 bits
3.16
Layer 1 Timing
There are eight recovered clocks, four outputs that provide timing sources for external timing circuitry in
redundant timing implementations, and four internal clocks for the timing-recovery circuit. The following
tables list the registers and pins associated with Layer 1 timing.
Table 121 • Layer 1 Timing Configuration Registers
Register
Description
HSIO::SYNC_ETH_CFG
Configures recovered clocks. Replicated per recovered clock.
HSIO::SYNC_ETH_PLL_CFG
Additional PLL recovered clock configuration. Replicated per
recovered clock.
HSIO::PLL5G_CFG3
Enables high speed clock output.
PHY:PHY_GP:PHY_RCVD_CLK0_CTRL
Configures PHY recovered clock 0.
PHY:PHY_GP:PHY_RCVD_CLK1_CTRL
Configures PHY recovered clock 1.
Table 122 • Layer 1 Timing Recovered Clock Pins
Pin Name
I/O
Description
RCVRD_CLK0
O
Recovered clock output, configured by SYNC_ETH_CFG[0].
This is an overlaid function on GPIO.
RCVRD_CLK1
O
Recovered clock output, configured by SYNC_ETH_CFG[1].
This is an overlaid function on GPIO.
CLKOUT
O
PLL high speed clock output.
It is possible to recover receive timing from any 10/100/1000 Mbps and 2.5 Gbps data streams into the
device.
The recovered clock outputs have individual divider configuration (through
SYNC_ETH_CFG.SEL_RCVRD_CLK_DIV) to allow division of SerDes receive frequency by 1, 2, 4, 5, 8,
16, or 25.
The recovered clocks are single-ended outputs, and the suggested divider settings in the following tables
are selected to make sure to not output too high a frequency through the input and outputs.
The four CuPHY ports share two recovered clocks. In table Table 123, page 153, the two clock resources
are called clk and can take the value 0 or 1. The CLK_SRC_SEL0 and CLK_SRC_SEL1 fields are
VMDS-10490 VSC7513 Datasheet Revision 4.2
152
Functional Descriptions
programmed with the number of the CuPHY that provides the recovered clock; CuPHYcan take the value
0 through 3.
Table 123 • Recovered Clock Settings for 1 Gbps and Lower
Interface Output Frequency
Register Settings for Output n
CuPHY
clk 0-1
31.25 MHz
SYNC_ETH_CFG[n].RCVRD_CLK_ENA=1,
SYNC_ETH_CFG[n].SEL_RCVRD_CLK_DIV=1,
SYNC_ETH_CFG[n].SEL_RCVRD_CLK_SRC=clk,
PHY_RCVD_CLK[clk]_CTRL.RCVD_CLK[clk]_ENA=1,
PHY_RCVD_CLK[clk]_CTRL.CLK_SRC_SEL[clk]=(CuPHY),
PHY_RCVD_CLK[clk]_CTRL.CLK_FREQ_SEL[clk]=1, and
PHY_RCVD_CLK[clk]_CTRL.CLK_SEL_PHY[clk]=1
SerDes
0-8
31.25 MHz
SYNC_ETH_CFG[n].RCVRD_CLK_ENA=1,
SYNC_ETH_CFG[n].SEL_RCVRD_CLK_DIV=1, and
SYNC_ETH_CFG[n].SEL_RCVRD_CLK_SRC=(SerDes+2)
Table 124 • Recovered Clock Settings for 2.5 Gbps
Interface Output Frequency
Register Settings for Output n
SerDes
7-8
SYNC_ETH_CFG[n].RCVRD_CLK_ENA=1,
SYNC_ETH_CFG[n].SEL_RCVRD_CLK_DIV=4, and
SYNC_ETH_CFG[n].SEL_RCVRD_CLK_SRC=(Serdes + 2)
31.25 MHz
The frequency of the PLL can be used as recovered clock. The following table shows the configurations.
Table 125 • Recovered Clock Settings for PLL
PLL
Output Frequency
Register Settings for Output n
PLL
31.25 MHz
SYNC_ETH_CFG[n].RCVRD_CLK_ENA=1,
SYNC_ETH_CFG[n].SEL_RCVRD_CLK_DIV=1, and
SYNC_ETH_CFG[n].SEL_RCVRD_CLK_SRC=11
The recovered clock from the PLL can also be sent directly out on the differential high-speed CLKOUT
output. The recovered clock frequency must be set to copy the switch core using
HSIO::PLL5G_CFG3.CLKOUT_SEL.
It is possible to automatically squelch the clock output when the device detects a loss of signal on an
incoming data stream. This can be used for failover in external timing recovery solutions.
The following table lists how to configure squelch for possible recovered clock sources (configured in
SYNC_ETH_CFG[n].SEL_RCVRD_CLK_SRC).
Table 126 • Squelch Configuration for Sources
SRC
Associated Squelch Configuration
0-5
Set SERDES1G_COMMON_CFG.SE_AUTO_SQUELCH_ENA in SD macro to enable
squelch when receive signal is lost. SD1G macro index is (SRC).
6-8
Set SERDES6G_COMMON_CFG.SE_AUTO_SQUELCH_ENA in SD macro to enable
squelch when receive signal is lost. SD6G macro-index is (SRC-6).
When squelching the clock, it stops when it detects loss of signal (or PLL lock). The clock stops on either
high or low level.
The auto squelch function is not supported when 100 Mbit operation on SerDes, so in this mode the auto
squelch function must be disabled.
VMDS-10490 VSC7513 Datasheet Revision 4.2
153
Functional Descriptions
3.17
Hardware Time Stamping
Hardware time stamping provides nanosecond-accurate frame arrival and departure time stamps, which
are used to obtain high precision timing synchronization and timing distribution.
All frames are Rx time stamped on arrival with a 48-bit time stamp value using a hardware timer (time
stamper) that is implemented in the Media Access Control (MAC) block. The Rx time stamper provides
high time stamp accuracy relative to actual arrival time of the first byte of the frame from the PHY device.
Within the VCAP IS2, it is decided if the frame and associated Rx time stamp must be redirected or
copied to CPU for processing. The frame is forwarded as normal otherwise.
The VCAP IS2 also decides if a Tx time stamp must be triggered for a frame. Given the Rx and Tx time
stamps, the frame’s residence time inside the switch is calculated. The residence time can be stored in a
time stamp queue for the CPU to access (two-step time stamping) or the residence time can be used to
update the residence time field inside Precision Time Protocol frames (one-step time stamping).
The Tx time stamper is located at the transmit side of the MAC block as close to the PHY device as
possible and provides high accuracy of time stamp relative to when the first byte of the frame is actually
transmitted to the PHY.
The device also implements a time of day counter with nanosecond-accuracy. The time of day counter is
derived from a one-second timer. The one-second timer generates a pulse per second and is either
derived from an adjusted system clock or from external timing equipment.
3.17.1
Time Stamp Classification
Frames requiring Rx or Tx time stamping are identified by VCAP IS2. The IS2 action that triggers time
stamping is REW_OP[2:0], with the following options:
•
•
•
One-step time stamping (REW_OP[2:0] = 2), which implies adding the frame’s residence time to the
correction field.
Two-step time stamping (REW_OP[2:0] = 3), which implies saving the frame’s Tx time in a time
stamp queue.
Origin time stamping (REW_OP[2:0] = 5), which implies writing the time of day into the origintime
stamp field.
IS2 can be configured to identify the following frame formats from IEEE 1588-2008:
•
•
•
Transport of PTP over UDP over IPv4
Transport of PTP over UDP over IPv6
Transport of PTP over IEEE 802.3/Ethernet
In addition, frames can be encapsulated in Q-in-Q tunnels. For more information about the frame
encapsulations and PTP protocol fields supported by the VSC7418-01 device, see VCAP IS2, page 78.
3.17.2
Time of Day Generation
The DEVCPU has connection to four GPIOs to be used for 1588 synchronization shown in the following
illustration.
VMDS-10490 VSC7513 Datasheet Revision 4.2
154
Functional Descriptions
Figure 54 • Timing Distribution
Four controllers configured for:
- Load absolute time
- Load signed delta time
- Store absolute time
- Generate pulse or clock on pin
Load/store can be done on incoming edge
or immediately.
Adjuster
GPIO
LoadStore
Ctrl
LoadStore
Ctrl
LoadStore
LoadStoreCtrl
Ctrl
load
AbsT
gen
store
DeltaT
gen
TimeOfDay
sec (48 bits)
nsec (30 bits)
nsf (32 bits)
ooo
TimeOfDay
TimeOfDay
Analyzer / Rewriter / Port Modules
(only NSF in port module)
Each block using timing has a TimeOfDay instance included. These modules let time pass according to
an incoming delta request, instructing it to add the nominal clock period in nanoseconds (+0/+1/–1) for
each system clock cycle. This is controlled by a deltaT function in the DEVCPU, which can be configured
to do regular adjustments to the time by adding a single nanosecond more or less at specified intervals.
The absT function in the DEVCPU can set the full TOD time in the system. This is controlled by the
LoadStore controllers.
The DEVCPU includes four LoadStore controllers, each using a designated GPIO pin on the GPIO
interface. LoadStore controller 0 uses PTP_0 pin; LoadStore controller 1 uses PTP_1 pin, and so forth.
Before using the LoadStore controller, the VCore-III CPU must enable the overlaid functions for the
appropriate GPIO pins. For more information, see GPIO Overlaid Functions, page 205.
Each controller has CPU accessible registers with the full time of day set, and can be configured to load
these into the TimeOfDay instances, or to store the current values from them. The operation can be done
on a detected edge on the associated pin or immediately. The GPIO pin can also generate a clock with
configurable high and low periods set in nanoseconds using the TimeOfDay watches or it can generate a
pulse at a configured time with a configurable duration and polarity.
Table 127 • LoadStore Controller
Pin Control Field
Function
Action
Load: Load TOD_SEC and TOD_NSEC through the absTime bus.
Delta: Add configured nsec to the current time of day (absT).
Store: Store the current TOD_SEC and TOD_NSEC.
Clock: Generate a clock or a pulse on the pin.
Sync
Execute the load/store on incoming edge, if action is LOAD or STORE.
Generate a pulse instead of clock if action is CLOCK.
Inverse polarity
Falling edges are detected/generated.
TOD_sec
The 48-bit seconds of a time of day set to be loaded or stored.
TOD_nsec
The 30-bit nanoseconds of a time of day set to be loaded or stored.
VMDS-10490 VSC7513 Datasheet Revision 4.2
155
Functional Descriptions
Table 127 • LoadStore Controller (continued)
Pin Control Field
Function
Waveform high
Number of nanoseconds in the high period for generated clocks.
Duration of pulse for generated pulse.
Waveform_low
Number of nanoseconds in the low period for generated clocks.
Delay from TOD_ns = 0 for generated pulse.
In addition, the load operation can load a delta to the current time. This is done by executing a LOAD
action but using the DELTA command.
Each operation generates an interrupt when executed. For the clock action, the interrupt is generated
when the output switches to the active level. The interrupts from each controller can be masked and
monitored by the interrupt controller in the ICPU_CFG register target.
The four controllers are completely equal in their capabilities.
3.17.3
Hardware Time Stamping Module
This section explains the functions of the hardware time stamping module. The following table lists the
registers associated with the hardware time stamping module.
Table 128 • Hardware Time Stamping Registers
Register
Description
Replication
SYS::PTP_TXSTAMP
time stamp value in time stamp queue.
None
SYS::PTP_NXT
Advancing the time stamp queue.
None
SYS::PTP_STATUS
time stamp queue status and entry data.
None
ANA::PTP_ID_HIGH
Release of time stamp identifiers, values 32 through 63.
None
ANA::PTP_ID_LOW
Release of time stamp identifiers, values 0 through 31.
None
Each port module contains a hardware time stamping module that measures arrival and departure times
based on the master timer. For information about how the Rx and Tx time stamps are derived, see Rx
and Tx Time Stamps, page 22.
3.17.3.1
Two-Step Time Stamping
Two-step time stamping is performed if the IS2 rewriter action is two-step
(IS2_ACTION.REW_OP[2:0] = 3). This action can be applied to any frame, also non-PTP frames,
because the frame itself is not modified. The frame’s Tx time stamp is stored in a time stamp FIFO
queue, which the CPU can access (SYS::PTP_STATUS). The time stamp is common for all egress ports
and can contain up to 128 time stamps. Each entry in the time stamp queue contains the following fields:
•
•
•
•
•
SYS::PTP_STATUS.PTP_MESS_VLD: A 1-bit valid bit meaning the entry is ready for reading.
SYS::PTP_STATUS.PTP_MESS_ID: A 6-bit time stamp identifier. A unique time stamp identifier is
assigned to each frame for which one or more Tx time stamps are generated. The time stamp
identifier is also available in the CPU extraction header for frames extracted to the CPU. The time
stamp identifier overloads the DSCP value in the CPU extraction header. For more information about
the CPU extraction header, see Table 115, page 142. By providing the time stamp identifier in both
the time stamp queue and in the extracted frames, the CPU can correlate which time stamps belong
to which frames. Note that time stamp identifier value 63 implies that no free identifier could be
assigned to the frame. The time stamp entry can therefore not be trusted.
SYS::PTP_STATUS.PTP_MESS_TXPORT: The port number where the frame is transmitted. When
transmitting a frame on multiple ports, there are generated multiple entries in the time stamp queue.
Each entry uses the same time stamp identifier but with different Tx port numbers.
SYS::PTP_STATUS.PTP_TXSTAMP_OAM: For two-step time stamping, this field is always 0. If set,
it identifies an entry inserted by the Vitesse OAM processor (VOP).
SYS::PTP_TXSTAMP: The frame’s Tx time stamp.
VMDS-10490 VSC7513 Datasheet Revision 4.2
156
Functional Descriptions
The time stamp queue is a simple FIFO that can be read by the CPU. The time stamp queue provides the
following handles for reading:
•
•
•
Overflow of the queue is signaled through SYS::PTP_STATUS.PTP_OVFL. Overflow implies that
one or more time stamps could not be enqueued due to all 128 entries being in use. time stamps not
enqueued are lost.
The head-of-line entry is read through SYS::PTP_STATUS and SYS::PTP_TXSTAMP.
Writing to the one-shot register SYS::PTP_NXT, removes the current head-of-line entry and
advances the pointer to the next entry in the time stamp queue.
When two-step Tx time stamping is performed for a frame destined for the CPU extraction queues, no
entry in the time stamp FIFO queue is made. The frame’s Rx time stamp is available through the CPU
extraction header.
The time stamp identifiers can take values between 0 to 63. Value 63 implies that all values 0-62 are in
use. Values 0 – 3 are pre-assigned to the CPU to be used for injection of frames. The remaining values
are assigned by the analyzer to frames requesting time stamping through the VCAP IS2 action. The
assigned values must be released again by the CPU by writing to the corresponding bit in
ANA::PTP_ID_HIGH (values 32 through 63) or ANA::PTP_ID_LOW (values 0 through 31). The CPU
releases a time stamp identifier when it has read the anticipated time stamp entries from the time stamp
queue. Note that multicasted frames generate a time stamp entry per egress port using the same time
stamp identifier. Each of these entries must be read before the time stamp identifier is released.
Two-step time stamping can be disabled per egress port using REW:PORT:PTP_CFG.PTP_2STEP_DIS.
This setting overrules the IS2 action.
3.17.4
Configuring I/O Delays
After a valid link is established and detected by the involved PCS logic, the I/O delays from the internal
time stamping points to the serial line must be configured. The delays are both mode-specific and
interface-specific, depending on the core clock frequency.
Ingress barrel shifter states that in 1G mode, the Rx delays must be added 0.8 ns times the value of
PCS1G_LINK_STATUS.DELAY_VAR to adjust for barrel shifting state after link establishment. In 2.5G
mode, the multiplier is 0.32 ns. In 100FX mode, the Rx delays must be subtracted 0.8 ns times the value
of PCS_FX100_STATUS.EDGE_POS_PTP to adjust for detected data phase.
The Rx and Tx delay values for the different ports and modes are automatically configured in the
software API.
3.18
Clocking and Reset
The reference clock for the PLL (REFCLK_P/N) is either differential or single-ended. The frequency can
be 25 MHz, 125 MHz, 156.25 MHz, or 250 MHz. The PLL must be configured for the appropriate clock
frequency by using strapping inputs REFCLK_CONF[2:0].
The PLL can be used as a recovered clock source for Synchronous Ethernet. For information about how
to configure PLL clock recovery, see Layer 1 Timing, page 152.
For information about protecting the VCore CPU system during a soft-reset, see Clocking and Reset,
page 157.
3.18.1
Pin Strapping
Configure PLL reference clock and VCore startup mode using the strapping pins on the GPIO interface.
The device latches strapping pins and keeps their value when nRESET to the device is released. After
VMDS-10490 VSC7513 Datasheet Revision 4.2
157
Functional Descriptions
reset is released, the strapping pins are used for other functions. For more information about which GPIO
pins are used for strapping, see GPIO Overlaid Functions, page 205.
Table 129 • Strapping
Pin
Description
REFCLK_CONF[2:0]
Configuration of reference clock frequency for PLL.
000: 125 MHz
001: 156.25 MHz
010: 250 MHz
100: 25 MHz
Other values are reserved and must not be used.
VCORE_CFG[3:0]
Configuration of VCore system startup conditions.
0000: VCore-III CPU is enabled (Little Endian mode) and boots from SI (the SI
slave is disabled).
1001: PCIe 1.x endpoint is enabled. Automatic boot of VCore-III CPU is disabled,
and SI slave is enabled.
1010: MIIM slave is enabled with MIIM address 0 (MIIM slave pins are overlaid on
GPIOs). Automatic boot of VCore-III CPU is disabled, and SI slave is enabled.
1011: MIIM slave is enabled with MIIM address 31 (MIIM slave pins are overlaid
on GPIOs). Automatic boot of VCore-III CPU is disabled, and SI slave is enabled.
1100: VCore-III CPU is enabled (Big Endian mode) and boots from SI (the SI
slave is disabled).
1111: Automatic boot of VCore-III CPU is disabled, and SI slave is enabled.
Other values are reserved and must not be used.
By using resistors to pull the GPIOs either low or high, software can use these GPIO pins for other
functions after reset has been released. For more information about overlaid functions on the GPIOs, see
GPIO Overlaid Functions, page 205.
Undefined configurations are reserved and cannot be used. VCore-III configurations that enable a front
port or the PCIe endpoint drive VCore_CFG[3:2] high when the front port or PCIe endpoint is ready to
use.
VMDS-10490 VSC7513 Datasheet Revision 4.2
158
VCore-III System and CPU Interfaces
4
VCore-III System and CPU Interfaces
This section provides information about the functional aspects of blocks and interfaces related to the
VCore-III on-chip microprocessor system and an external CPU system.
The device contains a powerful VCore-III CPU system that is based on an embedded MIPS24KEccompatible microprocessor and a high bandwidth Ethernet Frame DMA engine. The VCore-III system
can control the device independently, or it can support an external CPU, relieving the external CPU of the
otherwise time consuming tasks of transferring frames, maintaining the switch core, and handling
networking protocols.
When the VCore-III CPU is enabled, it either automatically boots up from serial Flash or an external CPU
can manually load a code-image to the device and then start the VCore-III CPU.
An external CPU can be connected to the device through the PCIe interface, serial interface (SI),
dedicated MIIM slave interface, or through Versatile Register Access Protocol (VRAP) formatted
Ethernet frames using the NPI Ethernet port. Through these interfaces, the external CPU has access to
the complete set of device registers and can control them without help from the VCore-IeVCore-III CPU if
needed.
The following illustration shows the VCore-III block diagram.
Figure 55 • VCore-III System Block Diagram.
VRAP
(Register access
through Ethernet)
SI Slave(1)
GPIO I/O
Controller
Switch Core
Register Bus
Access/Arbiter
MIIM Slave
VCore CPU
SGPIO I/O
Controller
MIIM
Masters × 2
Fan
Controller
Switch Core Register Bus (CSR)
VCore SBA
Access Block
Temperature
Sensor
Switch Core
Registers
Switch Core
Access Block
Interrupt
Controller
Timers × 3
VCore Shared Bus
Access/Arbiter
SI Flash Boot
Master(1)
VCore Shared Bus (SBA)
PCIe Inbound(2)
Two-Wire Serial
Interface
Manual Frame
Inject/Extract
UART × 2
Frame DMA
(FDMA)
PCIe
Outbound
DDR3/3L
Controller
1. When the Vcore-III CPU boots up from the SI Flash, the SI is reserved as boot interface and cannot be used by an external CPU.
2. Inbound PCIe access to BAR0 maps to VCore register space (switch core access block, interrupt controller, timers, two-wire serial
master/slave, UARTs, and manual frame injection/extraction). Inbound PCIe access to BAR2 maps to the DDR3/3L memory space
(DDR controller).
VMDS-10490 VSC7513 Datasheet Revision 4.2
159
VCore-III System and CPU Interfaces
4.1
VCore-III Configurations
The behavior of the VCore-III system after a reset is determined by four VCore strapping pins that are
overlaid on GPIO pins. The value of these GPIOs is sampled shortly after releasing reset to the device.
For more information about the strapping pins, see Pin Strapping, page 157.
The strapping value determines the reset value for the ICPU_CFG::GENERAL_CTRL register. After
startup, the behavior of the VCore-III system can be modified by changing some of the fields in this
register. The following are common scenarios.
•
•
•
•
After starting the device with the VCore-III CPU disabled, an external CPU can manually boot the
VCore-III CPU from SI Flash by writing ICPU_CFG::GENERAL_CTRL.IF_SI_OWNER = 1,
ICPU_CFG::GENERAL_CTRL.BOOT_MODE_ENA = 1, and
ICPU_CFG::GENERAL_CTRL.CPU_DIS = 0. Endianess is configured by
ICPU_CFG::GENERAL_CTRL.CPU_BE_ENA. Setting GENERAL_CTRL.IF_SI_OWNER disables
the SI slave, so the external CPU must use another interface than SI.
After starting the device with the VCore-III CPU disabled and loading software into
DDR3/DDR3Lmemory, an external CPU can boot the VCore-III CPU from DDR3/DDR3L memory by
writing ICPU_CFG::GENERAL_CTRL.BOOT_MODE_ENA = 0 and
ICPU_CFG::GENERAL_CTRL.CPU_DIS = 0. Endianess is configured using
ICPU_CFG::GENERAL_CTRL.CPU_BE_ENA.
After automatically booting from SI Flash, the VCore-III CPU can release the SI interface and enable
the SI slave by writing ICPU_CFG::GENERAL_CTRL.IF_SI_OWNER = 0. This enables SI access
from an external CPU to the device. A special PCB design is required to make the serial interface
work for both Flash and external CPU access.
MIIM slave can be manually enabled by writing
ICPU_CFG::GENERAL_CTRL.IF_MIIM_SLV_ENA = 1. The MIIM slave automatically takes control
of the appropriate GPIO pins.
The EJTAG interface of the VCore-III CPU and the Boundary Scan JTAG controller are both multiplexed
onto the JTAG interface of the device. When the JTAG_ICE_nEN pin is low, the MIPS’s EJTAG controller
is selected. When the JTAG_ICE_nEN pin is high, the Boundary Scan JTAG controller is selected.
4.2
Clocking and Reset
The following table lists the registers associated with reset and the watchdog timer.
Table 130 • Clocking and Reset Configuration Registers
Register
Description
ICPU_CFG::RESET
VCore-III reset protection scheme and initiating soft reset of
the VCore-III system and/or CPU.
DEVCPU_GCB::SOFT_RST
Initiating chip-level soft reset.
ICPU_CFG::WDT
Watchdog timer configuration and status.
The VCore-III CPU runs 500 MHz, the DDR3/DDR3L controller runs 312.50 MHz, and the rest of the
VCore-III system runs at 250 MHz.
The VCore-III can be soft reset by setting RESET.CORE_RST_FORCE. By default, this resets both the
VCore-III CPU and the VCore-III system. The VCore-III system can be excluded from a soft reset by
setting RESET.CORE_RST_CPU_ONLY; soft reset using CORE_RST_FORCE only then resets the
VCore-III CPU. The frame DMA must be disabled prior to a soft reset of the VCore-III system. When
CORE_RST_CPU_ONLY is set, the frame DMA, PCIe endpoint, and DDR3/DDR3L controller are not
affected by a soft reset and continue to operate throughout soft reset of the VCore-III CPU.
The VCore-III system comprises all the blocks attached to the VCore Shared Bus (SBA), including the
PCIe, DDR3/DDR3L, and frame DMA/injection/extraction blocks. Blocks attached to the switch core
Register Bus (CSR), including VRAP, SI, and MIIM slaves, are not part of the VCore-III system reset
domain. For more information about the VCore-III system blocks, see Figure 4.1, page 160.
VMDS-10490 VSC7513 Datasheet Revision 4.2
160
VCore-III System and CPU Interfaces
The device can be soft reset by writing SOFT_RST.SOFT_CHIP_RST. The VCore-III system and CPU
can be protected from a device soft reset by writing RESET.CORE_RST_PROTECT = 1 before initiating
a soft reset. In this case, a chip-level soft reset is applied to all other blocks, except the VCore-III system
and the CPU. When protecting the VCore-III system and CPU from a soft reset, the frame DMA must be
disabled prior to a chip-level soft reset. The SERDES and PLL blocks can be protected from reset by
writing to SOFT_RST.SOFT_SWC_RST instead of SOFT_CHIP_RST.
The VCore-III general purpose registers (ICPU_CFG::GPR) and GPIO alternate modes
(DEVCPU_GCB::GPIO_ALT) are not affected by a soft reset. These registers are only reset when an
external reset is asserted.
4.2.1
Watchdog Timer
The VCore system has a built-in watchdog timer (WDT) with a two-second timeout cycle. The watchdog
timer is enabled, disabled, or reset through the WDT register. The watchdog timer is disabled by default.
After the watchdog timer is enabled, it must be regularly reset by software. Otherwise, it times out and
cause a VCore soft reset equivalent to setting RESET.CORE_RST_FORCE. Improper use of the
WDT.WDT_LOCK causes an immediate timeout-reset as if the watchdog timer had timed out. The
WDT.WDT_STATUS field shows if the last VCore-III CPU reset was caused by WDT timeout or regular
reset (possibly soft reset). The WDT.WDT_STATUS field is updated only during VCore-III CPU reset.
To enable or to reset the watchdog timer, write the locking sequence, as described in WDT.WDT_LOCK,
at the same time as setting the WDT.WDT_ENABLE field.
Note: Because watchdog timeout is equivalent to setting RESET.CORE_RST_FORCE, the
RESET.CORE_RST_CPU_ONLY field also applies to watchdog initiated soft reset.
4.3
Shared Bus
The shared bus is a 32-bit address and 32-bit data bus with dedicated master and slave interfaces that
interconnect all the blocks in the VCore-III system. The VCore-III CPU, PCIe inbound, and VCore SBA
access block are masters on the shared bus; only they can start access on the bus.
The shared bus uses byte addresses, and transfers of 8, 16, or 32 bits can be made. To increase
performance, bursting of multiple 32-bit words on the shared bus can be performed.
All slaves are mapped into the VCore-III system’s 32-bit address space and can be accessed directly by
masters on the shared bus. There are two possible mappings of VCore-III shared bus slaves, boot mode
and normal mode.
•
•
Boot mode is active after power-up and reset of the VCore-III system. In this mode, the SI Flash boot
master is mirrored into the lowest address region.
In normal mode, the DDR3/DDR3L controller is mirrored into the lowest address region.
Changing between boot mode and normal mode is done by first writing and then reading
ICPU_CFG::GENERAL_CTRL.BOOT_MODE_ENA. A change takes effect during the read.
The device supports up to 1 gigabyte (GB) of DDR3/DDR3L memory. By default, only 512 megabytes
(MB) is accessible in the memory map. Write ICPU_CFG::MEMCTRL_CFG.512MBYTE_PLUS = 1 to
accommodate more than 512 MB of memory.
VMDS-10490 VSC7513 Datasheet Revision 4.2
161
VCore-III System and CPU Interfaces
Figure 56 • Shared Bus memory
0x00000000
0x10000000
0x20000000
0x40000000
0x50000000
0x70000000
0x80000000
Boot Mode (Physical), 512 MB
256 MB Mirror of SI Flash
256 MB
512 MB
256 MB
512 MB
256 MB
Reserved
0x00000000
0x20000000
DDR3/DDR3L
SI Flash
0x40000000
0x50000000
Reserved
Chip Registers
1 GB
0x70000000
0x80000000
Normal Mode (Physical), 512 MB
512 MB
Mirror of DDR3/DDR3L
512 MB
DDR3/DDR3L
SI Flash
256 MB
512 MB
256 MB
Reserved
Chip Registers
1 GB
Reserved
0xC0000000
Reserved
0xC0000000
1 GB
1 GB
PCIe DMA
0xFFFFFFFF
0x00000000
0x10000000
PCIe DMA
0xFFFFFFFF
Boot Mode (Physical), 1 GB(1)
256 MB Mirror of SI Flash
0x00000000
Normal Mode (Physical), 1 GB(1)
1 GB
768 MB
Mirror of DDR3/DDR3L
Reserved
0x40000000
0x50000000
0x70000000
0x80000000
256 MB
512 MB
256 MB
SI Flash
0x40000000
0x50000000
Reserved
Chip Registers
1 GB
0x70000000
0x80000000
256 MB
256 MB
Chip Registers
DDR3/DDR3L
0xC0000000
1 GB
Reserved
1 GB
DDR3/DDR3L
0xC0000000
SI Flash
512 MB
1 GB
PCIe DMA
0xFFFFFFFF
PCIe DMA
0xFFFFFFFF
1. To enable support 1 gigabyte (GB) of DDR3/DDR3L memory (and the associated
memory map), set ICPU_CFG::MEMCTRL_CFG.DDR_512MBYTE_PLUS.
Note: When the VCore-III system is protected from a soft reset using
ICPU_CFG::RESET.CORE_RST_CPU_ONLY, a soft reset does not change shared bus memory
mapping. For more information about protecting the VCore-III system when using a soft reset, see
Figure 4.2, page 160.
If the boot process copies the SI Flash image to DDR3/DDR3L, and if the contents of the SI memory and
the DDR3 memory are the same, software can execute from the mirrored region when swapping from
boot mode to normal mode. Otherwise, software must be execute from the fixed SI Flash region when
changing from boot mode to normal mode.
The Frame DMA has dedicated access to PCIe outbound and to the DDR3/DDR3L. This means that
access on the SBA to other parts of the device, such as register access, does not affect Frame DMA
injection/extraction performance.
VMDS-10490 VSC7513 Datasheet Revision 4.2
162
VCore-III System and CPU Interfaces
4.3.1
VCore-III Shared Bus Arbitration
The following table lists the registers associated with the shared bus arbitration.
Table 131 • Shared Bus Configuration Registers
Register
Description
SBA::PL_CPU
Master priorities
SBA::PL_PCIE
Master priorities
SBA::PL_CSR
Master priorities
SBA::WT_EN
Enable of weighted token scheme
SBA::WT_TCL
Weighted token refresh period
SBA::WT_CPU
Token weights for weighted token scheme
SBA::WT_PCIE
Token weights for weighted token scheme
SBA::WT_CSR
Token weights for weighted token scheme
The VCore-III shared bus arbitrates between masters that want to access the bus. The default is to use a
strict prioritized arbitration scheme where the VCore-III CPU has highest priority. The strict priorities can
be changed using registers PL_CPU, PL_PCIE, and PL_CSR.
•
•
•
*_CPU registers apply to VCore-III CPU access
*_PCIE registers apply to inbound PCIe access
*_CSR registers apply to VCore-III SBA access block access
It is possible to enable weighted token arbitration scheme (WT_EN). When using this scheme, specific
masters can be guaranteed a certain amount of bandwidth on the shared bus. Guaranteed bandwidth
that is not used is given to other masters requesting the shared bus.
When weighted token arbitration is enabled, the masters on the shared bus are grated a configurable
number of tokens (WT_CPU, WT_PCIE, and WT_CSR) at the start of each refresh period. The length of
each refresh period is configurable (WT_TCL). For each clock cycle that the master uses the shared bus,
the token counter for that master is decremented. When all tokens are spent, the master is forced to a
low priority. Masters with tokens always take priority over masters with no tokens. The strict prioritized
scheme is used to arbitrate between masters with tokens and between masters without tokens.
Example Guarantee That PCIe Can Get 25% Bandwidth. Configure WT_TCL to a refresh period of
2048 clock cycles; the optimal length of the refresh period depends on the scenario, experiment to find
the right setting. Guarantee PCIe access in 25% of the refresh period by setting WT_PCIE to 512 (2048
× 25%). Set WT_CPU and WT_CSR to 0. This gives the VCore-III CPU and CSR unlimited tokens.
Configure PCIe to the highest priority by setting PL_PCIe to 15. Finally, enable the weighted token
scheme by setting WT_EN to 1. For each refresh period of 2048 clock cycles, PCIe is guaranteed access
to the shared bus for 512 clock cycles because it is the highest priority master. When all the tokens are
spent, it is put into the low-priority category.
4.3.2
Chip Register Region
Registers in the VCore-III domain and inside the switch core are memory mapped into the chip registers
region of the shared bus memory map. All registers are 32-bit wide and must only be accessed using 32bit reads and writes. Bursts are supported.
Writes to this region are buffered (there is a one-word write buffer). Multiple back-to-back write access
pauses the shared bus until the write buffer is freed up (until the previous writes are done). Reads from
this region pause the shared bus until read data is available.
VMDS-10490 VSC7513 Datasheet Revision 4.2
163
VCore-III System and CPU Interfaces
Figure 57 • Chip Registers Memory Map
0x70000000
1 MB
VCore Registers
0x70100000
0x70100400
0x70100800
0x70100C00
0x70101000
0x70101400
0x70110000
0x70110400
0x70111000
0x70112000
0x71000000
1 KB
UART Registers
1 KB
TWI Registers
1 KB
UART2 Registers
1 KB
Reserved
1 KB
SIMC Registers
59 KB
1 KB
3 KB
1 KB
15 MB
Reserved
SBA Registers
Reserved
PCIe Registers
Reserved
16 MB
Switch Core Registers
0x72000000
The registers in the 0x70000000 through 0x70FFFFFF region are physically located inside the VCore-III
system, so read and write access to these registers is fast (done in a few clock cycles). All registers in
this region are considered fast registers.
Registers in the 0x71000000 through 0x71FFFFFF region are located inside the switch core; access to
registers in this range takes approximately 1 µs. The DEVCPU_ORG and DEVCPU_QS targets are
special; registers inside these two targets are faster; access to these two targets takes approximately
0.1 µs.
When more than one CPU is accessing registers, the access time may be increased. For more
information, see Register Access and Multimaster Systems.
Writes to the Chip Registers region is buffered (there is a one-word write buffer). Multiple back-to-back
write access pauses the shared bus until the write buffer is freed up (until the previous write is done). A
read access pause the shared bus until read data is available. Executing a write immediately followed by
a read requires the write to be done before the read can be started.
4.3.3
SI Flash Region
Read access from the SI Flash region initiates Flash formatted read access on the SI pins of the device
by means of the SI boot controller.
The SI Flash region cannot be written to. Writing to the SI interface must be implemented by using the SI
master controller. For more information, see SI Master Controller, page 189. For legacy reasons, it is also
possible to write to the SI interface by using the SI boot master’s software “bit-banging” register interface.
For more information, see SI Boot Controller, page 187.
4.3.4
DDR3/DDR3L Region
Read and write access from or to the DDR3/DDR3L region maps to access on the DDR3 interface of the
device using the DDR3 controller. For more information about the DDR3/DDR3L controller and initializing
DDR3/DDR3L memory, see DDR3/DDR3L Memory Controller.
VMDS-10490 VSC7513 Datasheet Revision 4.2
164
VCore-III System and CPU Interfaces
4.3.5
PCIe Region
Read and write access from or to the PCIe region maps to outbound read and write access on the PCIe
interface of the device by means of the PCIe endpoint controller. For more information about the PCIe
endpoint controller and how to reach addresses in 32-bit and 64-bit PCIe environments, see PCIe
Endpoint Controller.
4.4
VCore-III CPU
The VCore-III CPU system is based on a powerful MIPS24KEc-compatible microprocessor with 16-entry
MMU, 32 kilobytes (kB) instruction, and 32 kB data caches.
This section describes how the VCore-III CPU is integrated into the VCore-III system. For more
information about internal VCore-III CPU functions, such as bringing up caches, MMU, and so on, see
the software board support package (BSP) at www.microsemi.com.
When the automatic boot in the little-endian or big-endian mode is enabled using the VCore-III strapping
pins, the VCore-III CPU automatically starts to execute code from the SI Flash at byte address 0.
The following is a typical automatic boot sequence.
1.
2.
3.
4.
Speed up the boot interface. For more information, see SI boot controller.
Initialize the DDR3/DDR3L controller. For more information, see DDR3/DDR3L Memory Controller
Copy code-image from Flash to DDR3/DDR3L memory.
Change memory map from boot mode to normal mode, see Shared Bus.
When automatic boot is disabled, an external CPU is still able to start the VCore-III CPU through
registers. For more information, see VCore Configurations.
The boot vector of the VCore-III CPU is mapped to the start of the KESEG1, which translates to physical
address 0x00000000 on the VCore-III shared bus.
The VCore-III CPU interrupts are mapped to interrupt inputs 0 and 1, respectively.
4.4.1
Little Endian and Big Endian Support
The VCore-III system is constructed as a little endian system, and registers descriptions reflect little
endian encoding. When big endian mode is enabled, instructions and data are byte-lane swapped just
before they enter and when they leave the VCore-III CPU. This is the standard way of translating
between a CPU in big endian mode and a little endian system.
In big endian mode, care must be taken when accessing parts of the memory system that is also used by
users other than the VCore-III CPU. For example, device registers are written and read by the VCore-III
CPU, but they are also used by the device (which sees them in little endian mode). The VCore-III BSP
contains examples of code that correctly handles register access for both little and big endian mode.
Endianess of the CPU is selected by VCore-III strapping pins or by register configuration when manually
booting the CPU. For more information, see VCore-III configurations.
4.4.2
Software Debug and Development
The VCore CPU has a standard MIPS EJTAG debug interface that can be used for breakpoints, loading
of code, and examining memory. When the JTAG_ICE_nEN strapping pin is pulled low, the JTAG
interface is attached to the EJTAG controller.
4.5
External CPU Support
An external CPU attaches to the device through the PCIe, SI, MIIM, or VRAP. Through these interfaces,
an external CPU can access (and control) the device. For more information about interfaces and
connections to device registers, see VCore-III system block diagram.
Inbound PCIe access is performed on the VCore Shared Bus (SBA) in the same way as ordinary VCoreIII CPU access. By means of the switch core Access block it is possible to access the Switch Core
Register (CSR) bus. For more information about supported PCIe BAR regions, see PCIe Endpoint
Controller.
VMDS-10490 VSC7513 Datasheet Revision 4.2
165
VCore-III System and CPU Interfaces
The SI, MIIM, and VRAP interfaces attach directly to the CSR. Through the VCore SBA access block, it is
possible to access the VCore shared bus. For more information, see Access to the VCore Shared Bus.
The external CPU can coexist with the internal VCore-III CPU, and hardware-semaphores and interrupts
are implemented for inter-CPU communication. For more information, see Mailbox and Semaphores,
page 172.
4.5.1
Register Access and Multimaster Systems
There are three different groups of registers in the device:
•
•
•
Switch Core
Fast Switch Core
VCore
The Switch Core registers and Fast Switch Core registers are separated into individual register targets
and attached to the Switch Core Register bus (CSR). The Fast Switch Core registers are placed in the
DEVCPU_QS and DEVCPU_ORG register targets. Access to Fast Switch Core registers is less than
0.1 µs; other Switch Core registers take no more than 1 µs to access.
The VCore registers are attached directly to the VCore shared bus. The access time to VCore registers is
negligible (a few clock cycles).
Although multiple masters can access VCore registers and Switch Core registers in parallel without
noticeable penalty to the access time, the following exceptions apply.
•
•
•
When accessing the same Switch Core register target (for example, DEVCPU_GCB), the second
master to attempt access has to wait for the first master to finish (round robin arbitration applies.)
This does not apply to Fast Switch Core register targets (DEVCPU_QS and DEVCPU_ORG).
If both the VCore-IeVCore-III CPU and the PCIe master are performing Switch Core Register bus
(CSR) access, both need to be routed through the Switch Core Access block. The second master
has to wait for the first master to finish (shared bus arbitration applies).
If two or more SI, MIIM, or VRAP masters are performing VCore register access, they all need to go
through the VCore SBA Access block. Ownership has to be resolved by use of software (for
example, by using the built-in semaphores).
The most common multimaster scenario is with an active VCore-III CPU and an external CPU using
either SI or VRAP. In this case, Switch Core register access to targets that are used by both CPUs may
see two times the access time (no more than 2 µs).
4.5.2
Serial Interface in Slave Mode
This section provides information about the function of the serial interface in slave mode.
The following table lists the registers associated with SI slave mode.
Figure 58 • SI Slave Mode Register
Register
Description
DEVCPU_ORG::IF_CTRL
Configuration of endianess and bit order
DEVCPU_ORG::IF_CFGSTAT
Configuration of padding
ICPU_CFG::GENERAL_CTRL
SI interface ownership
The serial interface implements an SPI-compatible protocol that allows an external CPU to perform read
and write access to register targets within the device. Endianess and bit order is configurable, and
several options for high frequencies are supported.
The serial interface is available to an external CPU when the VCore-III CPU does not use the SI for Flash
or external SI access. For more information, VCore-III System and CPU interfaces.
VMDS-10490 VSC7513 Datasheet Revision 4.2
166
VCore-III System and CPU Interfaces
The following table lists the serial interface pins when the SI slave is configured as owner of SI interface
in GENERAL_CTRL.IF_SI_OWNER.
Table 132 • SI Slave Mode Pins
Pin Name
I/O
Description
SI_nCS0
I
Active-low chip select
SI_CLK
I
Clock input
SI_DI
I
Data input (MOSI)
SI_DO
O
Data output (MISO)
SI_DI is sampled on rising edge of SI_CLK. SI_DO is driven on falling edge of SI_CLK. There are no
requirements on the logical values of the SI_CLK and SI_DI inputs when SI_nCS is deasserted; they can
be either 0 or 1. SI_DO is only driven during read access when read data is shifted out of the device.
The external CPU initiates access by asserting chip select and then transmitting one bit read/write
indication, one don’t care bit, 22 address bits, and 32 bits of write data (or don’t care bits when reading).
With the register address of a specific register (REG_ADDR), the SI address (SI_ADDR) is calculated as:
SI_ADDR = (REG_ADDR & 0x00FFFFFF)>>2
Data word endianess is configured through IF_CTRL[0]. The order of the data bits is configured using
IF_CTRL[1].
The following illustration shows various configurations for write access. The order of the data bits during
writing, as depicted, is also used when the device is transmitting data during read operations.
Figure 59 • Write Sequence for SI
SI_nCS0
SI_CLK
Big endian mode (IF_CTRL[0]=1), Most significant bit first (IF_CTRL[1]=0)
2 2 1 1 1 1 1 1 1 1 1 1
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
9 8 7 6 5 4 3 2 1 0
9 8 7 6 5 4 3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
SI_DI
Serial Address (SI_ADDR)
Serial Data
SI_DO
Big endian mode (IF_CTRL[0]=1), Least significant bit first (IF_CTRL[1]=1)
1 1 1 1 1 1
2 2 1 1 1 1 1 1 1 1 1 1
2 2 2 2 2 2 3 3 1 1 1 1 2 2 2 2
0 1 2 3 4 5 6 7
9 8 7 6 5 4 3 2 1 0
8 9
0 1 2 3 4 5
1 0 9 8 7 6 5 4 3 2 1 0
4 5 6 7 8 9 0 1 6 7 8 9 0 1 2 3
SI_DI
Serial Address (SI_ADDR)
Serial Data
Little endian mode (IF_CTRL[0]=0), Most significant bit first (IF_CTRL[1]=0)
2 2 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1
2 2 2 2 1 1 1 1 3 3 2 2 2 2 2 2
9 8 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
9 8
1 0 9 8 7 6 5 4 3 2 1 0
5 4 3 2 1 0
3 2 1 0 9 8 7 6 1 0 9 8 7 6 5 4
SI_DI
Serial Address (SI_ADDR)
Serial Data
Little endian mode (IF_CTRL[0]=0), Least significant bit first (IF_CTRL[1]=1)
2 2 1 1 1 1 1 1 1 1 1 1
1 1 1 1 1 1 1 1 1 1 2 2 2 2 2 2 2 2 2 2 3 3
9 8 7 6 5 4 3 2 1 0 0 1 2 3 4 5 6 7 8 9
1 0 9 8 7 6 5 4 3 2 1 0
0 1 2 3 4 5 6 7 8 9 0 1 2 3 4 5 6 7 8 9 0 1
SI_DI
Serial Address (SI_ADDR)
Serial Data
When using the serial interface to read registers, the device needs to prepare read data after receiving
the last address bit. The access time of the register that is read must be satisfied before shifting out the
first bit of read data. For information about access time, see Register Access and Multimaster Systems.
The external CPU must apply one of the following solutions to satisfy read access time.
•
Use SI_CLK with a period of minimum twice the access time for the register target. For example, for
normal switch core targets (single master):
1/(2 × 1 µs) = 500 kHz (maximum)
VMDS-10490 VSC7513 Datasheet Revision 4.2
167
VCore-III System and CPU Interfaces
•
•
Pause the SI_CLK between shifting of serial address bit 0 and the first data bit with enough time to
satisfy the access time for the register target.
Configure the device to send out padding bytes before transmitting the read data to satisfy the
access time for the register target. For example, 1 dummy byte allows enough read time for the SI
clock to run up to 6 MHz in a single master system. See the following calculation.
The device is configured for inserting padding bytes by writing to IF_CFGSTAT.IF_CFG. These bytes are
transmitted before the read data. The maximum frequency of the SI clock is calculated as:
(IF_CFGSTAT.IF_CFG × 8 – 1.5)/access-time
For example, for normal switch core targets (single master), 1-byte padding give(1 × 8 – 1.5)
/1 µs = 6 MHz (maximum). The SI_DO output is kept tri-stated until the actual read data is transmitted.
The following illustrations show options for serial read access. The illustrations show only one mapping
of read data, little endian with most significant bit first. Any of the mappings can be configured and
applied to read data in the same way as for write data.
Figure 60 • Read Sequence for SI_CLK Slow
SI_nCS0
SI_CLK
Big endian mode (IF_CTRL[0]=1), Most significant bit first (IF_CTRL[1]=0), no padding (IF_CFGSTAT.IF_CFG=0)
SI_DI
2 2 1 1 1 1 1 1 1 1 1 1
9 8 7 6 5 4 3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0
Serial Address (SI_ADDR)
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
9 8 7 6 5 4 3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
SI_DO
Serial Data
Figure 61 • Read Sequence for SI_CLK Pause
SI_nCS0
pause
SI_CLK
Big endian mode (IF_CTRL[0]=1), Most significant bit first (IF_CTRL[1]=0), no padding (IF_CFGSTAT.IF_CFG=0)
SI_DI
2 2 1 1 1 1 1 1 1 1 1 1
9 8 7 6 5 4 3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0
Serial Address (SI_ADDR)
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
9 8 7 6 5 4 3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
SI_DO
Serial Data
Figure 62 • Read Sequence for One-Byte Padding
SI_nCS0
SI_CLK
Big endian mode (IF_CTRL[0]=1), Most significant bit first (IF_CTRL[1]=0), one-byte padding (IF_CFGSTAT.IF_CFG=1)
SI_DI
2 2 1 1 1 1 1 1 1 1 1 1
9 8 7 6 5 4 3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0
Serial Address (SI_ADDR)
3 3 2 2 2 2 2 2 2 2 2 2 1 1 1 1 1 1 1 1 1 1
9 8 7 6 5 4 3 2 1 0
1 0 9 8 7 6 5 4 3 2 1 0 9 8 7 6 5 4 3 2 1 0
SI_DO
padding (1 byte)
Serial Data
When dummy bytes are enabled (IF_CFGSTAT.IF_CFG), the SI slave logic enables an error check that
sends out 0x88888888 and sets IF_CFGSTAT.IF_STAT if the SI master does not provide enough time for
register read.
When using SI, the external CPU must configure the IF_CTRL register after power-up, reset, or chiplevel soft reset. The IF_CTRL register is constructed so that it can be written no matter the state of the
interface. For more information about constructing write data for this register, see the instructions in
IF_CTRL.IF_CTRL.
VMDS-10490 VSC7513 Datasheet Revision 4.2
168
VCore-III System and CPU Interfaces
4.5.3
MIIM Interface in Slave Mode
This section provides the functional aspects of the MIIM slave interface.
The MIIM slave interface allows an external CPU to perform read and write access to the device register
targets. Register access is done indirectly, because the address and data fields of the MIIM protocol is
less than those used by the register targets. Transfers on the MIIM interface are using the Management
Frame Format protocol specified in IEEE 802.3, Clause 22.
The MIIM slave pins on the device are overlaid functions on the GPIO interface. MIIM slave mode is
enabled by configuring the appropriate VCore_CFG strapping pins. For more information, see VCore-III
Configurations, page 160. When MIIM slave mode is enabled, the appropriate GPIO pins are
automatically overtaken. For more information about overlaid functions on the GPIOs for these signals,
see GPIO Overlaid Functions, page 205.
The following table lists the pins of the MIIM slave interface.
Table 133 • MIIM Slave Pins
Pin Name
I/O
Description
MIIM_SLV_MDC/GPIO
I
MIIM slave clock input
MIIM_SLV_MDIO/GPIO
I/O
MIIM slave data input/output
MIIM_SLV_MDIO is sampled or changed on the rising edge of MIIM_SLV_MDC by the MIIM slave
interface.
The MIIM slave can be configured to answer on one of two different PHY addresses using
ICPU_CFG::GENERAL_CTRL.IF_MIIM_SLV_ADDR_SEL or the VCore_CFG strapping pins.
The MIIM slave has seven 16-bit MIIM registers defined as listed in the following table.
Table 134 • MIIM Registers
Register Address
Register Name
Description
0
ADDR_REG0
Bits 15:0 of the address to read or write. The address
field must be formatted as word address.
1
ADDR_REG1
Bits 31:16 of the address to read or write.
2
DATA_REG0
Bits 15:0 of the data to read or write. Returns 0x8888 if
a register read error occurred.
3
DATA_REG1
Bits 31:16 of the data to read or write. The read or write
operation is initiated after this register is read or written.
Returns 0x8888 if read while busy or a register read
error occurred.
4
DATA_REG1_INCR
Bits 31:16 of data to read or write. The read or write
operation is initiated after this register is read or written.
When the operation is complete, the address register is
incremented by one. Returns 0x8888 if read while busy
or a register read error occurred.
5
DATA_REG1_INERT Bits 31:16 of data to read or write. Reading or writing to
this register does not cause a register access to be
initiated. Returns 0x8888 if a register read error
occurred.
VMDS-10490 VSC7513 Datasheet Revision 4.2
169
VCore-III System and CPU Interfaces
Table 134 • MIIM Registers (continued)
Register Address
Register Name
Description
6
STAT_REG
The status register gives the status of any ongoing
operations.
Bit 0: Busy. Set while a register read/write operation is
in progress.
Bit 1: Busy_rd. Busy status during the last read or write
operation.
Bit 2: Err. Set if a register access error occurred.
Others: Reserved.
A 32-bit switch core register read or write transaction over the MIIM interface is done indirectly due to the
limited data width of the MIIM frame. First, the address of the register inside the device must be set in the
two 16-bit address registers of the MIIM slave using two MIIM write transactions. The two 16-bit data
registers can then be read or written to access the data value of the register inside the device. Thus, it
requires up to four MIIM transactions to perform a single read or write operation on a register target.
The address of the register to read/write is set in registers ADDR_REG0 and ADDR_REG1. The data to
write to the register pointed to by the address in ADDR_REG0 and ADDR_REG1 is first written to
DATA_REG0 and then to DATA_REG1. When the write transaction to DATA_REG1 is completed, the
MIIM slave initiates the switch core register write.
With the register address of a specific register (REG_ADDR), the MIIM address (MIIM_ADDR) is
calculated as:
MIIM_ADDR = (REG_ADDR & 0x00FFFFFF)>>2
The following illustration shows a single MIIM write transaction on the MIIM interface.
Figure 63 • MIIM Slave Write Sequence
//
//
//
//
//
//
MDC
//
MDIO
1
0
1
0
1
//
//
PREAMBLE
32 bit
ST
2 bit
//
1
OP
2 bit
PHYAD
5 bit
0
//
//
REGAD
5 bit
TA
2 bit
DATA
16 bit
A read transaction is done in a similar way. First, read the DATA_REG0 and then read the DATA_REG1.
As with a write operation. The switch core register read is not initiated before the DATA_REG1 register is
read. In other words, the returned read value is from the previous read transaction.
The following illustration shows a single MIIM read transaction on the MIIM interface.
Figure 64 • MIIM Slave Read Sequence
MDC
MDIO
//
//
//
//
//
//
//
//
1
0
1
1
0
//
PREAMBLE
32 bit
ST
2 bit
OP
2 bit
//
//
Z
PHYAD
5 bit
REGAD
5 bit
0
//
TA
2 bit
VMDS-10490 VSC7513 Datasheet Revision 4.2
DATA
16 bit
170
VCore-III System and CPU Interfaces
4.5.4
Access to the VCore Shared Bus
This section provides information about how to access the VCore shared bus (SBA) from an external
CPU attached by means of the VRAP, SI, or MIIM. The following table lists the registers associated with
the VCore shared bus access.
Table 135 • VCore Shared Bus Access Registers
Register
Description
DEVCPU_GCB::VA_CTRL
Status for ongoing access
DEVCPU_GCB::VA_ADDR
Configuration of shared bus address
DEVCPU_GCB::VA_DATA
Configuration of shared bus address
DEVCPU_GCB::VA_DATA_INCR
Data register, access increments VA_ADDR
DEVCPU_GCB::VA_DATA_INERT
Data register, access does not start new access
An external CPU perform 32-bit reads and writes to the SBA through the VCore Access (VA) registers. In
the VCore-III system, a dedicated master on the shared bus handles VA access. For information about
arbitration between masters on the shared bus, see VCore Shared Bus Arbitration.
The SBA address is configured in VA_ADDR. Writing to VA_DATA starts an SBA write with the 32-bit
value that was written to VA_DATA. Reading from VA_DATA returns the current value of the register and
starts an SBA read access, when the read access completes, the result is automatically stored in the
VA_DATA register.
The VA_DATA_INCR register behaves similar to VA_DATA, except that after starting an access, the
VA_ADDR register is incremented by four (so that it points to the next word address in the SBA domain).
Reading from the VA_DATA_INCR register returns the value of VA_DATA, writing to VA_DATA_INCR
overwrites the value of VA_DATA.
Note By using VA_DATA_INCR, sequential word addresses can be accessed without having to
manually increment the VA_ADDR register between each access.
The VA_DATA_INERT register provides direct access to the VA_DATA value without starting access on
the SBA. Reading from the VA_DATA_INERT register returns the value of VA_DATA, writing to
VA_DATA_INERT overwrites the value of VA_DATA.
The VCore-III shared bus is capable of returning error-indication when illegal register regions are
accessed. If a VA access results in an error-indication from the SBA, the VA_CTRL.VA_ERR field is set,
and the VA_DATA is set to 0x88888888.
Note SBA error indications only occur when non-existing memory regions or illegal registers are
accessed. This will not happen during normal operation, so the VA_CTRL.VA_ERR indication is useful
during debugging only.
Example Reading from ICPU_CFG::GPR[1] through the VA registers. The GPR register is the second
register in the SBA VCore-III Registers region. Set VA_ADDR to 0x70000004, read once from VA_DATA
(and discard the read value). Wait until VA_CTRL.VA_BUSY is cleared, then VA_DATA contains the
value of the ICPU_CFG::GPR[1] register. Using VA_DATA_INERT (instead of VA_DATA) to read the data
is appropriate, because this does not start a new SBA access.
4.5.4.1
Optimized Reading
VCore-III shared bus access is typically much faster than the CPU interface, which is used to access the
VA registers. The VA_DATA register (VA_DATA_INCR and VA_DATA_INERT) return 0x88888888 while
VA_CTRL.VA_BUSY is set. This means that it is possible to skip checking for busy between read access
to SBA. For example, after initiating a read access from SBA, software can proceed directly to reading
from VA_DATA, VA_DATA_INCR, or VA_DATA_INERT
•
If the second read is different from 0x88888888, then the second read returned valid read data (the
SBA access was done before the second read was performed).
VMDS-10490 VSC7513 Datasheet Revision 4.2
171
VCore-III System and CPU Interfaces
•
If the second read is equal to 0x88888888, then the VA logic may have been busy during the read
and additional actions are required: First read the VA_CTRL.VA_BUSY field until the field is cleared
(VA logic is not busy). Then read VA_DATA_INERT. If VA_DATA_INERT returns 0x88888888, then
read-data is actually 0x88888888, continue to the next read. Otherwise, repeat the last read from
VA_DATA, VA_DATA_INCR, or VA_DATA_INERT and then continue to the next read from there.
Optimized reading can be used for single read and sequential read access. For sequential reads, the
VA_ADDR is only incremented on successful (non-busy) reads.
4.5.5
Mailbox and Semaphores
This section provides information about the semaphores and mailbox features for CPU to CPU
communication. The following table lists the registers associated with mailbox and semaphores.
Table 136 • Mailbox and Semaphore Registers
Register
Description
DEVCPU_ORG::MAILBOX_SET
Atomic set of bits in the mailbox register.
DEVCPU_ORG::MAILBOX_CLR
Atomic clear of bits in the mailbox register.
DEVCPU_ORG::MAILBOX
Current mailbox state.
DEVCPU_ORG::SEMA_CFG
Configuration of semaphore interrupts.
DEVCPU_ORG::SEMA0
Taking of semaphore 0.
DEVCPU_ORG::SEMA1
Taking of semaphore 1.
DEVCPU_ORG::SEMA0_OWNER
Current owner of semaphore 0.
DEVCPU_ORG::SEMA1_OWNER
Current owner of semaphore 1.
The mailbox is a 32-bit register that can be set and cleared atomically using any CPU interface (including
the VCore-III CPU). The MAILBOX register allows reading (and writing) of the current mailbox value.
Atomic clear of individual bits in the mailbox register is done by writing a mask to MAILBOX_CLR. Atomic
setting of individual bits in the mailbox register is done by writing a mask to MAILBOX_SET.
The device implements two independent semaphores. The semaphores are part of the Switch Core
Register Bus (CSR) block and are accessible by means of the fast switch core registers. Semaphore
ownership can be taken by interfaces attached to the CSR. That is, the VCore-III, VRAP, SI, and MIIM
can be granted ownership. The VCore-IeVCore-III CPU and PCIe interface share the same semaphore,
because they both access the CSR through the switch core access block.
Any CPU attached to an interface can attempt to take a semaphore n by reading SEMA0.SEMA0 or
SEMA1.SEMA1. If the result is 1, the corresponding semaphore was successfully taken and is now
owned by that interface. If the result is 0, the semaphore was not free. After successfully taking a
semaphore, all additional reads from the corresponding register will return 0. To release a semaphore,
write 1 to SEMA0.SEMA0 or SEMA1.SEMA1.
Note Any interface can release semaphores; it does not have to be the one that has taken the
semaphore. This allows implementation of handshaking protocols.
The current status for a semaphore is available in SEMA0_OWNER.SEMA0_OWNER and
SEMA1_OWNER.SEMA1_OWNER. See register description for encoding of owners.
Software interrupt is generated when semaphores are free or taken. Interrupt polarity is configured
through SEMA_CFG.SEMA_INTR_POL. Semaphore 0 is hooked up to SW0 interrupt and semaphore 1
is hooked up to SW1 interrupt. For configuration of software-interrupt, see Interrupt Controller.
In addition to interrupting on semaphore state, software interrupt can be manually triggered by writing
directly to the ICPU_CFG::INTR_FORCE register.
Software interrupts (SW0 and SW1) can be individually mapped to either the VCore-III CPU or to
external interrupt outputs (to an external CPU).
VMDS-10490 VSC7513 Datasheet Revision 4.2
172
VCore-III System and CPU Interfaces
4.6
PCIe Endpoint Controller
The device implements a single-lane PCIe 1.x endpoint that can be hooked up to any PCIe capable
system. Using the PCIe interface, an external CPU can access (and control) the device. Ethernet frames
can be injected and extracted using registers or the device can be configured to DMA Ethernet frames
autonomously to/from PCIe memory. The device’s DDR3/DDR3L memory is available through the PCIe
interface, allowing the external CPU full read and write access to DDR3/DDR3L modules attached to the
device. The DDR3/DDR3L controller and memory modules can be initialized either via PCIe or by the
VCore-III CPU.
Both the VCore-III CPU and Frame DMA can generate PCIe read/write requests to any 32-bit or 64-bit
memory region in PCIe memory space. However, it is up to software running on an external CPU to set
up or communicate the appropriate PCIe memory mapping information to the device.
The defaults for the endpoints capabilities region and the extended capabilities region are listed in the
registers list’s description of the PCIE registers. The most important parameters are:
•
•
•
•
•
Vendor (and subsystem vendor) ID: 0x101B, Microsemi
Device ID: 0xB005, device family ID
Revision ID: 0x00, device family revision ID
Class Code: 0x028000, Ethernet Network controller
Single function, non-Bridge, INTA and Message Signaled Interrupt (MSI) capable device
The device family 0xB005 covers several register-compatible devices. The software driver must
determine actual device ID and revision by reading DEVCPU_GCB::CHIP_ID from the device’s memory
mapped registers region.
For information about base address registers, see Base Address Registers, Inbound Requests.
The IDs, class code, revision ID, and base address register setups can be customized before enabling
the PCIe endpoint. However, it requires a manual bring-up procedure by software running locally on the
VCore-III CPU. For more information, see Enabling the Endpoint.
The endpoint is power management capable and implements PCI Bus Power Management Interface
Specification Revision 1.2. For more information, see Power Management.
The endpoint is MSI capable. Up to four 64-bit messages are supported. Messages can be generated on
rising and falling edges of each of the two external VCore-III interrupt destinations. For more information,
see Outbound Interrupts.
For information about all PCI Express capabilities and extended capabilities register defaults, see the
PCIE region’s register descriptions.
4.6.1
Accessing Endpoint Registers
The root complex accesses the PCIe endpoint’s configuration registers by PCIe CfgRd/CfgWr requests.
The VCore-III CPU can read configuration registers by means of the PCIE region. For more information,
see Chip Register Region. The PCIE region must not be accessed when the PCIe endpoint is disabled.
The PCIe region is used during manual bring-up of PCIe endpoint. By using this region, it is possible to
write most of the endpoint’s read-only configuration registers, such as Vendor ID. The PCIe endpoint’s
read-only configuration register values must not be changed after the endpoint is enabled.
The VCore-III has a few dedicated PCIe registers in the ICPU_CFG:PCIE register group. An external
CPU attached through the PCIe interface has to go through BAR0 to reach these registers.
4.6.2
Enabling the Endpoint
The PCIe endpoint is disabled by default. It can be enabled automatically or manually by either setting
the VCore_CFG strapping pins or by software running in the VCore-III CPU.
The recommended approach is using VCore_CFG strapping pins, because it is fast and does not require
special software running on the VCore-III CPU. The endpoint is ready approximately 50 ms after release
of the device’s nRESET. Until this point, the device ignores any attempts to do link training, and the PCIe
output remains idle (tri-stated).
VMDS-10490 VSC7513 Datasheet Revision 4.2
173
VCore-III System and CPU Interfaces
By using software running on the VCore-III CPU, it is possible to manually start the PCIe endpoint. Note
that PCIe standard specifies a maximum delay from nRESET release to working PCIe endpoint so
software must enable the endpoint as part of the boot process.
The root complex must follow standard PCIe procedures for bringing up the endpoint.
4.6.2.1
Manually Starting MAC/PCS and SerDes
This section provides information about how to manually start up the PCIe endpoint and customize
selected configuration space parameters.
The following table lists the registers related to manually bringing up PCIe.
Table 137 • Manual PCIe Bring-Up Registers
Register
Description
ICPU_CFG::PCIE_CFG
Disable of automatic link initialization
HSIO::SERDES6G_COMMON_CFG
SERDES configuration
HSIO::SERDES6G_MISC_CFG
SERDES configuration
HSIO::SERDES6G_IB_CFG
SERDES configuration
HSIO::SERDES6G_IB_CFG1
SERDES configuration
HSIO::SERDES6G_OB_CFG
SERDES configuration
HSIO::SERDES6G_OB_CFG1
SERDES configuration
HSIO::SERDES6G_DES_CFG
SERDES configuration
HSIO::SERDES6G_PLL_CFG
SERDES configuration
HSIO::SERDES6G_MISC_CFG
SERDES configuration
HSIO::MCB_SERDES6G_ADDR_CFG
SERDES configuration
PCIE::DEVICE_ID_VENDOR_ID,
PCIE::CLASS_CODE_REVISION_ID,
PCIE::SUBSYSTEM_ID_SUBSYSTEM_VENDOR_ID
Device parameter customization
PCIE::BAR1, PCIE::BAR2
Base address register customization
Disable automatic link training for PICe endpoint.
1.
PCIE_CFG.LTSSM_DIS = 1.
Configure and enable PCIe SERDES for 2G5 mode.
1.
2.
3.
4.
5.
6.
7.
8.
9.
10.
11.
12.
13.
14.
15.
16.
17.
18.
SERDES6G_MISC_CFG = 0x00000031.
SERDES6G_OB_CFG = 0x60000171.
SERDES6G_OB_CFG1 = 0x000000B0.
SERDES6G_DES_CFG = 0x000068A6.
SERDES6G_IB_CFG = 0x3D57AC37.
SERDES6G_IB_CFG1 = 0x00110FF0.
SERDES6G_COMMON_CFG = 0x00024009.
MCB_SERDES6G_ADDR_CFG = 0x80000004 and wait until bit 31 is cleared.
SERDES6G_PLL_CFG = 0x00030F20.
MCB_SERDES6G_ADDR_CFG = 0x80000004 and wait until bit 31 is cleared.
Wait at least 20 ms.
SERDES6G_IB_CFG = 0x3D57AC3F.
SERDES6G_MISC_CFG = 0x00000030.
MCB_SERDES6G_ADDR_CFG = 0x80000004 and wait until bit 31 is cleared.
Wait at least 60 ms.
SERDES6G_IB_CFG = 0x3D57ACBF.
SERDES6G_IB_CFG1 = 0x00103FF0.
MCB_SERDES6G_ADDR_CFG = 0x80000004 and wait until bit 31 is cleared.
VMDS-10490 VSC7513 Datasheet Revision 4.2
174
VCore-III System and CPU Interfaces
To optionally disable BAR1:
1.
2.
3.
PCIE_CFG.PCIE_BAR_WR_ENA = 1
BAR1 = 0x00000000
PCIE_CFG.PCIE_BAR_WR_ENA = 0
To optionally increase BAR2 from 128 to 256 megabytes:
1.
2.
3.
PCIE_CFG.PCIE_BAR_WR_ENA = 1
BAR2 = 0x0FFFFFFF
PCIE_CFG.PCIE_BAR_WR_ENA = 0
To optionally change selected PCIe configuration space values:
•
•
•
Write Vendor ID/Device ID using DEVICE_ID_VENDOR_ID.
Write Class Code/Revision ID using CLASS_CODE_REVISION_ID.
Write Subsystem ID/Subsystem Vendor ID using SUBSYSTEM_ID_SUBSYSTEM_VENDOR_ID.
Enable automatic link training for PCIe endpoint
1.
PCIE_CFG.LTSSM_DIS = 0
The last step enables the endpoint for link training, and the root complex will then be able to initialize the
PCIe endpoint. After this the PCIE parameters must not be changed anymore.
4.6.3
Base Address Registers Inbound Requests
The device implements three memory regions. Read and write operations using the PCIe are translated
directly to read and write access on the SBA. When manually bringing up the PCIe endpoint, BAR1 can
be disabled. For more information, see Manually Starting MAC/PCS and SerDes.
Table 138 • Base Address Registers
Register
Description
BAR0, 32-bit, 32 megabytes
Chip registers region. This region maps to the Chip registers
region in the SBA address space. See Chip Register Region.
This region only supports 32-bit word-aligned reads and
writes. Single and burst accesses are supported.
BAR1, 32-bit, 16 megabytes
SI Flash region. This region maps to the SI Flash region in the
SBA address space. See SI Flash Region.
This region only supports 32-bit word-aligned reads. Single
and burst access is supported.
BAR2, 32-bit, 128 megabytes
DDR3/DDR3L region. This region maps to the low 128
megabytes of the DDR3/DDR3L region in the SBA address
space. See DDR3/DDR3L Region.
This region supports all access types.
To access the BAR1 region, a Flash must be attached to the SI interface of the device. For information
about how to set up I/O timing and to program the Flash through BAR0; the Chip Registers Region, see
SI Boot Controller, page 187.
To access the BAR2 region, DDR3/DDR3L modules must be present and initialized. For information
about initializing the DDR3/DDR3L controller and modules through BAR0; the Chip Registers, see
DDR3/DDR3L Memory Controller. During manual bring up of PCIe, the size of the BAR2 region can be
changed to match the size of the attached DDR3/DDR3L modules. For more information, see Manually
Starting MAC/PCS and SerDes.
4.6.4
Outbound Interrupts
The device supports both Message Signaled Interrupt (MSI) and Legacy PCI Interrupt Delivery. The root
complex configures the desired mode using the MSI enable bit in the PCIe MSI Capability Register Set.
For information about the VCore-III interrupt controller, see Interrupt Controller, page 217.
VMDS-10490 VSC7513 Datasheet Revision 4.2
175
VCore-III System and CPU Interfaces
The following table lists the device registers associated PCIe outbound interrupts.
Table 139 • PCIe Outbound Interrupt Registers
Register
Description
ICPU_CFG::PCIE_INTR_COMMON_CFG Interrupt mode and enable
ICPU_CFG::PCIE_INTR_CFG
MSI parameters
In legacy mode, one interrupt is supported; select either EXT_DST0 or EXT_DST1 using
PCIE_INTR_COMMON_CFG.LEGASY_MODE_INTR_SEL. The PCIe endpoint uses Assert_INTA and
Deassert_INTA messages when configured for legacy mode.
In MSI mode, both EXT_DST interrupts can be used. EXT_DST0 is configured though
PCIE_INTR_CFG[0] and EXT_DST1 through PCIE_INTR_CFG[1]. Enable message generation on rising
and/or falling edges in PCIE_INTR_CFG[n].INTR_RISING_ENA and
PCIE_INTR_CFG[n].INTR_FALLING_ENA. Different vectors can be generated for rising and falling
edges, configure these through PCIE_INTR_CFG[n].RISING_VECTOR_VAL and
PCIE_INTR_CFG[n].FALLING_VECTOR_VAL. Finally, each EXT_DST interrupt must be given an
appropriate traffic class through PCIE_INTR_CFG[n].TRAFFIC_CLASS.
After the root complex has configured the PCIe endpoint’s MSI Capability Register Set and the external
CPU has configured how interrupts from the VCore-III interrupt controller are propagated to PCIe,
interrupts must then be enabled by setting PCIE_INTR_COMMON_CFG.PCIE_INTR_ENA.
4.6.5
Outbound Access
After the PCIe endpoint is initialized, outbound read/write access to PCIe memory space is initiated by
reading or writing the SBA’s PCIe DMA region.
The following table lists the device registers associated with PCIe outbound access.
Table 140 • Outbound Access Registers
Register
Description
ICPU_CFG::PCIESLV_SBA
Configures SBA outbound requests.
ICPU_CFG::PCIESLV_FDMA
Configures FDMA outbound requests.
PCIE::ATU_REGION
Select active region for the ATU_* registers.
PCIE::ATU_CFG1
Configures TLP fields.
PCIE::ATU_CFG2
Enable address translation.
PCIE::ATU_TGT_ADDR_LOW
Configures outbound PCIe address.
PCIE::ATU_TGT_ADDR_HIGH Configures outbound PCIe address.
The PCIe DMA region is 1 gigabyte. Access in this region is mapped to any 1 gigabyte region in 32-bit or
64-bit PCIe memory space by using address translation. Two address translation regions are supported.
The recommended approach is to configure the first region for SBA outbound access and the second
region for FDMA outbound access.
Address translation works by taking bits [29:0] from the SBA/FDMA address, adding a configurable
offset, and then using the resulting address to access into PCIe memory space. Offsets are configurable
in steps of 64 kilobytes in the ATU_TGT_ADDR_HIGH and ATU_TGT_ADDR_LOW registers.
The software on the VCore-III CPU (or other SBA masters) can dynamically reconfigure the window as
needed; however, the FDMA does not have that ability, so it must be disabled while updating the 1
gigabyte window that is set up for it.
Note Although the SBA and FDMA both access the PCIe DMA region by addresses 0xC0000000
though 0xFFFFFFFF, the PCIe address translation unit can differentiate between these accesses and
apply the appropriate translation.
VMDS-10490 VSC7513 Datasheet Revision 4.2
176
VCore-III System and CPU Interfaces
4.6.5.1
Configuring Outbound SBA Translation Region
Configure PCIESLV_SBA.SBA_OFFSET = 0 and select address translation region 0 by writing
ATU_REGION.ATU_IDX = 0. Set PCIE::ATU_BASE_ADDR_LOW.ATU_BASE_ADDR_LOW = 0x0000
and PCIE::ATU_LIMIT_ADDR.ATU_LIMIT_ADDR = 0x3FFF.
The following table lists the appropriate PCIe headers that must be configured before using the SBA’s
PCIe DMA region. Remaining header fields are automatically handled.
Table 141 • PCIe Access Header Fields
Header Field
Register::Fields
Attributes
ATU_CFG1.ATU_ATTR
Poisoned Data
PCIESLV_SBA.SBA_EP
TLP Digest Field Present
ATU_CFG1.ATU_TD
Traffic Class
ATU_CFG1.ATU_TC
Type
ATU_CFG1.ATU_TYPE
Byte Enables
PCIESLV_SBA.SBA_BE
Message Code
ATU_CFG2.ATU_MSG_CODE
Configure the low address of the destination window in PCIe memory space as follows:
•
•
Set ATU_TGT_ADDR_HIGH.ATU_TGT_ADDR_HIGH to bits [63:32] of the destination window. Set
to 0 when a 32-bit address must be generated.
Set ATU_TGT_ADDR_LOW.ATU_TGT_ADDR_LOW to bits [31:16] of the destination window. This
field must not be set higher than 0xC000.
Enable address translation by writing ATU_CFG2.ATU_REGION_ENA = 1. SBA access in the PCIe
DMA region is then mapped to PCIe memory space as defined by ATU_TGT_ADDR_LOW and
ATU_TGT_ADDR_HIGH.
The header fields and the PCIe address fields can be reconfigured on-the-fly as needed; however, set
ATU_REGION.ATU_IDX to 0 to ensure that the SBA region is selected.
4.6.5.2
Configuring Outbound FDMA Translation Region
Configure PCIESLV_FDMA.FDMA_OFFSET = 1, and select address translation region 1 by writing
ATU_REGION.ATU_IDX = 1.
Set PCIE::ATU_BASE_ADDR_LOW.ATU_BASE_ADDR_LOW = 0x4000 and
PCIE::ATU_LIMIT_ADDR.ATU_LIMIT_ADDR = 0x7FFF.
The FDMA PCIe header must be MRd/MWr type, reorderable, cache-coherent, and without ECRC.
Remaining header fields are automatically handled.
Table 142 • FDMA PCIe Access Header Fields
Header Field
Register::Fields
Suggested Value
Attributes
ATU_CFG1.ATU_ATTR
Set to 2
TLP Digest Field Present
ATU_CFG1.ATU_TD
Set to 0
Traffic Class
ATU_CFG1.ATU_TC
Use an appropriate traffic class
Type
ATU_CFG1.ATU_TYPE
Set to 0
Configure low address of destination window in PCIe memory space as follows:
•
Set ATU_TGT_ADDR_HIGH.ATU_TGT_ADDR_HIGH to bits [63:32] of the destination window. Set
to 0 when a 32-bit address must be generated.
VMDS-10490 VSC7513 Datasheet Revision 4.2
177
VCore-III System and CPU Interfaces
•
Set ATU_TGT_ADDR_LOW.ATU_TGT_ADDR_LOW to bits [31:16] of the destination window. This
field must not be set higher than 0xC000.
Enable address translation by writing ATU_CFG2.ATU_REGION_ENA = 1. The FDMA can be
configured to make access in the 0xC0000000 - 0xFFFFFFFF address region. These accesses will then
be mapped to PCIe memory space as defined by ATU_TGT_ADDR_LOW and ATU_TGT_ADDR_HIGH.
The FDMA must be disabled if the address window needs to be updated.
4.6.6
Power Management
The device’s PCIe endpoint supports D0, D1, and D3 device power-management states and associated
link power-management states. The switch core does not automatically react to changes in the PCIe
endpoint’s power management states. It is, however, possible to enable a VCore-III interrupt on device
power state changes and then have the VCore-III CPU software make application-specific changes to
the device operation depending on the power management state.
Table 143 • Power Management Registers
Register
Description
ICPU_CFG::PCIE_STAT
Current power management state
ICPU_CFG::PCIEPCS_CFG
Configuration of WAKE output and beacon
ICPU_CFG::PCIE_INTR
PCIe interrupt sticky events
ICPU_CFG::PCIE_INTR_ENA
Enable of PCIe interrupts
ICPU_CFG::PCIE_INTR_IDENT
Currently interrupting PCIe sources
ICPU_CFG::PCIE_AUX_CFG
Configuration of auxiliary power detection
Because the device does not implement a dedicated auxiliary power for the PCIe endpoint, the endpoint
is operated from the VDD core power supply. Before the power management driver initializes the device,
software can “force” auxiliary power detection by writing PCIE_AUX_CFG = 3, which causes the
endpoint to report that it is capable of emitting Power Management Events (PME) messages in the D3c
state.
The current device power management state is available using PCIE_STAT.PM_STATE. A change in this
field’s value sets the PCIE_INTR.INTR_PM_STATE sticky bit. To enable this interrupt, set
PCIE_INTR_ENA.INTR_PM_STATE_ENA. The current state of the PCIe endpoint interrupt towards the
VCore-III interrupt controller is shown in PCIE_INTR_IDENT register (if different from zero, then interrupt
is active).
The endpoint can emit PMEs if the PME_En bit is set in the PM Capability Register Set and if the
endpoint is in power-down mode.
•
•
Outbound request from either SBA or FDMA trigger PME.
A change in status for an enabled outbound interrupt (either legacy or MSI) triggers PME. This
feature can be disabled by setting
ICPU_CFG::PCIE_INTR_COMMON_CFG.WAKEUP_ON_INTR_DIS.
In the D3 state, the endpoint transmits a beacon. The beacon function can be disabled and instead drive
the WAKE output using the overlaid GPIO function. For more information about the overlaid function on
the GPIO for this signal, see GPIO Overlaid Functions, page 205.
Table 144 • PCIe Wake Pin
Pin Name
I/O
Description
PCIe_WAKE/GPIO
O
PCIe WAKE output
Enable WAKE by setting PCIEPCS_CFG.BEACON_DIS. The polarity of the WAKE output is configured
in PCIEPCS_CFG.WAKE_POL. The drive scheme is configured in PCIEPCS_CFG.WAKE_OE.
VMDS-10490 VSC7513 Datasheet Revision 4.2
178
VCore-III System and CPU Interfaces
4.6.7
Device Reset Using PCIe
The built-in PCIe reset mechanism in the PCIe endpoint resets only the PCIe MAC. The device reset is
not tied into the MAC reset. To reset the complete the device, use the following procedure.
1.
2.
3.
4.
Save the state of the PCIe controller registers using operating system.
Set DEVCPU_GCB::SOFT_RST.SOFT_CHIP_RST.
Wait for 100 ms.
Recover state of PCIe controller registers using operating system.
Setting SOFT_CHIP_RST will cause re-initialization of the device.
4.7
Frame DMA
This section describes the Frame DMA engine (FDMA). When FDMA is enabled, Ethernet frames can be
extracted or injected autonomously to or from the device’s DDR3/DDR3L memory and/or PCIe memory
space. Linked list data structures in memory are used for injecting or extracting Ethernet frames. The
FDMA generates interrupts when frame extraction or injection is done and when the linked lists needs
updating.
Table 145 • FDMA Registers
Register
Description
DEVCPU_QS::XTR_GRP_CFG
CPU port ownership, extraction direction.
DEVCPU_QS::INJ_GRP_CFG
CPU port ownership, injection direction.
DEVCPU_QS::INJ_CTRL
Injection EOF to SOF spacing.
SYS::PORT_MODE
Enables IFH and disables FCS recalculation (for
injected frames).
ICPU_CFG::FDMA_CH_CFG
Channel configuration, priorities, and so on.
ICPU_CFG::FDMA_CH_ACTIVATE
Enables channels.
ICPU_CFG::FDMA_CH_DISABLE
Disables channels.
ICPU_CFG::FDMA_CH_STAT
Status for channels.
ICPU_CFG::FDMA_CH_SAFE
Sets when safe to update channel linked lists.
ICPU_CFG::FDMA_DCB_LLP
Linked list pointer for channels.
ICPU_CFG::FDMA_DCB_LLP_PREV
Previous linked list pointer for channels.
ICPU_CFG::FDMA_CH_CNT
Software counters for channels.
ICPU_CFG::FDMA_INTR_LLP
NULL pointer event for channels.
ICPU_CFG::FDMA_INTR_LLP_ENA
Enables interrupt on NULL pointer event.
ICPU_CFG::FDMA_INTR_FRM
Frame done event for channels.
ICPU_CFG::FDMA_INTR_FRM_ENA
Enables interrupt on frame done event.
ICPU_CFG::FDMA_INTR_SIG
SIG counter incremented event for channels.
ICPU_CFG::FDMA_INTR_SIG_ENA
Enables interrupt on SIG counter event.
ICPU_CFG::MANUAL_INTR
Manual injection/extraction events.
ICPU_CFG::MANUAL_INTR_ENA
Enables interrupts on manual injection/extraction
events.
ICPU_CFG::FDMA_EVT_ERR
Error event for channels.
ICPU_CFG::FDMA_EVT_ERR_CODE
Error event description.
ICPU_CFG::FDMA_INTR_ENA
Enables interrupt for channels.
ICPU_CFG::FDMA_INTR_IDENT
Currently interrupting channels.
VMDS-10490 VSC7513 Datasheet Revision 4.2
179
VCore-III System and CPU Interfaces
Table 145 • FDMA Registers (continued)
Register
Description
DEVCPU_QS::XTR_FRM_PRUNING
Enables pruning of extraction frames.
ICPU_CFG::FDMA_CH_INJ_TOKEN_CNT
Injection tokens.
ICPU_CFG::FDMA_CH_INJ_TOKEN_TICK_RLD
Periodic addition of injection tokens.
ICPU_CFG::MANUAL_CFG
Configures manual injection/extraction.
ICPU_CFG::MANUAL_XTR
Memory region used for manual extraction.
ICPU_CFG::MANUAL_INJ
Memory region used for manual injection.
ICPU_CFG::FDMA_GCFG
Configures injection buffer watermark.
The FDMA implements two extraction channels per CPU port and a total of eight injection channels.
Extraction channels are hard-coded per CPU port, and injection channels can be individually assigned to
any CPU port.
•
•
•
•
FDMA channel 0 corresponds to port 11(group 0) extraction direction.
FDMA channel 1 corresponds to port 12(group 1) extraction direction.
FDMA channel 2 through 9 corresponds to port 11 (group 0) injection direction when
FDMA_CH_CFG[channel].CH_INJ_GRP is set to 0.
FDMA channel 2 through 9 corresponds to port 12 (group 1) injection direction when
FDMA_CH_CFG[channel].CH_INJ_GRP is set to 1.
The FDMA implements a strict priority scheme. Injection and extraction channels can be assigned
individual priorities, which are used when the FDMA has to decide between servicing two or more
channels. Channel priority is configured in FDMA_CH_CFG[ch].CH_PRIO. When channels have same
priority, the higher channel number takes priority over the lower channel number.
When more than one injection channel is enabled for injection on the same CPU port, then priority
determines which channel that is allowed to inject data. Ownership is re-arbitrated on frame boundaries.
The internal frame header is added in front of extracted frames and provides useful switching information
about the extracted frames.
Injection frames requires an internal frame header for controlling injection parameters. The internal frame
header is added in front of frame data. The device recalculates and overwrites the Ethernet FCS for
frames that are injected through the CPU when requested by setting in the internal frame header.
For more information about the extraction and injection IFH, see CPU Port Module, page 141.
The FDMA supports a manual mode where the FDMA decision logic is disabled and the FDMA takes and
provides data in the order that was requested by an external master (internal or external CPU). The
manual mode is a special case of normal FDMA operation where only few of the FDMA features apply.
For more information about manual operation, see Manual Mode.
The following configuration must be performed before enabling FDMA extraction: Set
XTR_GRP_CFG[group].MODE = 2.
The following configurations must be performed before enabling FDMA injection:
Set INJ_GRP_CFG[group].MODE = 2. Set INJ_CTRL[group].GAP_SIZE = 0,
set PORT_MODE[port].INCL_INJ_HDR = 1.
4.7.1
DMA Control Block Structures
The FDMA processes linked lists of DMA Control Block Structures (DCBs). The DCBs have the same
basic structure for both injection or for extraction. A DCB must be placed on a 32-bit word-aligned
address in memory. Each DCB must have an associated data block that is placed on a 32-bit word
aligned address in memory, the length of the data block must be a complete number of 32-bit words.
An Ethernet frame can be contained inside one data block (if the data block is big enough) or the frame
can be spread across multiple data blocks. A data block never contains more than one Ethernet frame.
VMDS-10490 VSC7513 Datasheet Revision 4.2
180
VCore-III System and CPU Interfaces
Data blocks that contain start-of-frame have set a special bit in the DCB’s status word, likewise for data
blocks that contains end of frame. The FDMA stores or retrieves Ethernet frame data in network order.
This means that the data at byte address (n) of a frame was received just before the data at byte address
(n + 1).
Frame data inside the DCB’s associated data blocks can be placed at any byte offset and have any byte
length as long as byte offset and length does not exceed the size of the data block. Byte offset and length
is configured using special fields inside the DCB status word. Software can specify offset both when
setting up extraction and injection DCBs. Software only specifies length for injection DCBs; the FDMA
automatically calculates and updates length for extraction.
Example If a DCB’s status word has block offset 5 and block length 2, then the DCB’s data block
contains two bytes of frame data placed at second and third bytes inside the second 32-bit word of the
DCB’s associated data block.
DCBs are linked together by the DCB’s LLP field. The last DCB in a chain must have LLP = NULL.
Chains consisting of a single DCB are allowed.
Figure 65 • FDMA DCB Layout
word-address n
LLP [31:0]: Linked List Pointer, this field points to the next DCB in the list, set to NULL for
end of list. DCBs must be word-aligned, which means LLP must point to a word-aligned
address (bit [1:0] = 00).
LLP
n+1
DATAP [31:0]: Data block pointer, this field points to the data block associated with this
DCB. DATAP must be !=NULL and must point to a word-aligned address (bit [1:0] = 00).
DATAP
n+2
[31:24]: For SW
use. FDMA will not
modify.
n+3
[23:18]:
Must be 0.
17 16
BLOCKO [31:20]: Byte offset
from beginning of the data block 19 18 17 16
to the first byte of frame-data.
DATAL [15:0]: Number of bytes available in
the data block associated with this DCB.
DATAL must be a complete number of words
(bit [1:0] = 00).
BLOCKL [15:0]: Number of frame-data
bytes in the data block. BLOCKL does not
include offset bytes.
DATAL
STAT
STAT[16] SOF: Set to 1 if data block contains start of frame.
STAT[17] EOF: Set to 1 if data block contains end of frame.
STAT[18] ABORT: Abort indication.
Extraction: Set to 1 if the frame associated with the data block was aborted.
Injection: If set to 1 when FDMA loads the DCB, it aborts the frame associated with the data block.
STAT[19] PD: Pruned/Done indication.
Extraction: Set to 1 if the frame associated with the data block was pruned.
Injection: The FDMA set this to 1 when done processing the DCB. If set to 1 when FDMA loads the DCB, it
is treated as ABORT.
DATAL[16] SIG: If set to 1 when FDMA loads the DCB, the CH_CNT_SIG counter is incremented by one.
DATAL[17] TOKEN: Token indication, only used during injection.
If set to 1, the FDMA uses one token (CH_INJ_TOKEN_CNT) when injecting the contents of the DCB. If the
token counter is 0 when loading the DCB, then injection is postponed until tokens are made available.
4.7.2
Enabling and Disabling FDMA Channels
To enable a channel (ch), write a valid DCB pointer to FDMA_DCB_LLP[ch] and enable the channel by
setting FDMA_CH_ACTIVATE.CH_ACTIVATE[ch]. This makes the FDMA load the DCB from memory
and start either injection or extraction.
To schedule a channel for disabling, set FDMA_CH_DISABLE.CH_DISABLE[ch]. An active channel
does not disable immediately. Instead, it waits until the current data block is done, saves the status word,
and then disables.
Channels can be in one of three states: DISABLED, UPDATING, or ACTIVE. Channels are DISABLED
by default. When the channel is reading a DCB or writing the DCB status word, it is considered to be
UPDATING. The status of individual channels is available in FDMA_CH_STAT.CH_STAT[ch].
The following illustration shows the FDMA channel states.
VMDS-10490 VSC7513 Datasheet Revision 4.2
181
VCore-III System and CPU Interfaces
Figure 66 • FDMA Channel States
DISABLED
Enable when user requested
ACTIVATE of channel.
Disable when DCB.LLP == NULL or
user requested DISABLE of channel.
UPDATING
Load DCB from address
ICPU_CFG::FDMA_DCB_LLP[ch].
Update STAT word at address
ICPU_CFG::FDMA_DCB_LLP_PREV[ch] + 0xC.
ACTIVE
A channel that has FDMA_DCB_LLP[ch].DCB_LLP==NULL when going from ACTIVE to UPDATING
disables itself instead of loading a new DCB. After this it can be re-enabled as previously described.
Extraction channels emit an INTR_LLP-event when loading a DCB with LLP==NULL. Injection channels
emit an INTR_LLP-event when saving status for a DCB that has the LLP==NULL.
Note: Extraction channel running out of DCBs during extraction is a problem that software must avoid. A
hanging extraction channel will potentially be head-of-line blocking other extraction channels.
It is possible to update an active channels LLP pointer and pointers in the DCB chains. Before changing
pointers software must schedule the channel for disabling (by writing
FDMA_CH_DISABLE.CH_DISABLE[ch]) and then wait for the channel to set
FDMA_CH_SAFE.CH_SAFE[ch]. When the pointer update is complete, soft must re-activate the channel
by setting FDMA_CH_ACTIVATE.CH_ACTIVATE[ch]. Setting activate will cancel the deactivate-request,
or if the channel has disabled itself in the meantime, it will re activate the channel.
Note: The address of the current DCB is available in FDMA_DCB_LLP_PREV[ch]. This information is useful
when modifying pointers for an active channel. The FDMA does not reload the current DCB when reactivated, so if the LLP-field of the current DCB is modified, then software must also modify
FDMA_DCB_LLP[ch].
Setting FDMA_CH_CFG[ch].DONEEOF_STOP_ENA disables an FDMA channel and emits LLP-event
after saving status for DCBs that contains EOF (after extracting or injecting a complete frame). Setting
FDMA_CH_CFG[ch].DONE_STOP_ENA disables an FDMA channel and emits LLP-event after saving
status for any DCB.
4.7.3
Channel Counters
The FDMA implements three counters per channel: SIG, DCB, and FRM. These counters are accessible
through FDMA_CH_CNT[ch].CH_CNT_SIG, FDMA_CH_CNT[ch].CH_CNT_DCB, and
VMDS-10490 VSC7513 Datasheet Revision 4.2
182
VCore-III System and CPU Interfaces
FDMA_CH_CNT[ch].CH_CNT_FRM, respectively. For more information about how to safely modify
these counters, see the register descriptions.
•
•
•
The SIG (signal) counter is incremented by one each time the FDMA loads a DCB that has the
DATAL.SIG bit set to 1.
The FRM (frame) counter is incremented by one each time the FDMA store status word for DCB that
has EOF set. It is a wrapping counter that can be used for software driver debug and development.
This counter does not count aborted frames.
The DCB counter is incremented by one every time the FDMA loads a DCB from memory. It is a
wrapping counter that can be used for software driver debug and development.
It is possible to enable channel interrupt whenever the SIG counter is incremented; this makes it possible
for software to receive interrupt when the FDMA reaches certain points in a DCB chain.
4.7.4
FDMA Events and Interrupts
Each FDMA channel can generate four events: LLP-event, FRM-event, SIG-event, and ERR-event.
These events cause a bit to be set in FDMA_INTR_LLP.INTR_LLP[ch],
FDMA_INTR_FRM.INTR_FRM[ch], FDMA_INTR_SIG.INTR_SIG[ch], and
FDMA_EVT_ERR.EVT_ERR[ch], respectively.
•
•
•
•
LLP-event occurs when an extraction channel loads a DCB that has LLP = NULL or when an
injection channel writes status for a DCB that has LLP=NULL. LLP-events are also emitted from
channels that have FDMA_CH_CFG[ch].DONEEOF_STOP_ENA or
FDMA_CH_CFG[ch].DONE_STOP_ENA set. For more information, see Enabling and Disabling
FDMA Channels.
FRM-event is indicated when an active channel loads a new DCB and the previous DCB had EOF.
The FRM-event is also indicated for channels that are disabled after writing DCB status with EOF.
SIG-event is indicated whenever the FDMA_CH_CNT[ch].CH_CNT_SIG counter is incremented.
The SIG (signal) counter is incremented when loading a DCB that has the DATAL.SIG bit set.
ERR-event is an error indication that is set for a channel if it encounters an unexpected problem
during normal operation. This indication is implemented to ease software driver debugging and
development. A channel that encounters an error will be disabled, depending on the type of error the
channel state may be too corrupt for it to be restarted without system reset. When an ERR-event
occurs, the FDMA_EVT_ERR_CODE.EVT_ERR_CODE shows the exact reason for an ERR-event.
For more information about the errors that are detected, see
FDMA_EVT_ERR_CODE.EVT_ERR_CODE.
Each of the events (LLP, FRM, SIG) can be enabled for channel interrupt through
FDMA_INTR_LLP_ENA.INTR_LLP_ENA[ch], FDMA_INTR_FRM_ENA.INTR_FRM_ENA[ch], and
FDMA_INTR_SIG.INTR_SIG[ch] respectively. The ERR event is always enabled for channel interrupt.
The highest numbered extraction channel supports two additional non-sticky events related to manual
extraction: XTR_SOF_RDY-event and XTR_ANY_RDY-event. An active event causes the following fields
to be set: MANUAL_INTR.INTR_XTR_SOF_RDY and MANUAL_INTR.INTR_XTR_ANY_RDY
respectively. For more information, see Manual Extraction.
•
•
XTR_SOF_RDY-event is active when the next word to be manually extracted contains an SOF
indication. This event is enabled in MANUAL_INTR_ENA.INTR_XTR_SOF_RDY_ENA.
XTR_ANY_RDY-event is active when any word is available for manually extraction. This event is
enabled in MANUAL_INTR_ENA.INTR_XTR_ANY_RDY_ENA respectively.
The highest numbered injection channel supports one additional non-sticky event related to manual
injection: INJ_RDY-event. This event is active when the injection logic has room for (at least) sixteen 32bit words of injection frame data. When this event is active, MANUAL_INTR.INTR_INJ_RDY is set. The
INJ_RDY-event can be enabled for channel interrupt by setting
MANUAL_INTR_ENA.INTR_INJ_RDY_ENA. For more information, see Manual Injection.
The FDMA_INTR_ENA.INTR_ENA[ch] field enables interrupt from individual channels,
FDMA_INTR_IDENT.INTR_IDENT[ch] field shows which channels that are currently interrupting. While
INTR_IDENT is non-zero, the FDMA is indicating interrupting towards to the VCore-III interrupt controller.
The following illustration shows the FDMA channel interrupt hierarchy.
VMDS-10490 VSC7513 Datasheet Revision 4.2
183
VCore-III System and CPU Interfaces
Figure 67 • FDMA Channel Interrupt Hierarchy
EVT_ERR[ch]
OR
INTR_LLP[ch]
AND
AND
INTR_IDENT[ch]
INTR_LLP_ENA[ch]
INTR_FRM[ch]
AND
INTR_FRM_ENA[ch]
INTR_SIG[ch]
AND
INTR_SIG_ENA[ch]
Only for highest numbered extraction channel
INTR_XTR_SOF_RDY
AND
INTR_XTR_SOF_RDY_ENA
INTR_XTR_ANY_RDY
AND
INTR_XTR_SOF_ANY_ENA
Only for highest numbered injection channel
INTR_INJ_RDY
AND
INTR_INJ_RDY_ENA
INTR_ENA[ch]
4.7.5
FDMA Extraction
During extraction, the FDMA extracts Ethernet frame data from the Queuing System and saves it into the
data block of the DCB that is currently loaded by the FDMA extraction channel. The FDMA continually
processes DCBs until it reaches a DCB with LLP = NULL or until it is disabled.
When an extraction channel writes the status word of a DCB, it updates SOF/EOF/ABORT/PRUNEDindications and BLOCKL. BLOCKO remains unchanged (write value is taken from the value that was
read when the DCB was loaded).
Aborting frames from the queuing system will not occur during normal operation. If the queuing system is
reset during extraction of a particular frame, then ABORT and EOF is set. Software must discard frames
that have ABORT set.
Pruning of frames during extraction is enabled per extraction port through
XTR_FRM_PRUNING[group].PRUNE_SIZE. When enabled, Ethernet frames above the configured size
are truncated, and PD and EOF is set.
4.7.6
FDMA Injection
During injection, the FDMA reads Ethernet frame data from the data block of the DCB that is currently
loaded by the FDMA injection channel and injects this into the queuing system. The FDMA continually
processes DCBs until it reaches a DCB with LLP = NULL or until it is disabled.
When an injection channel writes the status word of a DCB, it sets DONE indication. All other status word
fields remain unchanged (write value is stored the first time the injection channel loads the DCB).
The rate by which the FDMA injects frames can be shaped by using tokens. Each injection channel has
an associated token counter (FDMA_CH_INJ_TOKEN_CNT[ich]). A DCB that has the DATAL.TOKEN
field set causes the injection channel to deduct one from the token counter before the data block of the
DCB can be injected. If the token counter is at 0, the injection channel postpones injection until the
channels token counter is set to a value different from 0.
VMDS-10490 VSC7513 Datasheet Revision 4.2
184
VCore-III System and CPU Interfaces
Tokens can be added to the token counter by writing the FDMA_CH_INJ_TOKEN_CNT[ich] register.
Tokens can also be added automatically (with a fixed interval) by using the dedicated token tick counter.
Setting FDMA_CH_INJ_TOKEN_TICK_RLD[ich] to a value n (different from 0) will cause one token to be
added to that injection channel every n x 200 ns.
4.7.7
Manual Mode
The decision making logic of the FDMA extraction path and/or injection paths can be disabled to give
control of the FDMA’s extraction and/or injection buffers directly to any master attached to the Shared
Bus Architecture. When operating in manual mode DCB structure, counters and most of the interrupts do
not apply.
Manual extraction and injection use hard-coded channel numbers.
•
•
Manual extraction mode uses FDMA channel 1 (port 12 extraction direction).
Manual injection mode uses FDMA channel 9 (port 12 injection direction).
To enable manual extraction, set MANUAL_CFG.XTR_ENA. The FDMA must not be enabled for FDMA
extraction when manual extraction mode is active. To enable manual injection, set
MANUAL_CFG.INJ_ENA and FDMA_CH_CFG[9].CH_INJ_CRP = 1. The FDMA must not be enabled for
FDMA injection when manual injection mode is active. Extraction and injection paths are independent.
For example, FDMA can control extraction at the same time as doing manual injection by means of the
CPU.
4.7.7.1
Manual Extraction
Extraction is done by reading one or more blocks of data from the extraction memory area. A block of
data is defined by reading one or more data words followed by reading of the extraction status word. The
extraction memory area is 16 kilobytes and is implemented as a replicated register region
MANUAL_XTR. The highest register in the replication (0xFFF) maps to the extraction status word. The
status word is updated by the extraction logic and shows the number of frame bytes read, SOF and EOF
indications, and PRUNED/ABORT indications.
Note During frame extraction, the CPU does not know the frame length. This means that the CPU must
check for EOF regularly during frame extraction. When reading a data block from the device, the CPU
can burst read from the memory area in such a way that the extraction status word is read as the last
word of the burst.
Figure 68 • Extraction Status Word Encoding
SOF
[31:20]
EOF
ABORT
PD
BLOCKO
19181716
BLOCKL
[15:0]
BLOCKL: The amount of frame data (bytes) that
has been read in this block. The CPU might have
read more data than this, only valid frame data
(including Extraction Header) is counted here.
SOF: Start of frame, set if this block contains
start of a frame.
EOF: End of frame, set if this block contains end
of a frame.
ABORT: Set if this frame has been aborted by
the Queuing System. Write ‘1’ to discard the
remainder of the active frame.
PD: Pruned indication, set if the frame has been
pruned to less than original length.
BLOCKO: The amount of dummy bytes (non-frame
data) read before start of frame data.
The extraction logic updates the extraction status word while the CPU is reading out data for a block.
Prior to starting a new data block, the CPU can write the two least significant bits of the BLOCKO field.
The BLOCKO value is stored in the extraction logic and takes effect when the new data block is started.
Reading the status field always returns the BLOCKO value that applies to the current data block. Unless
VMDS-10490 VSC7513 Datasheet Revision 4.2
185
VCore-III System and CPU Interfaces
written (before stating a data block), the BLOCKO is cleared, so by default all blocks have 0 byte offset.
The offset can be written multiple times; the last value takes effect.
The CPU can abort frames that it has already started to read out by writing the extraction status field with
the ABORT field set. All other status-word fields will be ignored. This causes the extraction logic to
discard the active frame and remove it from the queuing system.
Reading of block data does not have to be done in one burst. As long as the status word is not read,
multiple reads from the extraction region are treated as belonging to the same block.
4.7.7.2
Manual Injection
Injection is done by writing one or more blocks of data to the injection memory area. A block of data is
defined by writing an injection status word followed by writing one or more data words. The injection
memory area is 16 kilobytes and is implemented as a replicated register region MANUAL_INJ. The first
register in this replication maps to the injection status word. The status word for each block defines the
following:
•
•
•
•
Number of bytes to be injected
Optional byte offset before injection data
SOF and EOF indications
Optional ABORT indication
Note In general, it makes sense to inject frames as a single large block of data (containing both SOF
and EOF). However, because offset/length can be specified individually for each block, injecting frames
through several blocks is useful when compensating for offset/word misalignment. For example, when
building a frame from different memory regions in the CPU main memory.
Figure 69 • Injection Status Word Encoding
SOF
[31:20]
EOF
ABORT
PD
BLOCKO
19 18 17 16
BLOCKL
[15:0]
BLOCKL: The amount of frame data (bytes) that
will be written for this block. The CPU is allowed to
write more data than this, additional data will be
ignored.
SOF: Start of frame, set to indicate that this block
contains start of a frame.
EOF: End of frame, set to indicate that this block
contains end of a frame.
ABORT: Set to abort active frame transfer. The
current frame will be aborted and removed from
Queuing System.
PD: Injection done, is set by the injection logic
when enough data has been received for this block
of data (BLOCKO+BLOCKL). If set when writing
status word, then this is treated as if ABORT had
been set.
BLOCKO: The amount of dummy bytes (non-frame
data) to expect before the frame data. The dummy
data will be ignored.
Injection logic updates the PD field of the status word. The status word can be read at any time during
injection without affecting current data block transfers. However, a CPU is able to calculate how much
data that is required to inject a complete block of data (at least BLOCKO + BLOCKL bytes), so reading
the status word is for software development and debug only. Writing status word before finishing a
previous data block will cause that frame to be aborted. Frames are also aborted if they do not start with
SOF or end with EOF indications.
As long as the status word is not written, multiple writes to the injection region are treated as data
belonging to the same block. This means multiple bursts of data words can be written between each
injection status word update.
VMDS-10490 VSC7513 Datasheet Revision 4.2
186
VCore-III System and CPU Interfaces
Software can abort frames by writing to injection status with ABORT field set. All other status word fields
are ignored. When a frame is aborted, the already injected data is removed from the queuing system.
4.8
VCore-III System Peripherals
This section describes the subblocks of the VCore-III system. Although the subblocks are primarily
intended to be used by the VCore-III CPU, an external CPU can also access and control them through
the shared bus.
4.8.1
SI Boot Controller
The SPI boot master allows booting from a Flash that is connected to the serial interface. For information
about how to write to the serial interface, see SI Master Controller, page 189. For information about using
an external CPU to access device registers using the serial interface, see Serial Interface in Slave Mode,
page 166.
The following table lists the registers associated with the SI boot controller.
Table 146 • SI Boot Controller Configuration Registers
Register
Description
ICPU_CFG::SPI_MST_CFG
Serial interface speed and address width
ICPU_CFG::SW_MODE
Legacy manual control of the serial interface pins
ICPU_CFG::GENERAL_CTRL
SI interface ownership
By default, the SI boot controller operates in 24-bit address mode. In this mode, there are four
programmable chip selects when the VCore-III system controls the SI. Each chip select can address up
to 16 megabytes (MB) of memory.
Figure 70 • SI Boot Controller Memory Map in 24-Bit Mode
SI Controller
+0x01000000
+0x02000000
+0x03000000
SI Controller Memory Map
16 MB
Chip Select 0, SI_nCS0
16 MB
Chip Select 1, SI_nCS1
16 MB
Chip Select 2, SI_nCS2
16 MB
Chip Select 3, SI_nCS3
The SI boot controller can be reconfigured for 32-bit address mode through SPI_MST_CFG.A32B_ENA.
In 32-bit mode, the entire SI region of 256 megabytes (MB) is addressed using chip select 0.
Figure 71 • SI Boot Controller Memory Map in 32-Bit Mode
SI Controller
SI Controller Memory Map (32- bit)
256 MB
Chip Select 0, SI_nCS0
Reading from the memory region for a specific SI chip select generates an SI read on that chip select.
The VCore-III CPU can execute code directly from Flash by executing from the SI boot controller’s
memory region. For 32-bit capable SI Flash devices, the VCore-III must start up in 24-bit mode. During
the boot process, it must manually reconfigure the Flash device (and SI boot controller) into 32-bit mode
and then continue booting.
The SI boot controller accepts 8-bit, 16-bit, and 32-bit read access with or without bursting. Writing to the
SI requires manual control of the SI pins using software. Setting SW_MODE.SW_PIN_CTRL_MODE
VMDS-10490 VSC7513 Datasheet Revision 4.2
187
VCore-III System and CPU Interfaces
places all SI pins under software control. Output enable and the value of SI_CLK, SI_DO, SI_nCSn are
controlled through the SW_MODE register. The value of the SI_DI pin is available in
SW_MODE.SW_SPI_SDI. The software control mode is provided for legacy reasons; new
implementations should use the dedicated master controller for writing to the serial interface. For more
information see SI Master Controller, page 189.
Note The VCore-III CPU cannot execute code directly from the SI boot controller’s memory region at
the same time as manually writing to the serial interface.
The following table lists the serial interface pins when the SI boot controller is configured as owner of SI
interface in GENERAL_CTRL.IF_SI_OWNER. For more information about overlaid functions on the
GPIOs for these signals, see GPIO Overlaid Functions, page 205.
Table 147 • Serial Interface Pins
Pin Name
I/O
Description
SI_nCS0
SI_nCS[3:1]/GPIO
O
Active low chip selects. Only one chip select can be active at any
time. Chip selects 1 through 3 are overlaid functions on GPIO pins.
SI_CLK
O
Clock output.
SI_DO
O
Data output (MOSI).
SI_DI
I
Data input (MISO).
The SI boot controller does speculative pre-fetching of data. After reading address n, the SI boot
controller automatically continues reading address n + 1, so that the next value is ready if requested by
the VCore-III CPU. This greatly optimizes reading from sequential addresses in the Flash, such as when
copying data from Flash into program memory.
The following illustrations depict 24-bit address mode. When the controller is set to 32-bit mode (through
SPI_MST_CFG.A32B_ENA), 32 address bits are transferred instead of 24.
Figure 72 • SI Read Timing in Normal Mode
SI_nCS0
SI_CLK
2 2 2 2 1 1 1 1 1 1 1 1 1 1
9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0
SI_DO
READ
24 Bit Address
SI_DI
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Data Byte #0
Data Byte #1
Data Byte #2
Data Byte #3
Figure 73 • SI Read Timing in Fast Mode
SI_nCS0
SI_CLK
2 2 2 2 1 1 1 1 1 1 1 1 1 1
9 8 7 6 5 4 3 2 1 0
3 2 1 0 9 8 7 6 5 4 3 2 1 0
SI_DO
FAST_READ
SI_DI
24 Bit Address
Dummy Byte
7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0 7 6 5 4 3 2 1 0
Data Byte #0
Data Byte #1
Data Byte #2
Data Byte #3
The default timing of the SI boot controller operates with most serial interface Flash devices. Use the
following process to calculate the optimized serial interface parameters for a specific SI device:
VMDS-10490 VSC7513 Datasheet Revision 4.2
188
VCore-III System and CPU Interfaces
1.
2.
3.
Calculate an appropriate frequency divider value as described in SPI_MST_CFG.CLK_DIV. The SI
operates at no more than 25 MHz, and the maximum frequency of the SPI device must not be
exceeded. The VCore-III system frequency in the device is 250 MHz.
The SPI device may require a FAST_READ command rather than normal READ when the SI
frequency is increased. Setting SPI_MST_CFG.FAST_READ_ENA makes the SI boot controller use
FAST_READ commands.
Calculate SPI_MST_CFG.CS_DESELECT_TIME so that it matches how long the SPI device
requires chip-select to be deasserted between access. This value depends on the SI clock period
that results from the SPI_MST_CFG.CLK_DIV setting.
These parameters must be written to SPI_MST_CFG. The CLK_DIV field must either be written last or at
the same time as the other parameters. The SPI_MST_CFG register can be configured while also
booting up from the SI.
When the VCore-III CPU boots from the SI interface, the default values of the SPI_MST_CFG register
are used until the SI_MST_CFG is reconfigured with optimized parameters. This implies that SI_CLK is
operating at approximately 8.1 MHz, with normal read instructions and maximum gap between chip
select operations to the Flash.
Note The SPI boot master does optimized reading. SI_DI (from the Flash) is sampled just before
driving falling edge on SI_CLK (to the Flash). This greatly relaxes the round trip delay requirement for
SI_CLK to SI_DI, allowing high Flash clock frequencies.
4.8.2
SI Master Controller
This section describes the SPI master controller (SIMC) and how to use it for accessing external SPI
slave devices, such as programming of a serially attached Flash device on the boot interface. VCore
booting from serial Flash is handled by the SI boot master.
The following table lists the registers associated with the SI master controller.
Table 148 • SI Master Controller Configuration Registers Overview
Register
Description
SIMC::CTRLR0
Transaction configuration
SIMC::CTRLR1
Configurations for receive-only mode
SIMC::SIMCEN
SI master controller enable
SIMC::SER
Slave select configuration
SIMC::BAUDR
Baud rate configuration
SIMC::TXFTLR
Tx FIFO threshold level
SIMC::RXFTLR
Rx FIFO Threshold Level
SIMC::TXFLR
Tx FIFO fill level
SIMC::RXFLR
Rx FIFO fill level
SIMC::SR
Various status indications
SIMC::IMR
Interrupt enable
SIMC::ISR
Interrupt sources
SIMC::RISR
Unmasked interrupt sources
SIMC::TXOICR
Clear of transmit FIFO overflow interrupt
SIMC::RXOICR
Clear of receive FIFO overflow interrupt
SIMC::RXUICR
Clear of receive FIFO underflow interrupt
SIMC::DR
Tx/Rx FIFO access
SIMC::RX_SAMPLE_DLY
RXD sample delay
ICPU_CFG::GENERAL_CTRL
Interface configurations
VMDS-10490 VSC7513 Datasheet Revision 4.2
189
VCore-III System and CPU Interfaces
The SI master controller supports Motorola SPI and Texas Instruments SSP protocols. The default
protocol is SPI, enable SSP by setting CTRLR0.FRF = 1 and GENERAL_CTRL.SSP_MODE_ENA = 1.
The protocol baud rate is programmable in BAUDR.SCKDV; the maximum baud rate is 25 MHz.
Before the SI master controller can be used, it must be set as owner of the serial interface. This is done
by writing GENERAL_CTRL.IF_SI_OWNER = 2.
The SI master controller has a programmable frame size. The frame size is the smallest unit when
transferring data over the SI interface. Using CTRLR0.DFS, the frame size is configured in the range of 4
bits to 16 bits. When reading or writing words from the transmit/receive FIFO, the number of bits that is
stored per FIFO-word is always equal to frame size (as programmed in CTRLR0.DFS).
The controller operates in one of three following major modes: Transmit and receive, transmit only, or
receive only. The mode is configured in CTRLR0.TMOD.
Transmit and receive. software paces SI transactions. For every data frame that software writes to the
transmission FIFO, another data frame is made available in the receive FIFO (receive data from the
serial interface). Transaction will go on for as long as there is data available in the transmission FIFO.
Transmit only. Software paces SI transactions. The controller transmits only; receive data is discarded.
Transaction will go on for as long as there is data available in the transmission FIFO.
Receive only. The controller paces SI transactions. The controller receives only data, software requests
a specific number of data frames by means of CTRLR1.NDF, the transaction will go on until all data
frames has been read from the SI interface. Transaction is initiated by software writing one data frame to
transmission FIFO. This frame is not used for anything else than starting the transaction. The SI_DO
output is undefined during receive only transfers. Receive data frames are put into the receive FIFO as
they are read from SI.
For SPI mode, chip select is asserted throughout transfers. Transmit transfers end when the transmit
FIFO runs out of data frames. Software must make sure it is not interrupted while writing data for a multiframe transfer. When multiple distinct transfers are needed, wait for SR.TFE = 1 and SR.BUSY = 0
before initiating new transfer. SR.BUSY is an indication of ongoing transfers, however, it is not asserted
immediately when writing frames to the FIFO. As a result, software must also check the SR.TFE
(transmit FIFO empty) indication.
The SI master controller supports up to 5 chip selects. Chip select 0 is mapped to the SI_nCS pin of the
serial interface. The remaining chips selects are available using overlaid GPIO functions. Software
controls which chip selects to activate for a transfer using the SER register. For more information about
overlaid functions on the GPIOs for these signals, see GPIO Overlaid Functions, page 205.
Table 149 • SI Master Controller Pins
Pin Name
I/O
Description
SI_nCS0
SI_nCS[4:1]/GPIO
O
Active low chip selects. Chip selects 1 through 4
are overlaid functions on the GPIO pins.
SI_CLK
O
Clock output.
SI_DO
O
Data output (MOSI).
SI_DI
I
Data input (MISO).
Writing to any DR replication index put data into the transmission FIFO, and reading from any DR
replication index take out data from the receive FIFO. FIFO status indications are available in the SR
register’s TFE, TFNF, RFF, and RFNE fields. For information about interrupting on FIFO status, see
SIMC Interrupts, page 192.
It is important to delay the sample of the RXD input signal by writing to SIMC::RX_SAMPLE_DLY. Each
value represents a single VCore system clock cycle delay on the sample. If this field is programmed with
a value that exceeds 25, a zero (0) delay will be applied. For optimal operation, it is suggested to set the
value to SIMC::BAUD/2, but no larger than 25. This will delay sampling of RX-data by half clock cycle for
SPI frequencies above 5MHz. Below 5 MHz the sampling delay will be 100ns. It is impossible to write to
this register when the SIMC is enabled.
VMDS-10490 VSC7513 Datasheet Revision 4.2
190
VCore-III System and CPU Interfaces
After completing all initial configurations, the SI master controller is enabled by writing
SIMCEN.SIMCEN = 1. Some registers can only be written when the controller is in disabled state. This is
noted in the register-descriptions for the affected registers.
4.8.2.1
SPI Protocol
When the SI master controller is configured for SPI mode, clock polarity and position is configurable in
CTRLR0.SCPH and CTRLR0.SCPOL. The following illustration shows the four possible combinations for
8-bit transfers.
Figure 74 • SIMC SPI Clock Configurations
SI_nCS0
SI_nCS0
SI_CLK
SI_CLK
SI_DO
7
6
5
4
3
2
1
0
SI_DO
7
6
5
4
3
2
1
0
SI_DI
7
6
5
4
3
2
1
0
SI_DI
7
6
5
4
3
2
1
0
CTRLR0.SCPH = 0, CTRLR0.SCPOL = 0
CTRLR0.SCPH = 0, CTRLR0.SCPOL = 1
SI_nCS0
SI_nCS0
SI_CLK
SI_CLK
SI_DO
7
6
5
4
3
2
1
0
SI_DO
7
6
5
4
3
2
1
0
SI_DI
7
6
5
4
3
2
1
0
SI_DI
7
6
5
4
3
2
1
0
CTRLR0.SCPH = 1, CTRLR0.SCPOL = 0
CTRLR0.SCPH = 1, CTRLR0.SCPOL = 1
Data is sampled in the middle of the data-eye.
When using SPI protocol and transferring more than one data frame at the time, the controller performs
one consecutive transfer. The following illustration shows a transfer of three data frames of 4 bits each.
Note Transmitting transfers end when the transmit FIFO runs out of data frames. Receive only transfers
end when the pre-defined number of data-frames is read from the SI interface.
Figure 75 • SIMC SPI 3x Transfers
SI_nCS0
SI_CLK
SI_DO
3
2
1
0
3
2
1
0
3
2
1
0
SI_DI
3
2
1
0
3
2
1
0
3
2
1
0
First frame
4.8.2.2
Second frame
Third frame
SSP Protocol
The SSP protocol for transferring two 6-bit data frames is shown in the following illustration. When using
SSP mode, CTRLR0.SCPH and CTRLR0.SCPOL must remain zero.
VMDS-10490 VSC7513 Datasheet Revision 4.2
191
VCore-III System and CPU Interfaces
4.8.2.3
SIMC SSP 2x Transfers
SI_nCS0
SI_CLK
SI_DO
5
4
3
2
1
0
5
4
3
2
1
0
SI_DI
5
4
3
2
1
0
5
4
3
2
1
0
First frame
4.8.2.4
Second frame
SIMC Interrupts
The SI master controller has five interrupt sources:
•
•
•
•
•
RXF interrupt is asserted when the fill level of the receive FIFO (available in RXFLR) exceeds the
programmable level set in RXFTLR. This interrupt is non-sticky; it is deasserted when fill level is
decreased below the programmable level.
RXO interrupt is asserted on receive FIFO overflow. This interrupt is cleared by reading the RXOICR
register.
RXU interrupt is asserted when reading from an empty receive FIFO. This interrupt is cleared by
reading the RXUICR register.
TXO interrupt is asserted when writing to a full transmit FIFO. This interrupt is cleared by reading the
TXOICR register.
TXE interrupt is asserted when the fill level of the transmit FIFO (available in TXFLR) is below the
programmable level set in TXFTLR. This interrupt is non-sticky; it is deasserted when fill level is
increased above the programmable level.
The raw (unmasked) status of these interrupts is available in the RISR register. Each of the interrupts can
be individually masked by the IMR register. All interrupts are enabled by default. The currently active
interrupts are shown in the ISR register.
If the RXO, RXU, and TXO interrupts occur during normal use of the SI master controller, it is an
indication of software problems.
Interrupt is asserted towards the VCore-III interrupt controller when any enabled interrupt is asserted and
the SI master controller is enabled.
4.8.2.5
SIMC Programming Example
This example shows how to use the SI master controller to interface with the SI slave of another device.
The slave device will be initialized for big endian/most significant bit first mode and then the
DEVCPU_GCB::GPR register is written with the value 0x01234567. It is assumed that the other device’s
SI slave is connected on SI_nCS1 (and that appropriate GPIO alternate function has been enabled).
The SI slave is using a 24-bit address field and a 32-bit data field. This example uses 4 x 16-bit data
frames to transfer the write-access. This means that 8 bits too much will be transferred, this is not a
problem for the SI slave interface; it ignores data above and beyond the 56 bit required for a writeaccess.
For information about initialization and how to calculate the 24-bit SI address field, see Serial Interface in
Slave Mode, page 166. The address-field when writing DEVCPU_GCB::GPR is 0x804001 (including
write-indication).
The following steps are required to bring up the SI master controller and write twice to the SI slave
device.
Important The following procedure disconnects the SI boot master from the SI interface. Booting must
be done before attempting to overtake the boot-interface.
1.
2.
3.
Write GENERAL_CTRL.IF_SI_OWNER = 2 to make SI master controller the owner of the SI
interface.
Write BAUDR = 250 to get 1 MHz baud rate.
Write SER = 2 to use SI_nCS1.
VMDS-10490 VSC7513 Datasheet Revision 4.2
192
VCore-III System and CPU Interfaces
4.
5.
6.
7.
8.
9.
Write CTRLR0 = 0x10F for 16-bit data frame and transmit only.
Write SIMCEN = 1 to enable the SI master controller.
Write DR[0] = 0x8000, 0x0081, 0x8181, 0x8100 to configure SI slave for big endian / most significant
bit first mode.
Wait for SR.TFE = 1 and SR.BUSY = 0 for chip select to deassert between accesses to the SI slave.
Write DR[0] = 0x8040, 0x0101, 0x2345, 0x6700 to write DEVCPU_GCB::GPR in slave device.
Wait for SR.TFE = 1 and SR.BUSY = 0, then disable the SI master controller by writing SIMCEN = 0.
When reading from the SI slave, CTRLR0.TMOD must be configured for transmit and receive. One-byte
padding is appropriate for a 1 MHz baud rate.
4.8.3
DDR3/DDR3L Memory Controller
This section provides information about how to configure and initialize the DDR3/DDR3L memory
controller.
The following table lists the registers associated with the memory controller.
Table 150 • DDR3/DDR3L Controller Registers
Register
Description
ICPU_CFG::RESET
Reset Control
ICPU_CFG::MEMCTRL_CTRL
Control
ICPU_CFG::MEMCTRL_CFG
Configuration
ICPU_CFG::MEMCTRL_STAT
Status
ICPU_CFG::MEMCTRL_REF_PERIOD
Refresh period configuration
ICPU_CFG::MEMCTRL_ZQCAL
DDR3/DDR3L ZQ-calibration
ICPU_CFG::MEMCTRL_TIMING0
Timing configuration
ICPU_CFG::MEMCTRL_TIMING1
Timing configuration
ICPU_CFG::MEMCTRL_TIMING2
Timing configuration
ICPU_CFG::MEMCTRL_TIMING3
Timing configuration
ICPU_CFG::MEMCTRL_MR0_VAL
Mode register 0 value
ICPU_CFG::MEMCTRL_MR1_VAL
Mode register 1 value
ICPU_CFG::MEMCTRL_MR2_VAL
Mode register 2 value
ICPU_CFG::MEMCTRL_MR3_VAL
Mode register 3 value
ICPU_CFG::MEMCTRL_TERMRES_CTRL
Termination resistor control
ICPU_CFG::MEMCTRL_DQS_DLY
DQS window configuration
ICPU_CFG::MEMPHY_CFG
SSTL configuration
ICPU_CFG::MEMPHY_ZCAL
SSTL calibration
The memory controller works with JEDEC-compliant DDR3/DDR3L memory modules. The controller
runs 312.50 MHz and supports one or two byte lanes in either single or dual row configurations (one or
two chip selects). The controller supports up to 16 address bits. The maximum amount of physical
memory that can be attached to the controller is 1 gigabyte.
The memory controller supports ECC encoding/decoding by using one of the two lanes for ECC
information. Enabling ECC requires that both byte lanes are populated. When ECC is enabled, half the
total physical memory is available for software use; the other half is used for ECC information.
The following steps are required to bring up the memory controller.
VMDS-10490 VSC7513 Datasheet Revision 4.2
193
VCore-III System and CPU Interfaces
1.
2.
3.
4.
5.
6.
Release the controller from reset by clearing RESET.MEM_RST_FORCE.
Configure timing and mode parameters. These depend on the DDR3/DDR3L module and
configuration selected for the device. For more information, see DDR3/DDR3L Timing and Mode
Configuration Parameters, page 194.
Enable and calibrate the SSTL I/Os. For more information, see Enabling and Calibrating SSTL I/Os.
Initialize the memory controller and modules. For more information, see Memory Controller and
Module Initialization.
Calibrate the DQS read window. For more information, see DQS Read Window Calibration.
Optionally configure ECC and 1 gigabyte support. For more information see ECC and 1 Gigabyte
Support.
Note For selected DDR3/DDR3L modules, the bring-up of the memory controller is already
implemented as part of the Board Support Package (BSP). For more information about implementing the
bring-up procedure, see Microsemi eCos BSP and Tool Chain, which is available on the Microsemi Web
site at www.Microsemi.com.
4.8.3.1
DDR3/DDR3L Timing and Mode Configuration Parameters
This section provides information about each of the parameters that must be configured prior to
initialization of the memory controller. It provides a quick overview of fields that must be configured and
their recommended values. For more information about each field, see the register list.
The memory controller operates at 312.5 MHz, and the corresponding DDR clock period is 3.2 ns
(DDR625). When a specific timing value is used in this section (for example, tMOD), it means that the
corresponding value from the memory module datasheet is expressed in memory controller clock cycles
(divided by 3.2 ns and rounded up and possibly adjusted for minimum clock cycle count).
The following table defines general parameters for DDR3/DDR3L required when configuring the memory
controller.
Table 151 • General DDR3/DDR3L Timing and Mode Parameters
Parameter
DDR3/DDR3L
RL
CL
WL
CWL
MD
tMOD
ID
tXPR
SD
tDLLK
OW
2
OR
2
RP
tRP
FAW
tFAW
BL
4
MR0
((RL-4)
工商网监
湘ICP备2023018690号
