Theory of Operation................................................................................................................................... 51
Overview of Features ................................................................................................................................. 52
Receive Data Path ...................................................................................................................................... 54
RX List Initiator ...................................................................................................................................... 55
Transmit Data Path..................................................................................................................................... 56
LED Control................................................................................................................................................. 59
Status Block .......................................................................................................................................... 61
MII Block................................................................................................................................................ 62
Section 4: Common Data Structures...............................................................................69
Theory of Operation................................................................................................................................... 69
Additional Ring Information for the BCM5718 Family .................................................................... 81
Status Block................................................................................................................................................ 82
Status Block Format .............................................................................................................................. 82
INTx/MSI — Legacy Mode Status Block Format ............................................................................ 83
Single-Vector or INTx — RSS Mode Status Block Format ............................................................. 84
Multivector RSS Mode Status Block Format .................................................................................. 85
Status Block and INT MailBox Addresses...................................................................................... 86
Section 5: Receive Data Flow...........................................................................................88
VLAN Tag Strip........................................................................................................................................... 98
RX Data Flow Diagram ............................................................................................................................. 100
Receive Side Scaling................................................................................................................................101
VLAN Tag Insertion.................................................................................................................................. 131
TX Data Flow Diagram.............................................................................................................................. 131
Configuration Space ................................................................................................................................168
PCI State Register ....................................................................................................................... 184
PCI Base Address Register ......................................................................................................... 184
Bus Interface............................................................................................................................................. 186
MII Control........................................................................................................................................... 550
Broadcom
January 29, 2016 • 5718-PG108-RPage 34
®
Page 35
Table of ContentsBCM5718 Programmer’s Guide
MII Status ............................................................................................................................................ 551
Flow Control Scenario ............................................................................................................................. 574
File Transfer ........................................................................................................................................ 575
File Transfer Complete........................................................................................................................ 578
Pause Control Frame ............................................................................................................................... 578
Figure 24: Ring Control Block ........................................................................................................................ 121
Figure 52: MSI Data FIeld .............................................................................................................................. 238
Table 2: BCM5718 Family Product Features................................................................................................... 47
Table 3: Family Revision Levels ...................................................................................................................... 49
Table 4: Ring Control Block Format ................................................................................................................. 71
Table 5: Flag Fields for a Ring ......................................................................................................................... 71
Table 6: Send RCBs for Multiple Rings ........................................................................................................... 72
Table 7: High Priority Mail Box Registers for VRQ Rings ................................................................................ 72
Table 8: Send Buffer Descriptors Format ........................................................................................................ 75
Table 9: Defined Flags for Send Buffer Descriptors ........................................................................................ 75
Table 18: Status Block Host Addresses and INT MailBox Addresses ............................................................. 86
Table 19: Status Word Flags ........................................................................................................................... 86
Table 29: ISO Read DMA Mode Register (Offset: 0x4A00)........................................................................... 111
Table 30: Flag Field Description .................................................................................................................... 113
Table 125: GbE Port Internal PHY Register Map .......................................................................................... 548
Table 126: MII Control ................................................................................................................................... 550
Table 127: MII Status ..................................................................................................................................... 551
This document covers the Broadcom® BCM5718 family of NetXtreme®/NetLink® Ethernet controllers. This
family of controllers includes the following devices:
•BCM5717
•BCM5718
•BCM5719
•BCM5720
The document focuses on the registers, control blocks, and software interfaces necessary for host software
programming. It is intended to complement the data sheet for the appropriate member of the NetXtreme/NetLink
Ethernet controller family. The errata documentation (see “Revision Levels” on page 49) complements this
document.
Acronyms and Abbreviations
In most cases, acronyms and abbreviations are defined on first use.
For a comprehensive list of acronyms and other terms used in Broadcom documents, go to:
http://www.broadcom.com/press/glossary.php.
Document Conventions
The following conventions may be used in this document:
ConventionDescription
BoldUser input and actions: for example, type exit, click OK, press Alt+C
Monospace
< >Placeholders for required elements: enter your <username> or wl <command>
[ ]Indicates optional command-line parameters: wl [-l]
ConventionDescription
Code: #include <iostream>
HTML: <td rowspan = 3>
Command line commands and parameters: wl [-l] <command>
Indicates bit and byte ranges (inclusive): [0:3] or [7:0]
Table 1: Register Access Methods
A/CClear contents after read
RORead-Only access, Write has no effect
RWFull Read and Write access
WOWrite-Only access, Read returns garbage
Broadcom®
January 29, 2016 • 5718-PG108-RPage 44
Page 45
BCM5718 Programmer’s Guide
Table 1: Register Access Methods (Cont.)
Convention Description
W1CWrite a value 1 to clear the bit.
W1SWrite a value 1 to set the bit
WZOWrite 0 only to avoid side effects, Read returns garbage
RW1CReadable / Write a 1’b1 value to clear the bit.
RW1SReadable / Write a 1’b1 to set the bit
RW/SReadable / Writeable but is not affected by any CPU reset or AHB reset.
References
The references in this section may be used in conjunction with this document.
Note: Broadcom provides customer access to technical documentation and software through its
Customer Support Portal (CSP) and Downloads & Support site (see Technical Support).
For Broadcom documents, replace the “xx” in the document number with the largest number available in the
repository to ensure that you have the most current version of the document.
Broadcom provides customer access to a wide range of information, including technical documentation,
schematic diagrams, product bill of materials, PCB layout information, and software updates through its
customer support portal (https://support.broadcom.com
support representative.
In addition, Broadcom provides other product support through its Downloads & Support site
(http://www.broadcom.com/support/
).
). For a CSP account, contact your Sales or Engineering
Broadcom®
January 29, 2016 • 5718-PG108-RPage 46
Page 47
IntroductionBCM5718 Programmer’s Guide
Section 1: Introduction
The NetXtreme and NetLink family of Media Access Controller (MAC) devices are highly-integrated, single-chip
Gigabit Ethernet LAN controller solutions for high-performance network applications. These devices integrate
the following major functions to provide a single-chip solution for Gigabit LAN-on-motherboard (LOM) and
network interface card (NIC) applications.
•Triple-speed IEEE 802.3-compliant MAC functionality
See Table 3 for the revision levels of the Ethernet controllers covered by this document. Host software can use
the PCI Revision ID and Chip ID information in the PCI configuration registers to determine the revision level of
the Ethernet controller on the board, and then load the appropriate workaround described in the errata sheets.
The Broadcom PCI vendor ID is 0x14E4. Ta bl e 3 shows the default values of PCI device IDs. These values may
be modified by firmware in accordance with the manufacturing information supplied in NVRAM (see “NVRAM
a.See Device ID and Vendor ID Register (Offset: 0x00) —Function 0”, per PCI specification.
b.See “PCI Classcode and Revision ID Register (offset: 0x8)—Function 0” as per the PCI specification. The
hardware default value of this register is 0x00. The boot code firmware programs this register with the value
as given in the table.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 49
Page 50
Programming the Ethernet ControllersBCM5718 Programmer’s Guide
c.See “Miscellaneous Host Control Register (offset: 0x68)” on page 282. The lower 16 bits are don’t cares for
determining chip id.
d.See “Product ASIC ID (offset: 0xF4)” on page 300 or determining ASIC ID.
e.See the appropriate errata documentation for the errata information and resolutions.
Note: If you are using silicon revision A0 of the BCM5718, you must load a “patch” image
(ap5718.012) into the boot code NVRAM in addition to the usual legacy boot code image common to
all NetXtreme/NetLink controllers. This extra patch image, which masquerades as “Management
Firmware”, works around an issue with A0 silicon in which the device may fail to load reliably and
execute the primary boot code image. This issue is fixed in BCM5718 B0 and is not an issue in
BCM5719 or BCM5720.
Programming the Ethernet Controllers
See Table 3 on page 49 for the revision levels of the Ethernet controllers. Host software can use the PCI
Revision ID and Chip ID information in the PCI configuration registers to determine the revision level of the
Ethernet controller on the board, and then load the appropriate workarounds described in the errata sheets.
Choice of host access mode determines the mailboxes:
•Host standard mode uses the high-priority mailboxes (see “Mailbox Registers” on page 92).
•Indirect mode uses the low-priority mailboxes (see “Mailbox Registers” on page 92).
The reference documents for Ethernet controller software development include this manual and the errata
documentation (see “Revision Levels” on page 49) that provide the necessary information for writing a host-
®
based device driver. The Broadcom Linux
driver (a.k.a. “tg3”) is also a very good reference source for writing
your own driver.
The programming model for the NetXtreme/NetLink Ethernet controllers does not depend on OS or processor
®
instruction sets. Programmers using Motorola
68000, Intel® x86, or DEC Alpha host instruction sets can
leverage this document to aid in device driver development. Concepts provided in this document are also
®
applicable to device drivers native to any operating system (i.e., DOS, UNIX
, Microsoft®, or Novell®).
Broadcom®
January 29, 2016 • 5718-PG108-RPage 50
Page 51
Hardware ArchitectureBCM5718 Programmer’s Guide
Receive
MAC
Rx
FIFO
Transmit
MAC
Tx
FIFO
Statistics
Rule
Check
Memory
Arbiter
Tx Frame Buffer
Memory
Send BD RING
RISC
Processor
Boot ROM
Frame Buffer
Manager
Queue
Memory
Read DMA
Read
FIFO
Write
DMA
Write
FIFO
Registers
PCIe Bus
Ring Controllers
Host Coalescing
Queue Management
Receive
GMII
Transmit
GMII
LED Control
PLL
LED Signals
125-MHz Clock
Receive BD RING
DMA Descriptor
Config
EEPROM Control
NVRAM
Interface
Physical Layer
Transceiver
PCIe
Rx Frame Buffer
Memory/RISC Scratch
Pad Memory
Applications
Processing
Engine
(APE runs
firmware such
as NC-SI)
Section 2: Hardware Architecture
Theory of Operation
Figure 1 shows the major functional blocks and interfaces of the Ethernet controllers covered in this document.
Only a single port is illustrated in Figure 1. The dual-port controllers in this family of controllers essentially
replicate a second instance of the major areas of functionality shown in the diagram below. The dual-port
controllers have only a single PCIe and NVRAM interfaces.
There are two packet flows: MAC-transmit and receive. The device’s DMA engine bus-masters packets from
host memory to device local storage, and vice-versa. The host bus interface is compliant with PCIe standards.
The RX MAC moves packets from the integrated PHY into device internal memory. All incoming packets are
checked against a set of QOS rules and then categorized. When a packet is transmitted, the TX MAC moves
data from device internal memory to the PHY. Both flows operate independently of each other in full-duplex
mode. An on-chip RISC processor is provided for running value-added firmware that can be used for custom
frame processing. The on-chip RISC operates independently of all the architectural blocks; essentially, RISC is
available for the auxiliary processing of data streams.
Figure 1: Individual Port Functional Block Diagram
Broadcom®
January 29, 2016 • 5718-PG108-RPage 51
Page 52
Overview of FeaturesBCM5718 Programmer’s Guide
Overview of Features
The BCM5718 family of controllers represents the third generation of Broadcom NetXtreme multi-port Gigabit
Ethernet controllers. This family is the successor to the BCM5714/BCM5715 family. The BCM5717, BCM5718,
and BCM5720 feature two independent 1 Gb Ethernet ports on the network side. A host computer can
communicate with the controller over a single PCIe link. However, the two network controller ports appear as
two independent PCIe functions to the host operating system (four functions in the quad-port BCM5719). In
essence, the chip consists of a single PCIe interface controller that offers multiple function-level interfaces, and
each function-level interface is further attached to an independent DMA engine which in turn feeds an
independent Ethernet Media Access Controller (EMAC).
Attached to the other end of each EMAC is the respective 802.3 Ethernet physical media interface. The
controller essentially consists of multiple DMA+EMAC logic instances, multiple Ethernet physical interfaces, and
a single instance of a PCIe core that is shared by the DMA blocks.
The BCM5718 is available as four SKUs, BCM5717, BCM5718, BCM5719 and BCM5720. These are also
referred to as the Dual-Copper SKU and the Dual-Media SKU. For the BCM5718, BCM5719, and BCM5720
part, any of the network ports may be independently configured as a copper-based (1000BASE-T) or as SerDesbased (1000BASE-X/SGMII) media interfaces. The choice of media interface on each port is configurable via a
power-on strapping option.
The BCM5717 part is permanently bonded as a copper (1000BASE-T) only device.
For the Dual-Media SKU (BCM5718 and BCM5719), whenever a port is configured as a SerDes medium, there
are two protocol choices: 1000BASE-X or SGMII. This choice can be made by an Auto-Detect feature or by
explicit software programming.
The software driver for this device is capable of loading or unloading each network port independently. The
DMA+EMAC associated with each port is also able to acquire different ACPI power states irrespective of the
other; however, the power state of the PCIe link may not necessarily follow that of either one or both ports. This
is a significant behavioral difference of a dual-port controllers compared to single-port. The BCM5718 family
hardware and firmware is cognizant of this effect and adds the necessary intelligence to handle it. This
functionality remains transparent to device driver software.
On top of the basic dual-port network controller functionality, the BCM5718, BCM5719, and BCM5720 also
support an advanced feature known as IO Virtualization (IOV).
Network Controller Sideband Interface (NC-SI) pass-through functionality is the Server Management solution
offered by the BCM5718 family of controllers. NC-SI pass-through is a part of the Server Management
infrastructure. Such technology offers server platform management via a BMC (baseboard management
controller) chip. A server platform and, in turn, a BMC is typically administered remotely over the network, but
BMCs are not equipped with direct network connectivity. Here, a network controller chip comes into the picture—
a pass-through-capable NIC chip offers a sideband packet interface to the BMC. Over this interface the BMC
can send and receive Ethernet packets to and from the network. In essence, the network adapter functionality
of the network controller chip is shared by the host computer system and the BMC chip. NC-SI pass-through
protocol is an industry standard (DMTF) for a side band interface between the BMC and network controller. The
physical and L2 layers of NC-SI are upwardly compliant to the respective sections of the IEEE 802.3
specification, thus allowing the exchange of Ethernet packets between the network port and BMC without any
protocol transformation whatsoever.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 52
Page 53
Overview of FeaturesBCM5718 Programmer’s Guide
Dual Function
PCIe
DMA 0DMA 1
EMAC 0EMAC 1
GHPY 0Serdes 0 GHPY 1Serdes 1
BMC
Host
Chipset
Mgmt
Engine
NC-SI
Pass - through
PCIe Link
BCM5718 Family
Port 0
Port 1
NVRAM
Device
RMII
x2 Gen1 /
x1 Gen2
In an environment of several network servers, typically no server is dedicated to running only the management
console. Host to BMC pass-through functionality identifies host to local BMC-bound packets and routes them
internally to the chip. Similarly, BMC to local host-bound packets are also identified and routed internally to the
NIC chip. Host to BMC pass-through functionality is offered by the BCM5720 controller.
In addition to IEEE 802.3 standard size Ethernet frames, the BCM5718 family also supports jumbo frames of
sizes up to 9622 bytes.
The BCM5718 family of controllers replaces the traditional PNP-based linear regulator with a more efficient
switching regulator. This regulator steps down system supplied 3.3V rail to 1.2V, which it supplies to the chip’s
core.
Figure 2: High-Level System Functional Block Diagram
Broadcom®
January 29, 2016 • 5718-PG108-RPage 53
Note: BCM5719 has the same general architecture, but four ports (ports 0, 1, 2, 3) and a quad-function
PCIe interface.
Page 54
Receive Data Path
RX
Engine
Rules Checker
Rx
FIFO
Frame
Buffers
Empty BD
NIC Standard RX Producer Ring
Host RX
Return
Ring
List
Initiator
Rx Return BD
Rx Return BD
Rx Return BD
Rx Return BD
Rx Return BD
Hos t St an d a rd R X P ro d u c er
Ring
DMA
DMA
Full BD
Empty BD
NIC Jumbo RX Producer Ring
DMA
Host Jumbo RX Produce r Ring
RX Engine
The receive engine (see Figure 3) activates whenever a packet arrives from the PHY.
Figure 3: Receive Data Path
Receive Data PathBCM5718 Programmer’s Guide
The receive engine performs the following four functions:
•Moves the data from the PHY to an internal FIFO
•Moves the data from the FIFO to NIC internal memory
•Classifies the frame and checks it for rules matches
•Performs the offloaded checksum calculations
RX FIFO
The RX FIFO provides elasticity while data is read from PHY transceiver and written into internal memory. There
are no programmable settings for the RX FIFO. This FIFO’s operation is completely transparent to host
software.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 54
Page 55
Receive Data PathBCM5718 Programmer’s Guide
Rules Checker
The rules checker examines frames. After a frame has been examined, the appropriate classification bits are
set in the buffer descriptor. The rules checker is part of the RX data path and the frames are classified during
data movement to NIC memory. The following frame positions may be established by the rules checker:
•IP Header Start Pointer
•TCP/UDP Header Start Pointer
•Data Start Pointer
RX List Initiator
The RX List Initiator function activates whenever the receive producer index for any of receive buffer descriptor
(BD) rings is written. This value is located in one of the receive BD producer mailboxes. The host software writes
to the producer mailbox and causes the RX Initiator function to enqueue an internal data structure/request,
which initiates the DMA of one or more new BDs to the NIC. The actual DMAs generated depend on the
comparison of the value of the received BD host producer index mailbox, the NIC copy of the received BD
consumer index, and the local copy of the received BD producer index.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 55
Page 56
Transmit Data PathBCM5718 Programmer’s Guide
TX
MAC
Consumer
Index
Update
Tx
FIFO
Send BD
NIC Send Ring Cache
Select Send BDs
(SBDs) from Send
Ring
Host Send Producer Rings
DMA
DMA
TX Data
TX Data
TX Data
TX Data
TX Data
TX Data
TX Data
TX Data
Buffer0
Buffer1
Buffer2
Buffer3
Buffer4
Buffer5
Transmit Data Path
TX MAC
The Read DMA engine moves packets from host memory into internal NIC memory (see Figure 4). When the
entire packet is available, the transmit MAC is activated.
Figure 4: Transmit Data Path
The transmit MAC is responsible for the following functions:
•Moving data from NIC internal memory into TX FIFO
•Moving data from TX FIFO to PHY
•Checksum substitutions (not calculation)
•Updating statistics
TX FIFO
The TX FIFO provides elasticity while data is moved from device internal memory to PHY. There are no
programmable settings for the TX FIFO. This FIFO’s operation is completely transparent to host software.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 56
Page 57
DMA ReadBCM5718 Programmer’s Guide
text
text
DMA
BD Packet#1
Host Send Buffer
Descriptors
Packet Data #1
Host Send Buffer
Memory
Buffer M anager
BD Packet#1
Frame Clas sify &
Checksum
Calculat ion
text
Packet Data #1
Frame Header #1
NIC BD
Memory
NIC Buffer
Memory
Tx
FIFO
Frame
Mod
TX
MAC
Statistics
TX
PCS
TX
RMII
TX
GMII
TX
IO
6416
Read
FIFO
DMA Read
Read Engine
The DMA read engine (see Figure 5) activates whenever a host read is initiated by the send or receive data
paths.
Figure 5: DMA Read Engine
The DMA read engine dequeues an internal data structure/request and performs the following functions:
•DMAs the data from the host memory to an internal Read DMA FIFO
•Moves the data from the Read DMA FIFO to NIC internal memory
•Classifies the frame
•Performs checksum calculations
•Copies the VLAN tag field from the DMA descriptor to the frame header
Read FIFO
The read FIFO provides elasticity during data movement from host memory to device local memory. The
memory arbiter is a gatekeeper for multiple internal blocks; several portions of the architecture may
simultaneously request internal memory. The PCI read FIFO provides a small buffer for the data read from host
memory while the Read DMA engine requests internal memory via the memory arbiter. The data is moved out
of the read DMA FIFO into device local memory once a memory data path is available. The FIFO isolates the
PCI clock domain from the device clock domain. This reduces latency internally and externally on the PCI bus.
The PCIe Read DMA FIFO holds 1024 bytes. The operation of the read DMA FIFO is transparent to host
software. The Read DMA engine makes sure there is enough space in internal Tx Packet Buffer Memory before
initiating a DMA request for transfer of Tx packet data from host memory to device internal packet memory.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 57
Page 58
DMA WriteBCM5718 Programmer’s Guide
text
RX
PCS
RX
RMII
RX
GMII
RX
IO
RX
MAC
Frame
Mod
WOL
Filter
Rx
FIFO
Power
Management
Frame Header #1
Packet Data #1
Frame
Cracker
Checksum
Calculation
Rules
Checker
Statistics
BD Packet #1
NIC
BD Memory
NIC
BufferMemory
Buffer Manager
DMA
Packet Data #1
BD Packet #1
Host Receive Buffer
Descriptor Ring
Host Receive Buffer
Memory
Write
FIFO
Buffer Manager
The buffer manager maintains pools of internal memory used by transmit and receive engines. The buffer
manager has logic blocks for allocation, free, control, and initialization of internal memory pools. The DMA read
engine requests internal memory for BDs and frame data. Figure 5 on page 57 shows the transmit data path
using the DMA Read Engine. The read DMA engine also fetches Rx BDs for the receive data path.
DMA Write
Write Engine
The DMA write engine, as shown in Figure 6, activates when a host write is initiated by the send or receive data
paths.
Figure 6: DMA Write Engine
The DMA write engine dequeues an internal request and performs the following functions:
•Gathers the data from device internal memory into the write DMA FIFO
•DMAs the data to the host memory from the write FIFO
•Performs byte and word swapping
•Interrupts the host using a line or message signaled interrupt
Write FIFO
The write FIFO provides elasticity during data movement from device memory to the host memory. The write
FIFO absorbs small delays created by PCIe bus arbitration. The NetXtreme family uses the write FIFO to buffer
data, so internal memory arbitration is efficient. Additionally, the FIFO isolates the PCI clock domain from the
device’s clock domain. This reduces latency on the PCI bus during the write operation (wait states are not
inserted while data is fetched from internal memory). The operation of the write DMA FIFO is transparent to host
software.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 58
Page 59
LED ControlBCM5718 Programmer’s Guide
Buffer Manager
The buffer manager maintains pools of internal memory used in transmit and receive functions. The buffer
manager has logic blocks for allocation, free, control, and initialization of internal memory pools. The receive
MAC requests NIC Rx Mbuf memory so inbound frames can be buffered. The read DMA engine requests the
device Tx Mbuf memory for buffering the packets from host memory before they are sent out on the wire. The
DMA write engine requests a small amount of internal memory for DMA and interrupt operations. The usage of
this internal memory is transparent to host software, and does not affect device/system performance.
LED Control
Refer to section “LED Control” in the applicable data sheet.
Memory Arbiter
The Memory Arbiter (MA) is a gatekeeper for internal memory access. The MA is responsible for decoding the
internal memory addresses that correspond to Ethernet controller data structures and control maps. If a
functional block faults or traps during access to internal memory, the MA handles the failing condition and reports
the error in a status register. In addition to architectural blocks, the MA provides a gateway for the RISC
processor to access local memory. The RISC has an MA interface that pipelines up to three access requests.
The MA negotiates local memory access, so all portions of the architecture are provided with fair access to
memory resources. The MA prevents starvation and bounds access latency. Host software may enable/disable/
reset the MA, and there are no tunable parameters.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 59
Page 60
Host CoalescingBCM5718 Programmer’s Guide
...
DMA
Write
Engine
Status Block
PCIe
Interface
Buffer
Manager
Host
Coalescing
Engine
MSI Mailbox
I/O
Driver
Host
Interrupt
Controller
IRQ
Write
FIFO
Tick
CounterBDCounter
Status
Memory
Host software may configure
line IRQ or MSI
MSI
FIFO
Host Coalescing
Host Coalesci ng Engine
The Host Coalescing Engine is responsible for pacing the rate at which the NIC updates the send and receive
ring indices located in host memory space. The completion of a NIC update is reflected through an interrupt on
the Ethernet controller INTA
separately, all updates occur at once. This is because all of the ring indices are in one status block, and any host
update updates all ring indices simultaneously. The Host Coalescing Engine triggers based on a tick and/or a
frame counter.
pin or a Message Signaled Interrupt (MSI). Although update criteria are calculated
Figure 7: Host Coalescing Engine
Broadcom®
January 29, 2016 • 5718-PG108-RPage 60
Page 61
Host CoalescingBCM5718 Programmer’s Guide
A host update occurs whenever one of the following criteria is met:
•The number of BDs consumed for frames received, without updating receive indices on the host, is equal to
or has exceeded the threshold set in the Receive_Max_Coalesced_BD register (see “Receive Max
Coalesced Bd Count Register (Offset: 0x3c10)” on page 254).
•The number of BDs consumed for transmitting frames, without updating the send indices, on the host is
equal to or has exceeded the threshold set in the Send_Max_Coalesced_BD register (see “Send Max
Coalesced BD Count Register (Offset: 0x3c14)” on page 254). Updates can occur when the number of BDs
(not frames) meets the thresholds set in the various coalescing registers (see Section 11: “Interrupt
Processing,” on page 229 for more information).
•The receive coalescing timer has expired, and new frames have been received on any of the receive rings,
and a host update has not occurred. The receive coalescing timer is then reset to the value in the
Receive_Coalescing_Ticks register (see “Send Coalescing Ticks Register (Offset: 0x3c0c)” on page 254).
•The send coalescing timer has expired, and new frames have been consumed from any send ring, and a
host update has not occurred. The send coalescing timer is then reset to the value in the
Send_Coalescing_Ticks register.
MSI FIFO
This FIFO is eight entries deep and four bits wide. This FIFO is used to send MSIs via the PCI interface. The
host coalescing engine uses this FIFO to enqueue requests for the generation of MSI. There are no configurable
options for this FIFO and this FIFOs operation is completely transparent to host software.
Status Block
This data structure contains consumer and producer indices/values. Host software reads this control block, to
assess hardware updates in the send and receive rings. Two copies of the status block exist. The local copy is
DMAed to host memory by the DMA write engine. Host software does not want to generate PCI transactions to
read ring status; rather quicker memory bus transactions are desired. The host coalescing engine enqueues a
request to the DMA write engine, so host software gets a refreshed copy of status. The status block is refreshed
before a line IRQ or MSI is generated. See “Status Block Format” on page 82 for a complete discussion of the
status block.
The Ethernet controller devices negotiate their mode of operation over the twisted-pair link using the autonegotiation mechanism defined in the IEEE 802.3u and IEEE 802.3ab specifications. Auto-negotiation can be
enabled or disabled by hardware or software control. When the auto-negotiation function is enabled, the
Ethernet controllers automatically choose the mode of operation by advertising its abilities and comparing them
with those received from its link partner. The Ethernet controllers can be configured to advertise 1000BASE-T
full-duplex and/or half-duplex, 100BASE-TX full-duplex and/or half-duplex, and 10BASE-T full-duplex and/or
half-duplex. The transceiver negotiates with its link partner and chooses the highest operating speed and duplex
that are common between them. Auto-negotiation can be disabled for testing or for forcing 100BASE-TX or
10BASE-T operation, but is always required for normal 1000BASE-T operation.
Automatic MDI Crossover
During auto-negotiation, one end of the link must perform an MDI crossover so that each transceiver’s
transmitter is connected to the other receiver. The Ethernet controllers can perform an automatic MDI crossover
when the Disable Automatic MDI Crossover bit in the PHY Extended Control register is disabled, thus
eliminating the need for crossover cables or cross-wired (MDIX) ports. During auto-negotiation, the Ethernet
controllers normally transmit on TRD{0} and receive on TRD{1}. When connected to another device that does
not perform the MDI crossover, the Ethernet controller automatically switches its transmitter to TRD{1} and its
receiver to TRD{0} to communicate with the remote device. If two devices that both have MDI crossover
capability are connected, an algorithm determines which end performs the crossover function. During
1000BASE-T operation, the Ethernet controllers swap the transmit symbols on pairs 0 and 1 and pairs 2 and 3
if auto-negotiation completes in the MDI crossover state. The 1000BASE-T receiver automatically detects pair
swaps on the receive inputs and aligns the symbols properly within the decoder.
PHY Control
The NetXtreme/NetLink Ethernet controller supports the following physical layer interfaces:
•The MII is used in conjunction with 10/100 Mbps copper Ethernet transceivers.
The MII interconnects the MAC and PHY sublayers (as shown in Figure 8 on page 63).
Broadcom®
January 29, 2016 • 5718-PG108-RPage 62
Page 63
Figure 8: Media Independent Interface
RX
I/O
RXD /4
RX_CLK1
RX_ER
RX_DV
TX
I/O
TXD /4
MII_TXCLK
TX_ER
TX_EN
Media
Status
I/O
COL
CRS
LNKRDY
RX Media
Access
Mgmnt
RX
MAC
Rx Data
Decapsulation
TX
Media
Access
Mgmnt
TX
MAC
Tx Data
Encapsulation
MAC Sublayer
Physical Layer
RX
I/O
Symbol
Decoder
TX
I/O
Symbol
Encoder
4-bit Data Path
2.5 MHz at 10 Mbps
25 MHz at 100 Mbps
4-bit Data Path
LED
Control
LED
I/O
2.5 MHz at 10 Mbps
25 MHz at 100 Mbps
MII
PHY ControlBCM5718 Programmer’s Guide
Broadcom®
January 29, 2016 • 5718-PG108-RPage 63
Page 64
PHY ControlBCM5718 Programmer’s Guide
The specifics of MII may be located in section 22 of the IEEE 802.3 specification. RXD[3:0] are the receive data
signals; TXD[3:0] are the transmit data signals. MII operates at both 10-Mbps and 100-Mbps wire-speeds.
(Gigabit Ethernet uses the GMII standard.) When MAC and PHY are configured for 10 Mbps operation, the
RX_CLK1 and MII_TXCLK clocks run at 2.5 MHz. Both RX_CLK1 and MII_TXCLK are sourced by the PHY. 100
Mbps wire speed requires RX_CLK1 and MII_TXCLK to provide a 25 MHz reference clock. Receive Data Valid
(RX_DV) is asserted when valid frame data is received; at any point during data reception, the PHY may assert
Receive Error (RX_ER) to indicate a receive error. The MAC will record this error in the statistics block. The
MAC may discard a bad RX frame—exception being sniffer/promiscuous modes (see Allow_Bad_Frames bit in
MAC mode register). The Transmit Enable (TX_EN) signal is asserted when the MAC presents the PHY with a
valid frame for transmission. The MAC may assert TX_ER to indicate the remaining portion of frame is bad. The
PHY will insert Bad Code symbols into the remaining portion of the frame. A detected collision in half-duplex
mode may be such a scenario where TX_ER is asserted. The PHY will assert COL when a collision is detected.
The COL signal is routed to both the RX and TX MACs. The transmit MAC will back off transmission and the
RX MAC will throw away partial frames.
The 10 Mbps physical layer uses Differential Manchester encoding on the wire. Manchester encoding uses two
encoding levels: 0 and 1. 100 Mbps Ethernet requires MLT-3 waveshaping on the transmission media. MLT-3
uses three encoding levels: – 1, 0, and 1. Both physical signaling protocols are transparent to the MAC sublayer
and are digitized by the PHY. The PHY encodes/decodes analog waveforms at its lower edge while the PHY
presents digital data at its upper edge (MII).
GMII Block
The GMII is full-duplex (see Figure 9 on page 65); the send and receive data paths operate independently.
The transmit signals TXD[7:0] create a eight-bit wide data path. The TXD[7:0] signals are synchronized to the
reference clockTX_CLK0. The TX_CLK0 clock runs at 125 MHz and is sourced by the MAC sublayer. Transmit
Error (TX_ER) is asserted by the MAC sublayer. The PHY will transmit a bad code until TX_ER is deasserted
by the MAC. TX_ER is driven synchronously with TX_CLK0. The Transmit Enable (TX_EN) indicates that valid
data is presented on the TXD lines. The TXD[7:0] data is framed on the rising edge of TX_EN.
The receive data path is also eight bits wide. RXD[7:0] are sourced by the PHY. When valid data is presented
to the MAC sublayer, the PHY will also assert Receive Data Valid (RX_DV). The rising edge of RX_DV indicates
the beginning of a frame sequence. The PHY drives the reference clock RX_CLK1, so the MAC sublayer can
synchronize data sampling on RXD[7:0]. The PHY may assert RX_ER to indicate frame data is invalid; the MAC
sublayer must consider frames in progress incomplete.
When the MAC operates in half-duplex mode, a switch or node may transmit a jamming pattern. The PHY will
drive the Collision (COL) signal so the MAC may back off transmission and throw away partially received
packet(s). The COL signal will also cause the TX MAC to stop the transmission of a packet. The COL signal is
not driven for full-duplex operation since collisions are undefined. The PHY will drive Carrier Sense (CRS) as a
response to traffic being sent/received. The MAC sublayer can monitor traffic and subsequently drive traffic
LEDs.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 64
Page 65
PHY ControlBCM5718 Programmer’s Guide
RX
I/O
RXD /8
RX_CLK1
RX_ER
RX_DV
TX
I/O
TXD /8
TX_CLK0
TX_ER
TX_EN
Media
Status
I/O
COL
CRS
LNKRDY
RX Media
Access
Mgmnt
RX
MAC
Rx Data
Decapsulation
TX Media
Access
Mgmnt
TX
MAC
Tx Data
Encapsulation
MAC Sublayer
Physical Layer
RX
I/O
Symbol
Decoder
LED
Control
TX
I/O
Symbol
Encoder
125-MHz Ref Clock8-bit Data Path
LED
I/O
8-bit Data Path125-MHz Ref Clock
GMII
Pulse Amplitude Modulated Symbol (PAM5) encoding is leveraged for Gigabit Ethernet wire transmissions.
PAM5 uses five encoding levels: –2, – 1, 0, 1, and 2. Four symbols are transmitted in parallel on the four twistedwire pairs. The four symbols create a code group (an eight-bit octet). The process of creating the code-group is
called 4D-PAM5. Essentially, eight data bits are represented by four symbols. Table 40-1 in the IEEE 802.3ab
specification shows the data bit to symbol mapping. The code group representation is also referred to as a
quartet of quinary symbols {TA, TB, TC, TD}. The modulation rate on the wire is measured at 125 Mbaud. The
resultant bandwidth is calculated by multiplying 125 MHz by eight bits, for
1000 Mbps wire speed.
Figure 9: GMII Block
Broadcom®
January 29, 2016 • 5718-PG108-RPage 65
Page 66
MDIO Register Interface
MAC Sublayer
Mgmnt
I/O
Mgmnt
Control
(MII & GMII)
Physical Layer
Mgmnt
I/O
Mgmnt
Control
MDC
MDIO
MDINT
MDI
Register
block
Figure 10 shows the MDI register interface.
Figure 10: MDI Register Interface
PHY ControlBCM5718 Programmer’s Guide
Management Data Clock
The Management Data Clock (MDC) is driven by the MAC sublayer. The PHY will sink this signal to synchronize
data transfer on the MDIO signal—MDC is a reference clock. This clock is not functionally associated to either
RX_CLK or TX_CLK. The minimum period for this clock is 400 ns with high and low times having 160 ns
duration.
Management Data Inpu t/Output
The Management Data Input/Output (MDIO) signal passes control and status data, between the MAC and PHY
sublayers. MDIO is a bidirectional signal, meaning both the PHY and MAC may transfer data. The MAC typically
transfers control information and polls status; whereas, the PHY transfers status back to the MAC, using MDIO.
Management Data Interrupt
The integrated Broadcom PHY may be programmed to generate interrupts. A PHY status change initiates a
Management Data Interrupt (MDINT). A MDI mask register allows host software to selectively enable/disable
status types, which cause MDINT notification. The PHY will assert INTR
Reading the status register will clear the interrupt.
until software clears the interrupt.
Management Register Block
The layout and configuration of MDI register block is device dependent. The MDI register block is the control/
status access point, which host software may read/write. The IEEE 802.3 specification defines a basic register
block for MII and GMII; the basic register set contains control and status registers. GMII also exposes an
extended register set, used in 1000 Mbps configuration/status. The fundamental point is to understand that the
MDC and MDIO signals are used to access the MDI register block.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 66
Page 67
NVRAM ConfigurationBCM5718 Programmer’s Guide
Section 3: NVRAM Configuration
Overview
Broadcom NetXtreme and NetLink controllers require the use of an external non-volatile memory (NVRAM)
device (Flash or SEEPROM), which contains a boot code program that the controller's on-chip CPU core loads
and executes upon release from reset. This external NVRAM device also contains many configuration items that
direct the behavior of the controller, enable/disable various management and/or value-add firmware
components, etc.
All configuration settings are default-configured in the official release binary image files provided in Broadcom's
CD software releases. However, the settings chosen as default by Broadcom may not be what best suits a
particular OEM's application, so some settings may need to be changed by the OEM.
The BCM5718 family supports the following boot code styles:
•“Legacy”—Boot code plus configuration options fully contained in an external 8k byte NVRAM device
•“Self-boot”—Uses a fixed internal ROM'd copy of the boot code program (requires only a very small
external NVRAM) for the purpose of housing OEM-programmable configuration items (refer to Application
Note NetXtreme-AN60x-R “NetXtreme/NetLink NVRAM Configuration Options”).
Note: If using self-boot, the design must use a very small (approximately 256 byte) external NVRAM
to hold configuration items and self-boot code patches.
Refer to Broadcom Application Note NetXtreme-AN40X-R (NetXtreme
Application Note) for additional detail regarding self-boot NVRAM structure.
Details relating to the legacy style NVRAM organization can be found in NetXtreme/NetLink NVRAM Access
Broadcom application note (NetXtreme-AN50X-R). Some of the topics addressed by this application note
include the following:
•Programming NVRAM (sample C code, x86 assembly)
•NVRAM map
•Configuration settings
•Boot code
•Multiple boot agent (MBA), PXE, etc.
Note: NVRAM CRC-32: There are multiple distinct regions contained within the NVRAM map. Each
of these regions has its own CRC-32 checksum value associated with it. If any data element contained
within a region is modified, then that region's CRC-32 value must also be updated. Details relating to
calculating the CRC-32 can be found in Calculating CRC32 Checksums for Broadcom NetLink,
Some NetLink controllers offer a capability known as self-boot. Self-boot allows the controller to use a very
small, low-cost, external NVRAM device that contains only a very condensed amount of configuration
information, along with any small boot code patches that may be necessary to optimize the functionality of a
particular controller.
Details relating to self-boot can be found in Self Boot Option (5754X_5787X-AN10X-R) and NetXtreme/NetLink Software Self-Boot NVRAM (NetXtreme-AN40X-R) Broadcom application notes.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 68
Page 69
Common Data StructuresBCM5718 Programmer’s Guide
Section 4: Common Data Structures
Theory of Operation
Several device data structures are common to the receive, transmit, and interrupt processing routines. These
data structures are hardware-related and are used by device drivers to read and update state information.
Descriptor Rings
In order to send and receive packets, the host and the controller use a series of shared buffer descriptor (BD)
rings to communicate information back and forth. Each ring is composed of an array of buffer descriptors that
reside in host memory. These buffer descriptors point to either send or receive packet data buffers. The largest
amount of data that a single buffer may contain is 65535 (64K-1) bytes (The length field in BD is 16 bits). Multiple
descriptors can be used per packet in order to achieve scatter-gather DMA capabilities.
Note: The maximum number of Send BDs for a single packet is (0.75)*(ring size).
There are three main types of descriptor rings:
•Send Rings
•Receive Producer Rings
•Receive Return Rings
The TX/RX ring base requires an 8 byte alignment. The receive buffer address (recorded in SBD/RBD) cannot
cross 4G.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 69
Page 70
Descriptor RingsBCM5718 Programmer’s Guide
The drawing shows a generic host descriptor ring (could be either a send ring or a receive ring), and
demonstrates how the consumer and producer indices are used to determine which descriptors in
the ring are vali d at an y given moment in ti m e.
1st
Cons
Prod
The delta between the producer and
consumer indices is indicated by the
shaded areas. These shaded
descriptors are considered to be valid
(non-empty) and thus need to be
processed.
Producer and Consumer Indices
The Producer Index and the Consumer Index control which descriptors are valid for a given ring. Each ring will
have its own separate Producer and Consumer Indices. When incremented, the Producer Index can be used to
add elements to the ring. Conversely, when incremented, the Consumer Index is used to remove elements from
the ring. The difference between the Producer and Consumer Indices mark which descriptors are currently valid
in the ring (see Figure 11). When the Producer and Consumer Index are equal, the ring is empty. When the
producer is one behind the consumer, the ring is considered to be full.
Figure 11: Generic Ring Diagram
Broadcom®
January 29, 2016 • 5718-PG108-RPage 70
Page 71
Descriptor RingsBCM5718 Programmer’s Guide
Ring Control Blocks
Each ring (send or receive) has a Ring Control Block (RCB) associated with it. Each RCB has the format shown
in Ta b le 4 .
Table 4: Ring Control Block Format
Offset (bytes) 3116 150
0x00Host Ring Address
0x04
0x08Max_lenFlags
0x0cReserved
The fields are defined as follows:
•The Host Ring Address field contains the 64-bit host address of the first element in the ring. Basically, this
field tells the controller precisely where in host memory the ring is located. This field only applies to rings
that are located in host memory. The Host_Ring_Address field contains the 64-bit address, in big-endian
ordering, of the first Send BD in host memory.
•The Flags field contains bits flags that contain control information about a given ring. Ta bl e 5 shows the two
flags that are defined.
Table 5: Flag Fields for a Ring
BitsNameDescription
0ReservedShould be set to 0.
1RCB_FLAG_RING_DISABLEDIndicates that the ring is not in use.
15:2STD_MAX_PACKET_SIZEIndicates maximum frame size for the ring.
•The Max_len field has a different meaning for different types of rings.
– This field indicates the number elements in the ring.
– The valid values for this field are 32, 64, 128, 256, 512, 1024, 2048, and 4096.
•Max ring sizes supported in the BCM5718 Family are shown below.
– Rx Return: 4096
– Rx Producer: 2048
– Rx Producer Jumbo: 1024
– Tx Producer: 512
•The NIC Ring Address field contains the address where the BD cache is located in the internal NIC address
space. This address is only valid for Receive Producer Rings. The Send Rings and Receive Return Rings
do not require this field to be populated. The location within the NIC address map for Receive Producer
Ring is provided in “PCI” on page 168.
Send Ring Control Blocks
The format of the Send RCB remains unchanged, only 15 more are added as shown in the Table below.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 71
Page 72
Table 6: Send RCBs for Multiple Rings
Send Ring RCB
Send Ring#Register Name
Host Address High0x100Legacy Mode,
Legacy /
1
2
3
4
5
….……………
16Host Address High0x1F0
** These are Memory Mapped registers
Host Address Low0x104
Max Length/Flag0x108
NIC Address0x10C
Host Address High0x110
Host Address Low0x114
Max Length/Flag0x118
NIC Address0x11C
Host Address Low0x1F4
Max Length/Flag0x1F8
NIC Address0x1FC
Register Address (**)
Descriptor RingsBCM5718 Programmer’s Guide
Usable in
RSS Mode &
IOV Mode
RSS Mode &
IOV Mode
IOV Mode Only
Note: Address range [0x100–0x10F] is the legacy single RCB address and is also used by RCB1.
Receive Ring Control Blocks
Ta bl e 7 lists all of the receive RCB Register Addresses.
Table 7: High Priority Mail Box Registers for VRQ Rings
Standard Ring RCB
VRQ #Register Name
Host Address High 0x24500x24400x200
0 (Default)
1
Host Address Low 0x24540x24440x204
Max Length/Flag0x24580x24480x208
NIC Address0x245C0x244C0x20C
Host Address High 0x25100x25000x210
Host Address Low 0x25140x25040x214
Max Length/Flag0x25180x25080x218
NIC Address0x251C0x250C0x21C
Register Address
Jumbo Ring RCB
Register Address
Return Ring RCB Register
Address (**)
Broadcom®
January 29, 2016 • 5718-PG108-RPage 72
Page 73
Table 7: High Priority Mail Box Registers for VRQ Rings (Cont.)
Descriptor RingsBCM5718 Programmer’s Guide
Standard Ring RCB
VRQ #Register Name
Host Address High 0x25300x25200x220
2
3
4Host Address High 0x25700x25600x240
.........................
16
Host Address Low 0x25340x25240x224
Max Length/Flag0x25380x25280x228
NIC Address0x253C0x252C0x22C
Host Address High 0x25500x25400x230
Host Address Low 0x25540x25440x234
Max Length/Flag0x25580x25480x238
NIC Address0x255C0x254C0x23C
Host Address High 0x26F00x26E00x300
Host Address Low 0x26F40x26E40x304
Max Length/Flag0x26F80x26E80x308
NIC Address0x26FC0x26EC0x30C
Note: [0x2450 .. 0x245C] and [0x2440 .. 0x244C] are legacy RCB addresses and are being assigned
to VRQ Ring# 0.
Register Address
Jumbo Ring RCB
Register Address
Return Ring RCB Register
Address (**)
Note: The Return Ring RCBs are Memory Mapped. Memory Address [0x200 .. 0x23C] are legacy
Return Ring RCB addresses and are being assigned to VRQ Return Ring# 0 through Ring# 3
Send Rings
The controller devices covered in this document support only one host based Send Ring.
The Send Ring Producer Index is incremented by host software to add descriptors to the Send Ring (see
Figure 12 on page 74). By adding descriptors to the ring, the device is instructed to transmit packets that are
composed of the buffers pointed to by the descriptors. A single transmit packet may be composed of multiple
buffers that are pointed to by multiple send descriptors. The maximum number of send descriptors for a single
packet is (0.75)*(ring size).
Broadcom®
January 29, 2016 • 5718-PG108-RPage 73
Page 74
Figure 12: Transmit Ring Data Structure Architecture Diagram
Host Memory
1-(64K-1) Bytes
Host Buffer
Send Host BD
Ring Control Block
1st
Host Ring Address
max_len
NIC Ring Address
flags
Host Send Ring #1
Cons
Prod
RCB
Status Word
unused
RX Prod #1
RX std cons
RX Prod #2
Unused
Status Block
Unused
Unused
TX Cons
RX Prod #4
Mailbox Registers
TX Host Ring Prod
Status Block (80 bytes)
The Status block resides in the NIC
memory space and is periodic ally
DMA'd to the host when the TX/RX
coalescing timers expire, or wh en the
RX/TX max coalesced frames
thresholds are met. Sof twa re can
examine the TX consumer indices in
the status block to determine which
packets have been sent by the
hardware.
The mailbox registers reside
on-chip starting at offs e t 0x 300.
Each mailbox register is 64 bits
wide. Writing the lower 32 bits
triggers an event in the HW.
SW updates the TX Host Ring
producer index to indicate that
there are buffer descriptors ready
for the HW to process.
Host Address
length
rsvd for firmware
Send Buffer Descriptor
flags
VLAN tag
Data Structures in the host
Data Structures kept on-chip
Transmit Ring Data Scr ucture is located in the host (as shown below), and the de v ice will keep a local (not shown) copy of the rings.
RX Prod #3
Descriptor RingsBCM5718 Programmer’s Guide
Broadcom®
January 29, 2016 • 5718-PG108-RPage 74
Page 75
Descriptor RingsBCM5718 Programmer’s Guide
Send Buffer Descriptors
Standard (Not La rge Segment Offload)
The format of an individual send buffer descriptor is shown in Ta bl e 8 .
Table 8: Send Buffe r Descriptors Format
Offset (Bytes) 3116 150
0x00Host Address [63:0]
0x04
0x08Length [15:0]Flags [15:0]
0x0cReservedVLAN Tag
The fields are defined as follows:
•The Host Address field contains the 64-bit host address of the buffer that the descriptor points to. A length
of 0 indicates that the descriptor does not have a buffer associated with it.
•The Flags field contains bits flags that contain control information for the device for transmitting the
packets. The defined flags are listed in Ta b le 9 .
Table 9: Defined Flags for Send Buffer Descriptors
BitsNameDescription
a
0
TCP_UDP_CKSUM
If set to 1, the controller replaces the TCP/UDP checksum field of TCP/UDP
packets with the hardware calculated TCP/UDP checksum for the packet
associated with this descriptor.
1IP_CKSUMIf set to 1, the controller replaces the IPv4 checksum field of TCP/UDP packets
over IPv4 with the hardware calculated IPv4 checksum for the packet associated
with this descriptor. This bit should only be set in the descriptor that points to the
buffer containing the IPv4 header. It is assumed that the IPv4 header is
contained in a single buffer.
2PACKET_ENDIf set to 1, the packet ends with the data in the buffer pointed to by this descriptor.
3Jumbo FrameThe driver must set this bit to 1 if the MTU length of the Send Frame is > 1500B.
The MTU length is the Ethernet payload length and excludes Header length (and
Trailer length).
All BDs belonging to a Send Packet must configure this bit identically.
4HDRLEN[2]The length of the Ether+IP+TCP Headers to be replicated in each segment
arising out of a Large TCP Segment (LSO).
5Capture Time Stamp (BCM5719/5720 only) If this bit is 1, this frame’s launch time shall be captured
in the TX Time-Stamp Register.
6
VLAN_TAG
a
If set to 1, the device inserts an IEEE 802.1Q VLAN tag into the packet. The 16bit TCI (Tag Control Information) field of four byte VLAN tag comes from the
VLAN Tag field in the descriptor.
7COAL_NOWIf set to 1, the device immediately updates the Send Consumer Index after the
buffer associated with this descriptor has been transferred via DMA to NIC
memory from host memory. An interrupt may or may not be generated according
to the state of the interrupt avoidance mechanisms. If this bit is set to 0, then the
Consumer Index is only updated as soon as one of the host interrupt coalescing
conditions has been met.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 75
Page 76
Descriptor RingsBCM5718 Programmer’s Guide
Table 9: Defined Flags for Send Buffer Descriptors (Cont.)
BitsNameDescription
8CPU_PRE_DMAIf set to 1, the controller’s internal CPU is required to act upon the packet before
the packet is given to the internal Send Data Initiator state machine. Normally
this bit should be set to 0.
9
CPU_POST_DMA
a
If set to 1, the controller’s internal CPU is required to act upon the packet before
the packet is given to the internal Send Data Completion state machine.
Normally this bit should be set to 0.
10HDRLEN[3]The length of the Ether+IP+TCP Headers (combined) to be replicated in each
frame arising out of a Large TCP Segment (LSO). Maximum Header Length is
256B.
11HDRLEN[4]–
12HDRLEN[5]–
13HDRLEN[6]–
14HDRLEN[7]–
15
DON’T_GEN_CRC
a. Indicates that this bit should be set in all descriptors for a given packet if the desired capability is to be
enabled for that packet.
a
If set to 1, the controller will not append an Ethernet CRC to the end of the frame.
Note: The UDP checksum engine does not span IP fragmented frames.
•The Length field specifies the length of the data buffer. The lengths for the buffers associated with a given
packet will add up to the length of the packet.
Note: The Ethernet controller does not validate the value of the Length field and may generate an
error on the PCI bus if the Length field has a value of 0. The host driver must ensure that the Length
field is nonzero before enqueueing the BD onto the Send Ring.
•The VLAN Tag field is only valid when the VLAN_TAG bit of Flags field is set. This VLAN Tag field contains
the 16-bit VLAN tag that is to be inserted into an IEEE 802.1Q (and IEEE 802.3ac)-compliant packet by the
controller. If VLAN tag insertion is desired, this field (and the flag) should be set in the first descriptor for
that packet (i.e., the descriptor that points to the buffer that contains the Ethernet header).
Large Segment Offload (LSO) Send BD
See “Large Segment Offload” on page 110.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 76
Page 77
Descriptor RingsBCM5718 Programmer’s Guide
Host Memory
1-(64K-1) Byt es
Host Buffer
RX BD
Host Address
index
type
ip chksum
error flag
reserved
opaque
Receive Buffer Descriptor
len
flags
tcp_udp_chsum
vlan tag
Ring Control Block
1st
Host Ring Address
max_len
NIC Ring Address
flags
Receive Ring #1
Receive Ring #4
1st
Prod
Cons
RCB #1
RCB #4
Status Word
unused
RX Prod #1
RX std cons
RX Prod #2
Unused
Status Block
Unused
Unused
TX Cons
RX Prod #4
Con
Prod
Mailbox Registers
RX Cons #1
RX Cons #2
RX Cons#4
Note: The receive return rings are stored in host memory.
Status Block (80 bytes)
Status block resides in the NIC memory
space and is periodically DMA'd to the
host based on the host coalescing Timer.
The NIC is the Producer of the receive return ring. It
increments the internal producer index to add
elements to the ring.
RX Prod #3
RX Cons #4
Receive Rings
The Ethernet controllers support two types of Receive Descriptor Rings: Producer Rings and Return Rings (see
Figure 13). Unlike previous NetXtreme controllers, the BCM5718 family adds a second Receive Producer ring
dedicated to jumbo frame reception. Descriptors in the Producer Rings point to free buffers in the host. When
the controller receives a packet and consumes a receive buffer, the controller will modify and write back the
descriptor for the consumed buffer into the given Receive Return Ring. Basically the Producer Rings contain
descriptors that point to buffers that the controller is free to use, whereas the Return Rings contain descriptors
that the device has used and await processing from host software.
Figure 13: Receive Return Ring Memory Architecture Diagram
Receive Producer Ring
The receive producer ring resides in the host and points to empty host receive buffers that will later be filled with
received packet data. The controller will internally cache a copy of the producer ring. When the host software
driver has a free host receive packet buffer available for incoming packets, it will fill out a receive buffer
descriptor and have that descriptor point to the available buffer. Host software will then update the producer
index for that receive producer ring to indicate to the controller that there is a newly available receive buffer. After
the controller fetches and caches (e.g., consumes) this receive producer descriptor, the controller will update
the consumer index of the receive producer ring.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 77
Page 78
Descriptor RingsBCM5718 Programmer’s Guide
Receive Return Rings
When the NIC receives a packet, it will DMA that packet to a host receive packet data buffer pointed to by the
available receive buffer descriptor (see Section 5: “Receive Data Flow,” on page 88). Earlier the NIC will have
received ownership of that data buffer via an update of the producer index of receive producer ring. After the
controller does the packet data write DMA, it will DMA a corresponding buffer descriptor into the appropriate
receive return ring. The buffer descriptor that is returned in the receive return ring will be slightly modified from
the original buffer descriptor that the controller fetched out of the receive producer ring. After the controller has
completed the DMA of the receive return ring descriptor, the controller will update its internal copy of the
producer index for that particular receive return ring. That new value for that receive return ring producer index
will be included in the next status block update that is made to the host. The updated value of receive return ring
producer index in status block will be used by host software in determining whether new packets have been
received.
Table 10: Receive Return Rings
DescriptionBCM5718 Family
Number of Rings4
Buffer Descriptor Size (bytes)32
Host Ring Size (# of Buffer Descriptors)Can be configured for 32 or 64 or 128 or 256 or 512 or
1024 or 208 or 4096
NIC Cache Size (# of Buffer Descriptors)0
Receive Buffer Descriptors
The format of Standard Receive Buffer Descriptors (in both producer ring and return rings) is shown in Table 11.
Table 11: Receive Descriptors Format
Offset (bytes)3116150
0x00Host Address
0x04
0x08IndexLength
0x0cTypeFlags
0x10IP_CksumTCP_UDP_Cksum
0x14Error_FlagsVLAN tag
0x18RSS Hash
0x1COpaque
The fields are defined as follows:
•Host Address—Contains the 64-bit host address of the buffer that the descriptor points to. A length of 0
indicates that the descriptor does not have a buffer associated with it.
•Length— Specifies the length of the data buffer. For Producer Rings this value is set by the host software to
correspond to the size of the buffer that is available for a receive packet. Once a packet has been received,
the controller will modify this length field to correspond to the length of the packet received. A value of 0
indicates that there is no valid data in the buffer.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 78
Page 79
Descriptor RingsBCM5718 Programmer’s Guide
•Index— Is set by host software in the descriptors in the producer rings. When the controller uses a given
buffer descriptor, it will opaquely pass the Index field for that buffer descriptor through to the corresponding
descriptor in the return ring. This index field of the BD in Return Ring is then used by the host software to
associate the BD in Return Ring with the BD in Producer Ring that points to the given receive buffer.
•Flags— Contains bits flags that contain control information about a given descriptor. The defined flags are
listed in Table 13 on page 80.
Table 12: Defined Flags for Receive Buffers
BitsNameDescription
15IP VersionIndicates whether the received IP packet is an IPv6 or IPv4 packet. This bit
will be 1 for IPv6 packet and 0 for IPv4 packet.
14TCP_UDP_IS_TCPIn producer rings this bit should be set to 0. In return rings this bit will be set
to 1 by the controller if the controller calculated that the incoming packet was
a TCP packet. If the packet is UDP or a non IP frame, then this bit should
be set to 0.
13TCP_UDP_CHECKSUMIn producer rings this bit should be set to 0. In return rings this bit will be set
to 1 by the controller if the controller calculated that the TCP or UDP
checksum in the corresponding incoming packet was correct.
12IP_CHECKSUMIn producer rings this bit should be set to 0. In return rings this bit will be set
to 1 by the controller if the controller calculated that the IP checksum in the
corresponding incoming packet was correct.
11Re s e r v ed–
10FRAME_HAS_ERRORIf set to 1 in a return ring, it indicates that the controller detected an error.
The specific type of error is specified in the Error_Flag field of the receive
return descriptor.
9:7RSS Hash TypeIndicates the hash type used in RSS hash calculation for a received packet.
Available hash types are:
•0 2_TUPLE_IPV4
•1 4_TUPLE_IPV4
•2 2_TUPLE_IPV6
•3 4_TUPLE_IPV6
•4 Reserved
•5 Reserved
•6 Reserved
•7 Reserved
See “Receive MAC Mode Register (offset: 0x468)” on page 322 for
additional information about enabling the different RSS hash types.
6VLAN_TAG*If set to 1 in a return ring, it indicates that the packet associated with this
buffer contained a four-byte IEEE 802.1Q VLAN tag. The 16 VLAN ID is
stripped from the packet and located in the VLAN tag field in the descriptor.
5ReservedShould be set to 0.
4ReservedShould be set to 0.
3RSS_Hash ValidIf set to 1, indicates host that the RSS_Hash in Receive BD of return ring is
valid.
2PACKET_ENDIf set to 1, the packet ends with the data in the buffer pointed to by this
descriptor.
1:0ReservedShould be set to 0.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 79
Page 80
Descriptor RingsBCM5718 Programmer’s Guide
•Type— Used internally by the controller. In producer rings it should be set to 0, and in return rings it should
be ignored by host software.
•TCP_UDP_Cksum — Holds the TCP/UDP checksum that the controller calculated for all data following the
IP header given the length defined in the IP header. If the Receive No Pseudo-header Checksum bit is set
(see “Mode Control Register (offset: 0x6800)” on page 468) to 1, then the pseudo-header checksum value
is not added to this value. Otherwise, the TCP_UDP_Cksum field includes the pseudo-header in the
controller’s calculation of the TCP or UDP checksum. If the packet is not a TCP or UDP packet, this field
has no meaning. Host software should zero this value in the producer ring descriptors. If the host is capable
of TCP or UDP checksum off load, then host software may examine this field in the return rings to
determine if the TCP or UDP checksum was correct.
•IP_Cksum — Host software should zero this value in the producer ring descriptors. For Receive Return
Ring descriptors, if using IP checksum offload, the host driver software should rely on the Flags bit
IP_CHECKSUM (Flags bit 12) to determine if the IP checksum in the received packet is correct. This field
used to contain the actual IP checksum value but that is not true for the BCM5718 family of controllers.
Only the Flags bit IP_CHECKSUM should be relied on by host driver software as is done by Broadcom
drivers.
•VLAN— Only valid when the VLAN_TAG bit is set. This field contains the 16-bit VLAN ID that was extracted
from an incoming packet that had an IEEE 802.1Q (and IEEE 802.3ac) -compliant header.
•Error_Flags — Contains bits flags that contain error information about an incoming packet that the
descriptor is associated with. The bits in this field are only valid if the FRAME_HAS_ERROR bit is set in the
Flags field in the descriptor. The defined error flags are listed in Ta bl e 1 3.
Table 13: Defined Error Flags for Receive Buffers
BitsNameDescription
31:9ReservedShould be set to 0.
8GIANT_PKT_RCVDIf set to 1, the received packet was longer than the maximum packet length
value set in the Receive MTU Size register (see “Receive MTU Size Register
(offset: 0x43C)” on page 316). The data in the received packet was truncated at
the length specified in the Receive MTU Size register.
7TRUNC_NO_RESIf set to 1, the received packet was truncated because the controller did not
have the resources to receive a packet of this length.
6LEN_LESS_64If set to 1, the received packet was less than the required 64 bytes in length.
5MAC_ABORTIf set to 1, the MAC aborted due to an unspecified internal error while receiving
this packet. The packet could be corrupted.
4ODD_NIBBLE_RX_MIIIf set to 1, the received packet contained an odd number of nibbles. Thus,
packet data could be corrupt.
3PHY_DECODE_ERR If set to 1, while receiving this packet the device encountered an unspecified
frame decoding error. This packet could be corrupted.
This bit is set for valid packets that are received with a dribble nibble. True
alignment errors will be dropped by that MAC and never show up to the driver.
2LINK_LOSTIf set to 1, link was lost while receiving this frame. Therefore, this packet is
incomplete.
1COLL_DETECTIf set to 1, a collision was encountered while receiving this packet.
0BAD_CRCIf set to 1, the received packet has a bad Ethernet CRC.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 80
Page 81
Descriptor RingsBCM5718 Programmer’s Guide
•When the RSS Hash Valid flag bit is 1, the RSS Hash field holds the 32-bit RSS hash value calculated for a
packet. This field should be ignored when the RSS Hash Valid flag bit is zero.
•The Opaque field is reserved for the host software driver. Any data placed in this field in a producer ring
descriptor will be passed through unchanged to the corresponding return ring descriptor.
Additional Ring Information for the BCM5718 Family
Rings in the BCM5718 Family are more complicated than in previous NetXtreme controllers. Before considering
ring structure details, first choose the mode of operation:
•Legacy
•RSS
•RSS+TSS
•IOV
Note: RSS (and/or TSS) and IOV are mutually exclusive.
Once the mode of operation is decided, determine if jumbo frames are to be used.
Setting ring sizes involves setting some ring sizes (such as the Rx Producer Rings) in registers and setting other
ring sizes (such as the Rx Return Rings) in memory locations (for example, the upper 16 bits of the 32 bit value
at memory offset 0x208 for Rx Return Ring number 0, rather than in a register). See Appendix C: “Device
Register and Memory Map,” on page 580 for more information. A Ring Control Block (RCB) consists of four 32
bit words:
•host address high
•host address low
•len/flags
•NIC ring address
For example, the RX Return Ring size is set in the high 16 bits of 32bit value in device memory offset 0x208.
If using RSS or IOV, there are either 4 or 17 Rx Return and Producer rings. The 17th Rx ring is a default throwaway ring for any Rx traffic that does not map to rings 0-3 (RSS) or 0-15 (IOV). Driver software only pulls valid
Rx BDs from 16 Rx Ret Rings (rings 0-15) in IOV mode.
For Rx Producer Rings, there are only 1 or 2 in non-IOV mode (the second one dedicated to the driver to supply
jumbo Rx BDs to the chip, if using jumbo frames). In RSS mode, there are up to 4. In IOV mode, there are up
to 16 (17, including the default ring).
The Tx path is simpler. Tx is 1 or 4 or 16 rings (legacy, TSS, or IOV) for giving Send BDs to the chip. Jumbo BDs
go onto the same Send ring as non-jumbos. There are no separate jumbo-dedicated Send ring(s) like there are
for Rx producer rings.
The max sizes of the various rings is as follow:
•Rx Ret: 4096
•Rx Prod: 2048
Broadcom®
January 29, 2016 • 5718-PG108-RPage 81
Page 82
Status BlockBCM5718 Programmer’s Guide
•Rx Prod Jumbo: 1024
•Tx Prod: 512
As a maximum use example, there can be an IOV implementation with the following total max ring size/count
arrangement:
•16 Send rings (size=512 each ring)
•16 Rx Prod rings (size=2048 each ring)
•16 Rx Prod jumbo rings (size=1024 each ring)
•17 Rx Ret rings (size=4096 each ring)
Status Block
The Status Block is another shared memory data structure that is located in host memory. The Status Block is
32 bytes in length. Host software will need to allocate 32 bytes of non-paged memory space for the Status Block
and set the Status Block Host Address register to point to the host memory physical address reserved for this
structure.
The controller will update the Status Block to host memory prior to a host coalescing interrupt or MSI. The
frequency of these Status Block updates is determined by the host coalescing logic (see “Host Coalescing
Engine” on page 60). Using the software configurable coalescing parameters, the device driver can optimize the
frequency of status block updates for a particular application or operating system.
The Status Block contains some of the Producer and Consumer indices for the rings described in “Descriptor
Rings” on page 69. These Producer and Consumer indices allow host software to know what the current status
of the controller is regarding its processing of the various send and receive rings. From information in the status
block a software driver can determine:
•Whether the Status Block has been recently updated (via a bit in the status word).
•Whether the Link State has changed (via a bit in the status word).
•Whether the controller has recently received a packet and deposited that packet into host memory for a
given ring (via the Receive Return Ring Producer Indices).
•Which host receive descriptors that controller has fetched, and it will consume when future packets are
received (via the Receive Producer Ring Consumer Indices).
•Whether the controller has recently completed a transmit descriptor buffer DMA for a given ring (via the
Send Ring Consumer Indices).
Status Block Format
Note: Reference registers 0x3C50–0x3CC0 for debug access to the various ring indices.
Each MSI-X vector is associated with a status-block structure. A status block is DMAed to the host memory
immediately prior to raising a legacy style interrupt (INTx, MSI) or MSI-X interrupt. Status block formats vary
depending on RSS and the MSI-X vector number.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 82
Page 83
Status BlockBCM5718 Programmer’s Guide
The various status block formats are shown in this section.
INTx/MSI—Legacy Mode Status Block Format
INTx and MSI use this status-block format in non-RSS mode.
Table 14: Status Block Format (MSI-X Single-Vector or INTx—RSS Mode)
31
1
Offset
0x00Status Word
0x04[31:8] Reserved 0x0[7:0]Status Tag
0x08Receive Standard Producer Ring Consumer
0x0CReserved 0x0Reserved 0x0
0x10Send BD Consumer IndexReceive Return Ring Producer Index
0x14Reserved 0x0Receive Jumbo Producer Ring Consumer Index
6
Index
15 0
Reserved 0x0
Status-Block [0] Status Word Format (single-vector RSS):
•Bit [0]: Update bit
•Bit [1]: Link status change
•Bit [2]: Error/attention
•Bits [31:3]: Reserved 0x0
Broadcom®
January 29, 2016 • 5718-PG108-RPage 83
Page 84
Status BlockBCM5718 Programmer’s Guide
Single-Vector or INTx— RSS Mode Status Block Format
In the single-vector RSS mode, the status-block format used by Vector#0 is shown below.
INTx and MSI also use this status-block format.
Table 15: Status Block Format (MSI-X Single-Vector or INTx—RSS Mode)
31
1
Offset
0x00Status Word
0x04[31:8] Reserved 0x0[7:0]Status Tag
0x08Receive Standard Producer Ring Consumer
0x0CReceive Return Ring 2 Producer IndexReceive Return Ring 3 Producer Index
0x10Send BD Consumer IndexReceive Return Ring 0 Producer Index
0x14Reserved 0x0 Receive Jumbo Producer Ring Consumer Index
Status-Block [0] Status Word Format (single-vector RSS):
•Bit [0]: Update bit
•Bit [1]: Link status change
•Bit [2]: Error/attention
•Bits [31:3]: Reserved — always 0x0
6
Index
15 0
Receive Return Ring 1 Producer Index
Broadcom®
January 29, 2016 • 5718-PG108-RPage 84
Page 85
Status BlockBCM5718 Programmer’s Guide
Multivector RSS Mode Status Block Format
There are five slightly different status-block formats used by the multivector RSS mode. Each of these formats
associate with their respective vector numbers as shown in the tables below.
Table 16: Status Block [0] Format (MSI-X Multivector RSS Mode)
31
1
Offset
0x00Status Word
0x04[31:8] Reserved 0x0[7:0]Status Tag
0x08Receive Standard Producer Ring Consumer
0x0CReserved 0x0Reserved 0x0
0x10Send BD Consumer IndexReserved 0x0
0x14Reserved 0x0Receive Jumbo Producer Ring Consumer Index
Status-Block [0] Status Word Format (multivector RSS):
0x08Reserved 0x0Receive Return Ring 1 Producer Index
0x0CReceive Return Ring 2 Producer Index
0x10Reserved 0x0Receive Return Ring 0 Producer Index
0x14Reserved 0x0Reserved 0x0
Status-Block [1 – 4] Status Word Format (multivector RSS):
Broadcom®
January 29, 2016 • 5718-PG108-RPage 85
6
Valid only for Status Block3 else RSVD 0x0
15 0
{independent for
each status blocks}
Valid only for Status Block2 else RSVD 0x0
Receive Return Ring 3 Producer Index
Valid only for Status Block4 else RSVD 0x0
Valid only for Status Block1 else RSVD 0x0
Page 86
Status BlockBCM5718 Programmer’s Guide
•Bit [0]: Update bit
•Bit [31:1]: Reserved 0x0
Status Block and INT MailBox Address es
Each status block may be placed in an independent host memory address (64-bit). Each vector may be
acknowledged via associated INT MailBoxes.
Table 18: Status Block Host Addresses and INT MailBox Addresses
RSS Mode
Status Blo ck Ho st
Status
Block #
Legacy0x3C3C, 0x3C380x200AllLegacy status block
0x3C3C, 0x3C380x200Link-Status change
10x3D00, 0x3D040x208Rx Return Ring 0
20x3D08, 0x3D0C0x210Rx Return Ring 1
30x3D10, 0x3D140x218Rx Return Ring 2
40x3D18, 0x3D1C0x220Rx Return Ring 3
50x3D20, 0x3D24N/AN/AUsed only in MSI-X multivector
Address Register
(64-Bit)
INT MailBox
Register
Address
Indication
Items
Error/Attention
SBD Ring 1 Cons Index
Std RBD Cons Index
Jmb RBD Cons Index
Prod Index
Prod Index
Prod Index
Prod Index
Comments
Used by INTx or MSI
Used in all MSI-X modes for
Vector#0
Used only in MSI-X multivector
RSS mode or multivector EAV
mode for Vector#1–Vector#4
EAV mode for Vector#5
The Status word field contains bit flags that contain error information about the status of the controller. The
defined flags are listed in Table 19.
Table 19: Status Word Flags
BitsNameDescription
0Updated This bit is always set to 1 each time the status block is updated in the host via
DMA. It is expected that host software clear this bit in the status block each time
it examines the status block. This provides the host driver with a mechanism to
determine whether the status block has been updated since the last time the
driver looked at the status block.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 86
Page 87
Status BlockBCM5718 Programmer’s Guide
Table 19: Status Word Flags (Cont.)
BitsNameDescription
1Link State ChangedIndicates that link status has changed. This method of determining link change
status provides a small performance increase over doing a PIO read of the
Ethernet MAC Status register (see “EMAC Status Register (offset: 0x404)” on
page 311. See “Wake on LAN Mode/Low-Power” on page 212 for a description
of the PHY setup required when link state changes.
2ErrorWhen this bit is asserted by the chip, the following conditions may have
occurred. Bit 2 of the status word is the OR of:
•All bits in Flow Attention register (0x3c48) (see “Flow Attention Register
(offset: 0x3C48)” on page 422.
•MAC_ATTN—Events from the MAC block (see “EMAC Status Register
(offset: 0x404)” on page 311.
•DMA_EVENT—Events from the following blocks:
– MSI (see “MSI Status Register (offset: 0x6004)” on page 467.
– DMA_RD (see “LSO Read DMA Status Register (offset: 0x4804)” on
page 435.
– DMA_WR (see “Write DMA Status Register (offset: 0x4C04)” on
page 450.
•RXCP_ATTN—Events from RX RISC (see “RX RISC Status Register (offset:
0x5004)” on page 452.
The Status Block format for these devices is as follows:
•Status Tag—Contains an unique eight-bit tag value in bits 7:0 when the Status Tagged Status mode bit of
the Miscellaneous Host Control register (see “Miscellaneous Host Control Register (offset: 0x68)” on
page 282) is set to 1. This Status Tag can be returned to the Mailbox 0 register at location 31:24
(see“Interrupt Mailbox 0 Register (offset: 0x5800)” on page 460) by host driver. When the remaining
Mailbox 0 register bits 23:0 are written as 0, the tag field of the Mailbox 0 register is compared with the tag
field of the last status block to be DMAed to host. If the tag returned is not equivalent to the tag of the last
status block DMAed to the host, the interrupt state is entered.
•Receive Producer Ring Consumer Index —Contains the controller’s current Consumer Index value for the
Receive Producer Ring. This field indicates how many receive descriptors are in the receive producer ring
that the controller has consumed. For more information regarding this ring, see “Receive Producer Ring” on
page 77.
•Receive Return Rings 0–3 Producer Indices —Contain controller’s current Producer Index value for the
each of the Receive Return Rings. When the controller receives a packet and writes that packet data into
host memory via DMA, it will increment the Producer Index for the corresponding Receive Return ring.
When a Producer Index is incremented, it is a signal to software that a newly arrived receive packet is
ready to be processed.
•Send Ring Consumer Index—Contains controller’s current Consumer Index value for the Send Ring.
When the controller completes the read DMA of the host buffer associated with a send BD, the controller
will update the Send Ring Consumer Index. This provides the host software with an indication that the
controller has buffered this send data and, therefore, the host software may free the buffer that was just
consumed by the device.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 87
Page 88
Receive Data FlowBCM5718 Programmer’s Guide
Section 5: Receive Data Flow
Introduction
The RX MAC pulls BDs from RX producer rings. The RX BD specifies the location(s) in host memory where
packet data may be written. Figure 14 on page 89 shows the receive buffer descriptor cycle.
All ingress Ethernet frames are classified by the RX rules engine. A class ID is associated to each frame based
on QOS rules setup in the RX MAC (see “Receive Rules Setup and Frame Classification” on page 95). The
Receive List Placement and Receive List Initiator portions of the MAC architecture move BDs to the RX return
rings; the class ID associated to the packet is examined to route the BD to a specific RX return ring.
Once the packet is queued to the RX return ring, the device driver will wait for indication of the same through
the status block update and interrupt from the host coalescing engine. The host coalescing engine will update
the status block and generate a line interrupt or MSI (see “Host Coalescing” on page 234 for further details
regarding interrupts) when a specified host coalescence criteria is met. Once the interrupt is generated, the host
device driver will service the interrupt. The ISR will determine if new BDs have been completed on the RX Return
Rings. Next, the device driver will indicate to the network protocol that the completed RX packets are available.
The network protocol will consume the packets and return physical buffers to the network driver at a later point.
The BDs may then be reused for new RX frames. The device driver must return the BD to an RX producer ring.
For this purpose, the driver should fill out either the opaque field or index field of the Rx BD when inserting/
initializing the BD in an RX Producer ring. When the BD is returned by the device through Return Ring, the
opaque or index data field of the BD will be used by the driver to identify the BD in Producer Ring that
corresponds to the Returned BD in Return Ring. The device driver will then reinitialize the identified BD in
Producer Ring with a new allocated buffer and replenish the Receive Producer Ring with this BD.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 88
Page 89
IntroductionBCM5718 Programmer’s Guide
RX
Return
Ring 1
RX
Return
Ring 2
RX
Return
Ring 3
RX
Return
Ring 4
DMA Read Engine
Local
Memory
List
Initiator
DMA Write Engi ne
Interrupt
Service
Routine
RX Indicate Available
Rx MAC
RX Return Packet
Protocol Interface
(i.e. TCP/IP)
Device DriverMAC
Host
Coalescing
Engine
RX
Jumbo
Producer
Ring
RX
Standard
Producer
Ring
Figure 14: Receive Buffer Descriptor Cycle
Broadcom®
January 29, 2016 • 5718-PG108-RPage 89
Page 90
Receive Producer RingBCM5718 Programmer’s Guide
Receive Producer Ring
A Receive Producer Ring is an array containing a series of Receive Buffer Descriptors (BD). The Receive
Producer Ring is host-based and a portion of the available buffer descriptors are cached in Ethernet controller
internal memory.
A receive producer ring contains a series of buffer descriptors which in turn contain information of host memory
locations to where packets are placed by the Ethernet controller at reception.
Setup of Producer Rings Using RCBs
A Ring Control Block (RCB) is used by the host software to set up the shared rings in host memory. In the context
of producer ring, the Receive Producer Ring RCB is a set of registers (or internal device memory offsets) used
to define the Receive Producer Ring. The host software must initialize the Receive Producer Ring RCB.
Receive Producer Ring RCB—Register Offset 0x24 50–0 x2 45 f
Other Considerations Relating to Producer Ring Setup
Other registers that affect the producer rings must be initialized by the host software. These registers include
the Receive BD Ring Replenish Threshold register, the Receive MTU register, and the Accept Oversized bit (bit
5) in the Receive MAC Mode register.
•Receive BD Producer Ring Replenish Threshold registers:
– “Standard Receive BD Producer Ring Replenish Threshold Register (offset: 0x2C18)” on page 373
– “Receive Data Completion Control Registers” on page 371.
These registers are used for setting the number of BDs that the Ethernet controller can use up before
requesting that more BDs be DMAed from a producer ring. In other words, the device does not initiate a DMA
for fetching the Rx BDs until the number of BDs made available to the device by the host is at least the value
programmed in this register.
•Receive MTU register (“Receive MTU Size Register (offset: 0x43C)” on page 316). This 32-bit register is
set to a value that is the maximum size of a packet that the Ethernet controller receives. Any packets above
this size is labeled as an oversized packet. The value for this register is typically set to 1522, which is the
Standard Producer Ring RCB typical setting. If Jumbo frames are supported, the MTU would be set to the
maximum Jumbo frame size.
•Receive MAC Mode register (“Receive MAC Mode Register (offset: 0x468)” on page 322). If the Accept
Oversized bit (bit 5) of this register is set, the Ethernet controller accepts packets (of size up to 64 KB)
larger than the size specified in the MTU.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 90
Page 91
Receive Producer RingBCM5718 Programmer’s Guide
Offset
0x00
0x04
0x08
0x0c
31 16
Host Ring Address
Max_LenFlags
NIC Ring Address
15 0
Std RingBD 1
512
511
BD 2
BD 3
Standard Producer Ring RCB
Standard Producer Ring
RCB Setup Pseudo Code
An example of setting up receive producer ring RCB:
Content of Pointer_to_RX_PRODUCER_RING_RCB + 0x00 = Host address of standard receive producer ring
high 32.
Content of Pointer_to_RX_PRODUCER_RING_RCB + 0x04 = Host address of standard receive producer ring
low 32.
Content of Pointer_to_RX_PRODUCER_RING_RCB + 0x0a = No flags.
Content of Pointer_to_RX_PRODUCER_RING_RCB + 0x08 = Max packet size of 1522.
Content of Pointer_to_RX_PRODUCER_RING_RCB + 0x0c = Internal Memory address for device copy of ring.
Figure 15 shows the standard ring RCB for the setup of a host-based standard producer ring.
Receive Buffer Descriptors (BDs) begin on the Receive Producer Ring. The host device driver will populate the
receive producer ring with a specified number of BDs supported by the receive producer ring (see “Receive MTU
Size Register (offset: 0x43C)” on page 316). When a packet is received, the RX MAC moves the packet data
into internal memory. The Receive MTU Size register (see “Receive MTU Size Register (offset: 0x43C)” on
page 316) specifies the largest packet accepted by the RX MAC; packets larger than the Receive MTU are
marked oversized and are discarded.
Figure 15: Receive Producer Ring RCB Setup
Receive Buffer Descriptors
The Receive Buffer Descriptor is a data structure in host memory. It is the basic element that makes up each
receive producer and receive return ring. The format of receive buffer descriptors can be seen in Table 11 on
page 78. A receive buffer descriptor has a 64-bit memory address and may be in any memory alignment and
may point to any byte boundary. For performance and CPU efficiency reasons, it is recommended that memory
be cache-aligned. The cache line size value is important for the controller to determine when to use the PCI
memory write and invalidate command. There are no requirements for memory alignment or cache line integrity
for the Ethernet controller.
Unlike send buffer descriptors, the receive buffer descriptors cannot be chained to support multiple fragments.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 91
Page 92
Receive Producer RingBCM5718 Programmer’s Guide
Management of Rx Producer Rings with Mailbox Registers and
Status Block
Status Block
The host software manages the producer rings through the Mailbox registers and by using the status block. It
does this by writing to the Mail Box registers when a BD is available to DMA to the Ethernet controller and
reading the status block to see how many BDs have been consumed by the Ethernet controller. The status block
can be seen in “Status Block” on page 82.
The status block is controlled and updated by the Ethernet controller. The status block in host memory is
constantly updated through a DMA copy by the Ethernet controller from an internal status block. The updates
occur at specific intervals and host coalescence conditions that are specified by host software during
initialization of the Ethernet controller. The registers for setting the intervals and conditions are in the Host
Coalescing Control registers (see “Host Coalescing” on page 234) starting at memory offset 0x3c00. The
Ethernet controller DMAs an updated status block to the 32-bit address that is set by the host software in the
Host Coalescing Control registers, 0x3c38.
Among other status, the status block displays the last 16-bit value, BD index that was DMAed to the Ethernet
controller from receive producer ring. The Ethernet controller updates these indices as the recipient or consumer
of the BD from the producer rings.
Mailbox
The host software is responsible for writing to the Mailbox registers (see Table 20) when a BD is available from
the producer rings for use by the Ethernet controller. Host software should use the high-priority mailbox region
from 0x200–0x3FF for host standard and the low-priority mailbox region from 0x5800–0x59FF for indirect
register access mode.
The Mailbox registers (starting at memory offset 0x200 for host standard and offset 0x5800 for indirect mode)
contain the following receive producer index register.
Receive BD Producer Ring Producer Index
•Host standard: memory offset 0x268–0x26F
•Indirect mode: memory offset 0x5868–0x586F
Table 20: Mailbox Registers
Offset
(High-Priority
Mailboxes for
Host
Standard Mode)
0x200–0x2070x5800–0x5807Interrupt Mailbox 0RW
0x208–0x20F0x5808–0x580FInterrupt Mailbox 1RW
0x268–0x26F0x5868–0x586FReceive BD Standard Producer Ring Producer IndexRW
0x280–0x2870x5880–0x5887Receive BD Return Ring 1 Consumer IndexRW
Offset
(Low-Priority
Mailboxes for
Indirect Mode)
RegisterAccess
Broadcom®
January 29, 2016 • 5718-PG108-RPage 92
Page 93
Receive Return RingsBCM5718 Programmer’s Guide
Table 20: Mailbox Registers (Cont.)
Offset
(High-Priority
Mailboxes for
Host
Standard Mode)
0x288–0x28F0x5888–0x588FReceive BD Return Ring 2 Consumer IndexRW
0x290–0x2970x5890–0x5897Receive BD Return Ring Consumer IndexRW
The Receive Producer Ring Producer Index register contains the index value of the next buffer descriptor from
the producer ring that is available for DMA to the Ethernet controller from the host. When the host software
updates the Receive Producer Ring Producer Index, the Ethernet controller is automatically signaled that a new
BD is waiting for DMA. At initialization time, these values must be initialized to zero. These indices are 64-bit
wide.
Offset
(Low-Priority
Mailboxes for
Indirect Mode)
RegisterAccess
Receive Return Rings
Receive Return Rings (RR) are host-based memory blocks that are used by host software to keep track of the
where the Ethernet controller is putting the received packets related receive buffer descriptors. Unlike the
producer rings, the return rings reside only in host memory. The Ethernet controller uses the BDs in the NIC
memory that are previously copied from the producer rings to use when packets are received from the LAN. It
places the BDs that correspond to received packets in the return rings.
Return rings are the exact opposite of producer rings, except that they are not categorized by the maximum
length receive packets supported. They are actually categorized by priority or class of received packet. The
highest priority return ring is ring 1, and the lowest priority is the last ring (Return Ring 2–Return Ring 4
depending on how many rings are set up by the host software).
The Receive Return Ring RCBs are used to set up return rings in much the same way the Receive Producer
Ring RCB is used to set up the receive producer ring. These RCBs for the return rings are set in the
Miscellaneous memory region (SSRAM) at offset 0x200 (this region should not be confused with the register
space in the chip). The RCB max_len field is used to indicate the number of buffer descriptor entries in a return
ring. If an invalid value is set, the Ethernet controller indicates an attention error in the Flow Attention register.
Figure 13 on page 77 shows receive return rings.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 93
Page 94
Receive Return RingsBCM5718 Programmer’s Guide
Management of Return Rings with Mailbox Registers and Status
Block
The return rings are managed by the host using the Mailbox registers and status block.
When a packet is received from the LAN, the Ethernet controller DMAs the packet to a location in the host, and
then DMAs the related BD to a return ring. As the producer of this packet to the host, the Ethernet controller
updates the status block producer indices for the related return ring (i.e., return ring 1 to return ring 4 that was
DMAed the BD received packet). These return ring indices can then be read by the host software to determine
the last BD index value of a particular ring that has information of the last received packet.
As the consumer of the received packet, the host software must update the return ring consumer indices in
Mailbox registers Receive BD Return Ring 1 Consumer Index (memory offset 0x280–0x287 for host standard
and 0x5880–0x5887 for indirect mode) through Receive BD Return Ring 4 Consumer Index.
Host Buffer Allocation
The allocation of memory in the host is dependent on the operating system in which the controller is being used.
There are two crucial items:
•The use of non-cached and physically contiguous memory is best for adapter performance.
•Physical memory mapping is required for the controller’s internal copies of logical host memory.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 94
Page 95
Receive Return RingsBCM5718 Programmer’s Guide
Receive Rules Setup and Frame Cla ssification
The Ethernet controller has a feature that allows for the classification of receive packets based on a set of rules.
The rules are determined by the host software and then input into the Ethernet controller.
A packet can be accepted or rejected based on the rules initialized into two rules register areas. The packets
can also be classified into groups of packets of higher to lower priority using the rules registers. This occurs
when the packet is directed to a specific return ring. Return rings 1–4 have an inherent priority associated with
them. The priority is from lowest ring number to highest ring number; return ring 1 being the highest priority ring
and return ring 4 being the lowest. The implementation of priority class is based on how many rings the host
software has initialized and made available to the Ethernet controller. As packets arrive, the Ethernet controller
may classify each packet based on the rules. When the host services the receive packet, it can service the lower
numbered rings first.
A rule can be changed by first disabling it by setting 0 into Enable bit (bit 31) in Receive BD Rules Control
register (see Table 22 on page 96). Wait about 20 receive clocks (rx_clock) and then reenable it when it is
programmed with a new rule. Otherwise, changing the rules dynamically during runtime may cause the rule
checker to output erroneous results because the rule checker is a pipelined design and uses the various fields
of the rules at different clock cycles.
Receive Rules Confi guration Register
The Receive Rules Configuration register (memory offset 0x500–0x503, see Ta b le 2 1) uses bits 3:7 to specify
the ring where a received packet should be placed into if no rules are met, or if the rules have not been set up.
A value of 0 means the received packet will be discarded. A value of 1–16 specifies a corresponding ring. This
ring should be initialized to at least a value of 1 if the rules are not being used to ensure that all received packets
will be DMAed to return ring 1.
Table 21: Receive Rules Configuration Register
BitsFieldAccess
31:8ReservedRO
7:3Specifies the default class (ring) if no rules are matchedRW
2:0ReservedRO
Broadcom®
January 29, 2016 • 5718-PG108-RPage 95
Page 96
Receive Return RingsBCM5718 Programmer’s Guide
Receive List Placement Rules Array
The Receive List Placement Rules Array (memory offset 0x480–0x4ff) is made up of 16 combined element
registers. The combined element is actually two 32-bit registers called the Receive BD Rules Control register
(see Tab le 2 2) and the Receive BD Rules Value/Mask register (see Table 24 on page 97). The element can be
looked at as a single 64-bit entity with a Control part and Value/Mask part since they use a single element. Bit
26 of the control part determines how the value/mask part is used. The Receive BD Rules Value/Mask register
can be used as either a 32-bit left-justified Value or a 16-bit Mask followed by a 16-bit Value.
Note: Receive rules cannot be used to match VLAN headers because the VLAN tag is stripped from
the Ethernet frame before the rule checker runs.
Table 22: Receive BD Rules Control Register
Table 23: Receive List Placement Rules Array (memory offset 0x480–0x4ff)
BitNameRWDescriptionDefault
31ERWEnable. Enabled if set to 1–
30&RWAnd With Next. This rule and next must both be true to match. The class
fields must be the same. A disabled next rule is considered true.
Processor activation bits are specified in the first rule in a series.
29P1RWIf the rule matches, the processor is activated in the queue descriptor for
the Receive List Placement state machine.
28P2RWIf the rule matches, the processor is activated in the queue descriptor for
the Receive Data and Receive BD Initiator state machine.
27P3RWIf the rule matches, the processor is activated in the queue descriptor for
the Receive Data Completion state machine.
26MRWMask If set, specifies that the value/mask field is split into a 16-bit value
and 16-bit mask instead of a 32-bit value.
25DRWDiscard Frame if it matches the rule.–
24MapRWMap Use the masked value and map it to the class.–
23:18Reserved RWMust be set to zero.0
17:16OpRWComparison Operator specifies how to determine the match:
15:13HeaderRWHeader Type specifies which header the offset is for:
•000: Start of Frame (always valid)
•001: Start of IP Header (if present)
•010: Start of TCP Header (if present)
•011: Start of UDP Header (if present)
•100: Start of Data (always valid, context sensitive)
•101–111: Reserved
12:8ClassRWThe class this frame is placed into if the rule matches. 0:4, where 0 means
discard. The number of valid classes is the Number of Active Queues
divided by the Number of Interrupt Distribution Groups. Ring 1 has the
highest priority and Ring 4 has the lowest priority.
7:0OffsetRWNumber of bytes offset specified by the header type.–
Table 24: Receive BD Rules Value/Mask Register
–
–
BitNameRWDescriptionDefault
31:16Mask–––
15:0Value–––
Class of Service Example
If either Start of IP Header, Start of TCP Header, or Start of UDP Header is specified, and the frame has no IP,
TCP, or UDP header, respectively, there is no frame match. The full set of rules provides a fairly rich selection
and filtering criteria.
Example: If you wanted to set a Class of Service (CoS) of 2 based on the eighth byte in the data portion of
an encapsulated IPX frame using Ethernet Type 2 having a value greater than 6, you could set up the rules
shown in Figure 16 on page 98.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 97
Page 98
Figure 16: Class of Service Example
Rule 1: Control = 0xc400020C
Where:Enable + And with next (chain with next rule)
Mask -Value/Mask is split into two 16-bit values
Class -Return Ring 2
Offset -12 bytes from start of frame
Mask/Value= 0xffff 8137
Where:Mask – 0xffff
Value - IPX
Rule 2: Control
= 0x84028207
Where:Enable
Mask – Value/Mask split into two 16-bit values
Comparison Operator –Greater Than
Header Type – Start of Data
Offset – 7 bytes from start of data
Mask/Value=0xff00 0600
Where:Mask – 0xff00
Value – 0600
Header Type – Start of Data
Comparison Operator –Equal
Class -Return Ring 2
Checksum CalculationBCM5718 Programmer’s Guide
Checksum Calculation
Whether the host software NOS supports checksum offload or not, the Ethernet controller automatically
calculates the IP, TCP, and UDP of received packets as described in RFC 791, RFC 793, and RFC 768,
respectively.
Which protocol checksum value is produced can be determined by reading the status flag field in the Receive
Return Ring. The valid flag values in the status flag field are IP_CHECKSUM and TCP_UDP_CHECKSUM.
When a valid checksum is produced, the values of the checksums are found in the corresponding receive buffer
descriptor register. These values should be 0xFFFF for a valid checksum or any other value if the checksum
was incorrectly calculated. Assert the Receive No Pseudo-header Checksum bit of the Mode Control register
(see “Mode Control Register (offset: 0x6800)” on page 468) to not to include Pseudo-header in TCP/UDP
checksums.
VLAN Tag Strip
Receiving VLAN-tagged (IEEE 802.1q-compliant) packets are automatically supported by the Ethernet
controller. There is no register or setting required to receive packets that are VLAN-tagged. The VLAN tag is
automatically stripped from the IEEE 802.1q-compliant packet at reception and then placed in a receive buffer
descriptor’s two byte VLAN tag field. The flag field has the BD_FLAGS_VLAN_TAG bit set when a valid VLAN
packet is received. After the packet has been serviced by the host software, these fields should be zeroed out.
In the Receive MAC Mode register (offset 0x468–0x46b), the Keep VLAN Tag Diag Mode bit (bit 10) can be set
to force the Ethernet controller to not strip the VLAN tag from the packet. This is only for diagnostic purposes.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 98
Page 99
Ta bl e 2 5 shows the frame format with IEEE 802.1Q VLAN tag inserted.
Table 25: Frame Format with 802.1Q VLAN Tag Inserted
OffsetDescription
0:5MAC destination address
6:11MAC source address
12:13Tag Protocol ID (TPID)—0x8100
14:15Tag Control Information (TCI):
•Bit 15:13—IEEE 802.1P priority
•Bit 12—CFI bit
•Bit 11:0—VLAN ID
16:17The original EtherType
18:1517Payload
VLAN Tag StripBCM5718 Programmer’s Guide
Broadcom®
January 29, 2016 • 5718-PG108-RPage 99
Page 100
RX Data Flow DiagramBCM5718 Programmer’s Guide
MailBox Registers
status word
rcv std cons
unused
unused
unusedunused
Status Block
Standard and Jumbo Producer Rings
In Host Memory
BD n
Buffer Descriptor points
to free RX buffer in host
TX cons #1RX prod #1
Receive Return Rings in
host memory
BD n
Used Buffer Descriptor points to host
memory where packet was copied
1
2
3
4
6
5
Host Memory
Network
Rcv BD Std Producer Ring Index
BCM570X
Family
RX Data Flow Diagram
The receive data flow can be summarized in Figure 17. The Receive Producer Ring, Receive Buffer Descriptors,
Receive Return Rings, Mailbox registers, and status block registers are the main areas of the receive data flow.
Figure 17: Overview Diagram of RX Flow
The RX flow sequence is as follows:
1. The host software updates a Receive Producer Ring Index in the Mailbox registers.
2. A receive BD or series of BDs with the corresponding index is DMAed to the Ethernet controller from the
host-based Receive Producer Ring.
3. The Ethernet controller updates the Receive Consumer Index in the Host Block register and stores copy of
the BD.
4. A valid Ethernet packet is received from the network into the device.
5. The Ethernet packet is DMAed to host memory using a BD previously DMAed from a Receive Producer
Ring.
Broadcom®
January 29, 2016 • 5718-PG108-RPage 100
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.