13-XAUI IP Core Users Guide
13-XAUI IP Core Users Guide
January 2012
IPUG68_01.6
Table of Contents
Chapter 1. Introduction .......................................................................................................................... 4
Quick Facts ........................................................................................................................................................... 4
Features ................................................................................................................................................................ 4
Chapter 2. Functional Description ........................................................................................................ 6
XAUI IP Core I/O................................................................................................................................................... 9
Functional Description......................................................................................................................................... 10
XGMII and Slip Buffers............................................................................................................................... 14
XAUI-to-XGMII Translation (Receive Interface) ......................................................................................... 15
XGMII-to-XAUI Translation (Transmit Interface) ........................................................................................ 16
Management Data Input/Output (MDIO) Interface (Optional) .................................................................... 18
Management Frame Structure ................................................................................................................... 19
Register Descriptions .......................................................................................................................................... 20
Input/Output Timing............................................................................................................................................. 22
XGMII Specifications.................................................................................................................................. 22
XAUI Specifications.................................................................................................................................... 24
MDIO Specifications................................................................................................................................... 24
Chapter 3. Parameter Settings ............................................................................................................ 25
XAUI IP Configuration Dialog Box....................................................................................................................... 25
Parameter Descriptions....................................................................................................................................... 25
Tx Slip Buffer.............................................................................................................................................. 25
Rx Slip Buffer ............................................................................................................................................. 26
MDIO.......................................................................................................................................................... 26
Behavioral Model ....................................................................................................................................... 26
Netlist [.ngo] ............................................................................................................................................... 26
Evaluation Directory ................................................................................................................................... 26
Tools Support............................................................................................................................................. 26
Chapter 4. IP Core Generation............................................................................................................. 27
Licensing the IP Core.......................................................................................................................................... 27
Getting Started .................................................................................................................................................... 27
IPexpress-Created Files and Top Level Directory Structure............................................................................... 29
Instantiating the Core ................................................................................................................................. 30
Running Functional Simulation .................................................................................................................. 31
Synthesizing and Implementing the Core in a Top-Level Design .............................................................. 31
Hardware Evaluation........................................................................................................................................... 32
Enabling Hardware Evaluation in Diamond................................................................................................ 32
Enabling Hardware Evaluation in ispLEVER.............................................................................................. 32
Updating/Regenerating the IP Core .................................................................................................................... 33
Regenerating an IP Core in Diamond ........................................................................................................ 33
Regenerating an IP Core in ispLEVER ...................................................................................................... 33
Chapter 5. Support Resources ............................................................................................................ 35
Lattice Technical Support.................................................................................................................................... 35
Online Forums............................................................................................................................................ 35
Telephone Support Hotline ........................................................................................................................ 35
E-mail Support ........................................................................................................................................... 35
Local Support ............................................................................................................................................. 35
Internet ....................................................................................................................................................... 35
References.......................................................................................................................................................... 35
LatticeECP3 ............................................................................................................................................... 35
LatticeECP2M ............................................................................................................................................ 35
© 2012 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.
Introduction
The 10Gb Ethernet Attachment Unit Interface (XAUI) IP Core User’s Guide for the LatticeECP2M™ and
LatticeECP3™ FPGAs provides a solution for bridging between XAUI and 10-Gigabit Media Independent Interface
(XGMII) devices. This IP core implements 10Gb Ethernet Extended Sublayer (XGXS) capabilities in soft logic that
together with PCS and SERDES functions implemented in the FGPA provides a complete XAUI-to-XGMII solution.
The XAUI IP core package comes with the following documentation and files:
• Protected netlist/database
• Behavioral RTL simulation model
• Source files for instantiating and evaluating the core
The XAUI 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 pur-
chase on an IP license. It may also be used to evaluate the core in hardware in user-defined designs. Details for
using the hardware evaluation capability are described in the Hardware Evaluation section of this document.
Quick Facts
Table 1-1 gives quick facts about the XAUI IP core.
Table 1-1. XAUI IP Core Quick Facts
XAUI IP Configuration
Features
• XAUI compliant functionality supported by embedded SERDES PCS functionality implemented in the
LatticeECP2M and LatticeECP3, including four channels of 3.125 Gbps serializer/deserializer with 8b10b encod-
ing/decoding.
• Complete 10Gb Ethernet Extended Sublayer (XGXS) solution based on LatticeECP2M and LatticeECP3 FPGA.
• Soft IP targeted to the FPGA implements XGXS functionality conforming to IEEE 802.3-2005, including:
– 10 GbE Media Independent Interface (XGMII).
– Optional slip buffers for clock domain transfer to/from the XGMII interface.
– Complete translation between XGMII and XAUI PCS layers, including 8b10b encoding and decoding of Idle,
Start, Terminate, Error and Sequence code groups and sequences, and randomized Idle generation in the
XAUI transmit direction.
– XAUI compliant lane-by-lane synchronization.
– Lane deskew functionality.
– Interface with the high-speed SERDES block embedded in the LatticeECP2M and LatticeECP3 that imple-
ments a standard XAUI.
– Optional standard compliant MDIO/MDC interface.
• Aldec and ModelSim simulation models and test benches provided for free evaluation.
Functional Description
XAUI is a high-speed interconnect that offers reduced pin count and has the ability to drive up to 20 inches of PCB
trace on standard FR-4 material. Each XAUI comprises four self-timed 8b10b encoded serial lanes each operating
at 3.125 Gbps and thus is capable of transferring data at an aggregate rate of 10 Gbps.
XGMII is a 156 MHz Double Data Rate (DDR), parallel, short-reach interconnect interface (typically less than 2
inches). It supports interfacing to 10 Gbps Ethernet Media Access Control (MAC) and PHY devices.
The locations of XAUI and XGXS in the 10GbE protocol stack are shown in Figure 2-1. A simplified block diagram
of the XAUI solution is shown in Figure 2-2. The XGMII interface, XGXS coding and state machines and XAUI mul-
tichannel alignment capabilities are implemented in the FPGA array. The XAUI 8b10b coding and SERDES func-
tionality are supported by the embedded SERDES_PCS block. An optional MDIO interface module is also
implemented in the FPGA array.
Figure 2-3 shows the I/O interface view of the XAUI IP core.
Upper Layers
* optional sublayer
XGMII
Adding the WIS makes the WAN PHY
XGXS*
XAUI
XGXS* XGMII/XAUI
XGMII
64b/66b coding
Medium
FPGA PCS
Array SERDES
XAUI IP Core
MDIO
Optional
xgmii_tx_data[31:0] HDOUT[P:N]0
Idle Generator
TX Slip Buffer
72b SDR
TX SERDES
TX Encoder
@156MHz HDOUT[P:N]1
xgmii_tx_ctrl3:0]
XGMII
IDDR HDOUT[P:N]2
TX
xgmii_txclk_156
HDOUT[P:N]3
REFCLK[P:N]
Optional
xgmii_rx_data[31:0]
HDIN[P:N]0
RX Slip Buffer
Multichannel
RX SERDES
RX Decoder
xgmii_rx_ctrl[3:0] 72b SDR HDIN[P:N]1
Alignment
@156MHz XGMII
ODDR HDIN[P:N]2
xgmii_rxclk_156_out RX
HDIN[P:N]3
xgmii_rxclk_156
reset_n
If TX Slip Buffer is selected clk_156_tx power_down
mca_resync mca_sync_status
If MDIO is NOT selected If MDIO is NOT selected
mdin mdout
mdc mdtri
sciwritedata
sciwstn
scireaddata scird
sciaddr
If MDIO is selected If MDIO is selected
scisel
scien
sciselaux
scienaux
gpi gpo
Functional Description
The XAUI receive path, shown in Figure 2-4, is the data path from the XAUI to the XGMII interface. In the receive
direction, 8b10b encoded data received at the XAUI SERDES interface is demultiplexed and passed to the multi-
channel alignment block, that compensates for lane-to-lane skew between the four SERDES channels as specified
in 802.3-2005. The aligned data streams are passed to decoder logic, where it is translated and mapped to the
XGMII data format. The output of the encoder is then passed through an optional slip buffer that compensates for
XAUI and XGMII timing differences and then to the XGMII 36-bit (32-bit data and four control bits) 156 MHz DDR
external interface.
The receive direction data translations are shown in Figure 2-5. The 8b10b symbols on each XAUI lane are con-
verted to XGMII format and passed to the corresponding XGMII lane. The XGMII comprises four lanes, labeled
[0:3], and one clock in both transmit and receive directions. Each lane includes eight data signals and one control
signal. Double Data Rate (DDR) transmission is utilized, with the data and control signals sampled on both the ris-
ing and falling edges of a 156.25 MHz (nom) clock for an effective data transfer rate of 2.5Gbps.
FPGA
XAUI IP CORE
xgmii_txclk_156 clk_156_rx 156MHz
REFCLK
xgmii_txclk_156_out rx_ddr_clk
Deskew Check
90°
PLL clk_156_rx_asb
Multichannel Alignment
sm
18b HDIN[P:N]0
RX Slip Buffer
RX SERDES
Rx Decoder
Check End
18b HDIN[P:N]1
xgmii_tx_data[31:0]
XGMII 18b HDIN[P:N]2
xgmii_tx_ctrl[3:0] TX 18b
DDR HDIN[P:N]3
Output 72b @ 72b @
156MHz 156MHz
FPGA
XAUI IP CORE
156MHz
REFCLK
xgmii_txclk_156_out rx_ddr_clk
Deskew Check
90°
PLL clk_156_rx_asb
Multichannel Alignment
sm
18b
Check End
HDIN[P:N]0
RX SERDES
Rx Decoder
18b HDIN[P:N]1
xgmii_tx_data[31:0] 18b
XGMII HDIN[P:N]2
TX 18b HDIN[P:N]3
xgmii_tx_ctrl[3:0]
DDR 72b @ 72b @
Output 156MHz 156MHz
K A B C D E FG H
XGXS mapping
C 01 2 3 4 5 67
XGMII
The transmit path, shown in Figure 2-6, is the data path from XGMII to XAUI. In the transmit direction, the 36-bit
DDR data and control received at the XGMII are converted to single-edge timing and passed through an optional
slip buffer that compensates for XAUI and XGMII timing differences. The XGMII data and control are then passed
to the TX encoder, where they are translated and mapped to the 8b10b XAUI transmission code and then passed
to the SERDES interface.
The transmit direction data translations are shown in Figure 2-7. Data and control from each of the four XGMII
lanes are translated and mapped to the corresponding XAUI lanes. The transmit encoder includes the transmit idle
generation state machine that generates a random sequence of /A/, /K/ and /R/ code groups as specified in IEEE
802.3-2005.
FPGA
XAUI IP CORE
xgmii_rxclk_156 clk_156_tx 156MHz
PLL
REFCLK
tx_ddr_clk
clk_156_tx_asb
TX Slip Buffer
18b HDOUT[P:N]0
RX SERDES
TX Encoder
18b HDOUT[P:N]1
FPGA
XAUI IP CORE
xgmii_rxclk_156 clk_156_tx 156MHz
PLL
clk_156_tx_asb REFCLK
tx_ddr_clk
18b HDOUT[P:N]0
RX SERDES
TX Encoder
18b HDOUT[P:N]1
xgmii_rx_data[31:0] 18b HDOUT[P:N]2
XGMII
RX 18b HDOUT[P:N]3
xgmii_rx_ctrl[3:0] DDR 72b @
Input 156MHz
XGMII
C 0 1 2 3 4 5 6 7
XGXS mapping
K A B C D E FG H
10b8b decoding
a b c d e i f g h j
The XGMII supports Double Data Rate (DDR) transmission (i.e., the data and control input signals are sampled on
both the rising and falling edges of the corresponding clock). The XGXS XGMII input (RX) data is sampled based
on an input clock typically sourced from the XGMII device running at 156.25 MHz, 1/64th of the 10Gb data rate and
is transmitted by the IP transmit part. The XGXS XGMII output (TX) data is referenced to a forwarded clock that is
phase locked to a 156.25 MHz (typical) input reference, and the data is received from the IP receiver part.
The control signal for each lane is de-asserted when a data octet is being sent on the corresponding lane and
asserted when a control character is being sent. Supported control octet encodings are shown in Table 2-3. All
data and control signals are passed directly to/from the 8b10b encoding/decoding blocks with no further process-
ing by the XGMII block. Note that the packet Start control word is only valid on lane 0.
The XGMII blocks incorporate optional slip buffers that accommodate small differences between XGMII and XAUI
timing by inserting or deleting idle characters. The slip buffer is implemented as a 256 x 72 FIFO. There are four
flags out of the FIFO: full, empty, partially full, and partially empty. The partially empty flag is used as the watermark
to start reading from the FIFO. If the difference between write and read pointers falls below the partially empty
watermark and the entire packet has been transmitted, idle characters are inserted until the partially full watermark
is reached. No idle is inserted during data transmission.
The multi-channel alignment block consists of four 16-byte deep FIFOs to individually buffer each XAUI lane. The
multi-channel alignment block searches for the presence of the alignment character /A/ in each XAUI lane, and
begins storing the data in the FIFO when the /A/ character is detected in a lane. When the alignment character has
been detected in all four XAUI lanes, the data is retrieved from each FIFO so that all of the alignment characters /A/
are aligned across all four XAUI lanes. Once synchronization is achieved, the block does not resynchronize until a
resynchronization request is issued.
The data from the RX multi-channel alignment is passed to the RX decoder. The RX decoder block converts the
XAUI code to the corresponding XGMII code. Table 2-4 shows the 8b10b code points. Table 2-5 shows the code
mapping between the two domains in the receive direction. XAUI /A/, /R/, /K/ characters are translated into XGMII
Idle (/I/) characters.
Data from the RX decoder block is written to the RX slip buffer. As mentioned previously, the slip buffers are
required to compensate for differences in the write and read clocks derived from the XAUI and XGMII reference
clocks, respectively. Clock compensation is achieved by deleting (not writing) idle cells into the buffer when the
“almost full” threshold is reached and by inserting (writing) additional idle cells into the buffer when the “almost
empty” threshold is reached. All idle insertion/deletion occurs during the Inter-Packet Gap (IPG) between data
frames.
After the slip buffer, the XGMII formatted transmit data and control are input to the TX encoder that converts the
XGMII characters into 8b10b format as shown in Table 7. The idle generation state machine in the TX encoder con-
verts XGMII /I/ characters to a random sequence of XAUI /A/, /K/ and /R/ characters as specified in IEEE 802.3-
2005. XGMII idles are mapped to a random sequence of code groups to reduce radiated emissions. The /A/ code
groups support XAUI lane alignment and have a guaranteed minimum spacing of 16 code-groups. The /R/ code
groups are used for clock compensation. The /K/ code groups contain the 8b10b comma sequence.
The random /A/, /R/, /K/ sequence is generated as specified in section 48.2.5.2.1 of IEEE 802.3-2005 and shown in
the state machine diagram given in Figure 2-8. In addition to idle generation, the state machine also forwards
sequences of ||Q|| ordered sets used for link status reporting. These sets have the XGMII sequence control charac-
ter on lane 0 followed by three data characters in XGMII lanes 1 through 3. Sequence ordered-sets are only sent
following an ||A|| ordered set.
The random selection of /A/, /K/, and /R/ characters is based on the generation of uniformly distributed random
integers derived from a PRBS. Minimum ||A|| code group spacing is determined by the integer value generated by
the PRBS (A_cnt in Figure 2-8). ||K|| and ||R|| selection is driven by the value of the least significant bit of the gen-
erated integer value (code_sel in Figure 2-8). The idle generation state machine specified in IEEE 802.3-2005 and
shown in Figure 2-7 transitions between states based on a 312 MHz system clock. The TX encoder implemented in
the XAUI IP runs at a system clock rate of 156 MHz. Thus the XGXS state machine implementation performs the
equivalent of two state transitions each clock cycle.
SEND_DATA
IF TX=||T|| THEN cvtx_terminate
TX_code-group<39:0>
ENCODE(TX)
PUDR
(next_ifg = K + A_CNT00)reset
next_ifg = A * A_CNT=0
SEND_A SEND_K
UCT
Q_det!Q_det
B
SEND_Q
TX_code-group<39:0> TQMSG
Q_det false
PUDR B
A_CNT00 * A
code_sel=1
UCT
SEND_RANDOM_R SEND_RANDOM_K
A_CNT00 *
code_sel=0 A_CNT=0 A_CNT00 *
A A_CNT=0 B code_sel=1
SEND_RANDOM_A A_CNT00 *
A code_sel=0
TX_code-group<39:0> ||A||
PUDR
Q_det
!Q_det *
B code_sel=1
SEND_RANDOM_Q
B code_sel=1
A code_sel=0
The physical interface consists of two signals: MDIO to transfer data/address/control to and from the device, and
MDC, a clock up to 2.5 MHz sourced externally to provide the synchronization for MDIO. The fields of the MDIO
transfer are shown in Figure 2-9.
ST=00
The next two fields are the port address (PRTAD) and device type (DTYPE). Since the physical layer function in 10
GbE is partitioned into various logical (and possibly separate physical) blocks, two fields are used to access these
blocks. The PRTAD provides the overall address to the PHY function. The first port address bit transmitted and
received is the MSB of the address. The DTYPE field addresses the specific block within the physical layer func-
tion.
Device address zero is reserved to ensure that there is not a long sequence of zeros. If the ST field is 01 then the
DTYPE field is replaced with REGAD (register address field of the original clause 22 specification). The XAUI core
does not respond to any accesses with ST = 01.
The TA field (Turn Around) is a 2-bit turnaround time spacing between the device address field and the data field to
avoid contention during a read transaction. The TA bits are treated as don’t cares by the XAUI core.
During a write or address operation, the address/data field transports 16 bits of write data or register address
depending on the access type. The register is automatically incremented after a read increment. The address/data
field is 16 bits.
For an address cycle, this field contains the address of the register to be accessed on the next cycle. For
read/write/increment cycles, the field contains the data for the register. The first bit of data transmitted and received
in the address/data field is the MSB (bit 15). An example access is shown in Figure 2-10.
Table 2-7 shows PHY XGXS registers as described in IEEE 802.3-2005. The shaded areas are used to indicate
register addresses that are specified in the draft but are not used in this implementation.
There are two vendor supported register ranges. The 4.8000h register range is used for accessing and program-
ming the XGXS registers implemented in the programmable array. All corresponding registers are listed in Table 2-
8. All PCS embedded core registers can be accessed thru the 4.9xxxh registers shown in Table 2-9, where the
address is directly mapped to the PCS embedded registers.
Register Descriptions
Table 2-7. Register Map for XAUI IP Core (Device Address = 4)
Register Address Register Name
0 PHY XGXS Control 1
1 PHY XGXS Status 1
2, 3 PHY XGXS Identifier
4 Reserved
5 PHY XGXS Status 2
6 - 23 Reserved
24 10G PHY XGXS Lane status
25 - 32767 Reserved
32768 - 65535 Vendor specific
Input/Output Timing
XGMII Specifications
Clause 46 if IEEE 802.3-2005 specifies HSTL1 I/O with a 1.5V output buffer supply voltage for all XGMII signals.
The HSTL1 specifications comply with EIA/JEDEC standard EIA/JESD8-6 using Class I output buffers with output
impedance greater than 38¾ to ensure acceptable overshoot and undershoot performance in an unterminated
interconnection. The parametric values for HSTL XGII signals are given in Table 2-10. The HSTL termination
scheme is shown in Figure 2-11. Timing requirements for chip-to-chip XGMII signals are shown in Figure 2-12.
R = 50 Ω
Z = 50
VREF = 0.75V
tpwmi tpwmi
n n
xgmii_txclk_156, VIH_AC(min)
xgmii_rxclk_156,
xgmii_rxclk_156_out
VIL_AC(max)
xgmii_tx_data[31:0], VIH_AC(min)
xgmii_tx_ctrl[3:0],
xgmii_rx_data[31:0],
xgmii_rx_ctrl[3:0] VIL_AC(max)
tsetup tsetup
thold thold
XAUI Specifications
Refer to the LatticeECP2M and LatticeECP3 PCS specifications for a complete XAUI timing requirements.
MDIO Specifications
The electrical specifications of the MDIO signals conform to Clause 45.4 of IEEE 802.3-2005.
MDC
t4 t5
MDIO (INPUT)
t6
MDIO (OUTPUT)
Parameter Settings
The IPexpress™ tool is used to create IP and architectural modules in the Diamond and ispLEVER software. Refer
to “IP Core Generation” on page 27 for a description on how to generate the IP.
Table 3-1 provides the list of user configurable parameters for the XAUI IP core. The parameter settings are speci-
fied using the XAUI IP core Configuration GUI in IPexpress.
Parameter Descriptions
This section describes the available parameters for the XAUI IP core.
Tx Slip Buffer
This option allows the user to include a slip buffer in the XAUI transmit direction for clock tolerance compensation
(enabled by default).
Rx Slip Buffer
This option allows the user to include a slip buffer in the XAUI receive direction for clock tolerance compensation
(enabled by default).
MDIO
This option allows the user to include an MDIO interface providing access to XAUI IP core internal registers (dis-
abled by default).
Behavioral Model
This option creates behavioral simulation model for IP core (always enabled).
Netlist [.ngo]
This option creates a netlist (.ngo file) for IP core (always enabled).
Evaluation Directory
This option creates an evaluation directory for IP core that includes simulation and implementation example proj-
ects (always enabled).
Tools Support
The XAUI IP core evaluation capability supports multiple synthesis and simulation tool flows. These options allow
the user to select desired tool support.
IP Core Generation
This chapter provides information on licensing the XAUI IP core, generating the core using the Diamond or isp-
LEVER software IPexpress tool, running functional simulation, and including the core in a top-level design. The Lat-
tice XAUI IP core can be used in LatticeECP3 and LatticeECP2M device families.
http://www.latticesemi.com/products/intellectualproperty/aboutip/isplevercoreonlinepurchas.cfm
Users may download and generate the XAUI IP core for Lattice ECP3 or LatticeECP2M and fully evaluate the core
through functional simulation and implementation (synthesis, map, place and route) without an IP license. The
XAUI 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 32 for further details). However, a license is required to enable timing simula-
tion, to open the design in the Diamond or ispLEVER EPIC tool, and to generate bitstreams that do not include the
hardware evaluation timeout limitation.
Getting Started
The XAUI IP core is available for download from the Lattice IP Server using the IPexpress tool in Diamond or isp-
LEVER. The IP files are automatically installed using ispUPDATE technology in any customer-specified directory.
After the IP core has been installed, it will be available in the IPexpress GUI dialog box shown in Figure 4-1.
The IPexpress tool GUI dialog box for the XAUI IP core is shown in Figure 4-1. To generate a specific IP core con-
figuration the user specifies:
• Project Path – Path to the directory where the generated IP files will be loaded.
• File Name – “username” designation given to the generated IP core and corresponding folders and files.
• (Diamond) Module Output – Verilog or VHDL.
• (ispLEVER) Design Entry Type – Verilog HDL or VHDL
• Device Family – Device family to which IP is to be targeted (e.g. LatticeECP2M, LatticeECP3, etc.). Only fami-
lies that support the particular IP core are listed.
• Part Name – Specific targeted part within the selected device family.
Note that if the IPexpress tool is called from within an existing project, Project Path, Module Output (Design Entry in
ispLEVER), 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, the user clicks the Customize button in the IPexpress tool dialog box to display
the XAUI SDRAM IP core Configuration GUI, as shown in Figure 4-2. From this dialog box, the user can select the
IP parameter options specific to their application. Refer to “Parameter Settings” on page 25 for more information on
the XAUI parameter settings.
Table 4-1 provides a list of key files and directories created by the IPexpress tool and how they are used. The IPex-
press 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 IPexpress tool.
Table 4-1. File List
File Description
This file contains the IPexpress tool options used to recreate or modify the core in the IPexpress
<username>.lpc
tool.
The IPX file holds references to all of the elements of an IP or Module after it is generated from
the IPexpress tool (Diamond version only). The file is used to bring in the appropriate files during
<username>.ipx
the design implementation and analysis. It is also used to re-load parameter settings into the
IP/Module generation GUI when an IP/Module is being re-generated.
<username>.ngo This file provides the synthesized IP core.
<username>_bb.v/.vhd This file provides the synthesis black box for the user’s synthesis.
<username>_inst.v/.vhd This file provides an instance template for the PCI IP core.
<username>_beh.v/.vhd This file provides the front-end simulation library for the PCI IP core.
Table 4-2 provides a list of key additional files providing IP core generation status information and command line
generation capability are generated in the user's project directory.
Table 4-2. Additional Files
File Description
This file is created when the GUI “Generate” button is pushed. This file may be run from com-
<username>_generate.tcl
mand line.
<username>_generate.log This is the synthesis and map log file.
<username>_gen.log This is the IPexpress IP generation log file
The \xaui_core_eval and subtending directories provide files supporting XAUI IP core evaluation. The \models
directory shown in Figure 4-3 contains files/folders with content that is constant for all configurations of the XAUI IP
core. The \<username> subfolder (\XAUI_core0 in this example) contains files/folders with content specific to
the username configuration.
The \xaui_core_eval directory is created by IPexpress the first time the core is generated and updated each
time the core is regenerated. A \<username> 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 \<username> directory is
generated for cores with different names, e.g. \xaui_core0, \xaui_core1, etc.
The top-level file <username>_eval.v is the same top-level file that is used in the simulation model described in the
next section. Designers may use this top-level reference as a template for the top level of their design. Included in
<username>_eval.v sample packet generation and checking capabilities at the XGMII interface.
The top-level file <username>_only_top.v supports the ability to implement just the XAUI IP core itself. This design
is intended only to provide an accurate indication of the device utilization associated with the XAUI IP core and
should not be used as an actual implementation example.
To instantiate this IP core using the Linux platform, users must manually add one environment variable named
“SYNPLIFY” to indicate the installation path of the OEM Synplify tool in the local environment file. For example,
SYNPLIFY=/tools/local/isptools7_2/isptools/synplify_linux.
1. Open ModelSim.
2. Under the File tab, select Change Directory and choose folder
<project_dir>\xaui_core_eval\<username>\sim\modelsim.
3. Under the Tools tab, select Execute Macro and execute one of the ModelSim “do” scripts shown.
The simulation waveform results will be displayed in the ModelSim Wave window.
Users may run the Aldec evaluation simulation by doing the following:
1. Open Active-HDL.
The simulation waveform results will be displayed in the Active-HDL Wave window.
Two example RTL top-level configurations supporting the XAUI IP core top-level synthesis and implementation are
provided with the XAUI IP core in \<project_dir>\xaui_core_eval\<username>\impl.
Push-button implementation of both top-level configurations is supported via the Diamond or ispLEVER project
files, <username>_core_only_eval.syn and <username>_eval.syn. These files are located in
\<project_dir>\xaui_core_eval\<username>\impl\(synplify or precision), for implementation
using either the Synplify synthesis tool or Precision synthesis tool, respectively.
For the Linux platform, the top-level synthesis must be run separately with a synthesis tool such as Synplify Pro,
since Diamond and ispLEVER for Linux only accept an EDIF entry. For the core-only project, the synthesis tcl file
<username>_core_only.tcl is generated in
\<project_dir>\xaui_core_eval\<username>\impl\synplify. The user can run this tcl script to syn-
thesize the core_only top-level files in the above directory.
2. Browse to
\<project_dir>\xaui_core_eval\<username>\impl\synplify (or precision) in the Open Proj-
ect dialog box.
3. Select and open <username>.ldf. At this point, all of the files needed to support top-level synthesis and imple-
mentation will be imported to the project.
5. Implement the complete design via the standard Diamond GUI flow.
2. Browse to
\<project_dir>\xaui_core_eval\<username>\impl\synplify (or precision) in the Open
Project dialog box.
3. Select and open <username>.syn. At this point, all of the files needed to support top-level synthesis and imple-
mentation will be imported to the project.
5. Implement the complete design via the standard ispLEVER GUI flow.
Hardware Evaluation
The XAUI IP core supports 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 user-defined
designs.
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 Tar-
get 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 exten-
sion.
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.
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.
2. In the Select a Parameter File dialog box, choose the Lattice Parameter Configuration (.lpc) file of the IP core
you wish to regenerate, and click Open.
3. The Select Target Core Version, Design Entry, and Device dialog box shows the current settings for the IP core
in the Source Value box. Make your new settings in the Target Value box.
4. If you want to generate a new set of files in a new location, set the location in the LPC Target File box. The base
of the .lpc file name will be the base of all the new file names. The LPC Target File must end with an .lpc exten-
sion.
5. Click Next. The IP core’s dialog box opens showing the current option settings.
6. In the dialog box, choose desired options. To get information about the options, click Help. Also, check the
About tab in the IPexpress tool for links to technical notes and user guides. The IP core might come with addi-
tional information. As the options change, the schematic diagram of the IP core changes to show the I/O and
the device resources the IP core will need.
7. Click Generate.
8. Click the Generate Log tab to check for warnings and error messages.
Support Resources
This chapter contains information about Lattice Technical Support, additional references, and document revision
history.
Online Forums
The first place to look is Lattice Forums (http://www.latticesemi.com/support/forums.cfm). Lattice Forums contain a
wealth of knowledge and are actively monitored by Lattice Applications Engineers.
In Asia, call Lattice Applications from 8:30 a.m. to 5:30 p.m. Beijing Time (CST), +0800 UTC. Chinese and English
language only.
E-mail Support
• [email protected]
• [email protected]
Local Support
Contact your nearest Lattice Sales Office.
Internet
www.latticesemi.com
References
• IEEE Std. 802.3-2005, Part 3: Carrier Sense Multiple Access with Collision Detection (CSMA/CD) Access
Method and Physical Layer Specifications, December 9, 2005.
• TN1084, LatticeSC SERDES Jitter
LatticeECP3
• HB1009, LatticeECP3 Family Handbook
LatticeECP2M
• HB1003, LatticeECP2M Family Handbook
Revision History
Document IP Core
Date Version Version Change Summary
June 2007 01.0 1.0 Initial release.
June 2008 01.1 1.1 Title changed from “10Gb Ethernet Attachment Unit Interface (XAUI) IP Core
User’s Guide” to “XAUI IP Core User’s Guide”.
Updated Appendix for LatticeECP2M FPGAs.
June 2009 01.2 1.2 Added support for LatticeECP3 FPGA family.
November 2009 01.3 1.3 Updated utilization tables with ispLEVER 8.0.
June 2010 01.4 1.3 Divided document into chapters. Added table of contents.
Added Quick Facts table in Chapter 1, “Introduction.”
Added new content in Chapter 4, “IP Core Generation.”
September 2010 01.5 1.4 Added support for Diamond software throughout.
January 2012 01.6 1.6 IP Core I/O and Signal Definitions table – Added lines for rx_fifo_empty and
rx_fifo_full to the With Optional Rx Slip Buffer section. Added lines for
tx_fifo_empty and tx_fifo_full to the With Optional Tx Slip Buffer section.
Resource Utilization
This appendix gives resource utilization information for Lattice FPGAs using the XAUI IP core.
IPexpress is the Lattice IP configuration utility, and is included as a standard feature of the Diamond and ispLEVER
design tools. Details regarding the usage of IPexpress can be found in the IPexpress and Diamond or ispLEVER
help system. For more information on the Diamond or ispLEVER design tools, visit the Lattice web site at:
www.latticesemi.com/software.
LatticeECP2M FPGAs
Table A-1. Performance and Resource Utilization1
Configuration Utilization
TX Slip Buf- RX Slip Buf-
Device fer fer MDIO SLICEs LUTs Registers EBRs
LFE2M20E-6F256CES No No No 1351 1813 1545 0
LFE2M20E-6F256CES No No Yes 1447 1951 1685 0
LFE2M35E-6F484CES No Yes No 1632 2137 1989 2
LFE2M50E-6F672CES Yes No No 1727 2264 2033 2
LFE2M70E-6F900CES Yes Yes Yes 2160 2801 2641 4
1. Performance and utilization data are generated using Lattice Diamond 1.0 and Synplify Pro for Lattice D-2009.12L software. Performance
may vary when using a different software version or targeting a different device density or speed grade within the LatticeECP2M family.
XAUI specification requires the receive side to have the ability to operate with 208ps (0.65UI) of jitter. The Lattice
solution for XAUI receive operates well within that specification.
LatticeECP3 FPGAs
Table A-2. Performance and Resource Utilization1
Configuration Utilization
TX Slip Buf- RX Slip Buf-
Device fer fer MDIO SLICEs LUTs Registers EBRs
LFE3-35E-7FN484CES No No No 1194 1674 1498 0
LFE3-70E-7FN672CES No Yes No 1529 2077 1980 2
LFE3-150E-7 FN1156CES Yes Yes No 1880 2510 2467 4
1. Performance and utilization data are generated using Lattice Diamond 1.0 and Synplify Pro for Lattice D-2009.12L software. Performance
may vary when using a different software version or targeting a different device density or speed grade within the LatticeECP3 family.