Serial Flash interface
Configurable LED operation for software or customizing OEM
LED displays
Device disable capability
Package size - 25 mm x 25 mm (X550-BT2)
Package size - 17 mm x 17 mm (X550-AT2)
Networking
10 GbE/1 GbE/100 Mb/s copper PHYs integrated on-chip
Support for jumbo frames of up to 15.5 KB
Flow control support: send/receive pause frames and receive
FIFO thresholds
Statistics for management and RMON
802.1q VLAN support
TCP segmentation offload: up to 256 KB
IPv6 support for IP/TCP and IP/UDP receive checksum
offload
Fragmented UDP checksum offload for packet reassembly
Message Signaled Interrupts (MSI)
Message Signaled Interrupts (MSI-X)
Interrupt throttling control to limit maximum interrupt rate
and improve CPU usage
Flow Director (16 x 8 and 32 x 4)
128 transmit queues
Receive packet split header
Receive header replication
Dynamic interrupt moderation
TCP timer interrupts
Relaxed ordering
Support for 64 virtual machines per port (64 VMs x 2
queues)
Support for Data Center Bridging (DCB);(802.1Qaz,
802.1Qbb, 802.1p)
Host Interface
PCIe 3.0 Base Specification
Bus width — x1, x4, x8
64-bit address support for systems using more than 4 GB of
physical memory
MAC F
UNCTIONS
Descriptor ring management hardware for transmit and
receive
ACPI register set and power down functionality supporting
D0 and D3 states
A mechanism for delaying/reducing transmit interrupts
Software-controlled global reset bit (resets everything
except the configuration registers)
Four Software-Definable Pins (SDP) per port
Wake up
IPv6 wake-up filters
Configurable flexible filter (through NVM)
LAN function disable capability
Programmable memory transmit buffers (160 KB/port)
Default configuration by NVM for all LEDs for pre-driver
functionality
Manageability
SR-IOV support
Eight VLAN L2 filters
16 Flex L3 port filters
Four Flexible TCO filters
Four L3 address filters (IPv4)
Advanced pass through-compatible management packet
transmit/receive support
SMBus interface to an external Manageability Controller (MC)
NC-SI interface to an external MC
Four L3 address filters (IPv6)
Four L2 address filters
Revision 2.2
July 2017
333369-004
Intel® Ethernet Controller X550 Datasheet—Revision History
Revision History
RevisionDateNotes
2.2July 21, 2017Updates include the following:
•Added Section 2.2.8.1, “Pin Differences in the X550-AT Single Port Device”.
• Section 11.7.6.1.3 — Added reference to list of support message types.
• Section 11.7.6.1.3 — Modified verbiage in “Value” column for Bytes 3:5 in Table 11-44.
• Section 12.3.9 — Added new table for X550-AT power consumption.
• Section 12.3.10.1 — Updated values in associate table.
2.1May 10, 2016Updates include the following:
• Removed EEC.FLUPD bit. No longer used for triggering Shadow RAM dump.
• Removed FLUPDATE register (0x00015F54).
• Tab le 3-2 5 — Updated description for SDP1.
• Section 9.2.3.6.7, “Link Capabilities Register (0xAC; RO)” — Changed default value for
ASPM support (bits 11:10) to 10b.
This document describes the external architecture (including device operation, pin descriptions, register
definitions, etc.) for the X550, a dual port 10GBASE-T Network Interface Controller.
This document is intended as a reference for logical design group, architecture validation, firmware
development, software device driver developers, board designers, test engineers, or anyone else who
might need specific technical or programming information about the X550.
1.2 Product Overview
The X550 is a derivative of the X540. Many features of its predecessor remain intact; however, some
have been removed or modified as well as new features introduced.
The X550 includes two integrated 10GBASE-T copper Physical Layer Transceivers (PHYs). A standard
MDIO interface, accessible to software via MAC control registers, is used to configure and monitor each
PHY operation.
1.2.1 System Configurations
The X550 is targeted for system configurations such as rack mounted, pedestal servers or workstations,
where it can be implemented used as an add-on NIC or LAN on Motherboard (LOM), or purchased from
Intel as a standard PCIe* adapter card.
Figure 1-1. Typical Rack/Pedestal System Configuration
1.3 External Interfaces
Figure 1-2. X550 External Interfaces Diagram
20333369-004
Introduction—Intel
®
Ethernet Controller X550 Datasheet
1.3.1 PCIe Interface
The X550 supports PCIe v3.0 (2.5 GT/s, 5 GT/s or 8 GT/s). See Section 2.2.1 for full pin description and
Section 12.4.5 for interface timing characteristics.
1.3.2 Network Interfaces
Two independent 10GBASE-T interfaces are used to connect the two X550 ports to external devices.
Each 10GBASE-T interface can operate at any of the following speeds:
• 10 Gb/s, 10GBASE-T mode
• 5 Gb/s, NBASE-T mode
• 2.5 Gb/s, NBASE-T mode
• 1 Gb/s, 1000BASE-T mode
• 100 Mb/s, 100BASE-TX mode
• Refer to Section 2.2.2for full-pin descriptions. For the timing characteristics of those interfaces,
refer to the relevant external specifications listed in Section 12.4.6.
1.3.3 Serial Flash Interface
The X550 uses an external SPI serial interface to a Flash device, also referred to as Non-Volatile
Memory (NVM). The X550 supports serial Flash devices with up to 4 MB of memory.
1.3.4 SMBus Interface
SMBus is an optional interface for pass-through and/or configuration traffic between an external
Manageability Controller (MC) and the X550.
The X550's SMBus interface supports a standard SMBus, up to a frequency of 1 MHz. Refer to
Section 2.2.4for full-pin descriptions and Section 12.4.4.3 for timing characteristics of this interface.
1.3.5 NC-SI Interface
NC-SI is an optional interface for pass-through traffic to and from an MC. The X550 meets the NC-SI
version 1.0.0 specification.
Refer to Section 2.2.5 for the pin descriptions, and Section 11.6 for NC-SI programming.
The X550 has four SDP pins per port that can be used for miscellaneous hardware or softwarecontrollable purposes. These pins can each be individually configured to act as either input or output
pins. Via the SDP pins, the X550 can support IEEE1588 auxiliary device connections and other
functionality. For more details on the SDPs see Section 3.5 and the ESDP register (Section 8.2.2.1.4).
1.3.7 LED Interface
The X550 implements four output drivers intended for driving external LED circuits per port. Each of the
four LED outputs can be individually configured to select the particular event, state, or activity, which is
indicated on that output. In addition, each LED can be individually configured for output polarity as well
as for blinking versus non-blinking (steady-state) indications.
The configuration for LED outputs is specified via the LEDCTL register (see Section 8.2.2.1.10). In
addition, the hardware-default configuration for all LED outputs can be specified via an NVM field (see
Section 6.4.7.3), thereby supporting LED displays configured to a particular OEM preference. For more
details on the LEDs see Section 3.6.
1.4 Feature Summary
Tab l e 1 -1 to Ta ble 1-7 list the X550's features in comparison to previous dual-port 10 GbE Ethernet
controllers.
Table 1-1. Network Features
Feature82599X540X550
Compliant with the 10 GbE and 1 GbE Ethernet/802.3ap (KX/KX4)
specification
Compliant with the 10 GbE 802.3ap (KR) specificationYNN
Flow Control support: Send/receive pause frames and receive Fifo
thresholds
Statistics for Management and RMONYYY
802.1q VLAN supportYYY
SerDes interface for external PHY connection or system
interconnect
YNN
1
YYY
YNN
1
Y
1
Y
22333369-004
Introduction—Intel
®
Ethernet Controller X550 Datasheet
Table 1-1. Network Features (Continued)
Feature82599X540X550
SGMII interface
Double VLANYYY
1. All the products support full-size 15.5 KB jumbo packets while in a basic mode of operation. When DCB mode is enabled, or security
engines enabled, or virtualization is enabled, or OS2BMC is enabled, then only 9.5 KB jumbo packets are supported. Packets to/
from the MC longer than 2 KB are filtered out.
Y
(100 Mb/s and
1 GbE only)
NN
Table 1-2. Host Interface Features
Feature82599X540X550
PCIe* version (Speed)
Number of lanesx1, x2, x4, x8x1, x2, x4, x8
64-bit address support for systems using more than 4 GB of
physical memory
Outstanding requests for Tx data buffers161616
Outstanding requests for Tx descriptors888
Outstanding requests for Rx descriptors888
Credits for P-H/P-D/NP-H/NP-D (shared for the two ports)16/16/4/416/16/4/416/16/4/4
Max Payload Size supported512 Bytes512 Bytes512 Bytes
Max Request Size supported2 KB2 KB2 KB
Link layer retry buffer size (shared for the two ports)3.4 KB3.4 KB3.4 KB
Vital Product Data (VPD)YYY
End to End CRC (ECRC)YYY
TLP Processing Hints (TPH)NNY
Latency Tolerance Reporting (LTR)NNY
ID-Based Ordering (IDO)NNY
Access Control Services (ACS)NYY
ASPM optional compliance capabilityNYY
PCIe functions off via pins, while LAN ports are onNYY
PCIe v2.0
(5/2.5 GT/s)
YYY
PCIe v2.1
(5/2.5 GT/s)
PCIe v3.0
(8/5/2.5 GT/s)
x1, x4
x8 (For X550-BT2,
x8 available in
Gen 1/2 only)
Table 1-3. Miscellaneous Features
Feature82599X540X550
Serial Flash Interface (SFI)YYY
4-wire SPI EEPROM interfaceYNN
Configurable LED operation for software or OEM customization of
LED displays
Advanced pass-through-compatible management packet transmit/
receive support
SMBus interface to an external MCYYY
New Management Protocol Standards Support (NC-SI) interface to
an external MC
L2 address filters444
VLAN L2 filters888
Flex L3 port filters161616
Flexible TCO filters441
L3 address filters (IPv4)444
L3 address filters (IPv6)444
Host-based Application-to-BMC Network Communication patch
(OS2BMC)
Flexible MAC AddressNYY
MC inventory of LOM device informationNYY
iSCSI boot configuration parameters via MCNYY
MC monitoring NYY
NC-SI to iMCNYY
NC-SI arbitrationNYY
MCTP over SMBus (pass-through and control)NY (control only)Y
MCTP over PCIe (pass-through and control)NNY
NC-SI package ID via SDP pinsNYY
NC-SI Flow controlNNY
YYY
YYY
NYY
26333369-004
Introduction—Intel
®
Ethernet Controller X550 Datasheet
1.5 Overview: New Capabilities Beyond the X540
1.5.1 NBASE-T Support
Support for 2.5GBASE-T and 5GBASE-T is added to the X550.
1.5.2 Filtering Capabilities
1.5.2.1 Flow Director Improvements
Two new modes, based on cloud tenant ID or on MAC, VLAN are added to the X550 to allow support of
the features described below. Also supported is a better definition of the packet which are candidate to
the flow director filtering and the ability to drop candidate packets that do not match any filter.
1.5.2.2 802.1BR Support
The X550 supports the IEEE 802.1BR specification. It allows forwarding to pools based on unicast or
multicast E-tags and allow insertion and removal of the E-tag using a per pool policy.
To allow L2 filtering on top of the E-tag forwarding, the flow director may be configured to MAC, VLAN
filtering and non matching packets may be dropped.
1.5.2.3 VXLAN and NVGRE Support
The X550 supports detection and off-loading of NVGRE and VXLAN packets. It provides transmit and
receive checksum off-load on both inner and outer IP headers and on TCP header. It also allows
forwarding to a specific VM within a tenant using a new flow director mode.
In the regular IP mode of the flow director, VXLAN and NVGRE flows can be differentiated from regular
IP packets and filtering based on the inner IP/L4 header is supported.
1.5.3 IEEE 1588 Improvements
The X550 improves the support for IEEE 1588 by adding the following features:
• Sampling based on a fixed clock, allowing operation independent from the link speed.
• Clock representation is divided to seconds, nanoseconds and sub-nano parts - allowing easier
handling by software.
• Enabling of sub-ns periodic corrections.
• Gradual time adjustment of frequency corrections preventing single large correction. An interrupt is
provided when the adjustment is done.
• Support for two different target times for SDP toggling.
• Each SDP can be associated with any 1588 functionality.
• Allow timestamp to be received in register or embedded in packet.
The X550 enables reporting and controlling all information exposed in a LOM device via NC-SI using the
MCTP protocol over PCIe in addition to SMBus. The MCTP interface over PCIe is used by the MC to
control the NIC and for pass-through traffic. In addition, the MCTP over SMBus interface can also be
used for pass-through traffic. For more information, refer to Section 11.7.
1.5.4.2 NVM Structures
Management related NVM structures were updated. For further information see Section 6.0.
1.5.4.3 Simplified SMBus TCO Status and Filter Setting
The TCO status in an SMBus received packet was reduced to 8 bytes and most of the information was
removed to keep only the information relevant to the MCs. See Section 11.5.11.2.1.1 for details.
In addition, a generic command was added to enable the setting of most common filtering options
independently of the actual filters implementation. See Section 11.5.11.1.7 and Section 11.5.11.1.8 for
details.
1.5.4.4 Diagnostic Commands
A command was added to the legacy SMBus interface to enable querying the identity of the X550 and
the firmware versions currently running on the X550. See Section 11.5.11.2.6 for details. This
command is the SMBus counterpart of the NC-SI command described in Section 11.6.3.13.2.
1.6 Conventions
1.6.1 Terminology and Acronyms
See Section 16.0, “Glossary and Acronyms”.
1.6.2 Byte Ordering
This section defines the organization of registers and memory transfers, as it relates to information
carried over the network:
• Any register defined in Big Endian notation can be transferred as is to/from Tx and Rx buffers in the
host memory. Big Endian notation is also referred to as being in network order or ordering.
• Any register defined in Little Endian notation must be swapped before it is transferred to/from Tx
and Rx buffers in the host memory. Registers in Little Endian order are referred to being in host
order or ordering.
28333369-004
Introduction—Intel
®
Ethernet Controller X550 Datasheet
Tx and Rx buffers are defined as being in network ordering; they are transferred as is over the network.
Note:Registers not transferred on the wire are defined in Little Endian notation. Registers
transferred on the wire are defined in Big Endian notation, unless specified differently.
1.7 References
The X550 implements features from the following specifications:
IEEE Specifications:
• 10GBASE-T as per the IEEE 802.3an standard.
• 1000BASE-T and 100BASE-TX as per the IEEE standard 802.3-2012 (Ethernet). Incorporates
various IEEE Standards previously published separately. Institute of Electrical and Electronic
Engineers (IEEE).
• NBASE-T as per the IEEE P802.3bz/D1.1 Draft Standard for Ethernet Amendment
• IEEE 1149.6 standard for Boundary Scan (MDI pins excluded)
• IEEE standard 802.3ap, draft D3.2.
• IEEE standard 1149.1, 2001 Edition (JTAG). Institute of Electrical and Electronics Engineers (IEEE).
• IEEE standard 802.1Q for VLAN.
• IEEE 1588 International Standard, Precision clock synchronization protocol for networked
measurement and control systems, 2004-09.
• IEEE P802.1AE/D5.1, Media Access Control (MAC) Security, January 19, 2006.
• IEEE 802.3az Energy Efficient Ethernet Amendment to IEEE 802.3, October 2010.
4A packet enters the PHY through the copper wires.
5The PHY performs the required manipulations on the incoming signal such as LDPC decoding, de-scrambling, PCS
6The PHY delivers the packet to the Rx MAC.
7The MAC forwards the packet to the security block.
8If the packet is identified as a IPsec packet, it is decrypted.
9If the packet matches the pre-programmed criteria of the Rx filtering, it is forwarded to an Rx FIFO.
10The receive DMA fetches the next descriptor from the appropriate host memory ring to be used for the next
11After the entire packet is placed into an Rx FIFO, the receive DMA posts the packet data to the location indicated
12When the packet is placed into host memory, the receive DMA updates all the descriptor(s) that were used by the
13The receive DMA writes back the descriptor content along with status bits that indicate the packet information
14The X550 initiates an interrupt to the software device driver to indicate that a new received packet is ready in host
15The software device driver reads the packet data and sends it to the TCP/IP stack for further processing. The
address location, length, head, and tail pointers of the ring (one of 128 available Rx queues).
places these descriptor(s) in the correct location at the appropriate Rx ring.
decoding, etc.
received packet.
by the descriptor through the PCIe interface.
If the packet size is greater than the buffer size, more descriptor(s) are fetched and their buffers are used for the
received packet.
packet data.
including what offloads were done on that packet.
memory.
software device driver releases the associated buffer(s) and descriptor(s) once they are no longer in use.
32333369-004
Pin Interface—Intel
®
Ethernet Controller X550 Datasheet
2.0 Pin Interface
2.1 Signal Type Definition
SignalDefinitionDC Specification
InStandard 3.3 V I/O buffer, functions as input-only signal.
Out (O)Standard 3.3 V I/O buffer, functions as output-only signal.
T/sTri-state is a 3.3 V bi-directional, tri-state input/output pin.
O/dOpen drain enables multiple devices to share as a wire-OR.Section 12.4.2
A-inAnalog input signals.Section 12.4.5 and Section 12.4.6
A-outAnalog output signals.Section 12.4.5 and Section 12.4.6
2.5 Gb/s. This output carries both data and an
embedded 8 GHz or 5 GHz or 2.5 GHz clock that
is recovered along with data at the receiving
end.
PCIe Serial Data Output: A serial differential
output pair running at 5 Gb/s or 2.5 Gb/s. This
output carries both data and an embedded
5 GHz or 2.5 GHz clock that is recovered along
with data at the receiving end.
Available only in the X550-BT2.
PCIe Serial Data Input: A serial differential
input pair running at 8 Gb/s, 5 Gb/s, or 2.5 Gb/
s. This input carries both data and an embedded
8GHz, 5GHz, or 2.5GHz clock that is
recovered along with data at the receiving end.
PCIe Serial Data Input: A serial differential
input pair running at 5 Gb/s or 2.5 Gb/s. This
input carries both data and an embedded 5 GHz
or 2.5 GHz clock that is recovered along with
data at the receiving end.
Available only in the X550-BT2.
PCIe Differential Reference Clock In (a 100
MHz differential clock input): This clock is
used as the reference clock for the PCIe Tx/Rx
circuitry and by the PCIe core PLL to generate
clocks for the PCIe core logic.
34333369-004
Pin Interface—Intel
®
Ethernet Controller X550 Datasheet
Pin Name
PE_RBIAST3Y4A-Inout
PE_RSENSER3Y5A-Inout
PE_WAKE_NL3W1O/dPup
PE_RST_NM3W2InPup
1. Pup value should be considered as 10 K.
Ball #
(X550-AT2)
Ball #
(X550-BT2)
Type
Internal
Pup/Pdn
External
Pup/Pdn
2.2.2 MDI
See AC/DC specifications in Section 12.4.6.
Pin Name
MDI0_0_p A2A3A-Inout
MDI0_0_nB2B3A-Inout
MDI0_1_p A3A5A-Inout
MDI0_1_nB3B5A-Inout
MDI0_2_p A5A7A-Inout
MDI0_2_nB5B7A-Inout
MDI0_3_p A6A9A-Inout
MDI0_3_nB6B9A-Inout
MDI0_4_p A8A11A-Inout
MDI0_4_nB8B11A-Inout
MDI1_0_p B16A22A-Inout
Ball #
(X550-AT2)
Ball #
(X550-BT2)
Type
Internal
Pup/Pdn
External
Pup/Pdn
Name and Function
BIAS: A 4.75 K ±0.1% resistor should be
connected between RBIAS and RSENSE pins.
Connect resistor as close as possible to the chip.
Resistor is used for internal impedance
compensation and BIAS current generation
circuitry.
Wake: Pulled low to indicate that a Power
Management Event (PME) is pending and the
1
PCIe link should be restored. Defined in the
PCIe specifications.
Power and Clock Good Indication: Indicates
that power and the PCIe reference clock are
within specified values. Defined in the PCIe
specifications. Also called PCIe Reset.
Name and Function
Port 0 pair A+ of the Line Interface:
Connects to the Pair A+ input of the
transformer. On reset, set to high impedance.
Port 0 pair A- of the Line Interface:
Connects to the Pair A- input of the transformer.
On reset, set to high impedance.
Port 0 pair B+ of the Line Interface:
Connects to the Pair B+ input of the
transformer. On reset, set to high impedance.
Port 0 pair B- of the Line Interface:
Connects to the Pair B- input of the transformer.
On reset, set to high impedance.
Port 0 pair C+ of the Line Interface:
Connects to the Pair C+ input of the
transformer. On reset, set to high impedance.
Port 0 pair C- of the Line Interface:
Connects to the Pair C- input of the transformer.
On reset, set to high impedance.
Port 0 pair D+ of the Line Interface:
Connects to the Pair D+ input of the
transformer. On reset, set to high impedance.
Port 0 pair D- of the Line Interface:
Connects to the Pair D- input of the transformer.
On reset, set to high impedance.
Port 0 Analog Test+: Connects to the pair E+
input of the transformer.
Port 0 Analog Test-: Connects to the pair Einput of the transformer.
Port 1 pair A+ of the Line Interface:
Connects to the Pair A+ input of the
transformer. On reset, set to high impedance.
2.2.8.1 Pin Differences in the X550-AT Single Port Device
NC = Pin is not connected in the package.
NameBall # (X550-AT2)Connection (X550-AT)
MDI1_0_pB16NC
MDI1_0_nC16NC
MDI1_1_pA14NC
MDI1_1_nB14NC
MDI1_2_pA12NC
MDI1_2_nB12NC
MDI1_3_pA11NC
MDI1_3_nB11NC
MDI1_4_pA9NC
MDI1_4_nB9NC
LAN1_DIS_NM16NC
For additional information on these pins in the X550-AT2, see Section 2.2.2.
2.2.9 Miscellaneous
See AC/DC specifications in Section 12.4.4.1.
Pin Name
LAN_PWR_GOODN/AL24InPupPup
BYPASS_PORN/AH23InPdnPdn
AUX_PWRH3P2InNote
MAIN_PWR_OKG3R2InNote
Ball #
(X550-AT2)
Ball #
(X550-BT2)
Type
Internal
Pup/Pdn
External
Pup/Pdn
1
2
3
4
LAN Power Good: A 3.3 V input signal. A
transition from low to high initializes the
X550 into operation. If not used
(BYPASS_POR = 0b), an internal Power-onReset (POR) circuit triggers the X550 power
up.
Bypass POR
Auxiliary Power Available: When set,
indicates that auxiliary power is available
and the X550 should support D3
state if enabled to do so. This pin is latched
at the rising edge of LAN_PWR_GOOD.
Main Power Good: Indicates that platform
main power is up. Must be connected
externally.
latched at the rising edge of
LAN_PWR_GOOD or PE_RST_N or In-Band
PCIe Reset. If this pin is not connected or
driven high during initialization, LAN 1 is
enabled. If this pin is driven low during
initialization, LAN 1 port is disabled.
LAN 0 Disable: This pin is a strapping
option pin latched at the rising edge of
LAN0_DIS_N
M15
(Strap)
K23In
5
PupPup
LAN_PWR_GOOD or PE_RST_N or In-Band
1
PCIe Reset. If this pin is not connected or
driven high during initialization, LAN 0 is
enabled. If this pin is driven low during
initialization, LAN 0 port is disabled.
Strap on
ENCRYPTION_EN
FLSH_SI
M1InPupPdn/Pup
(K3)
THERM_D0_P
THERM_D0_N
1. Pup value should be considered as 1 K.
2. Pdn value should be considered as 1 K.
3. Connect AUX_PWR signal to Pup if AUX power is available. Connect Pdn if AUX power is not available. Pup/Pdn value should be
considered as 1 K.
4. Connect MAIN_PWR_OK signal to Main Power through Pup resistor. Pup value should be considered as 10 K.
C3
C2
F4
F3
A-Inout
A-Inout
Encryption Enable: Enable/disable for the
internal IPsec engines.
1
When pulled up, encryption features are
enabled.
Thermal Diode Reference: Can be used
to measure on-die temperature.
5. For the X550-AT and X550-AT2, this pin is input during PCIe_RST_N assertion only, and is output after that.
2.2.10 JTAG
See AC specifications in Section 12.4.4.2.
Pin Name
Ball #
(X550-AT2)
JTCKF16Y22In-OnlyPupPdn
JTDIF14W22In-OnlyPupPup
JTDOF15V22OutPup
JTMSG14W21In-OnlyPupPup
JTRST_NH14W23In-OnlyPupPdn
1. Pdn value should be considered as 470 .
2. Pup value should be considered as 10 K.
3. Pup value should be considered as 3.3 K
Note:If the JTAG is disconnected, use the external pull-up or pull-down values listed.
Ball #
(X550-BT2)
Type
Internal
Pup/Pdn
External
Pup/Pdn
1
2
3
2
1
Name and Function
JTAG Clock Input
JTAG Data Input
JTAG Data Output
JTAG TMS Input
JTAG Reset Input: Active low reset for the
JTAG port.
42333369-004
Pin Interface—Intel
®
Ethernet Controller X550 Datasheet
2.2.11 Power Supplies
See AC specifications in Section 12.3.1.
Pin NameBall # (X550-AT2)Ball # (X550-BT2) TypeName and Function
The X550 supports Rev 3.0 of the PCIe base specification.
On top of the capabilities required by the PCIe specifications, The X550 supports optional functionality
as listed in this section:
• All PCI functions are native PCIe functions.
• Physical Layer:
— Support for 2.5 GT/s, 5 GT/s, and 8 GT/s
— Interface width of 1, 4 or 8 PCIe lanes (8 lanes are supported only in the X550-BT2, and only at
5 GT/s or 2.5 GT/s speeds.)
— Full swing and half swing signaling
— Lane reversal
• Transaction layer mechanisms:
— 64-bit and 32-bit memory address spaces
— Removal of I/O BAR (optional)
— Relaxed ordering
— Flow control update timeout mechanism
— ID-based ordering (IDO)
— Packet sizes: Maximum packet size: 512, Maximum read request size: 2 KB
— Function-Level Reset (FLR)
— TLP Processing Hints (TPH)
• Reliability:
— Advanced Error Reporting (AER)
— End-to-End CRC (ECRC) generation and checking
— Recovery from data poisoning
— Completion Timeout
Rules for accesses to the CSR space (both memory BAR and MSI-X BAR):
• Write accesses:
— Zero-length writes have no internal impact (nothing written, no effect such as clear-by-write).
The transaction is treated as a successful operation (no error event).
— CSR writes are 32-bit or 64-bit only. Larger or partial CSR writes are handled as Completer
Abort - data is dropped and an error is generated per PCIe rules.
• Read accesses:
— Partial reads with at least one byte disabled are handled as a full read. Any side effect of the full
read (such as clear by read) is also applicable to partial reads. The completion on PCIe obeys
the specification rules regarding the number of bytes reported in the completion.
— Zero-length reads generate a completion, but the register is not accessed and undefined data is
returned.
— CSR reads are 32-bit or 64-bit only. Larger CSR read requests are handled as Completer Abort.
The completion includes a CA status and an error is generated per PCIe rules.
— Some 64-bit reads are handled atomically (i.e. not interleaved with any other requests). This
applies mainly to reading counters, where all 64-bit need to be read simultaneously. Such
registers are explicitly marked in their description.
Rules for accessing the Flash space in the memory BAR or the Expansion ROM BAR:
• Write accesses:
— Writes to Flash are 8-bit wide only.
— Any larger write accesses are handled as Completer Abort - data is dropped and an error is
generated per PCIe rules.
• Read accesses:
— Reads to Flash are 32-bit wide.
— Partial reads with at least one byte disabled are handled internally as a full read. That is, any
side effect of the full read (such as clear by read) is also applicable to partial reads. The
completion on PCIe obeys the specification rules regarding the number of bytes reported in the
completion.
— Larger CSR read requests are handled as Completer Abort - the completion includes a CA status
• Write accesses:
— Write accesses are 32-bit wide.
— Zero-length writes have no internal impact (nothing written, no effect such as clear-by-write).
The transaction is treated as a successful operation (no error event).
— Other accesses (partial writes, larger writes) are handled as Completer Abort - data is dropped
and an error is generated per PCIe rules.
• Read accesses:
— Reads to the I/O BAR are 32-bit wide.
— Partial reads with at least one byte disabled are handled internally as a full read. That is, any
side effect of the full read (such as clear by read) is also applicable to partial reads. The
completion on PCIe obeys the specification rules regarding the number of bytes reported in the
completion.
— Larger CSR read requests are handled as Completer Abort - the completion includes a CA status
and an error is generated per PCIe rules.
3.1.2.1.1.3 Messages
MCTP messages may contain payload of up to 64 bytes.
3.1.2.1.2 Support for Dynamic Changes
The X550 captures the Bus Number and Device Number per each Configuration Write Request.
However, dynamic change of Bus Number or Device Number is not supported. Rather, the PCIe link
should be quiescent prior to such a change, including reception of all completion for previous requests.
3.1.2.2 Transaction Types Initiated by the X550
Table 3-2. Transaction Types Initiated by the Transaction Layer
• Max Payload Size — The value of the Max Payload Size Supported field in the Device Capabilities
Register is loaded from NVM.
— Hardware default is 512.
— System software then programs the actual value into the Max Payload Size field of the Device
Control Register.
• Non-ARI mode: If not all functions are programmed with the same value, the max payload
size used for all functions is the minimum value programmed among all functions.
•ARI mode: Max_Payload_Size is determined solely by the setting in Function 0.
• Max Read Request Size — The X550 supports read requests of up to 2 KB.
— The actual maximum size of a read request is defined as the minimum {2 KB, Max Read
Request Size field in the Device Control Register}.
The number of outstanding memory read requests is bounded by the following:
• The total number of outstanding requests is not more than 32 requests. These are shared by all
sources for memory reads.
3.1.2.2.1 Data Alignment
Requests must never specify an address/length combination that causes a memory space access to
cross a 4 KB boundary. The X550 therefore breaks requests into 4 KB-aligned requests (if needed). This
does not place any requirement on software. However, if software allocates a buffer across a 4 KB
boundary, hardware issues multiple requests for the buffer. Software should consider aligning buffers to
a 4 KB boundary in cases where it improves performance. The maximum size of a read request is
defined as the minimum {2 KB bytes, Max_Read_Request_Size}
The general rules for packet alignment are as follows. Note that these apply to all the X550 requests
(read/write):
• The length of a single request does not exceed the PCIe limit of MAX_PAYLOAD_SIZE for write and
MAX_READ_REQ for read.
• The length of a single request does not exceed the X550 internal limitations.
• A single request does not span across different memory pages as noted by the 4 KB boundary
alignment previously mentioned.
If a request can be sent as a single PCIe packet and still meet the general rules for packet alignment, it
is not broken at the cache line boundary but rather sent as a single packet. However, if any of the three
general rules require that the request is broken into two or more packets, the request is broken at the
cache line boundary.
For requests with data payload, if the payload size is larger than (MAX_PAYLOAD_SIZE CACHELINE_SIZE), the request is broken into multiple TLPs staring at the first cache line boundary
following the (MAX_PAYLOAD_SIZE - CACHELINE_SIZE) bytes. For example, if MAX_PAYLOAD_SIZE =
256 bytes and CACHELINE_SIZE = 64 bytes, a 1 KB request starting at address 0x...10 is broken into
TLPs such that the first TLP contains 240 bytes of payload (since 240B + 10h = 256B is on cache line
boundary).
The system cache line size is controlled by the PCI_CNF2.CACHELINE_SIZE bit, loaded from the NVM.
Note that the Cache Line Size Register in the PCI configuration space is not related to the
PCI_CNF2.CACHELINE_SIZE and is solely for software use.
Message packets are special packets that carry a message code. The upstream device transmits special
messages to the X550 by using this mechanism. The transaction layer decodes the message code and
responds to the message accordingly.
Table 3-3. Supported Messages in the X550 — as a Receiver
Message
Code [7:0]
0x14100bPM_Active_State_NAKAccepted
0x19011bPME_Turn_OffAccepted
0x40, 0x41,
0x43, 0x44,
0x45, 0x47,
0x48
0x50100bSlot power limit support (has one Dword
0x7E000b, 010b, 011b, 100bVendor defined type 0 Drop and handle as an Unsupported
0x7F100bVendor defined type 1 Silently drop.
0x7F010b, 011b, 000bVendor defined type 1 Send to MCTP reassembly if Vendor ID =
3.1.2.4.1 Traffic Class (TC) and Virtual Channels (VC)
The X550 only supports TC = 0 and VC = 0 (default).
3.1.2.4.2 TLP Processing Hints (TPH)
The X550 supports the TPH capability defined in the PCI Express specification. It does not support
Extended TPH requests.
Existence of a TLP Processing Hint (TPH) is indicated on the PCIe link by setting the TH bit in the TLP
header. Using the PCIe TLP Steering Tag (ST) and Processing Hints (PH) fields, The X550 can provide
hints to the root complex about the destination (socket ID) and about data access patterns (locality in
Cache) when executing DMA memory writes or read operations.
The X550 exposes a PCIe TPH capability structure (See Section 9.2.4.5) with no steering table.
See Section 7.5 for details on the usage of TPH.
3.1.2.5 Ordering Rules
The X550 meets the PCIe ordering rules by following the PCI simple device model:
1. Deadlock Avoidance — The X550 meets the PCIe ordering rules that prevent deadlocks:
a. Posted writes overtake stalled read requests. This applies to both target and master directions.
For example, if master read requests are stalled due to lack of credits, master posted writes are
allowed to proceed. On the target side, it is acceptable to timeout on stalled read requests to
allow later posted writes to proceed.
b. Target posted writes overtake stalled target configuration writes.
c. Completions overtake stalled read requests. This applies to both target and master directions.
For example, if master read requests are stalled due to lack of credits, completions generated
by the X550 are allowed to proceed.
2. Descriptor/Data Ordering — The X550 ensures that a Rx descriptor is written back on PCIe only
after the data that the descriptor relates to is written to the PCIe link.MSI and MSI-X Ordering
Rules. System software might change the MSI or MSI-X tables during run-time. Software expects
that interrupt messages issued after the table has been updated are using the updated contents of
the tables.
a. Since software does not know when the tables are actually updated in the X550, a common
scheme is to issue a read request to the MSI or MSI-X table (a PCI configuration read for MSI
and a memory read for MSI-X). Software expects that any message issued following the
completion of the read request, is using the updated contents of the tables.
b. Once an MSI or MSI-X message is issued using the updated contents of the interrupt tables, any
consecutive MSI or MSI-X message does not use the contents of the tables prior to the change.
3. The X550 meets the rules relating to independence between target and master accesses:
a. The acceptance of a target posted request does not depend upon the transmission of any TLP.
b. The acceptance of a target non-posted request does not depend upon the transmission of a
non-posted request.
c. Accepting a completion does not depend upon the transmission of any TLP.
56333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
3.1.2.5.1 Relaxed Ordering
The X550 takes advantage of the relaxed ordering rules in PCIe. By setting the relaxed ordering bit in
the packet header, the X550 enables the system to optimize performance in the following cases:
1. Relaxed ordering for descriptor and data reads — When the X550 masters a read transaction, its
split completion has no ordering relationship with the writes from the CPUs (same direction). It
should be allowed to bypass the writes from the CPUs.
2. Relaxed ordering for receiving data writes — When the X550 masters receive data writes, it also
enables them to bypass each other in the path to system memory because software does not
process this data until their associated descriptor writes are done.
3. The X550 cannot relax ordering for receive descriptor writes or an MSI write.
Relaxed ordering is enabled in the X550 by clearing the CTRL_EXT.RO_DIS bit. Relaxed ordering is
further controlled through the Enable Relaxed Ordering bit in the PCIe Device Control Register
(Section 9.2.3.6.5).
3.1.2.5.2 ID-Based Ordering (IDO)
ID-based ordering was introduced in the PCIe rev. 2.1 specification. When enabled, the X550 sets IDO
in all applicable TLPs defined in the PCIe specification.
This capability allows a supporting root complex to relax ordering rules for TLPs sent by different
requesters.
IDO is enabled when all of the following conditions are met:
•The NVM PCI_CAPSUP.IDO Enable bit is set (Section 6.4.5 and Section 8.2.2.5.11).
•The PCIe IDO Request Enable bit (for requests) or the IDO Completion Enable bit (for completions)
in Device Control 2 Register is set (Section 9.2.3.6.11).
3.1.2.6 Flow Control
3.1.2.6.1 Flow Control Rules
The X550 only implements the default Virtual Channel (VC0). A single set of credits is maintained for
VC0.
Table 3-5. Flow Control Credits Allocation
Credit TypeOperationsNumber of Credits (Dual Port)
Posted Request Header (PH)Target write
Message (one unit)
Posted Request Data (PD)Target Write (Length/16 bytes = one)
• UpdateFC packets are sent immediately when a resource becomes available.
• The X550 follows the PCIe recommendations for frequency of UpdateFC FCPs.
• Specific rules apply in L0 or L0s link states. See PCIe specification.
3.1.2.6.2 Flow Control Timeout Mechanism
The X550 implements the optional flow control update timeout mechanism. See the PCIe specification.
3.1.2.7 End-to-End CRC (ECRC)
The X550 supports ECRC as defined in the PCIe specification. The following functionality is provided:
• Inserting ECRC in all transmitted TLPs:
— The X550 indicates support for inserting ECRC in the ECRC Generation Capable bit of the PCIe
configuration registers. This bit is loaded from the ECRC Generation NVM bit.
— Inserting ECRC is enabled by the ECRC Generation Enable bit of the PCIe configuration
registers. VFs follow the behavior of their PF.
• ECRC is not added to MCTP messages (per MCTP specification) unless the
PCI_CAPSUP.ECRC_MCTP_GEN bit is set.
• ECRC is checked on all incoming TLPs. A packet received with an ECRC error is dropped. Note that
for completions, a completion timeout occurs later (if enabled).
— The X550 indicates support for ECRC checking in the ECRC Check Capable bit of the PCIe
configuration registers. This bit is loaded from the ECRC Check NVM bit.
— Checking of ECRC is enabled by the ECRC Check Enable bit of the PCIe configuration registers.
ECRC checking is done if enabled by at least one physical function (enablement is not done via
VFs).
• ECRC errors are reported on all physical functions (PFs) enabled for ECRC checking.
• System software can configure ECRC independently per each physical function.
3.1.3 Link Layer
3.1.3.1 ACK/NAK Scheme
The X550 supports two alternative schemes for ACK/NAK rate:
• NAKs are sent as soon as identified.
• ACKs are sent per Section 3.5.3.1 (Table 3-7, Table 3-8, and Table 3-9) in the PCIe Base
Specification.
58333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
3.1.3.2 Supported DLLPs
The following DLLPs are supported by the X550 as a receiver:
•ACK
•NAK
•PM_Request_Ack
•InitFC1-P
•InitFC1-NP
•InitFC1-Cpl
•InitFC2-P
•InitFC2-NP
•InitFC2-Cpl
•UpdateFC-P
•UpdateFC-NP
•UpdateFC-Cpl
The following DLLPs are supported by the X550 as a transmitter:
•ACK
•NAK
•PM_Enter_L1
•PM_Enter_L23
•InitFC1-P
•InitFC1-NP
•InitFC1-Cpl
•InitFC2-P
•InitFC2-NP
•InitFC2-Cpl
•UpdateFC-P
•UpdateFC-NP
Note:UpdateFC-Cpl is not sent because of the infinite FC-Cpl allocation.
3.1.3.3 Transmit End Data Bit (EDB) Nullifying — End Bad
A TLP may be signaled as EDB or poisoned if during its transmission from the device, an internal
memory error is detected that may corrupt the TLP payload.
The X550 supports PCIe 2.1 and PCIe 3.0.
The following configuration controls link speed:
• PCIe Supported Link Speeds bit — Indicates the link speeds supported by the X550.
• PCIe Current Link Speed bit — Indicates the negotiated link speed.
• PCIe Target Link Speed bit — used to set the target compliance mode speed when software is
using the Enter Compliance bit to force a link into compliance mode. The default value is loaded
from the highest link speed supported defined by the above Supported Link Speeds.
The X550 does not initiate a hardware autonomous speed change.
The X550 supports entering compliance mode at the speed indicated in the Target Link Speed field in
the PCIe Link Control 2 register (Section 9.2.3.6.13). Compliance mode functionality is controlled via
the PCIe Link Control 2 register.
3.1.4.2 Link Width
The X550 supports a maximum link width of x8, x4, or x1.The maximum link width is loaded into the
Max Link Width field of the PCIe Capability register (LCAP[11:6]). Hardware default is the x4 link for the
X550-AT2, and x8 link for the X550-BT2.
During link configuration, the platform and the X550 negotiate on a common link width. The link width
must be one of the supported PCIe link widths (x1, x4, x8), such that:
• If Maximum Link Width = x8, the X550 negotiates to either x8, x4 or x1.
• If Maximum Link Width = x4, the X550 negotiates to either x4 or x1
• If Maximum Link Width = x1, the X550 only negotiates to x1
When negotiating for x4, or x1 link, the X550 may negotiate the link to reside starting from physical
lane 0 or starting from physical lane 4.
The X550 does not initiate a hardware autonomous link width change.
When operating in x8 link width the X550 does not support Gen3 link speed (8GT/s).
The x8 link width is available only in the X550-BT2.
60333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
3.1.4.3 Lane Configurations
The X550 supports lane reversal and degraded modes.
The following general rules determine how the device reacts in different cases of lanes configuration:
• If lane 0 is found valid, the X550 does not initiate lane reversal. The link partner (LP) may initiate
lane reversal (to end up with an optimal lane width) and the X550 consents with the lane reversal.
• If lane 0 is found invalid, the X550 initiates lane reversal. Lane reversal succeeds if the link partner
supports link reversal.
• If the lanes at both ends of the port (i.e. lanes 0 & 7 for x8, lanes 0 & 3 for x4, lane 0 for x1) are
invalid, a link is not established.
Note:Some of the configurations or transitions assume lane reversal is done by the link partner. If
the link partner does not support a specific transition, the respective configuration is not
provided on that system.
Figure 3-2, Figure 3-3, and Figure 3-4 depict the initial link width configuration and link degradation
options. In Figure 3-2 and Figure 3-3, the upper part of the Figure describes link options where the Link
Partner (LP) and the X550 (NIC) are aligned. The bottom part of the Figure describes link options where
the Link Partner and the X550 are reversed in order.
• Figure 3-2 applies when either the Link partner or the X550 is physically set to x8.
• Figure 3-3 applies when either the Link partner or the X550 is physically set to x4 and both are not
physically set x8.
• Figure 3-4 applies when both the Link partner or the X550 is physically set to x1.
Figure 3-4. Link Width Configurations for a x1 Port
3.1.4.4 Receiver Framing Requirements
This section applies to Gen3 operation only and lists the optional capabilities defined in Section
4.2.2.3.3 (Receiver Framing Requirements) of the PCIe base specification.
The device implements the optional Gen3 receiver framing error checks other than:
• TLP Token length=0
• Mixed order sets across lanes
3.1.5 Error Events and Error Reporting
3.1.5.1 General Description
PCIe defines three error reporting paradigms: the baseline capability, the Advanced Error Reporting
(AER) capability, and a proprietary mechanism. The baseline error reporting capabilities are required of
all PCIe devices and define the minimum error reporting requirements. The AER capability is defined for
more robust error reporting and is implemented with a specific PCIe capability structure. Both
mechanisms are supported by the X550. The proprietary error reporting mechanism used for error
better handled by the software device driver using internal CSRs is described in Section 3.1.5.8.
The SERR# Enable and the Parity Error bits from the Legacy Command register also take part in the
error reporting and logging mechanism.
In a multi-function device, PCIe errors that are not related to any specific function within the device are
logged in the corresponding status and logging registers of all functions in that device. Figure 3-5
shows, in detail, the flow of error reporting in the X550.
64333369-004
Interconnects—Intel
Device Status ::
Correctable Error Detected
Device Status ::
Non-Fatal Error Detected
Device Status ::
Fatal Error Detected
Device Status ::
Unsupported Request Detected
Status ::
Signaled Target Abort
Status ::
Received Target Abort
Status ::
Received Master Abort
Status ::
Detected Parity Error
Root Error Status
Correctable Error Status
Correctable Error Mask
Uncorrectable Error Status
Uncorrectable Error Mask
Uncorrectable Error Severity
Status Reporting - Not Gated
Error Sources
(Associated with Port)
Device Control ::
Correctable Error Reporting Enable
Device Control ::
Unsupported Request Reporting Enable
Device Control ::
Non-Fatal Error Reporting Enable
Device Control ::
Fatal Error Reporting Enable
Report Error Command ::
Correctable Error Reporting Enable
Report Error Command ::
Non-Fatal Error Reporting Enable
Report Error Command ::
Fatal Error Reporting Enable
Interrupt
Command::
Parity Error Response
Bridge Control::
SERR Enable
Error Message
Processing
Rcv
Msg
Secondary Side Error Sources
System
Error
Root Control::
System Error on Correctable Error Enable
Root Control::
System Error on Non-Fatal Error Enable
Root Control::
System Error on Fatal Error Enable
Status::
Master Data Parity Error
Status::
Signaled System Error
Secondary Status::
Detected Parity Error
Secondary Status::
Signaled Master Abort
Secondary Status::
Received Target Abort
Secondary Status::
Received Target Abort
Bridge Control::
Parity Error Response Enable
Secondary Status::
Master Data Parity
Error
Secondary Status::
Received System Error
Either Implementation
Acceptable – the unqualified
version is more like PCI P2P
bridge spec
• Violations of flow control
initialization protocol.
• TLP with error forwarding.Uncorrectable
•Receipt of TLP with
unsupported request type.
• Receipt of an unsupported
vendor defined type 0
message.
• Invalid message code.
• Wrong function number.
• Received TLP outside BAR
address range.
• Receipt of a Request TLP
during D3hot, other than
Configuration and Message
requests.
expired.
Correctable
Send ERR_CORR
Correctable
Send ERR_CORR
Send ERR_CORR
Send ERR_CORR
Send ERR_CORR
Uncorrectable
Send ERR_FATAL
ERR_NONFATAL
Log Header
ERR_NONFATAL
Log Header
Uncorrectable
ERR_NONFATAL
Log header
Uncorrectable
ERR_NONFATAL
TLP to initiate NAK, drop data.
DLLP to drop.
TLP to initiate NAK, drop data.
DLLP todrop.
Follow LL rules.
Follow LL rules.
If completion TLP:
Error is non-fatal (default case):
• Send error message if advisory.
• Retry the request once and send
advisory error message on each failure.
• If fails, send uncorrectable error
message.
Error is defined as fatal:
• Send uncorrectable error message.
Error is non-fatal (default case):
• Send error message if advisory.
Error is defined as fatal:
• Send uncorrectable error message.
Send completion with UR.
Error is non-fatal (default case):
• Send error message if advisory.
Error is defined as fatal:
• Send uncorrectable error message.
66333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
Table 3-6. Response and Reporting of PCIe Error Events (Continued)
Error NameError EventsDefault SeverityAction
Completer Abort• Received target access with
Unexpected
Completion
Receiver Overflow• Received TLP beyond
Flow Control
Protocol Error
Malformed TLP (MP)• Data payload exceed
Completion with
Unsuccessful
Completion Status
illegal data size per
Section 3.1.2.1.1.
• Received completion without a
request for it (Tag, ID, etc.).
allocated credits.
• Minimum initial flow control
advertisements.
• Flow control update for infinite
credit advertisement.
Max_Payload_Size.
• Received TLP data size does
not match length field.
• TD field value does not
correspond with the observed
size.
• PM messages that do not use
TC0.
• Usage of unsupported VC.
• Target request crosses a 4KB
boundary.
Uncorrectable.
ERR_NONFATAL
Log header
Uncorrectable
ERR_NONFATAL
Log Header
Uncorrectable
ERR_FATAL
Uncorrectable.
ERR_FATAL
Uncorrectable
ERR_FATAL
Log Header
No Action (already done
by originator of
completion)
Send completion with CA.
Discard TLP.
Receiver behavior is undefined.
Receiver behavior is undefined.
Drop the packet, free FC credits.
Free FC credits.
3.1.5.3 Completion Timeout Mechanism
The X550 supports completion timeout as defined in the PCIe specification.
The X550 controls the following aspects of completion timeout:
• Disabling or enabling completion timeout.
—The PCIe Completion Timeout Disable Supported bit in the Device Capabilities 2 Register
(Section 9.2.3.6.10) is hardwired to 1b to indicate that disabling completion timeout is
supported
—The PCIe Completion Timeout Disable bit in Device Control 2 Register controls whether
completion timeout is enabled
• A programmable range of timeout values.
— The X550 supports all four ranges as programmed in the Completion Timeout Ranges
Supported field of the Device Capabilities 2 Register. The actual completion timeout value is
written in the Completion Timeout Value field of Device Control 2 Register (Section 9.2.3.6.10)
The following sequence takes place when completion timeout is detected:
• The appropriate message is sent on PCIe as described in Ta b le 3-6 .
• The affected queue or client takes action based on the nature of the original request.
If a TLP is received with an error-forwarding trailer, the packet is dropped and is not delivered to its
destination. The X550 then reacts as listed in Tabl e 3- 6.
The following sequence takes place when a poisoned TLP is received:
• The appropriate message is sent on PCIe as described in Ta b le 3-6 .
• An interrupt is issued.
• If the TLP is a completion, a completion timeout follows at some later time. Processing continues as
described in Section 3.1.5.3.
System logic is expected to trigger a system-level interrupt to signal the operating system of the
problem. Operating systems can then stop the process associated with the transaction, re-allocate
memory to a different area instead of the faulty area, etc.
3.1.5.5 Completion with Unsuccessful Completion Status
A completion arriving with unsuccessful completion status (either UR or CA) is dropped and not
delivered to its destination. A completion timeout follows at some later time. Processing continues as
described in Section 3.1.5.3.
3.1.5.6 Error Pollution
Error pollution can occur if error conditions for a given transaction are not isolated to the error's first
occurrence. If the PHY detects and reports a receiver error, to avoid having this error propagate and
cause subsequent errors at the upper layers, the same packet is not signaled at the data link or
transaction layers. Similarly, when the data link layer detects an error, subsequent errors that occur for
the same packet are not signaled at the transaction layer.
3.1.5.7 Blocking on Upper Address
The PCI_UPADD register blocks master accesses from being sent out on PCIe if the TLP address
exceeds some upper limit. Bits [31:1] correspond to bits [63:33] in the PCIe address space,
respectively.
When a bit is set in GLPCI_UPADD[31:1], any transaction in which the corresponding bit in its address
is set, is blocked and not sent over PCIe. If all register bits are cleared, there is no effect (in other
words, no TLPs are blocked by this mechanism).
The PCI_UPADD register is loaded from NVM with a value allowing all addresses to pass. The software
device driver should override this value with a system dependent value.
Processing a blocked transaction:
• Write transaction
— The transaction is dropped.
— Set the “Exceeded upper address limit (write requests)” event in the PCIe errors register (see
Section 3.1.5.8).
— An interrupt is issued as described in Section 3.1.5.8.
68333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
• Read transaction
— The transaction is dropped.
— Set the “Exceeded upper address limit (read requests)” event in the PCIe errors register (see
Section 3.1.5.8).
— The originating internal client is notified.
— The affected queue or client takes action based on the nature of the original request. An
interrupt is issued to the respective PF.
3.1.5.8 Proprietary Error Reporting
The PCIe specification defines how to report errors to system software. There are, however, error
events that the device driver should be aware of or that the device driver is in better position to handle
and recover from. This section describes the mechanism to report PCIe related errors to device drivers.
Several CSRs are dedicated to this functionality, with a separate bit allocated per error type (see
Tab l e 3 -7):
• The “PCIe Errors Reported” register (PCI_PCIERR - RO) indicates which errors are reported using
this mechanism. It is shared by all PFs. It is loaded from NVM. All non-reserved errors are enabled.
• The “PCIe Interrupt Cause” register (PCI_ICAUSE - RW1C) indicates pending errors for errors set in
the PCIe Errors Reported register. It is dedicated per PF.
• The “PCIe Interrupt Enable” register (PCI_IENA - RW) determines if an interrupt should be issued to
the respective PCI function on an error event. It is dedicated per PF.
Reporting an error to the PF driver involves the following steps:
• The device checks if the respective bit is set in the PCIe Errors Reported register. If cleared, done.
Else, continue
• The respective bit is set in the “PCIe Interrupt Cause” register
• If the respective bit is set in the “PCIe Interrupt Enable” register, an interrupt is issued to the PCI
function. The PCI_EXCEPTION cause is used (see the EICR register - Section 8.2.2.6.1).
Table 3-7. PCIe Errors Reported to Device Software
Error EventIndexDescription and CommentsFunction Association
Exceeded upper address
limit (read requests)
Exceeded upper address
limit (write requests)
Reserved02Reserved entriesN/A
Poisoned TLP received03See Section 3.1.5.4Sent to PF
Reserved04-05Reserved entriesN/A
ECRC error detected06ECRC check failed on a received TLP. See
Unsupported Request Request Type
Unsupported Request Vendor Message
333369-00469
00See Section 3.1.5.7Sent to PF
01See Section 3.1.5.7Sent to PF
Section 3.1.5.7
07Request causes an Unsupported Request due to
receipt of TLP with unsupported Request Type
08Request causes an Unsupported Request due to
receipt of an Unsupported Vendor Defined Type 0
Message
Sent to all PFs
Sent to PF
Sent to PF unless r[2:0] =
Broadcast from Root Complex, in
which case sent to all PFs
• Link and Physical layer event counters — Section 3.1.6.2
• Bandwidth counters — Section 3.1.6.3
• Latency counters — Section 3.1.6.4
General characteristics of the counters:
• Software can reset, stop, or start the counters.
• The counters are shared by all PCI functions (“Service” mode of sharing).
Part of the registers that manage the operation of the performance counters are accessed via the
PCI_LCBADD and PCI_LCBDATA register pair.
Reading a register via the PCI_LCBADD/PCI_LCBDATA pair is done as follows:
• Write the following values into the PCI_LCBADD register.
— ADDRESS — The 18-bit register address. See below for the specific address per each register.
— BLOCK_ID — Defines the sub-unit where the register resides. Use the value 0x7F to access
registers mentioned in this section.
— LOCK — Use if need to gain access in case of multiple agents accessing the PCI_LCBADD/
PCI_LCBDATA registers.
• Read the PCI_LCBDATA register.
Note:Although PCI_LCBDATA is a 32-bit register, the registers that maintain the actual count
are read as atomic 64-bit reads. The PCI_LCBADD contains the address of the low DW,
and reading PCI_LCBDATA returns a 64-bit value.
70333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
Writing a register via the PCI_LCBADD/PCI_LCBDATA pair is done as follows:
• Write the following values into the PCI_LCBADD register.
— ADDRESS — The 18-bit register address. See below for the specific address per each register.
— BLOCK_ID — Defines the sub-unit where the register resides. For actual values, consult the text
below.
— LOCK — Use if need to gain access in case of multiple agents accessing the PCI_LCBADD/
PCI_LCBDATA registers.
• Write to the PCI_LCBDATA register.
3.1.6.1 Event Counters - Transaction Layer
Counters operate in one of the following modes:
• Count Mode — The counter increments when the respective event occurred
• Leaky Bucket Mode — The counter increments only when the rate of events exceeded a certain
value. See Section 3.1.6.1.2 for more details.
The list of events supported by the X550 are listed in Tabl e 3 -8 .
Table 3-8. PCIe Statistic Events Encoding
Events
Cycles0x00Increment on each PCIe clock tick
Bad Request TLPs0x10Number of bad TLPs arriving to the transaction layer.These include:
Bad Completions0x11Number of bad Completions received. These include:
Completion Timeout0x12Number of completion timeout events
Poisoned TLP0x13Number of TLPs received with poisoned data
ECRC Check0x14Number of TLPs that foil ECRC check
Retry Buffer Timeout0x31Number of replay events that happen due to timeout (does not count replay
Retry Buffer Replay Roll-Over0x32Increment when a replay is initiated for more than 3 times
Receive Error0x50Increment when one of the following occurs:
Surprise Link Down0x51Increment when link is unpredictably down (Not because of reset or DFT)
Event
Mapping
(Hex)
Description
Transaction Layer Events
• Request caused UR
• Request caused CA
• Malformed TLP
• Unexpected Completion
•UR status
•CA status
Link Layer Events
initiated due to NACK)
Physical Layer Events
1. Decoder error occurred during training in the PHY. It is reported only when
training ends.
2. Decoder error occurred during link-up or till the end of the current packet (in
case the link failed). This error is masked when entering/exiting EI.
The following CSR fields control operation of the Count mode:
• Four 32-bit counters PCI_GSCN_0_3 track events and increment on each occurrence of an event.
— The four 32-bit counters can also operate in a two 64-bit mode to count long intervals or large
payloads.
• Registers PCI_GSCN_0_3[0] and PCI_GSCN_0_3[1] form the first 64-bit counter. Registers
PCI_GSCN_0_3[2] and PCI_GSCN_0_3[3] form the second 64-bit counter.
• The PCI_GSCL_1.GIO_64_BIT_EN selects between 32-bit and 64-bit modes.
• The PCI_GSCL_1.GIO_COUNT_EN_[3:0] bits enable each of the 4 counters.
— The enable bits for the two 64-bit counters are PCI_GSCL_1.GIO_COUNT_ EN_0 and
PCI_GSCL_1.GIO_COUNT_ EN_2, respectively.
• The PCI_GSCL_1.GIO_COUNT_START bit starts event counting of enabled counters.
• The PCI_GSCL_1.GIO_COUNT_STOP bit stops event counting of running counters.
• The PCI_GSCL_1.GIO_COUNT_RESET bit resets the event counters.
• The PCI_GSCL_2 associates an event with each of the 4 counters.
—In 64-bit mode, the GIO_EVENT_NUM_[2,0] fields are used.
3.1.6.1.2 Leaky Bucket Mode
Each of the counters can be configured independently to operate in a leaky bucket mode. When in leaky
bucket mode, the following functionality is provided:
• One of four 16-bit Leaky Bucket Counters (LBC) is enabled via the LBC_ENABLE_[3:0] bits in the
PCIe Statistic Control register #1.
• The LBC is controlled by the GIO_COUNT_START, GIO_COUNT_STOP, GIO_COUNT_RESET bits in
the PCIe Statistic Control register #1.
• The LBC increments every time the respective event occurs.
• The LBC is decremented every T s as defined in the LBC_TIMER_N field in the PCIe Statistic
Control registers #5...#8 (PCI_GSCL_5_8).
• When an event occurs and the value of the LBC meets or exceeds the threshold defined in the
LBC_THRESHOLD_N field in the PCIe Statistic Control registers #5...#8 (PCI_GSCL_5_8), the
respective statistics counter increments, and the LBC counter is cleared to zero.
3.1.6.2 Event Counters - Link and Physical Layers
This section describes the performance events for the Link and Physical layers and how to manage the
counters associated with these events.
Note:Before using LCB performance counters, the clock gating should be disabled by setting the
PCIE_CLKGATE_DIS field in the PCI_GLBL_CNF register.
The registers responsible for the Link and Physical layers counters are accessed via the PCI_LCBADD
and PCI_LCBDATA register pair.
Two events can be counted concurrently. The event counters include two sets of registers, each
managing one event counter. Such pairs are documents as <register_name>[1:0].
72333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
The following procedures manage the operation of the event counters (when writing to part of the
register, make sure other fields are written with their existing values):
• Resetting the counters configuration:
— Set the XPPERFCON.GRST bit.
— Clear the XPPERFCON.GRST bit (otherwise the logic stays in reset).
• Setting an event:
— Write 0x0...0 to the XPPMCL[1:0] registers
— Set the XPPMR[1:0].CENS field to 0x1
— Set the XPPMR[1:0].CNTMD field to 0x1
— Set the XPPMER[1:0].XPRSCA field to 0x1
— Set the event according to Tab le 3-9 .
• Starting a count:
— Set the XPPERFCON.GCE bit.
• Stopping a count:
— Clear the XPPERFCON.GCE bit.
• Reading the count (note: reading the counter clears their values):
— Read the respective XPPMDH[1:0] and XPPMDL[1:0] register pair in a single 64-bit aligned
access.
Tab l e 3 -9 defines the Link and Physical Layer events.
Table 3-9. Link and Physical Layer Performance Events
EventDescriptionRegister Field
Uncorrectable ErrorsCounts the total number of Uncorrectable Errors.XPPMER[1:0].CNTUCERR
Correctable ErrorsCounts the total number of Correctable Errors.XPPMER[1:0].CNTCERR
Tx L0s state utilizationCounts the number of entries to L0s on the Tx lanes.XPPMER[1:0].TXL0SU
Rx L0s state utilizationCounts the number of entries to L0s on the Rx lanes.XPPMER[1:0].RXL0SU
Link UtilizationCounts clocks that a port is receiving data.
If one counter counts receiver errors and another counter counts
Link Utilization, a bit error rate can be calculated.
Recovery State UtilizationCounts the number of entries to Recovery state.XPPMER[1:0].RECOVERY
ASPM L1 state utilizationCounts the number of entries to ASPM L1 state (i.e. initiated by
SW L1 state utilizationCounts the number of entries to L1 state initiated by software.XPPMER[1:0].SWL1
Tx and Rx L0s utilizationCounts number of events where both Tx and Rx are in L0s state.XPPMER[1:0].RXL0STXL0SU
NAK DLLP receivedCounts number of received NAK DLLPs.XPPMER[1:0].NAKDLLP
The bandwidth counters measure total payload bytes transferred over the PCIe link. Counting is
provided per each traffic type (posted, non-posted, completions) per direction (upstream,
downstream).
The mechanisms described above hold for the bandwidth counters with the following differences:
• Setting an event:
— Set the XPPMR[1:0].CENS field to 0x1.
— Set the XPPMR[1:0].EGS field to 0x2.
— Set the XPPMR[1:0].FCCSEL field to the desired traffic type (posted, non-posted, completions,
or all).
— Set the XPPPMER[1:0].TXRXSEL field to desired values.
— Set the XPPPMER[1:0].XPRSCA field to 0x1.
— Set the XPPERFCON.GCE field to 0x1.
Registers fields used exclusively by the bandwidth counters:
• XPPMR[1:0].FCCSEL — Selects the desired traffic type (posted, non-posted, completions, or all).
•XPPMER[1:0].TXRXSEL — Selects between monitoring downstream traffic, upstream traffic, or
both.
3.1.6.3.1 Register Map
The register fields that control the Link and Physical Layer events are as follows:
Table 3-15. Performance Monitor Local Control Register (XPPERFCON) (0x32C4)
FieldBit(s)Init.Description
GRST00bGlobal Reset
GCE10bGlobal Count Enable
RSVD31:20x0Reserved.
3.1.6.4 Latency Counter
The latency counter measures the min, max, or average read latency.
Note:Completion Timeout events are ignored when the latency counter is enabled.
The latency counters are managed via a set of register fields described below (see also Tabl e 3-1 6,
Tab l e 3 -17 , and Tab le 3-1 8). Each of the following sources of traffic has its separate set of registers and
counters:
0x0 — Rx LAN descriptor fetch
0x1 — Tx LAN descriptor fetch
0x4 — Internal cache load
0x5 — Internal management engine read
0x6 — Tx LAN packet fetch
The registers are accessed via the PCI_LCBADD and PCI_LCBDATA registers.
The register fields that control the latency counter operation are:
Table 3-16. NPQ Control Register - NPQC (0x00000)
FieldBit(s)Init.Description
Reserved3:00x4Reserved.
PERFMNTRAVG7:40x1Performance Monitor Average Rate
PERFMNTREN80bPerformance Monitor Enable
This field sets the averaging rate for all latency average monitors. See definition of
NPQRTDLY1.ARTDLY (Tabl e 3 -1 7).
This field divided by 16 is the weight W in an exponential moving average. The possible
values are 1, 2, 4 or 8, which correspond to averaging rates of 0.0625, 0.125, 0.25 or
0.5, respectively.
This bit should set to enable latency counters.
Clearing this bit clears the latency counters.
76333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
Table 3-16. NPQ Control Register - NPQC (0x00000) (Continued)
FieldBit(s)Init.Description
RTMNTREN90bLatency Counting Enable
This bit should set to enable latency counters. When set, completion timeout events are
ignored.
Captures the average read latency experienced since the last counter reset.
Latency is measured from time the read request starts until the time the completion starts
to arrive. Average is calculated as exponential moving average. That is, the new average
M(n) at sample n equals:
Captures the minimal read latency experienced since the last counter reset.
Latency is measured from time the read request starts until the time the completion starts
Captures the maximal read latency experienced since the last counter reset.
Latency is measured from time the read request starts until the time the completion starts
to arrive.
Latencies are measured in cycle counts, where a cycle duration is per Tab le 3- 19 .
The X550 contains three possible interfaces to an external BMC.
•SMBus
• NC-SI (over RMII)
• MCTP (over PCIe or SMBus)
3.2.1 SMBus
SMBus is an optional interface for pass-through and/or configuration traffic between an external BMC
and the X550. The SMBus channel behavior and the commands used to configure or read status from
the X550 are described in Section 11.5.
The X550 also enables reporting and controlling the device using the MCTP protocol over SMBus. The
MCTP interface is used by the BMC to control the NIC and for pass-through traffic. All network ports are
mapped to a single MCTP endpoint on SMBus. For information, refer to Section 11.5.
3.2.1.1 Channel Behavior
The SMBus specification defines a maximum frequency of 100 KHz. However, when acting as a slave,
the X550 can receive transaction with a clock running at up to 1 MHz. When acting as a master, it can
toggle the clock at 100 KHz, 400 KHz or 1 MHz. The speed used is set by the SMBus Connection Speed
field in the SMBus Notification Timeout and Flags NVM word (Section 6.5.4.3).
The NC-SI interface in the X550 is a connection to an external MC. It operates as a single interface with
an external BMC, where all traffic between the X550 and the BMC flows through the interface.
The X550 NC-SI interface meets the NC-SI version 1.0.0 specification as a PHY-side device.
3.3.1 Electrical Characteristics
The X550 complies with the electrical characteristics defined in the NC-SI specification.
3.3.2 NC-SI Transactions
The NC-SI link supports both pass-through traffic between the BMC and the X550 LAN functions, as well
as configuration traffic between the BMC and the X550 internal units as defined in the NC-SI protocol.
Refer to Section 11.6.2 for information.
78333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
3.3.3 MCTP (Over PCIe or SMBus)
The X550 supports MCTP protocol for management. MCTP runs over PCIe or SMBus. The X550
implements NC-SI over MCTP protocol for command and pass-through traffic. See Section 11.7 for
details.
3.4 Non-Volatile Memory (NVM)
3.4.1 General Overview
The X550 uses a Flash device to store product configuration information. The Flash is divided into three
general regions:
• Hardware Accessed — Loaded by the the X550 hardware after power-up, PCI reset de-assertion,
D3 to D0 transition, or software reset. Different hardware sections in the Flash are loaded at
different events. For more details on power-up and reset sequences, see Section 4.1 and
Section 4.2.
• Firmware Area — Includes firmware code and structures used by the firmware for management
configuration in its different modes.
• Software Accessed — This region is used by software entities such as LAN drivers, option ROM
software and tools, PCIe bus drivers, VPD software, etc.
3.4.1.1 NVM Protection
The NVM protection method implemented in the X550 relies on an “authenticate on update” concept. It
means that the protected modules are not authenticated after initialization, but prior to committing a
module update operation only. NVM protection is guaranteed by an inductive authentication chain, that
assumes an initial secured NVM image and requires that any NVM update must be secure as well. This
method mandates the following limitations and restricting working assumptions:
1. An initial ‘good’ image is loaded into the flash at the manufacturing site which is assumed to be
safe.
— It assumes customers (OEM and end-user) know the source of the installed components, the
supply chain producing these components is not compromised during manufacturing, and that
the NIC/LOM is physically protected from modification after deployment.
— The possibility exists that unauthorized firmware may be loaded into the NVM via physical
modification post manufacturing, as well as through supply chain vulnerabilities. However,
firmware updates via programmatic (software) methods are enhanced to require authentication
prior to updating NVM settings. Furthermore, host software can independently detect whether
the firmware image has an invalid digital signature.
2. In a normal operating mode, NVM write accesses are controlled by the device (firmware) and
cannot be performed via the memory mapped accesses, EEWR register, or bit-banging. Memory
mapped NVM access remains available for NVM read accesses only. For simplicity and flexibility
reasons, NVM write accesses from the host can be initiated via host interface commands
(Section 11.8.3.3), VPD write interface, or via a BMC command, which are all handled by firmware.
Memory BAR writes, EEWR and FLA bit-banging accesses are blocked by hardware when the NVM is
protected.
3. All the supported Flash parts share the same set of op-codes as described in Section 3.4.1.2. A
blank Flash programming mode is provided (besides the normal programming mode previously
mentioned in item 2), where the Flash can be programmed directly without firmware involvement
via the FLA bit-banging or Flash BAR interfaces. This mode is indicated by FLA.LOCKED = 0b.
3.4.1.2 Flash Device Requirements
The X550 supports Flash devices with a sector erase size of 4 KB and an address width of 24 bits (up to
4 MB). Note that many Flash vendors are using the term sector differently. This document uses the
term Flash sector for a logic section of 4 KB.
The X550 supports Flash devices that are either write-protected by default after power-up or not. The
X550 is responsible to remove the protection by sending the write-protection removal Op-Code to the
Flash after power up.
The following Op-Codes are supported by the X550 as they are common to all supported Flash devices:
1. Write Enable (0x06)
2. Read Status Register (0x05) - used by hardware internally.
3. Write Status Register (0x01). The written data is 0x00 to cancel the Flash default protection. Used
by hardware internally.
4. Read Data (0x03). Burst read is supported.
5. Byte Program (0x02). To program a data byte.
6. 4 KB Sector-Erase (0x20)
7. Chip-Erase (0xC7)
8. Read JEDEC ID (0x9F)
3.4.1.2.1 Flash Identification
The Flash connected to the X550 can be identified by its JEDEC ID that can be read using the Flash Info
host interface command (Section 11.8.3.3.9). This identification is available only if a valid Flash is
installed. If the Flash is empty or with an invalid signature, software can read the JEDEC ID by applying
an RDID command (opcode 0x9F) or a Read SFDP command (opcode 0x5A) via the bit-bang interface.
3.4.2 Shadow RAM
The first eight 4 KB sectors of the X550’s Flash are allocated to create two 16 KB sections (section 0 and
section 1), for the configuration content. At least one of these two sections must be valid at any given
time or else the X550 is set to hardware default. Following a Power On Reset (POR), the X550 copies
the valid section of the Flash device into an internal Shadow RAM. Any further read accesses of the
software or firmware to the lower 16 KB addresses of the NVM (not through flash BAR) are directed to
the internal Shadow RAM. Modifications made to the Shadow RAM content are copied by the X550 into
the other 16 KB section of the NVM, circularly flipping the valid section between sections 0 and 1 in the
NVM.
This mechanism provides the following advantages:
1. A way to protect the image-update procedure from power down events by establishing a doubleimage policy. See Section 3.4.8.1 for a description of the double-image policy. It relies on having
pointers to NVM modules stored in the NVM section mirrored in the internal Shadow RAM.
80333369-004
Interconnects—Intel
Section 0
Section 1
Shadow RAM
X550
Flash
EEPROM-
Mode Access
0x003FFF 0x000000
0x000000
0x003FFF
0x004000
0x007FFF
0x008000
0xFFFFFF
0x000000
0x003FFF
1:1
Physical Byte
address
Flash-Mode
Access
0xFFFFFF 0x000000
Logical
address
Internal RAM
address
16
KB
16
KB
®
Ethernet Controller X550 Datasheet
2. A way to ensure hardware auto-load during a PCIe reset event can be completed within PCIe timing
constraints (100 ms), even if the Flash is busy performing an erase operation initiated prior to that
reset event.
Figure 3-6 shows the Shadow RAM mapping and interface.
Figure 3-6. NVM Shadow RAM
3.4.2.1 Shadow RAM Update Flow
Following a write access by the software device driver to update the Shadow RAM, the data should be
updated in the Flash as well. The X550 updates the Flash from the Shadow RAM when software
explicitly requests to update the Flash using the Shadow RAM Dump host interface command
(Section 11.8.3.3.8). To reduce Flash update operations, software is expected to request a dump only
once its last Shadow RAM update access completes. The X550 then copies the content of the Shadow
RAM to the non valid configuration section and makes it the valid one.
3.4.3 NVM Clients and Interfaces
There are different software clients that can access the NVM: driver, tools, BIOS, VPD, etc.
Tab l e 3 -20 lists the different accesses to the NVM.
Software accesses to Flash by
toggling the SPI pins.
Access to Shadow RAM through
the Shadow RAM Read/Write
command
Software read from Flash via
Flash Read command.
Software write to sector/Flash
erase
VPD Address and Data
registers.
FLMNGCTL and FLMNGDATA
registers accesses to the FLASH
Write access is limited to a single byte,
and is allowed only if hardware
protection is disabled (FLA.LOCKED =
0).
FLA interface access is available only if
hardware protection is disabled
(FLA.LOCKED = 0).
Requires a valid firmware image.
Write protection is enforced by
firmware.
Requires a valid firmware image.
Requires a valid firmware image.
Writes to protected areas are dropped
when protection (enforced by firmware)
is enabled. Protected sector erase or a
complete Flash erase requests are
rejected when protection (enforced by
firmware) is enabled.
Write accesses are enabled to the R/W
area of the VPD
If the VPD structure is not valid, the
entire 1024 bytes area is RO.
Software access is available only when
protection is disabled.
3.4.3.1 Memory Mapped Host Interface
Using the legacy Flash transactions, the Flash is accessed by the X550 each time the host CPU performs
a read or a write operation to a memory location mapped to the Flash address space, or upon boot via
accesses in the space indicated by the Expansion ROM Base Address register. Accesses to the Flash are
based on a direct decode of CPU accesses to a memory window defined in either:
• Memory CSR + Flash Base Address Register (PCIe Control Register at offset 0x10).
• The Expansion ROM Base Address Register (PCIe Control Register at offset 0x30).
• The X550 is responsible to map accesses via the Expansion ROM BAR to the physical NVM. The
offset in the NVM of the Expansion ROM module is defined by the PCIe Expansion/Option ROM Pointer (NVM word address 0x05). This pointer is loaded by the X550 from the NVM before enabling
any access to the Expansion ROM memory space.
The X550 controls accesses to the Flash when it decodes a valid access. Attempt to out of range read
access the PCIe Expansion/Option ROM module (according to NVM Size field in NVM Control Word 1)
would return a value of 0xDEADBEEF. Attempt to memory-mapped write accesses to the Flash when
protection is enabled or via expansion ROM BAR are ignored.
82333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
3.4.4 Flash Access Contention
Flash accesses initiated through different LAN functions might occur concurrently. The X550 does not
synchronize between entities accessing the Flash, so a contention caused from one entity reading and
another modifying the same location is possible.
To avoid such contention between software LANs or between software and firmware accesses, these
entities are required to make use of the semaphore registers. Refer to Section 11.8.4. Any read or write
access to the NVM made by software/firmware must be preceded by acquiring ownership over the NVM.
This is also useful to avoid the time out of a PCIe transaction made to a memory mapped Flash address
while the Flash is busy performing a sector erase operation.
However, two software entities cannot use this semaphore mechanism: BIOS access through expansion
ROM and VPD software.
• Since VPD software accesses only the VPD module, which is located in the configuration section of
the NVM, VPD accesses are always performed against the Shadow RAM. Firmware must take NVM
ownership before dumping the VPD changes to the Flash. The Shadow RAM dump sequence is
described in Section 3.4.2.1.
• No contention can occur between the BIOS access through expansion ROM and other software
entities (including VPD) as it accesses the NVM while the operating system is down.
• Contentions between BIOS and firmware can however happen if a system reboot occurs while the
MC is accessing the NVM.
— If a system reboot is caused by a user pressing the standby button, it is required to route the
wake-up signal from the standby button to the MC and not to the chipset. The MC issues a
system reboot signal to the chipset only after the NVM write access completes. Firmware is
responsible to respond with a “busy” error code to MC NC-SI commands while other NVM writes
are in progress.
— If a system reboot is issued by a local user on the host, there is no technical way to prevent
NVM access contentions between the BIOS and the MC.
Caution:It is the user’s responsibility when remotely accessing the NVM via the MC, to make sure
another user is not currently initiating a local host reboot.
Notes:The PHY auto-load process from the Flash device is made up of short read bursts (32-bits)
that can be inserted by hardware in between other NVM clients’ accesses, at the lowest
priority. It is the user’s responsibility to avoid initiating a PHY auto-load while updating the
PHY NVM modules.
The MAC auto-load from the Flash device itself occurs after power-up only, before host or
firmware can attempt to access the Flash. The host must wait until PCIe reset is de-asserted
(after ~1 second, which is enough time for the MAC auto-load to complete), and firmware
starts its auto-load after the EEC.MNG_READY bit is asserted by hardware.
Other MAC auto-load events are performed from the internal Shadow RAM and do not
compete with memory mapped accesses to the Flash device. During such MAC auto-loads,
accesses from other clients via EEPROM-Mode registers are delayed until the auto-load
process completes.
Software and firmware should avoid holding Flash ownership (via the dedicated semaphore
bit) for more than 500 ms.
The Flash is a shared resource between the following clients:
1. Hardware auto-load of Shadow RAM (at power up).
2. LAN port 0 and LAN port 1 software accesses.
3. Manageability/firmware accesses.
4. Software tools.
All clients can access the Flash using parallel access. Hardware implements the actual access to the
Flash. Hardware arbitrates between the different clients and schedules these accesses, avoiding
starvation of any client.
However, the software and firmware clients can access the Flash using bit-banging. In this case, there is
a request/grant mechanism that locks the Flash to the exclusive use of one client. If one client is stuck
without releasing the lock, the other clients can no longer access the Flash. To avoid this deadlock, the
X550 implements a time-out mechanism, which revokes the grant from a client that does not toggle the
Flash bit-bang interface (FLA.FL_SCK bit) for more than 2 seconds. If any client fails to release the
Flash interface, hardware clears its grant, enabling the other clients to use the interface.
The deadlock timeout mechanism is enabled by the Deadlock Timeout Enable bit in NVM Control Word 2
in the Flash.
3.4.5 Signature Field
The only way the X550 can tell if a Flash is present is by trying to read the Flash. The X550 first reads
the Control word at word address 0x0 and at word address 0x2000. It then checks the signature value
at bits 7 and 6 in both addresses.
If bit 7 is 0b and bit 6 is 1b in (at least) one of the two addresses, it considers the Flash to be present
and valid. It then reads the additional Flash words from that section and programs its internal registers
based on the values read. Otherwise, it ignores the values read from that location and does not read
additional words.
If the signature bits are valid at both addresses the X550 assumes that the first section is the valid one.
3.4.6 VPD Support
The Flash image can contain an area for VPD. This area is managed by the OEM vendor and does not
influence the behavior of hardware. Word 0x2F of the Flash image contains a pointer to the VPD area in
the Flash. A value of 0xFFFF means VPD is not supported and the PCI_CAPCTRL.VPD_EN bit should be
cleared in the PCI NVM section (Section 6.4.5), to prevent the VPD capability from appearing in the
configuration space.
The maximal area size is 1024 bytes but can be smaller. The VPD block is built from a list of resources.
A resource can be either large or small. The structure of these resources are listed Tabl e 3 -2 1 and
Tab l e 3 -22 .
84333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
Table 3-21. Small Resource Structure
Offset01 — n
Content
Tag = 0xxx,xyyyb (Type = Small(0), Item Name = xxxx,
length = yy bytes)
Data
Table 3-22. Large Resource Structure
Offset01 — 23 — n
Content
Tag = 1xxx,xxxxb (Type = Large(1),
Item Name = xxxxxxxx)
LengthData
The X550 parses the VPD structure during the auto-load process following PCIe reset to detect the read
only and read/write area boundaries. The X550 assumes the following VPD fields with the limitations
listed:
Table 3-23. VPD Structure
TagLength (Bytes)DataResource Description
0x82Length of identifier stringIdentifierIdentifier string.
0x90Length of RO areaRO dataVPD-R list containing one or more VPD keywords.
0x91Length of RW areaRW data
0x78n/an/aEnd tag.
VPD-W list containing one or more VPD keywords. This part is
optional.
VPD structure limitations:
• The structure should start with a Tag = 0x82. If the X550 does not detect a value of 0x82 in the
first byte of the VPD area or the structure does not follow the description of Tabl e 3 -2 3, it assumes
the area is not programmed and the entire 1024 bytes area is read only.
• The RO area and RW area are both optional and can appear in any order. A single area is supported
per tag type. Refer to Appendix I in the PCI 3.0 specification for details of the different tags.
• If a VPD-W tag is found, the area defined by its size is writable via the VPD structure.
• The structure should end with a Tag = 0x78. The tag must be word aligned.
• The VPD area can be accessed through the PCIe configuration space VPD capability structure listed
in Tab le 3-2 3. Write accesses to a read only area or any access to an offset outside of the VPD area
via this structure are ignored.
• VPD area must be mapped in the first 16 KB section of the Flash mapped to the Shadow RAM.
• VPD software does not check the semaphores before attempting to access the Flash via dedicated
VPD registers. Even if the Flash is owned by another entity, VPD software read access to the VPD
area in the Flash might complete immediately since it is first performed against the Shadow RAM.
However, VPD software write access might not complete immediately since the VPD changes are
committed to the Flash device at the X550’s initiative, once the other entity releases Flash
ownership, which may take up to several seconds.
The VPD capability is exposed in the PCIe configuration space only if the PCI_CAPCTRL.VPD_EN bit is
set, regardless of any other sanity checks that are performed on the VPD area contents.
The VPD content and pointer can be written on a blank Flash without any limitation, such as for any
other NVM module when in the blank Flash programming mode. After protection is enabled, if VPD Write Enable bit in NVM Control Word 1 is cleared, only the RW area of the VPD is writable and only via
the VPD interface.
3.4.6.1.2 VPD Area Update Flow
1. The host initiates a VPD write by programming the offset and data fields of the VPD capability
register set, and then setting the capability's Flag bit.(bit 15 in VPD Address Register - 0xE2).
2. Firmware checks if the VPD write is allowed - it checks that the write offset falls within the VPD-RW
area.
a. If writing is not allowed, firmware clears the VPD flag in the configuration space to notify the VPD
software that the transaction completed, and then it exits the flow.
3. Firmware indicates VPD access completion by clearing the VPD flag in the configuration space.
Note:In case the Flash is occupied with a previous sector erase operation, or if NVM ownership is
held by software, the completion indication (Step 3) might be delayed. Additional writes
should not be attempted before the completion of Step 3.
3.4.7 NVM Read, Write, and Erase Sequences
Refer to Section 3.4.8.1 for the flow required to update secure NVM modules.
Any software flow described in this section must be preceded by taking NVM ownership via semaphores
as described in Section 11.8.4.
3.4.7.1 Flash Block Erase Flow by Software
1. Send a Flash Block Erase host interface command (Section 11.8.3.3.7) with the aligned address of
the block to erase.
2. Wait for the command to complete before releasing the NVM semaphore.
3.4.7.2 X550 Software Flow to the Bit-Banging Interface
To directly access the Flash when Flash is blank or not protected, software should follow these steps:
1. Write a 1b to the Flash Request bit (FLA.FL_REQ).
2. Poll the Flash Grant bit (FLA.FL_GNT) until it becomes 1b. It remains 0b as long as there are other
accesses to the Flash.
3. Write or read the Flash using the direct access to the 4-wire interface as defined in the FLA register.
The exact protocol used depends on the Flash placed on the board.
86333369-004
Interconnects—Intel
4. Write a 0b to the Flash Request bit (FLA.FL_REQ).
5. Following a write or erase instruction, software should clear the Request bit only after it has
checked that the cycles were completed by the NVM. This can be checked by reading the BUSY bit
in the Flash device STATUS register. Refer to Flash data sheet for the op-code to be used for reading
the STATUS register.
Note:The bit-banging interface is blocked during normal operation (protection enabled). Software
should use the Host Interface commands. The firmware can use this interface all the time.
®
Ethernet Controller X550 Datasheet
3.4.7.3 Erase Flow Using the FLA Register
To directly erase a sector in the Flash when Flash is blank or not protected, software should follow these
steps:
1. Take ownership of NVM semaphore.
2. Set the Flash Address (FLA.FL_ADDR) to the index of the 4 KB sector to erase and Sector Erase bit
(FLA.FL_SER) bit.
3. Read the FLA register until Flash Busy bit (FLA.FL_BUSY) is cleared.
4. Release ownership of NVM semaphore.
To directly erase the entire Flash when Flash is blank or not protected, software should follow these
steps:
1. Take ownership of NVM semaphore
2. Set Device Erase bit (FLA.FL_DER) bit.
3. Read the FLA register until Flash Busy bit (FLA.FL_BUSY) is cleared.
4. Release ownership of NVM semaphore.
3.4.7.4 Software Access Flow to Shadow RAM
3.4.7.4.1 Read Interface
Software can read from the Shadow RAM using the following flow:
1. Send a Shadow RAM Read host interface command (Section 11.8.3.3.2) with the address and
length to read.
2. Wait for the command to complete.
3. Read the data from the response buffer.
3.4.7.4.2 Write Interface
Software can write to the Shadow RAM using the following flow:
1. Send a Shadow RAM Write host interface command (Section 11.8.3.3.4) with the address, length
and data to write.
3.4.7.5 Software Access to Flash via Memory Mapped Interface
3.4.7.5.1 Read Access
Software can always use the Flash BAR for read accesses.
Note:Software should take semaphore ownership before executing the flow.
3.4.7.5.2 Write Access
When Flash is blank or protection is disabled, software might initiate a write cycle via the Flash BAR as
follows:
1. Take semaphore ownership before executing the flow.
2. Write the data byte to the Flash through the Flash BAR.
3. Poll the FL_BUSY flag in the FLA register until cleared.
4. Repeat Step 2 and Step 3 to write additional bytes.
5. Release NVM semaphore ownership
As a response, hardware executes the following steps for each write access:
1. Set the FL_BUSY bit in the FLA register.
2. Initiate autonomous write enable instruction.
3. Initiate the program instruction right after the enable instruction.
4. Poll the Flash status until programming completes.
5. Clear the FL_BUSY bit in the FLA register.
Note:Software must erase the sector prior to programming it.
3.4.7.6 Software Flash Programming via Host Interface
Command
Software must take semaphore ownership before executing the flow.
Software can write to non write protected areas of the flash using the following flow:
1. Send a Flash Write host Interface command (Section 11.8.3.3.3) with the address, length and data
to write.
2. Wait for the command to complete.
88333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
3.4.7.7 SoftwareFlash Read via Host Interface Command
Software must take semaphore ownership before executing the flow.
Software can read from the flash using the following flow:
1. Send a Flash Read host Interface command (Section 11.8.3.3.1) with the address and length of the
data to read.
2. Wait for the command to complete.
3. Read the data from the completion of the command.
3.4.8 Extended NVM Flows
3.4.8.1 Flow for Updating Secured Modules
This section describes the flow to use to update the firmware image (Section 6.5.7), Option ROM
(Section 6.6) or PHY module (Section 6.7).
To protect the Flash update procedure from power-down events, a double image policy is used for each
of the updated modules. The software flow to update a module is as follows:
1. Take ownership over the NVM via the semaphore bits. Refer to Section 11.8.4.
a. If SW_FW_SYNC.NVM_UPDATE_STARTED bit is read as clear, set this bit together with setting
NVM semaphore bit. It is used to notify other entities that a long NVM update process which may
take up to several minutes has started. During this time, other entities can not perform a write
access to the firmware or PHY modules, but reading these modules in between update write
bursts is allowed using the flash memory mapping. Legacy EEPROM Modules are not concerned
by this limitation.
b. Otherwise, release NVM semaphore ownership and restart the update process later on.
2. Read the pointer to the free provisioning area (NVM word 0x40). Check that the free provisioning
area size read from NVM word 0x41 is greater or equal to the size of the new firmware/PXE/PHY
image to be loaded in NVM.
a. If not, release NVM semaphore ownership, clear the SW_FW_SYNC.NVM_UPDATE_STARTED bit
and exit the flow.
3. Initiate sector erase instructions (Section 3.4.7.1) to the entire free space provisioning segment.
a. To guarantee NVM semaphore ownership time does not exceed the 1 sec timeout, it is
recommended to perform at this step no more than four 4 KB sector erase operations at once in
a burst, releasing semaphore ownership for 200 s in between. This way, other entities can insert
NVM read accesses in between burst without waiting for the entire update process completion,
which might take minutes.
4. Write the new firmware/Option ROM/PHY module to the free provisioning area via Flash-mode
access.
a. Same as Step 3a, it is recommended to write at this step no more than four 4 KB sectors at once
in a burst, releasing semaphore ownership for 200 s in between.
5. Send a Flash Module Update host Interface command (Section 11.8.3.3.5) with the module ID of
the section to update.The encoding of the modules is:
ModuleIDReference
Firmware code0x1Section 6.5.7
Reserved0x2
Reserved0x3
Reserved0x4
PHY Firmware Image 0x5Section 6.7
Reserved0x6-0xFD
Option ROM0xFESection 6.6
Reserved (Full Shadow RAM)0xFF
6. Release the NVM semaphore and clear the SW_FW_SYNC.NVM_UPDATE_STARTED bit.
a. Software must avoid taking the NVM semaphore again until the firmware command has
completed. Any attempt to write the NVM until then is not performed by the device.
7. Firmware swaps between the Free Provisioning Area Pointer (word 0x40) and the Firmware Code
Module pointer, PXE module pointer or the PHY pointer located at the Shadow RAM word address
0x3A/0x5/0x4 respectively
8. Software waits for the command to complete.
a. If the update process failed due to a security check failure or a flash write fault, an Authentication
Error (0x80) or Data Error (0x6) respectively is returned. Software must then exit the flow, prior
to attempt another update.
9. If the updated module is the PHY image, the PHY should be instructed to reload the image using the
following flow:
a. Update the PHY firmware version number at NVM word address 0x19 (Section 6.3.4.2) using the
b. Read-modify-write SRAMREL register for setting LATCH_IMAGE_VLD bit to 1b.
c. Read-modify-write SRAMREL register for setting LATCH_IMAGE_VLD bit to 0b.
d. Write PHY register bit 1E.C474.0 bit to 0b.
e. Force PHY image reload by setting PHY register bit 1E.C442.0 to 1b.
10. If the updated module is the firmware image, the firmware should be instructed to reload the image
using the Apply Update command (Section 11.8.3.3.6).
90333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
3.4.8.2 Flow for Updating One of the RW Legacy EEPROM
Modules
When updating one or several fields from a legacy EEPROM module there is a risk that a hardware autoload event occurs in the middle of the operation (fox example, due to a sudden PCIe reset), leading to
the auto-load of an invalid or inconsistent content from the internal Shadow RAM into the device
registers or memory. Therefore unless the field(s) can be updated by a single EEPROM-mode access,
the updating software must repeatedly use the following procedure for each legacy EEPROM module to
be updated:
1. Take ownership over the NVM via semaphore bits. Refer to Section 11.8.4.
2. Invalidate the pointer to the module to be modified by setting it to 0xFFFF using Shadow RAM Write
command. This way, if a hardware auto-load of the module is attempted, the associated register
defaults are loaded instead. Do not invalidate pointers to firmware modules, only to hardware
auto-load modules.
3. Modify the contents of the module via Shadow RAM Write command.
4. Restore the pointers modified in Step 2 via Shadow RAM Write command.
5. Compute and update the software checksum (word 0x3F) if the contents covered by the software
checksum was modified.
6. Release the NVM semaphore.
7. Send a Shadow RAM dump command (Section 11.8.3.3.8) to ask the device firmware to load the
internal Shadow RAM into the Flash.
Note:Depending on the modified RO items, a system reset is generally required for loading the
modifications into the device.
3.4.9 NVM Authentication Procedure
NVM update integrity feature ensures that only Intel approved firmware code (or other protected NVM
module) is able to be updated on the X550 devices after manufacturing. This procedure is performed
whenever attempting to update one of the protected modules.
Integrity validation of NVM updates is provided by a digital signature. The digital signature is a SHA256
Hash computed over the protected content (long by 256-bits) which is then encrypted by a 2048-bits
RSA encryption using an Intel private key. This digital signature is stored in the manifest in the NVM
module image. Also stored in the manifest is the corresponding RSA modulus (public key) and RSA
exponent to be used to decrypt the digital signature.
To verify the authenticity of the digital signature, firmware must first verify that the RSA Modulus and
RSA Exponent fields in the new firmware image loaded are identical to those in the old firmware image.
If the RSA Modulus and Exponent fields are the same, firmware decrypts the digital signature using the
2048-bit RSA Modulus and Exponent fields stored in the manifest of the old firmware image to extract
the expected SHA256 Hash of content (stored hash). Firmware then performs an independent SHA256
Hash over the protected content (computed hash). If the stored hash matches the computed hash, the
digital signature is accepted, and the NVM update is applied.
NVM updates are validated prior to invalidating the old NVM configuration, such that the old NVM
configuration is still usable if the update fails to validate. After the new NVM is successfully verified, the
updated image is committed to device flash.
Figure 3-7. Sign & Verify Procedures for Authenticated NVM Modules
3.4.9.1 Digital Signature Algorithm Details
As described the digital signature generation is a hash computation followed by an RSA encryption. This
is performed within Intel as part of the NVM update image generation process and not performed by
Intel software in the field, nor by the X550.
The different algorithms used are described in the following locations:
The X550 has four software-defined pins (SDP pins) per port that can be used for miscellaneous
hardware or software-controllable purposes. Unless specified otherwise, these pins and their function
are bound to a specific LAN device. The use, direction, and values of SDP pins are controlled and
accessed by the Extended SDP Control (ESDP) register. To avoid signal contention, following power-up,
all four pins are defined as input pins.
Some SDP pins have specific functionality:
• The default direction of the SDP pins is loaded from the SDP Control word in the NVM.
• The lower SDP pins (SDP0-SDP2) can also be configured for use as External Interrupt Sources
(GPI). To act as GPI pins, the desired pins must be configured as inputs and enabled by the GPIE
register. When enabled, an interrupt is asserted following a rising-edge detection of the input pin
(rising-edge detection occurs by comparing values sampled at the internal clock rate, as opposed to
an edge-detection circuit). When detected, a corresponding GPI interrupt is indicated in the EICR
register.
Note:An SDP configured as output can also generate interrupts, but this is not a recommended
configuration.
The bit mappings are shown in Tab l e 3 - 24 for clarity.
Table 3-24. GPI to SDP Bit Mappings
SDP Pin to be Used as GPI
DirectionalityEnable as GPI Interrupt
2SDP2_IODIRSDP2_GPIEN27
1SDP1_IODIRSDP1_GPIEN26
0SDP0_IODIRSDP0_GPIEN25
ESDP Field Settings
Resulting EICR Bit (GPI)
• SDP1 pins can also be used to (electrically) disable both PCIe functions altogether. Also, if the MC is
present, the MC-to-LAN path(s) remain fully functional. This PCIe-Function-Off mode is entered
when SDP1 pin of a port is driven high while PE_RST_N is de-asserted. For correct capturing, it is
therefore recommended to set SDP1 pins to their desired levels while the PE_RST_N pin is driven
low and to maintain the setting on the (last) rising edge of PE_RST_N. This ability is enabled by
setting bit 11 in NVM Control Word 2 (global NVM offset 0x01 - Section 6.4.2.2).
Note:The PCIe-Function-Off is activated regardless of the SDP1 direction defined in the NVM
SDP Control word.
• The lowest SDP pins (SDP0_0) of port 0 can be used to encode the NC-SI package ID of the X550.
This ability is enabled by setting bit 15 in NC-SI Configuration 2 word (offset 0x05 -
Section 6.5.4.6) of the NVM. The 3-bit package ID is encoded as follows: Package ID = {0,
SDP0_0, 0}.
• When the SDP pins are used as IEEE1588 auxiliary signals they can generate an interrupt on any
transition (rising or falling edge), refer to Section 7.7.4.
2
• A pair of SDPs can be used to create an I
C interface as described in Section 3.5.1.
All SDP pins can be allocated to hardware functions. See more details on IEEE1588 auxiliary
functionality in Section 7.7.4 while I/O pins functionality are programmed by the TimeSync Auxiliary
Control (TSAUXC) register.
If mapping of these SDP pins to a specific hardware function is not required, the pins can be used as
general purpose software defined I/Os. For any of the function-specific usages, the SDP I/O pins should
be set to native mode by software setting of the SDPxxx_NATIVE bits in the ESDP register. Native mode
in those SDP I/O pins, defines the pin functionality at inactive state (reset or power down) while
behavior at active state is controlled by the software. The hardware functionality of these SDP I/O pins
differs mainly by the active behavior controlled by software.
Tab l e 3 -25 summarize the setup required to achieve each of the possible SDP configurations.
Table 3-25. SDP Settings
SDPUsageNVM Setting
SDPN/A0Input/Output
NC-SI package ID
(Port #0 only)
0
1588 functionality as
defined by the TSSDP
register
SDPN/A0Input/Output0
PCI disable
1588 functionality as
defined by the TSSDP
1
register
Thermal Sensor
ReservedN/A1N/A1
SDP
1588 functionality as
2
defined by the TSSDP
register
2
C clock1N/A1
I
SDP
1588 functionality as
3
defined by the TSSDP
register
2
C data1N/A1
I
Bit 15 in NC-SI
Configuration 2 NVM
word
N/A1Input/Output
NVM Control Word 2,
SDP_FUNC_OFF_EN
TS NVM-based Mode
bit
N/A1Input/Output0
Enable bit in the
Common Firmware
Parameters word
N/A
N/A
SDPx_NATIVESDPx_IODIRSDP1_FunctionSDP23_function
0Input
N/AN/AN/A
0Output 1
0Input/Output
1Input/Output0
0Input/Output
1Input/Output0
ESDP
N/A
N/A
N/A
N/A
N/A
N/A
94333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
3.5.1 I2C Over SDP
The I2C usage of SDP pins is enabled by setting the SDP23_function bit and the SDP[23]_NATIVE bits
to 1b in ESDP register. This relates to the SDPx_2 and SDPx_3 pins, which operate as I2C_CLK and
I2C_DATA, respectively.
2
C interface operates via the I2CCMD and I2CPARAMS register set. Since this register set can be
The I
used by either software or firmware in alternation, its ownership must be acquired/released via the
semaphore ownership taking/release flows described in Section 4.7.
2
C interface can be used in two methods, a hardware based access, where the device initiate a
The I
transaction following a software device driver request via the I2CCMD register (Section 8.2.2.1.16) or a
software controlled bit-banging using the I2CPARAMS register (Section 8.2.2.1.17).
3.5.1.1 Hardware Based I2C Access
The following flows should be used to access an I2C register.
As part of device initialization, or anytime before the actual access, the following parameters should be
set:
•I2CPARAMS.PHYADD — the address of the device to access.
•I2CPARAMS.ACCESS_WIDTH — the width of the data to read or write (byte or word).
2
Note:The I2CPARAMS register should not be modified during an I
C transaction.
To execute a write access, the following steps should be done:
1. Check that register is ready: Poll I2CCMD.R bit until it is read as 1b.
2. Command — The I2CCMD register is initialized with the appropriate PHY register address in
REGADD field, the data to write in the DATA field and the operation (write) to the OP field (0b).
a. If an interrupt is required, set the I2CCMD.I field
3. Check that command is done: Poll I2CCMD.R bit until it is read as 1b.
a. Check that no error is indicated in the I2CCMD.E field.
To execute a read access, the following steps should be done:
1. Check that register is ready: Poll I2CCMD.R bit until it is read as 1b.
2. Command — The I2CCMD register is initialized with the appropriate PHY register address in the
REGADD field, and the operation (read) to the OP field (1b).
a. If an interrupt is required, set the I2CCMD.I field
3. Check that command is done: Poll I2CCMD.R bit until it is read as 1b.
a. Check that no error is indicated in the I2CCMD.E field.
4. Read the data returned from the I2CCMD.DATA field. If a byte access is done
(I2CPARAMS.ACCESS_WIDTH = 0), only DATA[7:0] is valid.
2
See Section 3.5.1.3 below for the I
commands. All the transactions uses a clock of 100 KHz. When using the bit-bang method any
command can be given to the I
C commands supported when using the built in read and write
In this mode, the software device driver controls the I2C interface directly using the I2CPARAMS
register according to the following table:
Pad
2
SDPx_2 (I
SDPx_3 (I
1. 0b = Pad is output. 1b = Pad is input.
C clock)CLK_OUTCLK_INCLK_OE_N
2
C data)DATA_O UTDATA_INDATA_OE_N
Field Controlling the Output
Value
Field Reflecting the Input
Value
Field Controlling the Output
Enable Value
1
3.5.1.3 Supported Commands
Note:The gray columns below denotes cycles driven by the I2C device. White columns denotes
cycles driven by the X550.
When a word read command (I2CPARAMS.ACCESS_WIDTH = 1b, I2CCMD.OP =1b) is given the
following sequence is done by the X550:
Table 3-26. I2C Read Transaction - Dummy Write
171181
SDevice AddressWr
From I2CCMD.PHYADD0
Table 3-27. I2C Read Transaction - Word Read
171181811
SDevice AddressRd
From I2CPARAMS.PHYADD1
ARegister AddressA
0From I2CCMD.REGADD0
ADataADataAP
0Stored in I2CCMD.DATA[7:0]0Stored in I2CCMD.DATA[15:8]0
When a byte read command (I2CPARAMS.ACCESS_WIDTH = 0b, I2CCMD.OP =1b) is given the
following sequence is done by the X550:
Table 3-28. I2C Read Transaction - Dummy Write
171181
SDevice AddressWr
From I2CPARAMS.PHYADD0
ARegister AddressA
0From I2CCMD.REGADD0
Table 3-29. I2C Read Transaction - Byte Read
1711811
SDevice AddressRd
From I2CPARAMS.PHYADD1
96333369-004
ADataAP
0Stored in I2CCMD.DATA[7:0]0
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
When a word write command (I2CPARAMS.ACCESS_WIDTH = 1b, I2CCMD.OP =0b) is given the
following sequence is done by the X550:
2
Table 3-30. I
1718181811
SDevice AddressWrRegister Address
I2CPARAMS.PHYADD
C Write Transaction - Word Write
From
0From
I2CCMD.REGADD
ADataADataAP
0From in
I2CCMD.DATA[7:0]
0From in
I2CCMD.DATA[15:8]
0
When a byte write command (I2CPARAMS.ACCESS_WIDTH = 0b, I2CCMD.OP =0b) is given the
following sequence is done by the X550:
Table 3-31. I2C Write Transaction - Byte Write
17181811
SDevice AddressWrRegister Address
From I2CPARAMS.PHYADD0From I2CCMD.REGADD
ADataAP
0From in I2CCMD.DATA[7:0]0
3.6 LEDs
The X550 implements four output drivers intended for driving external LED circuits per port. Each of the
four LED outputs can be individually configured to select the particular event, state, or activity, which is
indicated on that output. In addition, each LED can be individually configured for output polarity as well
as for blinking versus non-blinking (steady-state) indication.
The configuration for LED outputs is specified via the LEDCTL register. Furthermore, the hardwaredefault configuration for all LED outputs can be specified via NVM fields (Section 6.4.7.3) thereby
supporting LED displays configurable to a particular OEM preference.
Each of the four LED's can be configured to use one of a variety of sources for output indication. For
more information on the MODE bits see LEDCTL register (see Section 8.2.2.1.10).
The IVRT bits enable the LED source to be inverted before being output or observed by the blink-control
logic. LED outputs are assumed to normally be connected to the negative side (cathode) of an external
LED.
The BLINK bits control whether the LED should be blinked (on for 200 ms, then off for 200 ms or 83 ms
on and 83 ms off according to the LEDCTL.GLOBAL_BLINK_MODE) while the LED source is asserted.
The blink control can be especially useful for ensuring that certain events, such as ACTIVITY indication,
cause LED transitions, which are sufficiently visible by a human eye.
Note:The LINK/ACTIVITY mode functions slightly differently than others as it ignores the BLINK
value. The LED is:
• Off if there is no LINK
• On if there is LINK and no ACTIVITY
• Blinks if there is LINK and ACTIVITY
The mapping in Tabl e 3 - 32 is used to specify the LED control source (MODE) for each LED output:
0000bLINK_UPAsserted or blinking according to the LEDx_BLINK setting when any speed link is
0001bLINK_10GAsserted or blinking according to the LEDx_BLINK setting when a 10 Gb/s link is
0010bMAC_ACTIVITYActive when link is established and packets are being transmitted or received. In this
0011bFILTER_ACTIVITYActive when link is established and packets are being transmitted or received that passed
0100bLINK/ACTIVITYAsserted steady when link is established and there is no transmit or receive activity.
0101bLINK_1GAsserted or blinking according to the LEDx_BLINK setting when a 1 Gb/s link is
0110bLINK_100Asserted or blinking according to the LEDx_BLINK setting when a 100 Mb/s link is
0111bLINK_2_5GAsserted or blinking according to the LEDx_BLINK setting when a 2.5 Gb/s link is
1000bLINK_5GAsserted or blinking according to the LEDx_BLINK setting when a 5 Gb/s link is
1001b:1101bReservedReserved.
1110bLED_ONAlways asserted or blinking according to the LEDx_BLINK setting.
1111bLED_OFFAlways de-asserted.
established and maintained.
established and maintained.
mode, the LEDx_BLINK must be set.
MAC filtering. In this mode, the LEDx_BLINK must be set.
Blinking when there is link and receive or Transmit activity.
established and maintained.
established and maintained.
established and maintained.
established and maintained.
3.7 Network Interface
3.7.1 Overview
The X550 provides dual-port network connectivity with copper media. Each port includes integrated
MAC-PHY functionality and can be operated at either 10 GbE, 1 GbE, 5GBASE-T, 2.5GBASE-T, or
100BASE-T(X) link speed. In terms of functionality there is no primary and secondary port as each port
can be enabled or disabled independently from the other, and they can be set at different link speeds.
The integrated PHYs support the following specifications:
• 10GBASE-T as per the IEEE 802.3an standard.
• 1000BASE-T and 100BASE-TX as per the IEEE 802.3 standard.
• 2.5 and 5 Gb/s as per the NBASE-T specification.
Note:The reader is assumed to be familiar with the specifications included in these standards,
which is not overlapping with content of subsequent sections.
All MAC configuration is performed using Device Control registers mapped into system memory or I/O
space; an internal MDIO/MDC interface, accessible via software, is used to configure the PHY operation.
98333369-004
Interconnects—Intel
®
Ethernet Controller X550 Datasheet
3.7.2 Internal MDIO Interface
The X550 implements an internal IEEE 802.3 Management Data Input/Output Interface (MDIO
Interface or MII Management Interface) between each MAC and its attached integrated PHY. This
interface provides firmware and software the ability to monitor and control the state of the PHY. It
provides indirect access to an internal set of addressable PHY registers. It complies with the new
protocol defined by Clause 45 of IEEE 802.3 std. No backward compliance with Clause 22.
Notes:MDIO access to PHY registers must be operational from the time the PHY has completed its
initialization once having read the PHY image from the NVM.
During internal PHY reset events where the MAC is not reset, PHY registers might not be
accessible and the MDIO access does not complete.
Software is notified that PHY initialization and/or reset has completed by either polling or by
PHY reset done interrupt (see Section 3.7.3.4.4).
The internal MDIO interface is accessed through registers MSCA and MSRWD. An access transaction to
a single PHY register is performed by setting the MSCA.MDICMD bit to 1b after programming the
appropriate fields in the MSCA and MSRWD registers. The MSCA.MDICMD bit is auto-cleared after the
read or write transaction completes.
To execute a write access, the following steps should be done:
1. Address Cycle - Register MSCA is initialized with the appropriate PHY register address in MDIADD DEVADD, and PORTADD fields, the OPCODE field set to 00b and MDICMD bit set to 1b.
2. Poll MSCA.MDICMD bit until it is read as 0b.
3. Write Data Cycle - Data to be written is programmed in field MSRWD.MDIWRDATA.
4. Write Command Cycle - OPCODE field in the MSCA register is set to 01b for a write operation and
the MSCA.MDICMD bit is set to 1b.
5. Wait for the MSCA.MDICMD bit to reset to 0b, which indicates that the transaction on the internal
MDIO interface completed.
To execute a read access, the following steps should be done:
1. Address Cycle - Register MSCA is initialized with the appropriate PHY register address in MDIADD DEVADD, and PORTADD fields, the OPCODE field set to 00b and MDICMD bit set to 1b.
2. Poll MSCA.MDICMD bit until it is read as 0b.
3. Read Command Cycle - OPCODE field in the MSCA register is set to 11b for a read operation and
the MSCA.MDICMD bit is set to 1b.
4. Wait for the MSCA.MDICMD bit to reset to 0b, which indicates that the transaction on the internal
MDIO interface completed.
5. Read Data Cycle - Read the data in field MSRWD.MDIRDDATA.
Notes:A read-increment-address flow is performed if the OPCODE field is set to 10b in Step 3 The
address is increased internally once data is read at Step 5 so that no address cycle is needed
to perform a data read from the next address.
Before writing the MSCA register, make sure that the MDIO interface is ready to perform the
transaction by reading MSCA.MDICMD as 0b.
Table 3-33. BER and Ranges vs. Link Speed and Cable Types
SpeedCable Committed ReachCommitted BER
CAT-7Full reach: 100 m
CAT-6aFull reach: 100 m
10GBASE-T
1000BASE-TCAT-5eFull reach: 100 m< 10
100BASE-TXCAT-5eFull reach: 100 m< 10
2.5GBASE-T
5GBASE-T
CAT-6aShort reach: 30 m
CAT-6aJumper mode / direct attach: 1 m
CAT-655 m
CAT-5e1m
CAT-5eFull Reach: 100 m
CAT-6Full Reach: 100 m
CAT-5eFull Reach: 100 m
CAT-6Full Reach: 100 m
< 10
< 10
< 10
-12
-10
-8
-12
-12
Note:Reaches specified in the table refer to real cable lengths and not to the IEEE standard model.
3.7.3.1.2 MDI/Magnetics Spacing
The X550 supports a variable distance of from 1.5 to 4 inches with the magnetics.
3.7.3.1.3 Cable Discharge
The X550 is capable of passing the Intel cable discharge test. Contact your Intel representative for
more details.
3.7.3.2 Auto-Negotiation and Link Setup
Link configuration is always determined by PHY auto-negotiation with the link partner. The X550 does
not support parallel detect 100BASE-TX.
The software device driver must intervene in cases where a successful link is not negotiated or the
designer desires to manually configure the link. This can be the situation only if the link partner is a
legacy 100BASE-TX device, which does not support auto-negotiation.
100333369-004
Loading...
+ hidden pages
You need points to download manuals.
1 point = 1 manual.
You can buy points or you can get point for every manual you upload.