SGMII and Gb Ethernet PCS IP Core User’s Guide
April 2014
IPUG60_02.1
Table of Contents
Chapter 1. Introduction .......................................................................................................................... 4
Quick Facts ........................................................................................................................................................... 4
Features ................................................................................................................................................................ 5
Chapter 2. Functional Description ........................................................................................................ 6
Transmit Rate Adaptation ............................................................................................................................ 8
Transmit State Machine ............................................................................................................................... 8
Soft Receive Clock Tolerance Compensation (CTC) Circuit........................................................................ 8
Synchronization State Machine.................................................................................................................... 9
Receive State Machine ................................................................................................................................ 9
Receive Rate Adaptation ............................................................................................................................. 9
Auto-Negotiation State Machine .................................................................................................................. 9
Collision Detect .......................................................................................................................................... 11
Carrier Sense ............................................................................................................................................. 12
Data Path Latency Specifications .............................................................................................................. 12
Signal Descriptions ............................................................................................................................................. 13
Chapter 3. Parameter Settings ............................................................................................................ 17
General Tab ........................................................................................................................................................ 17
(G)MII Style ................................................................................................................................................ 17
RX CTC Mode............................................................................................................................................ 17
Static CTC FIFO Low Threshold ................................................................................................................ 17
Static CTC FIFO High Threshold ............................................................................................................... 18
Guidelines for Calculating Static CTC FIFO Thresholds .................................................................................... 18
Chapter 4. IP Core Generation............................................................................................................. 19
IP Core Generation in IPexpress ........................................................................................................................ 19
Licensing the IP Core................................................................................................................................. 19
Getting Started ........................................................................................................................................... 19
IPexpress-Created Files and Top Level Directory Structure...................................................................... 22
Instantiating the Core ................................................................................................................................. 23
Running Functional Simulation .................................................................................................................. 25
Synthesizing and Implementing the Core in a Top-Level Design .............................................................. 25
Hardware Evaluation.................................................................................................................................. 26
Updating/Regenerating the IP Core ........................................................................................................... 26
IP Core Generation in Clarity Designer............................................................................................................... 27
Getting Started ........................................................................................................................................... 27
Clarity Designer Created Files and Top Level Directory Structure ............................................................ 29
Simulation Evaluation................................................................................................................................. 30
IP Core Implementation ............................................................................................................................. 30
Regenerating an IP Core in Clarity Designer Tool ..................................................................................... 31
Recreating an IP Core in Clarity Designer Tool ......................................................................................... 32
Chapter 5. Application Support........................................................................................................... 33
SGMII-to-(G)MII Reference Design..................................................................................................................... 33
Features ..................................................................................................................................................... 33
Detailed Description ................................................................................................................................... 33
The SGMII and Gb Ethernet PCS IP Core................................................................................................. 34
PCS/SERDES ............................................................................................................................................ 34
Rate Resolution.......................................................................................................................................... 34
Control Registers ....................................................................................................................................... 34
(G)MII I/O Logic.......................................................................................................................................... 40
Signal Descriptions .................................................................................................................................... 41
© 2014 Lattice Semiconductor Corp. All Lattice trademarks, registered trademarks, patents, and disclaimers are as listed at www.latticesemi.com/legal. All other brand
or product names are trademarks or registered trademarks of their respective holders. The specifications and information herein are subject to change without notice.
IPUG60_02.1, April 2014
2
SGMII and Gb Ethernet PCS IP Core User’s Guide
Table of Contents
Chapter 6. Core Validation................................................................................................................... 43
Chapter 7. Support Resources ............................................................................................................ 44
Lattice Technical Support.................................................................................................................................... 44
E-mail Support ........................................................................................................................................... 44
Local Support ............................................................................................................................................. 44
Internet ....................................................................................................................................................... 44
References.......................................................................................................................................................... 44
LatticeECP3 ............................................................................................................................................... 44
ECP5.......................................................................................................................................................... 44
Revision History .................................................................................................................................................. 45
Appendix A. Resource Utilization ....................................................................................................... 46
LatticeECP3 FPGAs............................................................................................................................................ 46
Supplied Netlist Configurations .................................................................................................................. 46
ECP5 FPGAs ...................................................................................................................................................... 46
Supplied Netlist Configurations .................................................................................................................. 46
IPUG60_02.1, April 2014
3
SGMII and Gb Ethernet PCS IP Core User’s Guide
Chapter 1:
Introduction
The Lattice SGMII and Gb Ethernet PCS IP core implements the PCS functions of both the Cisco SGMII and the
IEEE 802.3z (1000BaseX) specifications. The PCS mode is pin selectable. This IP core may be used in bridging
applications and/or PHY implementations.
The Serial Gigabit Media Independent Interface (SGMII) is a connection bus for Ethernet Media Access Controllers
(MACs) and Physical Layer Devices (PHYs) defined by Cisco Systems. It replaces the classic 22-wire GMII connection with a low pin count, 4-pair, differential SGMII connection. The classic GMII interface defined in the
IEEE802.3 specification is strictly for Gigabit rate operation. However, the Cisco SGMII specification defines a
method for operating 10 Mbps and 100 Mbps MACs over the interface. Moreover, the Cisco SGMII specification is
comprised of more than just a bus interface definition; it defines a bridging function between SGMII and GMII
buses.
These applications can be completely implemented in ECP5™ and LatticeECP3™ Field Programmable Gate Array
(FPGA) devices. As an example, Lattice has developed a reference design for a complete SGMII-to-(G)MII bridge.
This reference design is included with the SGMII and Gb Ethernet PCS IP Core package and is described in detail
in “SGMII-to-(G)MII Reference Design” on page 33.
This document describes the IP core's operation, and provides instructions for generating the core through Lattice’s IPexpress™ tool, and for instantiating, synthesizing, and simulating the core.
Quick Facts
Table 1-1 gives quick facts about the Lattice SGMII and Gb Ethernet PCS core.
Table 1-1. Lattice SGMII and Gb Ethernet PCS IP Core Quick Facts
SGMII and Gb Ethernet IP Configuration
Across All IP Configurations
Core
Requirements
FPGA Families
Supported
ECP5, LatticeECP3
Minimal Device Needed
LFE5UM-25F-6MG285C
LFE3-17E-7FN256C
Targeted Devices
LFE5UM-85F-7BG756C
LFE3-70EA-7FN484C
Data Path Width
Resource
Utilization
8
LUTs
800 to 1000
sysMEM EBRs
0 to 1
Registers
800 to 1000
Lattice Diamond® 3.2
Lattice Implementation
®
Synopsys Synplify Pro® for Lattice I-2013.09L-SP1
Synthesis
Design Tool
Support
Mentor Graphics® Precision® RTL
Aldec® Active-HDLTM 9.3 Lattice Edition
Simulation
Mentor Graphics® ModelSim® SE (Verilog only)
IPUG60_02.1, April 2014
4
SGMII and Gb Ethernet PCS IP Core User’s Guide
Introduction
Features
• Implements PCS functions of the Cisco SGMII Specification, Revision 1.8
• Implements PCS functions for IEEE 802.3z (1000BaseX)
• Dynamically selects SGMII/1000BaseX PCS operation
• Supports MAC or PHY mode for SGMII auto-negotiation
• Supports (G)MII data rates of 1G bps, 100 Mbps, 10 Mbps
• Provides Management Interface Port for control and maintenance
• Includes Easy Connect option for seamless integration with Lattice's Tri-Speed MAC (TSMAC) IP core
IPUG60_02.1, April 2014
5
SGMII and Gb Ethernet PCS IP Core User’s Guide
Chapter 2:
Functional Description
The SGMII and Gb Ethernet PCS IP core converts GMII frames into 8-bit code groups in both transmit and receive
directions and performs auto-negotiation with a link partner as described in the Cisco SGMII and IEEE 802.3z
specifications. The IP core’s block diagram is shown in Figure 2-1.
Figure 2-1. SGMII and Gb Ethernet PCS IP Core Block Diagram
Operational Rate
mr_adv_ability
Tx Rate
Adaptation
Rx Rate
Adaptation
Transit
State Machine
Receive
State Machine
Rx_Clk_125
Rx _MII_Clk
RxD[7:0]
Rx_Er
Rx_Dv
Collision
Detect
CRS
Col
Tx_En
Tx_Er
TxD[7:0]
GbE Mode
Tx_MII_Clk
MAC/PHY Mode
Tx_Clk_125
(G)MII
mr_an_complete
mr_lp_adv_ability
mr_an_enable
mr_main_reset
Synchronization
State Machine
Rx_Data[7:0]
Rx_Kctl
Rx_Cv_Err
Rx_Disp_Err
Rx_Even
Receive
Clock Tolerance
Compensation
Signal_Detect
xmit_autoneg
Tx_Kctl
force_unidir
Tx_Data[7:0]
force_loopback
Tx_Disparity_Cntl
force_isolate
Rx_Err_Decode_Mode
mr_restart_an
mr_page_rx
SERDES_Recovered_Clk
Auto-Negotiation
State Machine
an_link_ok
8-bit Code Group Interface
IPUG60_02.1, April 2014
6
SGMII and Gb Ethernet PCS IP Core User’s Guide
Functional Description
An example of how this core may be used in implementing a complete SGMII-to-(G)MII bridge is shown in
Figure 2-2.
Figure 2-2. SGMII to (G)MII Bridge Reference Design
MAC / PHY
Mode
125MHz
Ref Clk
GbE
Mode
Part of Quad/Dual
PCS/SERDES ASB
(G)MII
to
MAC / PHY
Primary
I/O
4 or 8 bits
@ 2.5, 25, 125MHz
SGMII and
Gb Ethernet
PCS
IP Core
(G)MII
4 or 8 bits
@ 2.5, 25, 125MHz
Rate
Resolution
8BI
8B10B
Encoder SERDES
Decoder
8 bits
@ 125MHz
Link State Machine
SGMII
for
PHY / MAC
CML
Differential Pairs
@ 1.25Gbps
Management
Interface
Control
Registers
MDIO
Figure 2-3 shows typical clock network connections between the IP core, the SERDES, and a MAC.
Figure 2-3. Typical SGMII Clocking Network
Serial Gigabit Media Independent Interface
(SGMII)
Tx
Ref
Clk
Gigabit Media
Media Independent
Independent Interface
Interface
(GMII)
((G)MII)
8-Bit Interface
(8BI)
Rx
Ref
Clk
125MHz
SERDES/PCS
10
1
Deserializer
CDR
recov clk
1.25GHz
÷10
SGMI/GbE PCS IP Core
Sync
FSM
10
8B10B
DEC
8
8
CTC
RX
FSM
8
Rate
Adapt
8 or 4
125MHz
MAC
AutoNeg
FSM
TX
PLL
1.25GHz
÷10
1
Driver
125MHz
10
Serializer
8B10B
ENC
8
TX
FSM
8
Rate
8 or 4
Adapt
GMII Clock (125 MHz)
÷1 or
÷5 or
÷50
IPUG60_02.1, April 2014
7
(G)MII Clock (125 or 25 or 2.5MHz)
SGMII and Gb Ethernet PCS IP Core User’s Guide
Functional Description
Transmit Rate Adaptation
This block adjusts the byte-per-byte data rate such that the output rate is always 1Gbps. For the case where the
incoming (G)MII operates at 1Gbps, there is no data rate alteration. The incoming data is 8 bits wide clocked at 125
MHz and the outgoing data is also 8 bits wide clocked at 125 MHz. For the case where the incoming (G)MII operates at 100 Mbps, each incoming data byte is replicated ten times on the outgoing port. The incoming data is 4 bits
wide clocked at 25 MHz clock and the outgoing data is 8 bits wide clocked at 125 MHz. The case for 10 Mbps
(G)MII operation is similar except that data bytes are replicated 100 times and the incoming clock rate is 2.5 MHz.
Transmit State Machine
The transmit state machine implements the transmit functions described in clause 36 of the IEEE802.3 specification. The state machine's main purpose is to convert GMII data frames into code groups. A typical timing diagram
for this circuit block is shown in Figure 2-4. Note that the state machine in this IP core does not fully implement the
conversion to 10-bit code groups as specified in the IEEE802.3 specification. Instead, partial conversion to 8-bit
code groups is performed. A separate encoder in the Lattice SERDES completes the full conversion to 10-bit code
groups.
Figure 2-4. Typical Transmit Timing Diagram
tx_en
tx_d
preamble SFD
Dest Add
Src Add
Len/Type
Data
FCS
tx_kcntl
tx_data
IDLE
SPD preamble SFD
Dest Add
Src Add
Len/Type
Data
FCS EPD IDLE
Soft Receive Clock Tolerance Compensation (CTC) Circuit
This block allows the receive path to compensate for slight frequency offsets between two clocks with a nominal
frequency of 125 MHz. One timing source is the recovered clock from the SERDES Rx physical link. The other timing source is the locally generated Rx clock. As long as the two clock frequencies are within acceptable limits, the
compensation circuit can maintain data path integrity. The circuit employs a 1024-byte deep FIFO with programmable high and low watermarks. When the FIFO occupancy is below the low watermark and the datastream is within
an inter-packet region, FIFO reading is halted and two idle-2 ordered sets are inserted into the datastream. This
action compensates for situations where the local clock is faster than the recovered clock. When the FIFO occupancy is above the high watermark and the datastream is within an inter-packet region, FIFO writing is inhibited for
a period of one idle ordered set. This action compensates for situations where the local clock is slower than the
recovered clock.
Note that the amount of timing drift between the two CTC clocks is dependent upon the size of the frequency offset
and the size of the ethernet frame. Larger frame sizes produce larger timing drifts; larger frequency offsets produce
larger timing drifts. For example, a +/- 100 ppm offset for a 1500 byte frame produces a 2.4 ns time drift. Increasing
the frame size to 15,000 bytes produces a 24 ns time drift. The characteristics of the system design affect the compensation requirements for the CTC.
To address some of these issues, the IP core has three CTC implementations.
• A dynamic mode.
• A static mode.
• A “none” mode.
The user chooses the desired CTC mode when the IP core is generated using the IPexpress tool.
IPUG60_02.1, April 2014
8
SGMII and Gb Ethernet PCS IP Core User’s Guide
Functional Description
The dynamic CTC mode is intended for use where the IP core is expected to utilize all three of the possible (G)MII
data rates (1 Gbps, 100 Mbps, 10 Mbps). The dynamic mode CTC automatically changes its FIFO thresholds to
match the (G)MII data rate. These thresholds are hard-coded, and cannot be changed by the user. The thresholds
are 16/32 for 1 Gbps, 34/68 for 100 Mbps, 340/640 for 10 Mbps. These settings provide the following compensation
performance for a 9600 byte frame: +/- 729 ppm for 1Gbps; +/- 166 ppm for 100 Mbps; and +/- 176 ppm for 10
Mbps.
The static CTC mode is intended for use where the IP core is expected to operate at only one (G)MII data rate
(1 Gbps, or 100 Mbps, or 10 Mbps). The user is able to choose the FIFO thresholds when the IP core is generated
using the IPexpress tool. The default FIFO thresholds are 16/32, providing +/- 729 ppm compensation for a 9600
byte frame at (G)MII data rate of 1 Gbps. However, the user can alter these thresholds to provide other compensation capabilities.
The “none” CTC mode is intended for cases where a CTC function within the IP core is unwanted. The “none”
mode utilizes a 16-byte deep FIFO to provide clean data transfers between the RX recovered clock, and the local
RX clock. These two clocks may have arbitrary phase relationships with respect to each other; however the clocks
must be at exactly the same frequency (0 ppm offset).
Synchronization State Machine
The synchronization state machine implements the alignment functions described in clause 36 of the IEEE802.3
specification. The state machine's main purpose is to determine whether incoming code groups are properly
aligned. Once alignment is attained, proper code groups are passed to the receive state machine. If alignment is
lost for an extended period, an auto-negotiation restart is triggered.
Receive State Machine
The receive state machine implements the receive functions described in clause 36 of the IEEE802.3 specification.
The state machine's main purpose is to convert code groups into GMII data frames. A typical timing diagram for
this circuit block is shown in Figure 2-5. Note that the state machine in this IP core does not fully implement the
conversion from 10-bit code groups as specified in the IEEE802.3 specification. Instead, partial conversion from 8bit code groups is performed. A separate decoder in the Lattice SERDES performs 10-bit to 8-bit code group conversions.
Figure 2-5. Typical Receive Timing Diagram
rx_kcntl
rx_data IDLE SPD preamble SFD
Dest Add
Src Add
Len/Type
Data
FCS EPD
IDLE
rx_dv
rx_d
preamble SFD
Dest Add
Src Add
Len/Type
Data
FCS
Receive Rate Adaptation
This block's function is similar to the transmit rate adaptation block, except that it operates in reverse. The incoming
data rate is always 1Gbps. The outgoing data rate is reduced by factors of 1x, 10x, or 100x for (G)MII rates of
1Gbps, 100 Mbps, and 10 Mbps respectively.
Auto-Negotiation State Machine
The auto-negotiation state machine implements the link configuration functions described in clause 37 of
IEEE802.3 specification. However, the Cisco SGMII specification defines several changes (summarized below).
This IP core will operate in adherence to either specification, based on the setting of an external “mode” pin. Please
consult the two specifications for a detailed description of auto-negotiation operation. From a high-level view, the
primary auto-negotiation functions are: testing the physical link for proper operation, and passing link configuration
information between entities sitting on both sides of the link.
IPUG60_02.1, April 2014
9
SGMII and Gb Ethernet PCS IP Core User’s Guide
Functional Description
The major Cisco SGMII auto-negotiation modifications include:
• Decreases link timer interval from 10 msec to 1.6 msec.
• Redefines “link ability” bit assignments (see Table 2-1).
• Eliminates the need to pass link ability information from MAC to PHY.
• Adds a new condition that forces a restart on the PHY side whenever the PHY link abilities change.
A rough flow of auto-negotiation operation is as follows:
• An event triggers the process (e.g. reset, loss of sync).
• Both link entities recognize that the process has started and begin transmitting their abilities.
• The link timer expires.
• Both link entities attempt to verify reception of link partner abilities. Once reception is achieved, the entity transmits an acknowledge signal.
• The link timer expires.
• Both link entities verify receipt of link partner acknowledgement and then begin transmitting IDLE code groups.
• The link timer expires.
• Both link entities verify reception of IDLE code groups from link partner. Then the process enters the LINK-OK
state and normal PCS operation can begin. The machine will remain in the LINK-OK state until a re-start event is
detected.
Figure 2-6. Typical Auto-Negotiation Timing Diagram for MAC-Side Entity
power up reset
mr_page_rx
mr_an_complete
mr_adv_ability
mr_lp_adv_ability
0x4001
0x0000
0xd801
IP core signal ports associated with the auto-negotiation function are listed in Table 2-1.
IPUG60_02.1, April 2014
10
SGMII and Gb Ethernet PCS IP Core User’s Guide
Functional Description
Table 2-1. IP Core Signal Ports Associated with Auto-Negotiation
Bit Number
SGMII PHY Mode
SGMII MAC Mode
15
Link Status
0
Next Page
14
Acknowledge
(controlled by autoneg
state machine)
1
Acknowledge
(controlled by autoneg
state machine)
13
0
0
Remote Fault[1]
12
Duplex Mode
1=full; 0=half
0
Remote Fault[0]
11
(G)MII Speed[1]
11=rsvd; 10=1Gbps
0
0
10
(G)MII Speed[0]
01=100Mbps;
00=10Mbps
0
0
mr_adv_ability[15:0]
GbE Mode
9
0
0
0
8
0
0
Pause[1]
7
0
0
Pause[0]
6
0
0
Half Duplex
5
0
0
Full Duplex
4
0
0
0
3
0
0
0
2
0
0
0
1
0
0
0
0
1
1
0
mr_lp_adv_ability[15:0] Displays ability data received by entity (from link partner)
mr_an_enable
Active high signal; enables auto-negotiation operation
mr_restart_an
Active high signal; forces restart of auto-negotiation
mr_page_rx
Active high signal, asserts while state machine is in “Complete Acknowledge” state
mr_an_complete
Active high signal, asserts while state machine is in “Link OK” state
sgmii_mode
Controls auto-negotiation behavior. 0 = MAC-side operation; 1 = PHY-side operation
Controls duration of link interval timer.
0 = Timer interval is normal (1.6 msec/SGMII 10msec/1000BaseX)
1 = Timer interval is 2 µsec (debug).
debug_link_timer_short
This signal should be tied to logic-0 when synthesizing the IP core so that the timer operates normally. However, for simulation, the signal can be tied to logic high to speed up completion of the autonegotiation portion of the simulation.
Collision Detect
The collision detect signal is the logical-and of the tx_en and rx_dv GMII signals.
IPUG60_02.1, April 2014
11
SGMII and Gb Ethernet PCS IP Core User’s Guide
Functional Description
Carrier Sense
The carrier sense signal is identical to the rx_dv GMII signal.
Data Path Latency Specifications
Latency is the time delay taken to propagate signals between two points in the data path. This section provides
latency specifications for the transmit and receive data paths of the SGMII IP core. The latency values are found by
measuring the delay time between the leading edge of the SFD symbol of an ethernet frame, as it passes through
the data path. For example, to specify the latency of the RX-CTC circuit, a continuous burst of constant-width ethernet frames, with constant 12-clock-cycle inter frame gaps are applied to the head-end of the RX data path. Then
the latency is found by measuring the difference between the leading edge of the SFD symbol into and out-of the
CTC circuit. The latency specifications are given in units of clock-cycles (125 MHz clock). All latency specifications
are provided for the 1Gbps (G)MII data rate.
Referring back to Figure 2-3, it is shown that the two major elements in the IP core’s transmit data path include the
transmit-rate-adaptation-block and the transmit-state-machine-block. Both blocks provide constant delays, regardless of ethernet frame size, clock accuracy, and inter frame gap. There is no latency variation due to these factors.
Table 2-2 shows the transmit data path latencies for the IP core's two (G)MII configurations – classic style and
TSMAC easy connect style. Other IP core modes such as MAC/PHY, GbE/SGMII, etc. have no influence on transmit data path latency.
Table 2-2. Transmit Data Path Latency Specifications
IP Core GMII
Configuration
TX FSM
Latency
TX Rate Adapt
Latency
TX Total
Latency
Classic GMII
3
9
12
Easy Connect GMII
3
2
5
Referring back to Figure 2-3, it is shown that the three major elements in the IP core’s receive data path include the
RX-CTC-block, the RX-state-machine-block, and the RX-rate-adaptation-block. The last two blocks provide constant delays; there is no frame-to-frame latency variation. However, the RX-CTC block is affected by frame-size,
clock accuracy, and FIFO-thresholds. The RX-CTC-block does exhibit frame-to-frame latency variation. Table 2-3
shows the RX data path latencies for various frequency accuracies, frame sizes, and (G)MII physical configurations. Note however that all specifications are given with Dynamic/Static CTC FIFO thresholds of 16-low; 32-high
(these are the default threshold settings).
Table 2-3. Receive Data Path Latency Specifications
Frequency Offset
Between Sender
and Receiver
IP Core GMII
Configuration
RX CTC Expected
Number of Clock
Slips per Frame
RX CTC Number
of Clock Cycles
Added/Dropped
per Frame
Min.
Max.
RX CTC
Latency
Min.
Max.
RX FSM
Latency
Min.
RX Rate Adapt
Latency
Max.
Min.
Max.
RX Total Latency
Min.
Max.
64-Byte Frames
+200 ppm
Classic GMII
-0.03
0
2add
24
26
6
6
8
8
38
40
0 ppm
Classic GMII
0
0
0
27
27
6
6
8
8
41
41
-200 ppm
Classic GMII
+0.03
0
2drop
32
34
6
6
8
8
46
48
+200 ppm
Easy Connect GMII
-0.03
0
2add
24
26
6
6
2
2
32
34
0 ppm
Easy Connect GMII
0
0
0
27
27
6
6
2
2
35
35
-200 ppm
Easy Connect GMII
+0.03
0
2drop
32
34
6
6
2
2
40
42
1500-Byte Frames
+200 ppm
Classic GMII
-0.3
0
2add
24
26
6
6
8
8
38
40
0 ppm
Classic GMII
0
0
0
27
27
6
6
8
8
41
41
-200 ppm
Classic GMII
+0.3
0
2drop
32
34
6
6
8
8
46
48
+200 ppm
Easy Connect GMII
-0.3
0
2add
24
26
6
6
2
2
32
34
0 ppm
Easy Connect GMII
0
0
0
27
27
6
6
2
2
35
35
-200 ppm
Easy Connect GMII
+0.3
0
2drop
32
34
6
6
2
2
40
42
IPUG60_02.1, April 2014
12
SGMII and Gb Ethernet PCS IP Core User’s Guide
Functional Description
Table 2-3. Receive Data Path Latency Specifications (Continued)
Frequency Offset
Between Sender
and Receiver
IP Core GMII
Configuration
RX CTC Expected
Number of Clock
Slips per Frame
RX CTC Number
of Clock Cycles
Added/Dropped
per Frame
Min.
Max.
RX CTC
Latency
Min.
Max.
RX FSM
Latency
Min.
RX Rate Adapt
Latency
Max.
Min.
Max.
RX Total Latency
Min.
Max.
15,000-Byte Frames
+200 ppm
Classic GMII
-3.0
2add
4add
25
27
6
6
8
8
39
41
0 ppm
Classic GMII
0
0
0
27
27
6
6
8
8
41
41
-200 ppm
Classic GMII
+3.0
2drop
4drop
31
33
6
6
8
8
45
47
+200 ppm
Easy Connect GMII
-3.0
2add
4add
25
27
6
6
2
2
33
35
0 ppm
Easy Connect GMII
0
0
0
27
27
6
6
2
2
35
35
-200 ppm
Easy Connect GMII
+3.0
2drop
4drop
31
33
6
6
2
2
39
41
Random Frame Sizes From 64 to 15,000 Bytes, Random PPM Offset From -200 to +200
Random ppm
Classic GMII
-3.0 min. +3.0 max.
4drop
4add
24
34
6
6
8
8
38
48
Random ppm
Easy Connect GMII
-3.0 min. +3.0 max.
4drop
4add
24
34
6
6
2
2
32
42
Signal Descriptions
Table 2-4 shows a detailed listing of all the SGMII IP core I/O signals.
Table 2-4. SGMII and Gb Ethernet PCS IP Core Input and Output Signals
Signal Name
I/O
Signal Description
tx_clk_125
In
Transmit 125MHz Clock - 125 MHz clock for transmit state machine. Incoming data from
the transmit rate adaptation block data is sampled on rising edge of this clock. Outgoing 8bit code group transmit data is launched on the rising edge of this clock.
tx_mii_clk
In
Transmit MII Clock - 125 MHz, 25 MHz, or 2.5 MHz clock for incoming (G)MII transmit
data. Data is sampled on the rising edge of this clock. Note, this port is only present when
the IP core is generated using the “classic” (G)MII option.
Out
Transmit Clock Enable Source - This signal is only present when the IP core is generated
using the “TSMAC Easy Connect” (G)MII option. This signal is used in combination with the
transmit 125 MHz clock to regulate the flow of transmit (G)MII data. The signal is generated
by the transmit rate adaptation block. This clock enable should be tied to the transmit section of the Lattice MAC that sends transmit Ethernet frames to the SGMII and Gb Ethernet
PCS IP core. This clock enable should also be tied to the clock enable “sink” of the SGMII
and Gb Ethernet PCS IP core. This clock enable’s behavior is controlled by the setting of
the operational_rate pins of the IP core. For 1Gbps operation, the clock enable is constantly
high. For 100 Mbps operation, the clock enable is high for one-out-of-ten 125 MHz clock
cycles. For 10 Mbps operation, the clock enable is high for one-out-of-one-hundred 125
MHz clock cycles.
tx_clock_enable_sink
In
Transmit Clock Enable Sink - This signal is only present when the IP core is generated
using the “TSMAC Easy Connect” (G)MII option. This signal is used in combination with the
transmit 125 MHz clock to regulate the flow of transmit (G)MII data. When the clock enable
is high and the transmit clock edge rises, (G)MII data is sampled.
rx_clk_125
In
Receive 125MHz Clock - 125 MHz clock for synchronization and receive state machines.
Incoming code groups from the receive CTC block data are sampled on rising edge of this
clock. Outgoing GMII data is launched on the rising edge of this clock.
rx_mii_clk
In
Receive MII Clock - 125 MHz, 25 MHz, or 2.5 MHz clock for outgoing (G)MII receive data.
Data is launched on the rising edge of this clock. Note, this port is only present when the IP
core is generated using the “classic” (G)MII option.
Out
Receive Clock Enable Source - This signal is similar to the tx_clock_enable_source
described above, except that it is used for the receive data path. Note that this signal is only
present when the IP core is generated using the “TSMAC Easy Connect” (G)MII option.
In
Receive Clock Enable Sink - This signal is only present when the IP core is generated
using the “TSMAC Easy Connect” (G)MII option. This signal is used in combination with the
receive 125 MHz clock to regulate the flow of receive (G)MII data. When the clock enable is
high and the receive clock edge rises, (G)MII data is launched.
Clock Signals
tx_clock_enable_source
rx_clock_enable_source
rx_clock_enable_sink
IPUG60_02.1, April 2014
13
SGMII and Gb Ethernet PCS IP Core User’s Guide
Functional Description
Table 2-4. SGMII and Gb Ethernet PCS IP Core Input and Output Signals (Continued)
Signal Name
I/O
Signal Description
In
SERDES Recovered Clock -125 MHz clock recovered from receive side of SERDES. This
signal is synchronous with the 8-bit code groups received by the SERDES and should be
used to clock receive data between the SERDES and the IP core. The IP core samples
incoming 8-bit code groups on the rising edge of this clock.
tx_d[7:0]
In
Transmit Data - Incoming (G)MII data. Note, this port’s behavior varies depending on the
(G)MII option used when generating the IP core. For “classic” mode, when the (G)MII data
rate is 1Gbps, all 8 bits of tx_d are valid. However, for 100 Mbps and 10 Mbps, only bits 3:0
of tx_d are valid. For the “TSMAC Easy Connect” mode all 8 bits of tx_d are valid for all
(G)MII data rates (1Gbps, 100 Mbps, 10 Mbps).
tx_en
In
Transmit Enable - Active high signal, asserts when incoming data is valid.
tx_er
In
Transmit Error - Active high signal used to denote transmission errors and carrier extension on incoming (G)MII data port.
rx_d[7:0]
Out
Receive Data - Outgoing (G)MII data. Note, this port’s behavior varies depending on the
(G)MII option used when generating the IP core. For “classic” mode, when the (G)MII data
rate is 1Gbps, all 8 bits of rx_d are valid. However, for 100 Mbps and 10 Mbps, only bits 3:0
of rx_d are valid. For the “TSMAC Easy Connect” mode all 8 bits of rx_d are valid for all
(G)MII data rates (1Gbps, 100 Mbps, 10 Mbps).
rx_dv
Out
Receive Data Valid - Active high signal, asserts when outgoing data is valid.
rx_er
Out
Receive Error - Active high signal used to denote transmission errors and carrier extension
on outgoing (G)MII data port.
col
Out
Collision Detect - Active high signal, asserts when tx_en and rx_dv are active at the same
time.
crs
Out
Carrier Sense Detect - Active high signal, asserts when rx_dv is high.
SERDES_recovered_clk
GMII Signals
8-Bit Code Group Signals
8b Transmit Data - 8-bit code group data after passing through transmit state machine.
Note: the transmit 8-bit code group interface operates differently in the LatticeECP2M and
LatticeSC FPGA families.
For LatticeECP2M, the port truly behaves as an 8-bit code group interface where data is
tx_data[7:0], and tx_kcntl and tx_disparity_cntl are control signals for the 8-bit to 10-bit
encoder within the LatticeECP2M SERDES.
tx_data[7:0]
Out
However for LatticeSC, the port behaves as a 10-bit code group interface, with signals
tx_kcntl and tx_disparity_cntl forming bits 8 and 9 of the 10-bit interface. In addition, the 8bit to 10-bit encoder resides within the IP core; and consequently the encoder within the
LatticeSC SERDES is bypassed.
Note that even though there are functional differences between the LatticeECP2M and LatticeSC implementations, the IPcore/SERDES connectivity is the same for both implementations - tx_data[7:0] of IP core connects to tx_data[7:0] of SERDES - tx_kcntl of IP core
connects to tx_kcntl of SERDES - tx_disparity_cntl connects to tx_disparity_cntl of
SERDES.
tx_kcntl
Out
8b Transmit K Control - Denotes whether current code group is data or control.
1 = control, 0 = data.
tx_disparity_cntl
Out
8b Transmit Disparity Control - Used to influence the disparity state of an idle code group
at the beginning of an inter-packet gap. 1 = Insert /I1/ if inter-packet gap begins with positive disparity, otherwise insert /I2/; 0 = normal, insert /I2/.
rx_data[7:0]
In
8b Receive Data - 8-bit code group data presented to the receive state machine.
rx_kcntl
In
8b Receive K Control - Denotes whether current code group is data or control. 1 = control,
0 = data.
IPUG60_02.1, April 2014
14
SGMII and Gb Ethernet PCS IP Core User’s Guide
Functional Description
Table 2-4. SGMII and Gb Ethernet PCS IP Core Input and Output Signals (Continued)
Signal Name
I/O
Signal Description
Receive Error Control Mode - The embedded SERDES block of the LatticeECP2M
FPGAs has two modes of interpreting errors - decoded and normal. In decoded mode, the
three signals (rx_even, rx_cv_err, rx_disp_err) are used to decode one of eight error conditions. In decoded mode, the IP core responds to the following errors:
rx_err_decode_mode
In
100 - Coding Violation Error
111 - Disparity Error
All other error codes are ignored by the IP core.
In normal mode, the three error signals (rx_even, rx_cv_err, rx_disp_err) behave normally.
The rx_err_decode_mode signal should be set high for decode-mode, and low for normal
mode. When using LatticeSC devices, the pin should always be tied low.
rx_even
In
Rx Even - This signal is only used when error decoding mode is active. Otherwise, the signal should be tied low.
rx_cv_err
In
Rx Coding Violation Error - In normal mode, an active high signal denoting a coding violation error in the receive data path. In decode mode, used to decode 1 of 8 error conditions.
rx_disp_err
In
Rx Disparity Error - In normal mode, an active high signal denoting a disparity error in the
receive data path. In decode mode, used to decode 1 of 8 error conditions.
signal_detect
In
Signal Detect - Denotes status of SERDES Rx physical link. 1 = signal is good; 0 = loss of
receive signal.
rx_compensation_err
Out
Receive CTC Compensation Error - This active high signal asserts when the receive
CTC FIFO either underflows or overflows.
ctc_drop_flag
Out
CTC Drop Indication – Active high signal that asserts when the CTC logic drops an idlecode-group from the RX data stream.
ctc_add_flag
Out
CTC Add Indication – Active high signal that asserts when the CTC logic adds an idlecode group to the RX data stream.
Auto-negotiation XMIT Status – This signal should be tied to the “xmit_chn” pin of the
SERDES. When the signal is high, it forces the RX data path of the SERDES to periodically
insert idle-code groups into the SERDES RX data stream. This ensures that the SERDES
CTC has opportunities to rate-adapt for ppm offsets.
xmit_autoneg
Out
The PCS IP core drives this signal high when the auto-negotiation process is running. At all
other times, the PCS IP core drives this signal low.
Use of this signal is required if the designer chooses to use the CTC function embedded
within the SERDES (instead of using the soft CTC function within the SGMII/GbE PCS IP
core). Otherwise, the use of this signal is optional.
Management Signals
mr_adv_ability[15:0]
In
Advertised Ability - Configuration status transmitted by PCS during auto-negotiation process.
mr_an_enable
In
Auto-Negotiation Enable - Active high signal that enables auto-negotiation state machine
to function.
mr_main_reset
In
Main Reset - Active high signal that forces all PCS state machines to reset.
mr_restart_an
In
Auto-Negotiation Restart - Active high signal that forces auto-negotiation process to
restart.
mr_an_complete
Out
Auto-Negotiation Complete - Active high signal that indicates that the auto-negotiation
process is completed.
mr_lp_adv_ability[15:0]
Out
Link Partner Advertised Ability - Configuration status received from partner PCS entity
during the auto-negotiation process. The bit definitions are the same as described above
for the mr_adv_ability port.
mr_page_rx
Out
Auto-Negotiation Page Received - Active high signal that asserts while the auto-negotiation state machine is in the “Complete_Acknowledge” state.
IPUG60_02.1, April 2014
15
SGMII and Gb Ethernet PCS IP Core User’s Guide
Functional Description
Table 2-4. SGMII and Gb Ethernet PCS IP Core Input and Output Signals (Continued)
Signal Name
force_isolate
I/O
Signal Description
In
Force PCS Isolate – Active high signal that isolates the PCS. When asserted, the RX
direction forces the (G)MII port to all zeros, regardless of the condition of the incoming
1.25Gbps serial data stream. In the TX direction, the condition of the incoming (G)MII port
is ignored. The TX PCS behaves as though the (G)MII TX input port was forced to all zeros.
Note, however, that the isolate function does not produce any electrical isolation – such as
tri-stating of the (G)MII RX outputs of the IP core.
When the signal is deasserted (low), the PCS isolation functions are deactivated.
The use of this signal is optional. If the user chooses not to use the isolate function, then
this signal should be tied low.
force_loopback
In
Force PCS Loopback – Active high signal that activates the PCS loopback function. When
asserted, the 8-bit code-group output of the transmit state machine is looped back to the 8bit code-group input of the receive state machine. When deasserted, the loopback function
is deactivated.
The use of this signal is optional. If the user chooses not to use the loopback function, then
this signal should be tied low.
force_unidir
In
Force PCS Unidirectional Mode – Active high signal that activates the PCS unidirectional
mode. When asserted, the transmit state machine path between the TX (G)MII input and
the TX 8-bit code-group output will remain operational, regardless of what happens on the
RX data path. (Normally RX loss of sync, invalid code-group reception, auto-negotiation
restarts can force the transmit state machine to temporarily ignore inputs from the TX
(G)MII port).
When deasserted, the unidirectional mode is deactivated.
The use of this signal is optional. If the user chooses not to use the unidirectional function,
then this signal should be tied low.
an_link_ok
Out
Auto-Negotiation Link Status OK – Active high signal that indicates that the link is ok.
The signal is driven by the auto-negotiation state machine. When auto-negotiation is
enabled, the signal asserts when the state machine is in the LINK_OK state. If auto-negotiation is disabled, the signal asserts when the state machine is in the
AN_DISABLE_LINK_OK state (see IEEE 802.3 figure 37-6).
This signal is intended to be used to produce the “Link Status” signal as required by IEEE
802.3, Status Register 1, Bit D2 (see IEEE 802.3 paragraph 22.2.4.2.13)
Miscellaneous Signals
rst_n
In
Reset - Active low global reset.
sgmii_mode
In
operating in SGMII mode.
0 = operates as MAC-side entity, 1 = operates as PHY-side entity.
gbe_mode
In
Gigabit Ethernet Mode – Controls the core’s PCS function.
0 = operates as SGMII PCS, 1 = operates as Gigabit Ethernet PCS (1000BaseX)
SGMII Mode – Controls the behavior of the auto-negotiation process when the core is
Operational Rate – When the core operates in SGMII PCS mode, this port controls the
regulation rate of the rate adaptation circuit blocks as follows:
operational_rate[1:0]
In
10 = 1G bps Rate
01 = 100 Mbps Rate
00 = 10 Mbps Rate
Note in Gigabit Ethernet PCS mode, the rate adaptation blocks always operates at the
1Gbps rate, regardless of the settings on the operational_rate control pins.
debug_link_timer_short
IPUG60_02.1, April 2014
In
Debug Link Timer Mode – Active high signal that forces the auto-negotiation link timer to
run much faster than normal. This mode is provided for debug purposes (e.g., allowing simulations to run through the auto-negotiation process much faster than normal).
16
SGMII and Gb Ethernet PCS IP Core User’s Guide
Chapter 3:
Parameter Settings
The IPexpress tool is used to create IP and architectural modules in the Diamond software. Refer to “IP Core Generation” on page 19 for a description on how to generate the IP.
Table 3-1 provides the list of user configurable parameters for the SGMII IP core. The parameter settings are specified using the SGMII IP core Configuration GUI in IPexpress.
Table 3-1. SGMII and Gb Ethernet PCS IP Core Configuration Parameters
Parameter
Range/Options
Default
Classic/
TSMAC Easy Connect
Classic
Dynamic/
Static or None
Dynamic
Static CTC FIFO
Low Threshold
3-1010
16
Static CTC FIFO
High Threshold
13-1020
32
(G)MII Style
RX CTC Mode
General Tab
Figure 3-1 shows the contents of the SGMII and Gb Ethernet Options in the IPexpress Tool.
Figure 3-1. SGMII and Gb Ethernet Options in the IPexpress Tool
The SGMII and Gb Ethernet IP options of the following parameters:
(G)MII Style
This parameter affects the behavior and implementation of the (G)MII port. In “Classic” mode, the (G)MII data port
is 8 bits wide. All 8 bits are used for 1Gbps operation. Only the lower 4 bits are used for 100Mbs and 10 Mbps operation. A separate MII clock is used to synchronize the (G)MII data. The MII clock frequency varies with the (G)MII
data rate: 125 MHz for 1 Gbps, 25 MHz for 100 Mbps, 2.5 MHz for 10 Mbps. For the “TSMAC Easy Connect” mode,
the (G)MII data port is 8 bits wide; and all 8 bits are used, regardless of the (G)MII data rate. A single 125 MHz
clock is used to synchronize (G)MII data; and a clock enable is used to regulate the (G)MII data rate.
RX CTC Mode
This parameter controls the behavior of the CTC block. In dynamic mode, the CTC FIFO thresholds are automatically changed, based upon the current operational rate of the rate adaptation blocks. Optimal thresholds are internally chosen for the three data rates (1Gbps, 100 Mbps, 10 Mbps). In static mode, the user manually chooses the
CTC FIFO thresholds, and these thresholds remain fixed. In "none" mode, the CTC function is replaced by a shallow FIFO that facilitates clock domain crossing between the recovered SERDES clock and the local IP core
receive-side 125 MHz clock.
Static CTC FIFO Low Threshold
When RX CTC Static mode is chosen, this parameter specifies FIFO low (almost empty) threshold.
IPUG60_02.1, April 2014
17
SGMII and Gb Ethernet PCS IP Core User’s Guide
Parameter Settings
Static CTC FIFO High Threshold
When RX CTC Static mode is chosen, this parameter specifies FIFO high (almost full) threshold
Guidelines for Calculating Static CTC FIFO Thresholds
The FIFO thresholds directly affect the compensation capability of the CTC circuit. The thresholds should be set to
accommodate the transmission characteristics of the system into which the IP core is used. The critical system
characteristics for setting the FIFO thresholds are maximum ppm offset, maximum frame size, and (G)MII data
rate. The following procedure can be used to calculate the Static CTC FIFO thresholds.
1. Calculate the maximum clock slip between maximum-sized frames, rounded up to the nearest integer,
2N
M = ----------- 10 – 3
R
where:
• N = maximum ethernet frame size (bytes)
•
= maximum ppm offset (e.g. 100 for +/- 100 ppm offset; 200 for +/- 200 ppm offset, etc.)
• R = (G)MII data rate (e.g. 1000 for 1Gbps, 100 for 100 Mbps, 10 for 10Mbps)
2. Calculate the low FIFO threshold. Note this equation computes the minimum required threshold. However,
using a larger value will provide additional design margin.
THRESHOLD LOW = M + 2
3. Calculate the high FIFO threshold. Note this equation computes the minimum required threshold. However,
using a larger value will provide additional design margin..
THRESHOLD HIGH = THRESHOLD LOW + 10
4. Calculate the minimum acceptable FIFO full level. This value must be less than 1024 -- the maximum space
allocated for the FIFO. If the computed full level is greater than 1024, then the static CTC will not meet the specified design constraints..
THRESHOLD FULL = THRESHOLD HIGH + M + 2
Table 3-2 provides minimum CTC static threshold calculations for six different system specifications.
Table 3-2. Minimum CTC Static Threshold Calculations
M
100
100
100
100
100
100
Max ppm Offset (+/-)
1500
1500
1500
9600
9600
9600
Max Frame Size (bytes)
1000
100
10
1000
100
10
(G)MII Data Rate (Mbps)
1
3
30
2
20
193
ThresholdLOW
3
5
32
4
22
195
ThresholdHIGH
13
15
42
14
32
205
ThresholdFULL
16
20
74
18
54
400
IPUG60_02.1, April 2014
18
SGMII and Gb Ethernet PCS IP Core User’s Guide
Chapter 4:
IP Core Generation
IP Core Generation in IPexpress
This chapter provides information on how to generate the Lattice SGMII IP core using the IPexpress tool in the Diamond software, and how to include the core in a top-level design.
Licensing the IP Core
An IP core- and device-specific license is required to enable full, unrestricted use of the SGMII IP core in a complete, top-level design. Instructions on how to obtain licenses for Lattice IP cores are given at:
http://www.latticesemi.com/products/intellectualproperty/aboutip/isplevercoreonlinepurchas.cfm
Users may download and generate the SGMII IP core and fully evaluate the core through functional simulation and
implementation (synthesis, map, place and route) without an IP license. The SGMII IP core also supports Lattice’s
IP hardware evaluation capability, which makes it possible to create versions of the IP core that operate in hardware for a limited time (approximately four hours) without requiring an IP license. See “Hardware Evaluation” on
page 26 for further details. However, a license is required to enable timing simulation, to open the design in the Diamond EPIC tool, and to generate bitstreams that do not include the hardware evaluation timeout limitation.
Getting Started
The SGMII and Gb Ethernet PCS IP core is available for download from the Lattice IP server using the IPexpress
tool. The IP files are automatically installed using ispUPDATE technology in any customer-specified directory. After
the IP core has been installed, the IP core will be available in the IPexpress GUI dialog box shown in Figure 4-1.
The IPexpress tool GUI dialog box for the SGMII and Gb Ethernet PCS IP core is shown in Figure 4-1. To generate
a specific IP core configuration the user specifies:
• Project Path – Path to the directory where the generated IP files will be located.
• File Name – “username” designation given to the generated IP core and corresponding folders and files.
• Module Output – Verilog or VHDL.
• Device Family – Device family to which IP is to be targeted (e.g. LatticeECP3, ECP5, etc.). Only families that
support the particular IP core are listed.
• Part Name – Specific targeted part within the selected device family.
IPUG60_02.1, April 2014
19
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
Figure 4-1. IPexpress Dialog Box (Diamond Version)
Note that if the IPexpress tool is called from within an existing project, Project Path, Module Output, Device Family
and Part Name default to the specified project parameters. Refer to the IPexpress tool online help for further information.
To create a custom configuration:
1. Click the Customize button in the IPexpress tool dialog box to display the SGMII IP core Configuration GUI, as
shown in Figure 4-2.
2. Select the IP parameter options specific to your application. Refer to “Parameter Settings” on page 17 for more
information on the SGMII and Gb Ethernet PCS IP core parameter settings.
IPUG60_02.1, April 2014
20
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
Figure 4-2. Configuration Dialog Box (Diamond Version)
IPUG60_02.1, April 2014
21
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
IPexpress-Created Files and Top Level Directory Structure
When the user clicks the Generate button, the IP core and supporting files are generated in the specified “Project
Path” directory. The directory structure of the generated files is shown in Figure 4-3.
Figure 4-3. SGMII and Gb Ethernet PCS IP Core Generated Directory Structure
The design flow for IP created with the IPexpress tool uses a post-synthesized module (NGO) for synthesis and a
protected model for simulation. The post-synthesized module is customized and created during the IPexpress tool
generation.
Table 4-1 provides a list of key files created by the IPexpress tool. The names of most of the created files are customized to the user’s module name specified in the IPexpress tool. The files shown in Table 4-1 are all of the files
necessary to implement and verify the SGMII and Gb Ethernet PCS IP core in a top-level design.
Table 4-1. File List
File
Description
_inst.v
This file provides an instance template for the IP.
_bb.v
This file provides the synthesis black box for the user’s synthesis.
_beh.v
This file provides a behavioral simulation model for the IP core.
.ngo
This file provides the synthesized IP core.
.lpc
This file contains the IPexpress tool options used to recreate or modify the core in the IPexpress tool.
IPUG60_02.1, April 2014
22
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
Table 4-1. File List (Continued)
File
Description
.ipx
IPexpress package file (Diamond only). This is a container that holds references to all of the
elements of the generated IP core required to support simulation, synthesis and implementation. The IP core may be included in a user's design by importing this file to the associated
Diamond project.
pmi_*.ngo
One or more files implementing synthesized memory modules used in the IP core.
The following additional files providing IP core generation status information are also generated in the “Project
Path” directory:
• _generate.log – IPexpress synthesis and EDIF2NGD log file.
• _gen.log – IPexpress IP generation log file.
The \ and subtending directories shown in Figure 4-3 provide files supporting SGMII and Gb
Ethernet PCS core evaluation. The \ directory contains files/folders with content that is constant for all configurations of the SGMII and Gb Ethernet PCS. The \ subfolder (\sgmii_core0 in
this example) contains files/folders with content specific to the username configuration.
The \sgmii_pcs_eval directory is created by IPexpress the first time the core is generated and updated each
time the core is regenerated. A \ directory is created by IPexpress each time the core is generated
and regenerated each time the core with the same file name is regenerated. A separate \ directory is
generated for cores with different names, e.g. \, \, etc.
Instantiating the Core
The generated SGMII and Gb Ethernet PCS IP core package includes black box (_bb.v) and instance
(_inst.v) templates that can be used to instantiate the core in a top-level design. Two example RTL
top-level reference source files are provided in
\\sgmii_pcs_eval\\src\rtl\top\.
The top-level file top_smi.v (top_hb.v when TSMAC Easy Connect mode is chosen) implements the SGMII-to(G)MII reference design described in “SGMII-to-(G)MII Reference Design” on page 33. Verilog source files associated with the reference design are located in the following directory:
\\sgmii_pcs_eval\\src\rtl\template\.
The top-level file top_pcs_core_only.v supports the ability to implement just the SGMII and Gb Ethernet PCS core
by itself. This design is intended only to provide an indication of the device utilization associated with the SGMII
and Gb Ethernet PCS IP core; and it should not be used as useful example of a design application.
Using the SERDES with the SGMII IP Core
Note that most applications for the SGMII IP core require use of the FPGA SERDES block. The reference design
(see “SGMII-to-(G)MII Reference Design” on page 33) demonstrates how the SERDES is used with the SGMII IP
core. However, note that the reference design only demonstrates one implementation – a single SERDES,
assigned to channel 0. If your application requires a different SERDES configuration, for example utilizing a different channel number, or utilizing multiple channels, then you cannot use the SERDES module provided in the reference design. Instead, you must generate an appropriate SERDES module with the configuration settings required
for your application. The SERDES module can be generated using IPexpress. Please see TN1176, LatticeECP3
SERDES/PCS Usage Guide for details about configuring the SERDES.
IPUG60_02.1, April 2014
23
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
The following are a few key SERDES settings that must be chosen for SGMII applications:
• ECP5:
– Channel Protocol: SGMII
– CTC block: DISABLED (Default is DISABLED)
• LatticeECP3:
– Channel Protocol: SGMII
– CTC block: DISABLED (Default is DISABLED)
*IPexpress only allows the default CTC settings to be chosen. You must manually alter these defaults CTC settings by altering
the SERDES auto-config file generated by IPexpress. For example, with LatticeECP2M, open the auto-config file with a text editor. Search for a line containing the CTC setting (e.g. CH0_CTC_BYP). Change the word "NORMAL" to the word "BYPASS".
Using CTC with the SGMII IP Core
Note that both the SERDES and the SGMII IP core have clock tolerance compensation (CTC) circuits. So there
may be some confusion about which CTC circuit should be used with the IP core. Lattice recommends that the
SERDES CTC should be turned-off, and the SGMII IP core CTC should be turned-on. Designers should not
choose the case where both the SERDES CTC and the IP core CTC are turned-on at the same time; unpredictable
behavior may result.
The enable/disable CTC circuit settings are specified through the IPexpress tool when the SERDES and/or SGMII
IP core are generated.
There may be some cases where the designer chooses to disable the CTC within the IP core (SGMII CTC mode =
“none”). This mode was intended for use in synchronous systems, where the SERDES recovered clock and the
local RX clock have no ppm offset. The CTC of the SERDES should also be disabled for such systems. This configuration will provide reliable operation between the SERDES and IP core.
However, there may be cases where the designer chooses to disable the IP core CTC circuit within an asynchronous system (where there is a ppm offset between SERDES recovered clock and the local RX clock). In this case
the user may intend to utilize the SERDES CTC. It should be noted that there are some limitations when using the
SERDES CTC with the IP core. For the LatticeSC FPGA family, it is not possible to utilize the SERDES CTC with
the IP core because the SERDES permanently disables the CTC when the Generic 8B10B SERDES mode is
selected. However, it is possible to utilize the SERDES CTC with the IP core within the LatticeECP3 and ECP5
FPGA families. But even in these three FPGA families, there are limitations on how the SERDES CTC may be used
with the IP core. The restriction is associated with auto-negotiation. The SERDES CTC requires that idle-codegroups are occasionally added to the RX data path to maintain proper CTC operation. This happens normally during the inter-packet gaps of normal ethernet frame transmission. However, during auto-negotiation idle-code-group
transmissions are not always present. To overcome this problem, the SERDES CTC provides an input pin (labeled
“xmit_chn” in LatticeECP3 and ECP5 devices). When this pin is driven high, it occasionally inserts idle-codegroups into the RX data path. If the IP core is allowed to run auto-negotiation, then the SERDES “xmit_chn” pin
must be driven “high” throughout most of the auto-negotiation process. After the auto-negotiation process completes, the “xmit_chn” pin should be driven “low.” If auto-negotiation never runs, then the SERDES “xmit_chn” pin
can be driven permanently driven “low.”
For SGMII IP core versions 3.4 and higher, the IP core provides a signal labelled "xmit_autoneg" that can be tied to
the SERDES "xmit_chn" pin to satisfy the required insertion of idle code groups while auto negotiation runs.
For SGMII IP core versions 3.3 and lower, the IP core does not provide a direct signal to drive the “xmit_chn”
SERDES pin. However, the designer can create an appropriate control signal for driving “xmit_chn” by combining
two IP core output signals as shown in Figure 4-4.
IPUG60_02.1, April 2014
24
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
Figure 4-4. Combining Two IP Core Output Signals
mr_an_enable
mr_an_complete
1
xmit_chn
0
Running Functional Simulation
The functional simulation model generated in the “Project Path” root directory (_beh.v) may be instantiated in the user's testbench for evaluation in the context of their design application. Lattice does not provide a testbench for evaluating this IP core in isolation. However, a functional simulation capability is provided in which
_beh.v is instantiated in the SGMII-to-(G)MII reference design described in “SGMII-to-(G)MII Reference Design” on page 33. This FPGA top is instantiated in a testbench provided in
\\sgmii_pcs_eval\testbench.
Users may run the eval simulation by doing the following.
Using Aldec Active-HDL:
1. Open Active-HDL.
2. Under the Tools tab, select Execute Macro.
3. Browse to folder \\sgmii_pcs_eval\\sim\aldec and execute one of the
"do" scripts shown.
Using Mentor Graphics ModelSim
1. Open ModelSim.
2. Under the File tab, select Change Directory and choose the folder
\sgmii_pcs_eval\\sim\modelsim.
3. Under the Tools tab, select Execute Macro and execute the ModelSim “do” script shown.
The simulation waveform results will be displayed in the ModelSim Wave window.
Synthesizing and Implementing the Core in a Top-Level Design
The SGMII and Gb Ethernet PCS IP core itself is synthesized and provided in NGO format when the core is generated through IPexpress. You may combine the core in your own top-level design by instantiating the core in your
top-level file as described above in the “Instantiating the Core” section and then synthesizing the entire design with
either Synplify or Precision RTL Synthesis.
The following text describes the evaluation implementation flow for Windows platforms. The flow for Linux and
UNIX platforms is described in the Readme file included with the IP core.
As described previously, the top-level file top_pcs_core_only.v provided in
\\sgmii_pcs_eval\\src\rtl\top supports the ability to implement the
SGMII and Gb Ethernet PCS core in isolation. Push-button implementation of this top level design is supported via
the project file _core_only_eval.ldf located in
\\sgmii_pcs_eval\\impl.
IPUG60_02.1, April 2014
25
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
To use this project file in Diamond:
1. Choose File > Open > Project.
2. Browse to
\\sgmii_pcs_eval\\impl\core_only\synplify (or precision) in
the Open Project dialog box.
3. Select and open _core_only_eval.ldf. At this point, all of the files needed to support top-level synthesis and implementation will be imported to the project.
4. Select the Process tab in the left-hand GUI window.
5. Implement the complete design via the standard Diamond GUI flow.
Push-button implementation is also supported for the SGMII-to-(G)MII reference design specified by the top-level
file top_smi.v described previously. This capability is supported via the Diamond project file located in
\\sgmii_pcs_eval\\impl\reference\synplify. The flow for implementing
the reference design is equivalent to the flow for implementing the core-only design described above.
Hardware Evaluation
The SGMII and Gb Ethernet PCS IP core supports Lattice’s IP hardware evaluation capability, which makes it possible to create versions of the IP core that operate in hardware for a limited period of time (approximately four
hours) without requiring the purchase of an IP license. It may also be used to evaluate the core in hardware in userdefined designs.
Enabling Hardware Evaluation in Diamond
Choose Project > Active Strategy > Translate Design Settings. The hardware evaluation capability may be
enabled/disabled in the Strategy dialog box. It is enabled by default.
Updating/Regenerating the IP Core
By regenerating an IP core with the IPexpress tool, you can modify any of its settings including: device type, design
entry method, and any of the options specific to the IP core. Regenerating can be done to modify an existing IP
core or to create a new but similar one.
Regenerating an IP Core in Diamond
To regenerate an IP core in Diamond:
1. In IPexpress, click the Regenerate button.
2. In the Regenerate view of IPexpress, choose the IPX source file of the module or IP you wish to regenerate.
3. IPexpress shows the current settings for the module or IP in the Source box. Make your new settings in the Target box.
4. If you want to generate a new set of files in a new location, set the new location in the IPX Target File box. The
base of the file name will be the base of all the new file names. The IPX Target File must end with an .ipx extension.
5. Click Regenerate. The module’s dialog box opens showing the current option settings.
6. In the dialog box, choose the desired options. To get information about the options, click Help. Also, check the
About tab in IPexpress for links to technical notes and user guides. IP may come with additional information. As
the options change, the schematic diagram of the module changes to show the I/O and the device resources
the module will need.
IPUG60_02.1, April 2014
26
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
7. To import the module into your project, if it’s not already there, select Import IPX to Diamond Project (not
available in stand-alone mode).
8. Click Generate.
9. Check the Generate Log tab to check for warnings and error messages.
10.Click Close.
The IPexpress package file (.ipx) supported by Diamond holds references to all of the elements of the generated IP
core required to support simulation, synthesis and implementation. The IP core may be included in a user's design
by importing the .ipx file to the associated Diamond project. To change the option settings of a module or IP that is
already in a design project, double-click the module’s .ipx file in the File List view. This opens IPexpress and the
module’s dialog box showing the current option settings. Then go to step 6 above.
IP Core Generation in Clarity Designer
Getting Started
The first step in generating an IP Core in Clarity Designer is to start a project in Diamond software with the ECP5
device. Clicking the Clarity Designer button opens the Clarity Designer tool.
Figure 4-5. Starting a Project in Clarity Designer
To generate a specific IP core configuration the user specifies:
• Instance Path – Path to the directory where the generated IP files will be located.
• Instance Name – “username” designation given to the generated IP core and corresponding folders and files.
• Module Output – Verilog or VHDL.
• Device Family – Device family to which IP is to be targeted.
• Part Name – Specific targeted part within the selected device family.
Note that because the Clarity Designer tool must be called from within an existing project, Project Path, Module
Output, Device Family and Part Name default to the specified project parameters. Refer to the IPexpress tool online
help for further information.
IPUG60_02.1, April 2014
27
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
To create a custom configuration:
1. Click the Customize button in the Clarity Designer dialog box to display the SGMII IP core Configuration GUI,
as shown in Figure 4-2.
2. Select the IP parameter options specific to your application. Refer to “Parameter Settings” on page 17 for more
information on the SGMII IP core parameter settings.
3. After setting the parameters, click Customize.
4. A dialog box, shown in Figure 4-6, displays logs, errors and warnings. Click Close.
Figure 4-6. Clarity Designer Generate Log Tab
5. The Clarity Designer Builder tab, shown in Figure 4-7, opens.
Figure 4-7. Clarity Designer Builder Tab
IPUG60_02.1, April 2014
28
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
Clarity Designer Created Files and Top Level Directory Structure
The directory structure of the generated files is shown in Figure 4-8.
Figure 4-8. ECP5 SGMII IP Core Directory Structure
The design flow for IP created with the Clarity Designer tool uses post-synthesized modules (NGO) for synthesis
and a protected model for simulation. The post-synthesized module are customized and created during the Clarity
Designer tool generation.
Table 4-2 provides a list of key files and directories created by the Clarity Designer tool and how they are used. The
Clarity Designer tool creates several files that are used throughout the design cycle. The names of most of the created files are customized to the user’s module name specified in the Clarity Designer tool.
Table 4-2. File List
File
Description
.v
This file provides the IP core wrapper.
_inst.v
This file provides an instance template for the IP.
_bb.v
This file provides the synthesis black box for the user’s synthesis.
_beh.v
This file provides a behavioral simulation model for the IP core.
_core.ngo
This file provides the synthesized IP core.
_pcs.ngo
This file provides the synthesized PCS logic.
.lpc
This file contains the IPexpress tool options used to recreate or modify the core in the IPexpress tool.
.ipx
IPexpress package file (Diamond only). This is a container that holds references to all of the
elements of the generated IP core required to support simulation, synthesis and implementation. The IP core may be included in a user's design by importing this file to the associated Diamond project.
pmi_*.ngo
One or more files implementing synthesized memory modules used in the IP core.
IPUG60_02.1, April 2014
29
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
The following additional files, which provides IP core generation status information, are also generated in the Project Path directory:
• _generate.log – Clarity synthesis and EDIF2NGD log file.
• _gen.log – Clarity IP generation log file.
Simulation Evaluation
Please refer to “Simulation Evaluation” on page 30 for details.
IP Core Implementation
After completing the Configuration step, perform the procedure below. Please refer to Figure 4-10.
1. Click the Planner tab.
Figure 4-9. Planner Tab in Clarity Designer
2. Expand the configured IP instance to Lane level.
3. Drag the lanes of the IP to the DCU channel(s).
4. Click the Generate button to create the Clarity Designer (.sbx) file.
Clarity Designer (.sbx) files can be used in design projects such as an HDL file or an IPexpress generated (.ipx)
file. A key difference between IPexpress generated files and Clarity Designer generated files is that the latter may
contain not only a single block but multiple modules or IP blocks and may represent a subsystem. In IPexpress, the
process generates a single module or IP. This is a one step process since an IPexpress file can only contain one
module or IP. In Clarity Designer, saving a file is a separate step. Modules or IP are configured and multiple modules or IP can optionally be added within the same file. Additionally, since building and planning can also be done,
saving the file and generating the blocks may be performed later.
After the Generate step is completed, the “.sbx” file is automatically added to current Diamond Project Input Files
list as shown in Figure 4-10.
IPUG60_02.1, April 2014
30
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
Figure 4-10. File List in Report Dialog Box
After this step, click Process at the bottom of window, then double-click Place & Route Design to Start PAR. This
is similar to a standard Diamond PAR flow.
Regenerating/Recreating the IP Core
By regenerating an IP core with the Clarity Designer tool, you can modify any of the options specific to an existing
IP instance. By recreating an IP core with Clarity Designer tool, you can create (and modify if needed) a new IP
instance with an existing LPC/IPX configuration file.
Regenerating an IP Core in Clarity Designer Tool
To regenerate an IP core in Clarity Designer:
1. In the Clarity Designer Builder tab, right-click on the existing IP instance and choose Config.
2. In the module dialog box, choose the desired options.
For more information about the options, click Help. You may also click the About tab in the Clarity Designer window for links to technical notes and user guides. The IP may come with additional information.
As the options change, the schematic diagram of the module changes to show the I/O and the device resources
the module needs.
3. Click Configure.
IPUG60_02.1, April 2014
31
SGMII and Gb Ethernet PCS IP Core User’s Guide
IP Core Generation
Recreating an IP Core in Clarity Designer Tool
To recreate an IP core in Clarity Designer:
1. In Clarity Designer click the Catalog tab.
2. Click the Import IP tab (at the bottom of the view).
3. Click Browse.
4. In the Open IPX File dialog box, browse to the .ipx or .lpc file of the module. Use the .ipx if it is available.
5. Click Open.
6. Type in a name for Target Instance. Note that this instance name should not be the same as any of the existing
IP instances in the current Clarity Designer project.
7. Click Import. The module's dialog box opens.
8. In the dialog box, choose desired options.
For more information about the options, click Help. You may also check the About tab in the Clarity Designer
window for links to technical notes and user guides. The IP may come with additional information.
As the options change, the schematic diagram of the module changes to show the ports and the device
resources the module needs.
9. Click Configure.
IPUG60_02.1, April 2014
32
SGMII and Gb Ethernet PCS IP Core User’s Guide
Chapter 5:
Application Support
This chapter provides application support information for the SGMII and Gb Ethernet PCS IP Core.
SGMII-to-(G)MII Reference Design
This section describes the operation of an SGMII-to-(G)MII bridge, using Lattice's SGMII and Gb Ethernet PCS IP
Core. This bridge demonstrates how the IP core can be used in a bridging application and as a starting point for
developing your own custom bridge design.
Features
• Tri-Speed (G)MII Interface operating at 10 Mbs, 100 Mbs, or 1G bps
• Differential, CML, SGMII Port operating at 1.25 Gbps
• Pin selectable SGMII MAC/PHY mode
• Dynamically switchable SGMII/1000BaseX PCS mode
• Management registers accessible through MDIO
Detailed Description
The block diagram of the SGMII-to-(G)MII Bridge is shown in Figure 5-1.
Figure 5-1. Bridge with SMII Control Interface
GbE
Mode
125Mhz
Ref Clk
MAC / PHY
Mode
Quad/Dual
PCS/SERDES
(G)MII
Input
Logic
Tx
Rate
Adaption
Tx
State
Machine
8B10B
Encoder
SGMII and Gb
Ethernet PCS
IP Core
AutoNeg
State
Machine
(G)MI
(G)MII
Output
Logic
Rx
Rate
Adaption
Rx
State
Machine
Sync
State
Machine
Rx CTC
Serializer
8BI
SGMII
8B10B
Decoder De-Serializer
Link State Machine
Rate
Resolution
MDIO
IPUG60_02.1, April 2014
Management
Interface
Control
Registers
33
SGMII and Gb Ethernet PCS IP Core User’s Guide
Application Support
The SGMII and Gb Ethernet PCS IP Core
The IP core performs the data channel encoding/decoding, auto-negotiation, and rate adaptation functions
described earlier in the main section of this document.
PCS/SERDES
This block is an embedded circuit function within the FPGA architecture. It provides this application with a
1.25Gbps SERDES function, and 8B10B data encoder/decoder functions.
Rate Resolution
This block is used to drive the operational_rate port of the IP core, thereby controlling the data flow rate of the rate
adaptation blocks within the IP core. Operational_Rate is a 2-bit vector, where 10=1 Gbps; 01=100 Mbps;
00=10 Mbps. Table 5-1 shows how rates are resolved by this circuit block.
Table 5-1. Rate Resolution Function
GBE Mode
0=SGMII PCS
1=1000BaseX PCS
SGMII Mode
0=MAC 1=PHY
Auto
Negotiation
Enable
IP Core’s
Advertised
Rate (sent)
IP Core’s
Link Partner
Rate (recv)
Rate when
AutoNeg
Disabled
Rate
Resolution
Output
x
x
0
x
x
DIS[1:0]
DIS[1:0]
0
0
1
x
LP[1:0]
LP[1:0]
0
1
1
AR[1:0]
x
AR[1:0]
1
x
x
x
x
‘10’
(1 Gbps)
Control Registers
The control register block contains five of the management registers specified in IEEE 802.3, Clause 37 – Control,
Status, Auto Negotiation Advertisement, Link Partner Ability, Auto Negotiation Expansion, and Extended Status.
Note that the register set implementation varies, dependent upon which (G)MII interface style is used to generate
the IP core within ipExpress. For the classic-GMII style, the register set is read/written through a serial management interface (SMI) or MDIO as specified in IEEE 802.3, Clause 22. For the TSMAC-Easy-Connect GMII style, the
register set is read/written through the parallel Host-Bus interface – the same parallel interface that the Lattice
TSMAC uses to access TSMAC IP core registers.
The register map addresses and register descriptions for both implementation styles are shown below.
Table 5-2. Register Map for SMI Registers
IPUG60_02.1, April 2014
Address
Mode
0x0
R/W
Control Register
Register Name
0x1
R
Status Register
0x4
R/W
Advertised Ability
0x5
R
Link Partner Ability
0x6
R
Auto Negotiation Expansion Register
0xF
R
Extended Status Register
34
SGMII and Gb Ethernet PCS IP Core User’s Guide
Application Support
Table 5-3. Description of Control Register (Address 0x0 - SMI)
Data Bit
Name
Mode
Description
15
Reset
R/W
1=Reset (self clearing)
0=normal
14
Loopback
R/W
1=Loopback
0= normal
Combined with bit D6 to form 2-bit vector
Speed Selection [1:0] = 11 = reserved
Speed Selection [1:0] = 10 = 1Gbps
Speed Selection [1:0] = 01 = 100Mbps
Speed Selection [1:0] = 00 = 10Mbps
13
Speed Selection[0]
R/W or
Stuck-at-0
In GbE Mode, Speed Selection [1:0] is stuck at “10” = 1Gbps.
In SGMII Mode, the Speed Selection[1:0] bits can be written to any value.
However, the specified speed only affects the (G)MII data rate when autonegotiation is disabled. Otherwise, these control bits have no effect. The
control of (G)MII data rate when auto-negotiation is enabled is managed by
bits [11:10] of the advertised ability vector.
12
Auto Neg Enable
R/W
1=Enable, 0=Disable
11
Power Down
R/W
1=Power Down, 0=Power Up
10
Isolate
R/W
1=Isolate, 0=Normal
9
Restart Auto Neg
R/W
1=Restart (self clearing), 0=Normal
1=Full Duplex, 0=Half Duplex
Note that the setting of this bit has no effect on the operation of the PCS
channel. The PCS channel is always a 4-wire interface with separate TX
and RX data paths.
8
Duplex Mode
R/W
7
Collision Test
Stuck-at-0
1=Enable Test, 0=Normal
6
Speed Selection[1]
R/W or
Stuck-at-1
Combined with bit D13 to form the 2-bit vector Speed Selection [1:0]
5
Unidirectional
4
reserved
Stuck-at-0
R/W
1=Unidirectional, 0=Normal
3
reserved
Stuck-at-0
2
reserved
Stuck-at-0
1
reserved
Stuck-at-0
0
reserved
Stuck-at-0
Table 5-4. Description of Status Register (Address 0x1 - SMI)
Data Bit
Name
Mode
Description
15
100BASE-T4
Stuck-at-0
0=not supported
14
100BASE-X Full Duplex
Stuck-at-0
0=not supported
13
100BASE-X Half Duplex
Stuck-at-0
0=not supported
12
10 Mbps Full Duplex
Stuck-at-0
0=not supported
11
10 Mbps Half Duplex
Stuck-at-0
0=not supported
10
100BASE-T2 Full Duplex
Stuck-at-0
0=not supported
9
100BASE-T2 Half Duplex
Stuck-at-0
0=not supported
8
Extended Status
Stuck-at-1
1=supported
7
Unidirectional Capability
R
1=supported, 0=not supported
6
MF Preamble Suppress
Stuck-at-0
0=not supported
5
Auto Neg Complete
R
1=complete, 0=not complete
4
Remote Fault
Stuck-at-0
0=not supported
3
Auto Neg Ability
Stuck-at-1
1=supported
2
Link Status
R
1=Link Up, 0=Link Down (Latch-on-zero, Clear-on-read)
IPUG60_02.1, April 2014
35
SGMII and Gb Ethernet PCS IP Core User’s Guide
Application Support
Data Bit
Name
Mode
Description
1
Jabber Detect
Stuck-at-0
0=not supported
0
Extended Capability
Stuck-at-0
0=not supported
Table 5-5. Description of Advertised Ability Register (Address 0x4 - SMI)
PCS=GbE
Data Bit
Mode
Name
PCS=SGMII-PHY-Side
PCS=SGMII-MAC-Side
Mode
Name
Mode
Name
15
R/W
Next Page
R/W
Link Status
R
0
14
R/W
Acknowledge
R/W
Acknowledge
R
1
13
R/W
Remote Fault[1]
R/W
0
R
0
12
R/W
Remote Fault[0]
R/W
Duplex Mode
R
0
11
R/W
0
R/W
Speed[1]
R
0
10
R/W
0
R/W
Speed[0]
R
0
9
R/W
Pause[1]
R/W
0
R
0
8
R/W
Pause[0]
R/W
0
R
0
7
R/W
Half Duplex
R/W
0
R
0
6
R/W
Full Duplex
R/W
0
R
0
5
R/W
0
R/W
0
R
0
4
R/W
0
R/W
0
R
0
3
R/W
0
R/W
0
R
0
2
R/W
0
R/W
0
R
0
1
R/W
0
R/W
0
R
0
0
R/W
0
R/W
1
R
1
Table 5-6. Description of Link Partner Ability Register (Address 0x5 - SMI)
PCS=GbE
Data Bit
Mode
PCS=SGMII
Name
Mode
Name
15
R
Next Page
R
Link Status
14
R
Acknowledge
R
Acknowledge
13
R
Remote Fault[1]
R
0
12
R
Remote Fault[0]
R
Duplex Mode
11
R
0
R
Speed[1]
10
R
0
R
Speed[0]
9
R
Pause[1]
R
0
8
R
Pause[0]
R
0
7
R
Half Duplex
R
0
6
R
Full Duplex
R
0
5
R
0
R
0
4
R
0
R
0
3
R
0
R
0
2
R
0
R
0
1
R
0
R
0
0
R
0
R
1
IPUG60_02.1, April 2014
36
SGMII and Gb Ethernet PCS IP Core User’s Guide
Application Support
Table 5-7. Description of Auto Negotiation Expansion Register (Address 0x6 - SMI)
Data Bit
15:3
Name
Mode
Description
Reserved
Stuck-at-0
Reserved
2
Next Page Able
Stuck-at-0
0=not supported
1
Page Received
R
0
Reserved
1=received, 0=not received
latch on 1, clear on read
Stuck-at-0
Reserved
Table 5-8. Description of Extended Status Register (Address 0xF - SMI)
Data Bit
Name
Mode
Description
15
1000BASE-X Full Duplex
Stuck-at-1
1 = Supported
14
1000BASE-X Half Duplex
Stuck-at-0
0 = Not supported
13
1000BASE-T Full Duplex
Stuck-at-0
0 = Not supported
12
11:0
1000BASE-T Half Duplex
Stuck-at-0
0 = Not supported
Reserved
Stuck-at-0
Reserved
Table 5-9. Register Map for Host Bus Registers
Address
Mode
0x0
R/W
Control Register - Low
Register Name
0x1
R/W
Control Register - High
0x2
R
Status Register - Low
0x3
R
0x8
R/W
Advertised Ability - Low
Status Register - High
0x9
R/W
Advertised Ability - High
0xA
R
Link Partner Ability - Low
0xB
R
Link Partner Ability - High
0xC
R
Auto Negotiation Expansion Register - Low
0xD
R
Auto Negotiation Expansion Register - High
0x1E
R
Extended Status Register - Low
0x1F
R
Extended Status Register - High
IPUG60_02.1, April 2014
37
SGMII and Gb Ethernet PCS IP Core User’s Guide
Application Support
Table 5-10. Description of Control Register
Data Bit
Name
Mode
Description
Control Register High, Address 0x1 - Host Bus
7
Reset
R/W
6
Loopback
R/W
1 = Reset (self clearing), 0 = Normal
1 = Loopback, 0 = Normal
Combined with bit D6 in Control Register Low to form a 2-bit vector:
5
R/W
or Stuck-at-0
Speed Selection[0]
Speed Selection [1:0] = 11 = Reserved
Speed Selection [1:0] = 10 = 1Gbps
Speed Selection [1:0] = 01 = 100Mbps
Speed Selection [1:0] = 00 = 10Mbps
In GbE Mode, Speed Selection [1:0] is stuck at “10” = 1Gbps
In SGMII Mode, the Speed Selection[1:0] bits can be written to any
value. However, the specified speed only affects the (G)MII data rate
when auto-negotiation is disabled. Otherwise, these control bits have
no effect. The control of (G)MII data rate when auto-negotiation is
enabled is managed by bits [11:10] of the advertised ability vector.
4
Auto Neg Enable
R/W
1=Enable, 0=Disable
3
Power Down
R/W
1=Power Down, 0=Power Up
2
Isolate
R/W
1=Isolate, 0=Normal
1
Restart Auto Neg
R/W
1=Restart (self clearing), 0=Normal
1=Full Duplex, 0=Half Duplex
0
Duplex Mode
Control Register Low
Note that the setting of this bit has no effect on the operation of the
PCS channel. The PCS channel is always a 4-wire interface with separate TX and RX data paths.
R/W
Address 0x0 - Host Bus
7
Collision Test
Stuck-at-0
6
Speed Selection[1]
R/W
or Stuck-at-1
5
Unidirectional
4
Reserved
Stuck-at-0
R/W
3
Reserved
Stuck-at-0
2
Reserved
Stuck-at-0
1
Reserved
Stuck-at-0
0
Reserved
Stuck-at-0
1=Enable Test
0=Normal
Combined with bit D5 in Control Register High to form the 2-bit vector
Speed Selection [1:0]
1=Unidirectional, 0=Normal
Table 5-11. Description of Status Register
Data Bit
Name
Status Register High
7
100BASE-T4
6
5
Mode
Description
Address 0x3 - Host Bus
Stuck-at-0
0=not supported
100BASE-X Full Duplex
Stuck-at-0
0=not supported
100BASE-X Half Duplex
Stuck-at-0
0=not supported
4
10 Mbps Full Duplex
Stuck-at-0
0=not supported
3
10 Mbps Half Duplex
Stuck-at-0
0=not supported
2
100BASE-T2 Full Duplex
Stuck-at-0
0=not supported
1
100BASE-T2 Half Duplex
Stuck-at-0
0=not supported
0
Extended Status
Stuck-at-1
1=supported
Status Register Low
7
Address 0x2 - Host Bus
Unidirectional Capability
IPUG60_02.1, April 2014
R
1=supported, 0=not supported
38
SGMII and Gb Ethernet PCS IP Core User’s Guide
Application Support
Data Bit
Name
Mode
Description
6
MF Preamble Suppress
Stuck-at-0
0=not supported
5
Auto Neg Complete
R
1=complete, 0=not complete
4
Remote Fault
Stuck-at-0
0=not supported
3
Auto Neg Ability
Stuck-at-1
1=supported
2
Link Status
R
1=Link Up, 0=Link Down Latch-on-zero Clear-on-read
1
Jabber Detect
Stuck-at-0
0=not supported
0
Extended Capability
Stuck-at-0
0=not supported
Table 5-12. Description of Advertised Ability Register
PCS=GbE
Data Bit
Mode
PCS=SGMII-PHY-Side
Name
Mode
PCS=SGMII-MAC-Side
Name
Mode
Name
Advertised Ability Register High, Address 0x9 - Host Bus
7
R/W
Next Page
R/W
Link Status
R
0
6
R/W
Acknowledge
R/W
Acknowledge
R
1
5
R/W
Remote Fault[1]
R/W
0
R
0
4
R/W
Remote Fault[0]
R/W
Duplex Mode
R
0
3
R/W
0
R/W
Speed[1]
R
0
2
R/W
0
R/W
Speed[0]
R
0
1
R/W
Pause[1]
R/W
0
R
0
0
R/W
Pause[0]
R/W
0
R
0
R/W
0
R
0
Advertised Ability Register Low, Address 0x8 - Host Bus
7
R/W
Half Duplex
6
R/W
Full Duplex
R/W
0
R
0
5
R/W
0
R/W
0
R
0
4
R/W
0
R/W
0
R
0
3
R/W
0
R/W
0
R
0
2
R/W
0
R/W
0
R
0
1
R/W
0
R/W
0
R
0
0
R/W
0
R/W
1
R
1
Table 5-13. Description of Link Partner Ability Register
PCS=GbE
Data Bit
Mode
PCS=SGMII
Name
Mode
Name
Link Partner Ability Register High, Address 0xB - Host Bus
7
R
Next Page
R
Link Status
6
R
Acknowledge
R
Acknowledge
5
R
Remote Fault[1]
R
0
4
R
Remote Fault[0]
R
Duplex Mode
3
R
0
R
Speed[1]
2
R
0
R
Speed[0]
1
R
Pause[1]
R
0
0
R
Pause[0]
R
0
Link Partner Ability Register Low, Address 0xA - Host Bus
7
R
Half Duplex
R
0
6
R
Full Duplex
R
0
IPUG60_02.1, April 2014
39
SGMII and Gb Ethernet PCS IP Core User’s Guide
Application Support
PCS=GbE
PCS=SGMII
Data Bit
Mode
Name
Mode
Name
5
R
0
R
0
4
R
0
R
0
3
R
0
R
0
2
R
0
R
0
1
R
0
R
0
0
R
0
R
1
Table 5-14. Description of Auto Negotiation Expansion Register
Data Bit
Name
Mode
Description
Auto Negotiation Expansion Register High, Address 0xD - Host Bus
7:0
Reserved
Stuck-at-0
Reserved
Auto Negotiation Expansion Register High, Address 0xC - Host Bus
7:3
Reserved
Stuck-at-0
Reserved
2
Next Page Able
Stuck-at-0
0=not supported
1
Page Received
R
0
Reserved
1=received, 0=not received
Latch on 1, clear on read
Stuck-at-0
Reserved
Table 5-15. Description of Extended Status Register
Data Bit
Name
Mode
Description
Extended Status Register High, Address 0x1F - Host Bus
7
1000BASE-X Full Duplex
Stuck-at-1
1=supported
6
1000BASE-X Half Duplex
Stuck-at-0
0=not supported
5
1000BASE-T Full Duplex
Stuck-at-0
0=not supported
4
3:0
1000BASE-T Half Duplex
Stuck-at-0
0=not supported
Reserved
Stuck-at-0
Reserved
Extended Status Register Low, Address 0x1E - Host Bus
7:0
Reserved
Stuck-at-0
Reserved
(G)MII I/O Logic
The I/O logic consists of I/O flip-flops and buffers for moving (G)MII data into and out of the FPGA.
IPUG60_02.1, April 2014
40
SGMII and Gb Ethernet PCS IP Core User’s Guide
Application Support
Signal Descriptions
Table 5-16 shows a detailed listing of all the reference design I/O signals.
Table 5-16. Input and Output Signals for (G)MII-to-SGMII Bridge
Signal Name
I/O
Description
125MHz Reference Clock Signals
in_clk_ref
In
Inbound Reference Clock - 125MHz clock source for the transmit data path. It is used by the GMII
side of the Tx rate-adapt logic, the tx state machine, the 8b10b encoder, and the SERDES serializer.
out_clk_ref
In
Outbound Reference Clock - 125MHz clock source for the receive data path. It is used by the GMII
side of the Rx rate adapt logic, the Rx state machine, the Sync state machine, 8b10b decoder, and
the SERDES de-serializer.
data_in_mii[7:0]
In
Inbound MII Data - Incoming (G)MII data. It can be either MII data (10 Mbps or 100 Mbps) or GMII
data (1Gbps). When used for MII data, only bits 3:0 are valid. Bits 7:4 should be tied to fixed-state
logic levels. When used for GMII data, all eight bits are valid.
en_in_mii
In
Inbound MII Enable - Active high signal, asserts when incoming data is valid.
err_in_mii
In
Inbound MII Error - Active high signal, used to denote transmission errors and carrier extension on
incoming (G)MII data port.
data_out_mii[7:0]
Out
Outbound MII Data - Outgoing (G)MII data. It can be either MII data (10 Mbps or 100 Mbps) or GMII
data (1Gbps). When used for MII data, only bits 3:0 are valid. Bits 7:4 are always driven to logic-low
levels. When used for GMII data, all eight bits are valid.
dv_out_mii
Out
Outbound MII Data Valid - Active high signal, asserts when outgoing data is valid.
err_out_mii
Out
Outbound MII Error - Active high signal, used to denote transmission errors and carrier extension on
outgoing (G)MII data port.
col_out_mii
Out
Outbound MII Collision Detect - Active high signal, asserts when data valid signals are simultaneously active at the transmit and receive data paths of the GMII port of the Lattice IP core.
crs_out_mii
Out
Outbound MII Carrier Sense Detect - Active high signal, asserts when data valid signal is high at
receive data path of the GMII port of the Lattice IP core.
HDOUTP0
Out
Outbound SGMII(P) Signal - P-sense portion of differential SERDES transmit signal.
HDOUTN0
Out
Outbound SGMII(N) Signal - N-sense portion of differential SERDES transmit signal.
MII Signals
SERDES Signals
HDINP0
In
Inbound SGMII(P) Signal - P-sense portion of differential SERDES receive signal.
HDINN0
In
Inbound SGMII(N) Signal - N-sense portion of differential SERDES receive signal.
Miscellaneous Signals
rst_n
In
Reset Active low global reset
sgmii_mode
In
SGMII Mode - Controls the behavior of the auto-negotiation process when the IP core operates in the
SGMII PCS mode. 0=operates as MAC-side entity 1=operates as PHY-side entity
gbe_mode
In
GbE Mode - Controls IP core’s PCS function. 1 = operates as 1000BaseX PCS. 0 = operates as
SGMII PCS.
Implementation Specific Signals for Classic (G)MII Configuration
MII Clock Signals
in_clk_mii
out_clk_mii
In
In
Inbound MII Clock. MII clock source for the transmit data path. It is used by the MII input logic and
the MII side of the Tx rate adapt logic. The frequency of this clock is dependent on the type of data
driven into the MII data port. For 10Mbps data, the clock frequency is 2.5MHz; for 100Mbps data, the
clock frequency is 25MHz; for 1Gbps data, the clock frequency is 125MHz.
Outbound MII Clock. MII clock source for the receive data path. It is used by the MII output logic and
the MII side of the rx rate adapt logic. The frequency of this clock is dependent on the type of data
driven into the MII data port. For 10Mbps data, the clock frequency is 2.5MHz; for 100Mbps data, the
clock frequency is 25MHz; for 1Gbps data, the clock frequency is 125MHz.
IPUG60_02.1, April 2014
41
SGMII and Gb Ethernet PCS IP Core User’s Guide
Application Support
Table 5-16. Input and Output Signals for (G)MII-to-SGMII Bridge (Continued)
Signal Name
I/O
Description
Management Register Interface Signals
mdc
mdio
port_id[4:0]
In
Management Data Clock. Clock source for the serial management interface. The IEEE 802.3 specification (clause 22) dictates that the maximum frequency for this clock is 2.5 MHz. However, in this
bridge design the clock can be conservatively driven as fast as 50 MHz.
In/Out Management Data Input/Output. Bi-directional signal used to read/write management registers.
In
Port Identification Address. Used to define the binary address of this management node. The value
used here corresponds to the PHY-ADD portion of the management frame format (specified in IEEE
802.3, clause 22).
Implementation Specific Signals TSMAC Easy Connect (G)MII Configuration
MII Clock Signals
In
Inbound Reference Clock – In the TSMAC Easy Connect configuration, there is no separate transmit clock provided for the (G)MII port. Instead, the “in_clk_ref” signal (125 MHz) listed above in this
table is used to clock data and control signals into the transmit (G)MII port.
Out
Inbound Clock Enable Source – This signal is used in combination with the in_clk_ref clock to regulate the flow of transmit (G)MII data. The signal is generated by the transmit rate adaptation block.
This clock enable should be tied to the transmit section of the Lattice MAC that sends transmit Ethernet frames to the SGMII and Gb Ethernet PCS IP core. This clock enable should also be tied to the
clock enable “sink” of the SGMII and Gb Ethernet PCS IP core. This clock enable’s behavior is controlled by the setting of the operational_rate pins of the IP core. For 1Gbps operation, the clock
enable is constantly high. For 100 Mbps operation, the clock enable is high for one-out-of-ten 125
MHz clock cycles. For 10 Mbps operation, the clock enable is high for one-out-of-one-hundred 125
MHz clock cycles.
in_ce_sink
In
Inbound Clock Enable Sink - This signal is used in combination with the in_clk_ref clock to regulate
the flow of transmit (G)MII data. When the in_ce_sink signal is high and the in_clk_ref edge rises,
(G)MII data is sampled.
(out_clk_ref)
In
Outbound Reference Clock - In the TSMAC Easy Connect configuration, there is no separate
receive clock provided for the (G)MII port. Instead, the “out_clk_ref” signal (125 MHz) listed above in
this table is used to clock data and control signals out of the receive (G)MII port.
Out
Outbound Clock Enable Source - This signal is similar to the in_ce_source signal described above,
except that it is used for the receive data path.
In
Outbound Clock Enable Sink - This signal is used in combination with the out_clk_ref clock to regulate the flow of receive (G)MII data. When the out_ce_sink signal is high and the out_clk_ref edge
rises, (G)MII data is launched.
(in_clk_ref)
in_ce_source
out_ce_source
out_ce_sink
Management Interface Signals1
hclk
In
Host Clock. This is the Host Bus clock, and is used to clock the Host Bus interface.
hcs_n
In
Host Chip Select. This is an active low signal used to select management registers for read/write
operations.
hwrite_n
In
Host Write. This active low signal is used to write data to the selected register.
haddr[5:0]
In
Host Address. This addresses one of the management registers.
hdatain[7:0]
In
Host Data Input. The CPU writes to the management registers through this data bus.
hdataout[7:0]
Out
Host Data Output. The CPU reads the management registers through this data bus.
hready_n
Out
Host Ready. This is an active low signal used to indicate the end of transfer. For write operations,
hready_n is asserted after data is accepted (written). For read operations, hready_n is asserted
when data on the hdataout bus is ready to be driven out to the CPU.
1. Note for the TSMAC Easy Connect (G)MII configuration, the register interface implementation is identical to the host interface used for the
Lattice TSMAC. Therefore, the management registers of the SGMII and Gb Ethernet PCS IP core are accessed in the identical manner that
TSMAC registers are accessed. Consult IPUG51, Tri-Speed Ethernet MAC User’s Guide, for host interface timing details.
IPUG60_02.1, April 2014
42
SGMII and Gb Ethernet PCS IP Core User’s Guide
Chapter 6:
Core Validation
The Lattice SGMII and Gb Ethernet PCS IP core has been validated through interoperability tests with an external
Marvell 8E1111 PHY device. An external ethernet protocol generator/analyzer, such as the Spirent Smartbits tester, was used to exercise auto-negotiation, and drive/monitor ethernet traffic through the Marvel PHY and
SGMII/GbE IP core test circuit.
Refer to the following Lattice interoperability technical note:
• TN1197 - LatticeECP3 Marvell SGMII Physical/MAC Layer Interoperability
IPUG60_02.1, April 2014
43
SGMII and Gb Ethernet PCS IP Core User’s Guide
Chapter 7:
Support Resources
This chapter contains information about Lattice Technical Support, additional references, and document revision
history.
Lattice Technical Support
There are a number of ways to receive technical support.
E-mail Support
techsupport@latticesemi.com
Local Support
Contact your nearest Lattice Sales Office.
Internet
www.latticesemi.com
References
The following documents provide more technical information regarding this IP core:
• Serial-GMII Specification, Revision 1.8, November 2, 2005, Cisco Systems
• IEEE 802.3-2002 Specification
LatticeECP3
• HB1009, LatticeECP3 Family Handbook
• TN1176, LatticeECP3 SERDES/PCS Usage Guide
• TN1197, LatticeECP3 Marvell SGMII Physical/MAC Layer Interoperability
• IPUG51, Tri-Speed Ethernet MAC User’s Guide
ECP5
• HB1012, ECP5 Family Handbook
IPUG60_02.1, April 2014
44
SGMII and Gb Ethernet PCS IP Core User’s Guide
Support Resources
Revision History
Date
Document Version
IP Core Version
Change Summary
September 2006
01.0
1.0
Initial release.
November 2006
01.1
2.0
Added support for LatticeECP2M family.
April 2007
01.2
2.0
Added rx_compensation_err signal to the SGMII IP Core Input
and Output Signals table (8-Bit Code Group Signals section).
August 2008
01.3
3.0
Updated to include changes introduced by release 3.0 of IP
core.
April 2009
01.4
3.1
Added support for LatticeECP3 family.
June 2009
01.5
3.2
Updated to include information on updating the PCS and
implementing multiple PCS blocks.
September 2009
01.6
3.2
Corrected description for gbe_mode signal in the Input and
Output Signals for (G)MII-to-SGMII Bridge table.
June 2010
01.7
3.3
Added support for Diamond software.
Divided the document into chapters and added table of contents.
Added Table 1-1 in Chapter 1.
Added Figure 2-3.
Updated Table 5-16.
Added Chapter 6, “Core Validation.”
August 2010
01.8
3.3
Updated “Soft Receive Clock Tolerance Compensation (CTC)
Circuit” on page 8.
Added “Guidelines for Calculating Static CTC FIFO Thresholds
” on page 18.
Updated “Using CTC with the SGMII IP Core” on page 24.
March 2011
01.9
3.4
Update document for new IP core version 3.4.
October 2011
02.0
3.4
Updated “IP Core Signal Ports Associated with Auto-Negotiation” on page 11.
April 2014
02.1
4.0
Added support for Diamond 3.2.
Added support for ECP5 device family.
Removed references to LatticeECP2MTM and LatticeSCTM
device families.
Updated corporate logo.
Updated “Lattice Technical Support” on page 44.
IPUG60_02.1, April 2014
45
SGMII and Gb Ethernet PCS IP Core User’s Guide
Appendix A:
Resource Utilization
This appendix gives resource utilization information for Lattice FPGAs using the SGMII and Gb Ethernet PCS core.
The IP configurations shown in this chapter were generated using the IPexpress software tool. IPexpress is the Lattice IP configuration utility, and is included as a standard feature of the Diamond design tools. Details regarding the
usage of IPexpress can be found in the IPexpress and Diamond help systems. For more information on the Diamond design tools, visit the Lattice web site at: www.latticesemi.com/software.
LatticeECP3 FPGAs
Table A-1. Performance and Resource Utilization1
Configuration
RX CTC
Mode
FIFO Low
Threshold
FIFO High
Threshold
SLICEs
LUTs
Registers
EBRs
fMAX2
(MHz)
Classic
None
—
—
747
877
898
0
125
Classic
Static
16
32
839
1000
1007
1
125
Easy Connect
Static
240
260
709
848
851
1
125
Easy Connect
Dynamic
—
—
729
869
882
1
125
GMII Style
1. Performance and utilization data are generated targeting an LFE3-70EA-7FN484C device using Lattice Diamond 3.2 and Synplify Pro
I.2013.09L-SP1 software. Performance may vary when using a different software version or targeting a different device density or speed
grade within the LatticeECP3 family.
2. The SGMII requires operation at 125 MHz, therefore a higher frequency is not stated. However this core can easily attain frequencies
above 140 MHz in a LatticeECP3 speed grade 7 device.
Supplied Netlist Configurations
The Ordering Part Number (OPN) for the SGMII and Gb Ethernet PCS core targeting LatticeECP3 devices is GBESGMII-E3-U1.
ECP5 FPGAs
Table A-2. Performance and Resource Utilization1
Configuration
RX CTC
Mode
FIFO Low
Threshold
FIFO High
Threshold
SLICEs
LUTs
Registers
EBRs
fMAX2
(MHz)
Classic
None
—
—
750
879
898
0
125
Classic
Static
16
32
837
1002
1007
1
125
Easy Connect
Static
240
260
709
851
851
1
125
Easy Connect
Dynamic
—
—
745
897
882
1
125
GMII Style
1. Performance and utilization data are generated targeting an LFE5UM-85F-7MG756C device using Lattice Diamond 3.2 and Synplify Pro
I.2013.09L-SP1 software. Performance may vary when using a different software version or targeting a different device density or speed
grade within the ECP5 family.
2. The SGMII requires operation at 125 MHz, therefore a higher frequency is not stated. However this core can easily attain frequencies
above 140 MHz in a ECP5 speed grade 7 device.
Supplied Netlist Configurations
The Ordering Part Numbers (OPNs) for the SGMII and Gb Ethernet PCS core targeting ECP5 devices are GBESGMII-E5-U and GBE-SGMII-E5-UT.
IPUG60_02.1, April 2014
46
SGMII and Gb Ethernet PCS IP Core User’s Guide
工商网监
湘ICP备2023018690号
