XCPRI: A Single-Chip CPRI PHY Layer Implemented in the Virtex-II Pro FPGA Author: Paul Hardy

Transcription

1 Application Note: Virtex-II Pro FPGA Family XAPP761 (v1.1.1) May 9, 2007 XCPI: A Single-Chip CPI PHY Layer Implemented in the Virtex-II Pro FPGA Author: Paul Hardy Summary This application note describes XCPI, a pre-engineered design module for Virtex -II Pro devices that implements the Common Packet adio Interface (CPI). The internal ocketio Multi-Gigabit Transceivers (MGTs) are used to implement the Physical layer, including all CPI-specified line rates. A fully customizable Data Link layer, supporting multiple I/Q channels and both Ethernet and HDLC control mechanisms, is implemented within the FPGA. VHDL source code is provided, together with a testbench and sample implementation targeted at the Xilinx ML321 development board. Introduction This reference design implements Layer 1 and Layer 2 of the CPI specification [ef 1] in a Xilinx FPGA of the Virtex-II Pro family. CPI is a new standard for communication between a adio Equipment Controller (EC) / Basestation and one or more adio Equipment (E) units in a 3rd-Generation cellular network. It is an initiative for open access to mobile base station interfacing, governing levels 1 and 2 of the communication between the E and EC. See Figure 1. Backplane, Cable, or Fibre adio Equipment (E) CPI CPI adio Equipment Controller (EC) / Basestation adio Network Controller (NC) x761_01_ Figure 1: Overview of CPI Interface The goal of the CPI interface is to use one physical layer for the radio data (I/Q data), radio unit management (automatic gain control, alarms, etc.) and synchronization (clock frequency control, frame synchronization). The CPI physical layer is specified for operation at Mbaud, Mbaud, and Mbaud over one serial link, and is defined to be electrically compliant with previously specified High Speed Serial Link standards (physical performances, cables and connectors) such as the Gigabit Ethernet Standard IEEE series. The XCPI reference design is an implementation of this protocol in a Xilinx Virtex-II Pro Platform FPGA, employing the built-in ocketio Multi-Gigabit Transceivers (MGTs) for physical transmission, and providing the following client-side interfaces: I/Q interface: Consists of radio data (I/Q), which is synchronized to the UMTS radio frame pulse. The reference design supports from 1 to 24 different channels. Synchronization interface: Provides the means for the adio Equipment (E) to synchronize to the network time, by transmitting the UMTS radio frame pulse and clock frequency. HDLC interface: For management traffic between the Basestation/EC and E. The HDLC interface is serialized and synchronous, as per the industry standard [ef 3] Xilinx, Inc. All rights reserved. All Xilinx trademarks, registered trademarks, patents, and further disclaimers are as listed at All other trademarks and registered trademarks are the property of their respective owners. All specifications are subject to change without notice. NOTICE OF DISCLAIME: Xilinx is providing this design, code, or information "as is." By providing the design, code, or information as one possible implementation of this feature, application, or standard, Xilinx makes no representation that this implementation is free from any claims of infringement. You are responsible for obtaining any rights you may require for your implementation. Xilinx expressly disclaims any warranty whatsoever with respect to the adequacy of the implementation, including but not limited to any warranties or representations that this implementation is free from claims of infringement and any implied warranties of merchantability or fitness for a particular purpose. XAPP761 (v1.1.1) May 9,

2 Features Ethernet interface: Adhering to the MII interface standard, for connecting to Ethernet media access controllers (EMACs) [ef 2]. Management interface: Provides read/write status and a control register that controls the operation of the XCPI reference design. It also provides a complete alarm interface. Simple status interface: Provides a means to assert the status of the CPI line. The CPI standard describes three different service access points (SAP) to the upper level. These are the synchronization, user plane and control, and management access points, and are available within the XCPI reference design as separate pins. In addition, these access points are split into two or more groups as described later in this document. This document describes the XCPI reference design, its compliance with the CPI specification, and the interfaces which enable a designer to use this reference design as the starting point to support a CPI interface in a custom design. Features The following lists the key features of the XCPI reference design and the Virtex-II Pro Platform FPGA architecture used to implement it: High-performance, low-cost, flexible, scalable reference design Fully compliant with CPI specification V1.2 Uses Virtex-II Pro ocketio Multi-Gigabit Transceivers to achieve high transceiver capability, including Up to Gb/s line speed (Maximum CPI line rate is Mbaud) Automatic clock/data recovery 8B/10B encode and decode [ef 7] The reference design can be configured to handle either the EC side or the E side The user side of the reference design has the following capabilities Easy-to-use synchronous interface for I/Q data and synchronization information Configurable 1 to 24 Antenna Carrier support Industry-standard synchronous serial communications interface for HDLC communication (optional) Industry-standard media independent interface (MII) for Ethernet communication (optional) Design is verified by Xilinx proprietary test bench and verified in hardware using the publicly available Xilinx ML321 development board Complete documentation provided, including HDL source code Product specification Verification harness and environment Instantiation template User constraints file for sample implementation targeted to the ML321 development board 2 XAPP761 (v1.1.1) May 9, 2007

3 Functional Description Functional Description The XCPI reference design is intended for base station applications, or any other application where synchronous data and management protocols need to be transferred across any distance of other media types such as optical fibre, cable, or backplanes. Figure 2 illustrates the reference design s architecture. Status Alarm Management Interface TxD TxEn xd xdv Coll. Carrier Ethernet MII Interface Alarm I/F Interleaving / De-interleaving Startup & Control High- Speed Serial Transceiver Serial Data HDLC Serial Interface I/Q Frame & Sync I/Q I/F #1 I/Q I/F #24 Ctrl Data (Optional) TxFrame xframe I/Q I/Q x761_02_ The XCPI reference design is organized into separate modules to facilitate a flexible end product. These logic modules are: Start-Up & Control Alarm I/Q Synchronization and Framing I/Q Interface (1 to 24 possible Antenna Carriers) Multi-Gigabit Transceiver Ethernet Interface (optional) HDLC Interface (optional) Each of these modules is further partitioned into a receive and transmit side. The receive side handles the ingress traffic, and the transmit side the egress traffic. Communication between the ingress and egress sides of the modules is minimal and easily managed. Further, each logic module handles one aspect of the CPI specification such that, when not needed, a module can be removed to enable a minimal implementation of the CPI communication interface. Each logic module is described in the following sections: Start-Up and Control Module Figure 2: XCPI eference Design Architecture The start-up and control module is responsible for performing the needed negotiations regarding line speed, HDLC data rate, and Ethernet data rate. It also determines when the CPI line is up. Management is software-controlled and can be modified by the user. Discussion of the details of this are planned for a future version of this application note. Please contact cpri@xilinx.com or your local Field Applications Engineer for further details. XAPP761 (v1.1.1) May 9,

4 Functional Description Alarm Module The alarm module is responsible for receiving and sending the special CPI alarms as specified in section of the CPI specification. A single alarm bit and four status bits are generated corresponding to each of the four alarm conditions. These bits can be used to drive LEDs, or can be used within the design to signal the alarm condition to higher system layers. I/Q Module This module is replicated for each I and Q data channel that is needed. Up to 24 separate channels can exist, as required by the CPI specification, each programmable to support 4- to 20-bit widths [ef 1]. The data is multiplexed into the I/Q section of the CPI basic frame structure. The I/Q module is easily modified to support specific I/Q data multiplexing and demultiplexing requirements without requiring changes elsewhere in the CPI interface. Ethernet Module Management and control data can be supported via a 10/100 Ethernet channel that is multiplexed into the CPI data stream. The Ethernet module enables support of this management and control. Standard Ethernet supports up to 100 Mb/s data rate, but the maximum CPI-supported speed for Ethernet is 92 Mb/s. Buffering is therefore performed within the CPI reference design, which, to the client side, appears like standard half-duplex operation. This enables the Ethernet MAC to be implemented by the user within the FPGA fabric (e.g., by using the Xilinx Ethernet MAC IP), or by using some other industry-standard MII interface-compliant Ethernet controller. This module is optional. HDLC Module Management and control data can be supported via an HDLC channel that is multiplexed into the CPI datastream. The HDLC module enables support of this management & control. The client side interface is fully synchronous and supports a negotiable data rate of up to 1920 kb/s as required by the CPI protocol. The HDLC controller can be implemented by the user within the FPGA fabric (e.g., by using the Xilinx HDLC controller IP) or as a function external to the FPGA (e.g., via a communications processor). This module is optional. Interleaving and De-interleaving Module This module gathers data from all transmitting elements and multiplexes them onto the serial line. This does not require any external interface, as it is handled automatically. At the receiving end, the process of distributing the right bits at the right time to the right place is handled by this functional module. 4 XAPP761 (v1.1.1) May 9, 2007

5 Design Parameters Design Parameters The XCPI reference design is highly modular and parameterized. Parameters within the HDL source allow the design to be easily customized for specific implementations that are typically unique to individual designs. These parameters are set at compile time. Table 1 lists the parameters, the range of values that can be used for each, and the default value (in parentheses) that is assumed should the parameter not be defined by the user. Table 1: Compile Time Parameter Definitions Group Parameter name Values (Default) Description C_X_WIDTH_N C_TX_WIDTH_N 0, 4 20 (20) 0, 4 20 (20) Total width of I/Q channel N (N = 1 to 24), receive side, when accounting for oversampling. When set to 0, interface N is disabled. Total width of I/Q channel N (N = 1 to 24), receive side, when accounting for oversampling. When set to 0, interface N is disabled. I/Q group C_IQ_X_STAT_N (0) C_IQ_TX_STAT_N (0) Determines the bit position of the Nth I/Q channel (N = 1 to 24) in each basic frame, receive side. Bit 0 is the first bit after the control word. Maximum bit number depends on I/Q channel width and line speed. Determines the bit position of the Nth I/Q channel (N = 1 to 24) in each basic frame, transmit side. Bit 0 is the first bit after the control word. Maximum bit number depends on I/Q channel width and line speed. C_LINE_SPEED 0-2 (1) The CPI line rate: (1) 0 = Mbaud 1 = Mbaud 2 = Mbaud Miscellaneous C_IS_EC True/False (True) If set TUE, the core acts as an EC. If set FALSE, the core acts as an E. C_USE_ETHENET True/False (True) If set TUE, the Ethernet-based Fast Management Interface is enabled. If set FALSE, the interface is disabled and supporting logic is removed from the design. Notes: 1. A subsequent release of the XCPI reference design will fully support auto-negotiation. Static link speed will continue to be supported as an option. Interfaces I/Q (Data) Interface The I/Q interface is used for sending and receiving client-side data and other data that must be synchronized with a specific frame, such as automatic gain control. A parallel transmit interface is implemented that is sampled once each T (1) C for downlink, and two or four times each T C for uplink (two or four times oversampling). The interface is divided into a maximum of 24 antenna carriers (AxC). Each AxC is then divided into an I-downlink, Q-downlink, I-uplink and Q-uplink. The width of the I and Q interfaces is programmable at compile time for widths between 4 and 10 bits for uplink, and between 8 and 20 bits for downlink, as defined by the CPI specification. 1. T C is the 3GPP chip rate period defined as 1 / 3.84MHz, or approximately 260 ns that is, CPI provides a transparent Transport channel. XAPP761 (v1.1.1) May 9,

6 Interfaces In the case of oversampling, the I/Q channel is two or four times as wide, and all data is sampled at the same instance when the enable signal is High. Note: Even though the term "I and Q data" is used here, the upper level can map any data to its interface, and expect the same bits to be received at the other end. The clock for the transmit interface is a reference clock, operating at MHz or MHz. All AxC carriers must be synchronous to this clock. The enable signal for the transmit side must be asserted exactly one clock period of the reference clock each T C in time. This timing is shown in Figure 3. PLL_EF_CLK TX_ENABLE Tc = 260ns IQ_TX_I_n IQ_TX_Q_n x761_03_ Figure 3: CPI Transmit Timing The receive interface is implemented in the same fashion as the transmit interface. In this case, the reference clock is generated from the XCPI reference design, and is the clock recovered from the serial line by the high-speed ocketio transceiver. The xdatavalid signal indicates when the I/Q sample is valid, and is asserted once each Tc in time as shown in Figure 4. ECOVEED_CLK X_DATA_VALID Tc = 260ns IQ_X_I_n IQ_X_Q_n x761_04_ Figure 4: CPI eceive Timing Table 2: I/Q Interface Signals Signal Size Dir Clock Description iq_tx_i_n C_TX_WIDTH_N I System ef Clk iq_tx_q_n C_TX_WIDTH_N I System ef Clk iq_rx_i_n C_X_WIDTH_N O x ecovered Clk iq_rx_q_n C_X_WIDTH_N O x ecovered Clk iq_tx_enable 1 I System ef Clk iq_rx_datavalid 1 O x ecovered Clk I data for transmit direction (N = 1 to 24) Q data for transmit direction (N = 1 to 24) I data for receive direction (N = 1 to 24) I data for receive direction (N = 1 to 24) The transmit enable indicating start of new T C The receive data valid indicating start of new T C 6 XAPP761 (v1.1.1) May 9, 2007

7 Interfaces Frame and Synchronization Interface The synchronization interface sends and receives the UMTS NodeB frame number (BFN). The length of a UMTS frame is 10 ms and is synchronized to the clock of the User Plane interface. Synchronization can be achieved by combining BFN and the User Plane clock. BFN is sampled on the transmit side as a parallel signal when the frame strobe signal is asserted at the edge of the transmit clock, and is qualified by TxEnable. The frame strobe signal must be asserted for T C ns. Figure 5 shows what this looks like at MHz clock. At a higher clock frequency, the TxEnable pulse gets shorter, and at a lower clock frequency it gets longer. However, the periodicity of the pulse is the same, approximately 260 ns On the receive side, shown in Figure 6, the frame strobe is generated at the clock edge of the I/Q data for T C ns, and the frame number is presented at the same instant. As CPI does not receive the complete frame number until 193 T C after the frame strobe, the presented frame number is valid for the previous frame at the time the frame strobe is asserted. Table 3: Synchronisation Interface Signals Signal Width Dir Clock Description bfn_tx_strobe 1 I System ef Clk UMTS NodeB frame strobe in transmit direction bfn_tx_nr 12 I System ef Clk UMTS NodeB frame number in transmit direction bfn_rx_strobe 1 O x ecovered Clk UMTS NodeB frame strobe in receive direction bfn_rx_nr 12 O x ecovered Clk UMTS NodeB frame number in receive direction PLL_EC_CLK UMTS Frame = 10ms TxENABLE Tc = 260ns BFN_TX_STOBE BFN_TX_N F F+1 Figure 5: UMTS Transmit Frame Timing x761_05_ ECOVEED_CLK UMTS Frame = 10ms xenable Tc = 260ns BFN_X_STOBE BFN_X_N F F+1 Figure 6: UMTS eceive Frame Timing x761_06_ XAPP761 (v1.1.1) May 9,

8 Interfaces Slow Control and Management Interface The slow control and management interface is specified as an HDLC interface. The transmit data is a serial input referenced to the system reference clock (Figure 7). The receive data is a serial output referenced to the x-side recovered clock (Figure 8). The XCPI reference design generates Tx-side enable and data valid signals with regular intervals, and with the average data rate that has been negotiated and determined at a higher layer in the overall protocol stack. The negotiation selects the highest speed of those available to the XCPI reference design, specified at compile time and dependent on the CPI line rate. The XCPI reference design does require the HDLC protocol to be handled by an outside entity, such as the Xilinx HDLC core or any major integrated communications controller complying with the HDLC specification [ef 3]. Table 4: Slow Control and Management Interface Signals Signal Width Dir Clock Description hdlc_rx_data 1 O x ecovered Clk HDLC serial data in receive direction hdlc_rx_datavalid 1 O x ecovered Clk HDLC serial receive data valid hdlc_tx_data 1 I System ef Clk HDLC serial data in transmit direction hdlc_tx_enable 1 O System ef Clk HDLC serial transmit data enable. PLL_EF_CLK HDLC_TX_DATA HDLC_TX_ENABLE Figure 7: Transmit HDLC Interface Timing x761_07_ ECOVEED_CLK HDLC_X_DATA HDLC_X_DATA_VALID Figure 8: eceive HDLC Interface Timing Fast Control and Management Interface x761_08_ The fast control and management interface is specified as an Ethernet MII [ef 2] interface. An outside controller such as a Xilinx EMAC IP core can directly connect to this port, as the XCPI reference design acts like an MII-compliant PHY. The Ethernet MAC must be run at 100 Mb/s half-duplex, as this is the only supported speed. As the speed to/from the Ethernet MAC is fixed at 100 Mb/s, which is more than the achievable bandwidth on the CPI link, a flow-control scheme using collision detection is employed. To the external Ethernet MAC, this looks like the standard CSMA/CD flow control used by some Ethernet switches on half-duplex lines. The speed adaptation requires buffers between the MII interface and the CPI line. The carrier sense signal is used to signal that there is not room for 8 XAPP761 (v1.1.1) May 9, 2007

9 Interfaces a new packet in the buffer. This scheme achieves the goal of not having to modify the Ethernet MAC to transmit packets without overrun. The transmit signals are referenced to the transmit clock, and the receive signals are referenced to the receive clock. These clocks are generated by the XCPI reference design with the help of an external 25 MHz clock input. The actual transmission speed of the Ethernet frames varies from 0.48 Mb/s to Mb/s, depending on the speed that was negotiated between the EC and E. The negotiation selects the highest speed of those available to the XCPI reference design, specified at compile time and dependent on the CPI line rate. To the Ethernet MAC however, transmit and receive clocks are always 25 MHz. Standard MII-compliant interface timing is used, as shown in Figure 9. Table 5: Fast Control and Management Interface Signals Signal Width Dir Clock Description eth_txd 4 I Ethernet ef Clk Ethernet transmit data eth_tx_en 1 I Ethernet ef Clk Ethernet transmit enable eth_tx_er 1 I Ethernet ef Clk Ethernet transmit data error eth_rx 4 O Ethernet ef Clk Ethernet receive data eth_rx_dv 1 O Ethernet ef Clk Ethernet receive data valid eth_rx_er 1 O Ethernet ef Clk Ethernet receive data error eth_col 1 O Ethernet ef Clk Ethernet collision detected eth_crs 1 O Ethernet ef Clk Ethernet carrier sense eth_ref_clk 1 I - Ethernet reference clock (25 MHz) ETH_EF CLK ETH_TX_EN ETH_TXD D0 D1 D2 D3 D4 D5 D6 D7 D8 D9 D10 ETH_TX_E ETH_CS ETH_COL ETH_X_DV ETH_XD D0 D1 D2 D3 D4 D5 D6 JAM ETH_X_E Figure 9: MII Ethernet Interface Timing x761_09_ XAPP761 (v1.1.1) May 9,

10 Interfaces General Management Interface The management interface is implemented as a Fast Simplex Link (FSL), to enable an easy interconnection to other FPGA logic, including a MicroBlaze soft processor. This interface appears as a FIFO at the client side, and therefore can also easily interface to logic other than a processor. Details of the Fast Simplex Link interface are found in XAPP529 [ef 4]. The interface acts as a memory-mapped interface with eight status registers and eight control registers. It is used for writing control information for the reference design, such as line speed, reset request, etc., and reading status information such as alarms and negotiated speeds. The exact mapping of the functionality is shown in Table 6 and Table 7 (b0 is LSB): Table 6: Management Interface Memory Map (eading) egister Name Address Description Status code and alarm 000 Misc. status 001 HDLC rate 010 Ethernet pointer 011 bit [4] - Summary alarm bit, same as stat_summary bits [3:0] - Status code, same as the four bit port stat_code(). bit [0] - Loss of signal bit [1] - Loss of frame synch bit [7] - Am I EC? Current HDLC rate, bits [2:0]: No HDLC kb/s kb/s kb/s kb/s Current Ethernet pointer. Value from 20 to 63, where 20 is highest speed. eceived sub-channel 2, word 0 eceived sub-channel 2, word 1 eceived sub-channel 2, word 2 eceived sub-channel 2, word See CPI Standard. 101 See CPI Standard. 110 See CPI Standard. 111 See CPI Standard. Table 7: Management Interface Memory Map (Writing) egister Name Address Description eset request register Ethernet 000 bit [0] - eset request transmit bit [1] - eset request receive CPI Alarms transmitted 110 bit [0] - eset (Downlink - request, Uplink - acknowledge) bit [2] - SDI (Other alarms are handled automatically) The management interface is a 12-bit-wide FIFO interface. Bit [11] of each word written indicates if a read or a write is issued, with a '1' indicating a write. Bits [10:8] are the address taken from tables above. When writing, bits [7:0] are the written byte; when reading, the lower eight bits have no meaning. The management interface signals are described in Table 8, with the timing illustrated in Figure XAPP761 (v1.1.1) May 9, 2007

11 Interfaces Table 8: General Management Interface Signals Signal Width Dir Clock Description mgmnt_m_data 8 O System ef Clk Data when reading from the XCPI reference design mgmnt_m_write 1 O System ef Clk Write strobe to the FSL mgmnt_m_full 1 I System ef Clk FSL indicates the FIFO is full mgmnt_s_data 12 I System ef Clk Address, /W and possibly data when initiating a transaction mgmnt_s_read 1 O System ef Clk Indication to FSL that the command is read PLL_EF_CLK MGMNT_W_FULL MGMNT_M_DATA MGMNT_M_WITE MGMNT_S_DATA MGMNT_S_EAD MGMNT_S_EXISTS x761_10_ Serial Line Interface Figure 10: Management Interface Timing Diagram The serial line interface is 8B/10B-encoded according to the specification [ef 1], and is implemented using the ocketio Muti-Gigabit Transceivers (MGTs) featured in the Virtex-II Pro Platform FPGA. The line rate varies from to Mbaud. Transmit and receive are done by a differential pair that can be used directly for short-distance cable. (1) It is also feasible to omit the multi-gigabit transceiver from the reference design so that external SerDes can be supported for instance, to allow the CPI eference design to drive a Laser Driver for optical based communication. To support this particular scenario, the XCPI reference design provides for a loss of laser (LOL) input from the laser driver. The LOL signal is then used to set and/or clear the LOS alarm on the alarm interface, and to also control the internal state of the reference design. A transmit inhibit signal is generated when the XCPI reference design is in standby mode. These two signals are asynchronous. Other signals to and from the laser or any other external drivers are not directly supported by the CPI standard, and should be handled outside the XCPI reference design. The serial line interface signals are described in Table 9, with the timing illustrated in Figure 11 and Figure Note that no MGT is included in the XCPI reference design. An example implementation is provided, however, showing the connection to a Xilinx MGT. XAPP761 (v1.1.1) May 9,

12 Interfaces Table 9: Serial Line Interface Signals Signal Width Dir Clock Description ser_tx_p 1 O - ser_tx_n 1 O - ser_rx_p 1 O - ser_rx_n 1 O - Serial data output positive side (dedicated pin) Serial data output negative side (dedicated pin) Serial data input positive side (dedicated pin) Serial data input negative side (dedicated pin) ser_lol 1 I Asynch Serial laser driver loss of signal detected ser_tx_inhib 1 O Asynch Serial laser driver transmit inhibit ser_txd 16 O System ef Clk Parallel data interface to the transceiver ser_tx_k 2 O System ef Clk Parallel K-code indicator to the transceiver ser_rxd 16 I x ecovered Clk Parallel data interface from the transceiver ser_rx_iscomma 2 I x ecovered Clk ser_rx_isk 2 I x ecovered Clk ser_rx_er 2 I x ecovered Clk Parallel comma indicator from the transceiver Parallel K character indicator from the transceiver Parallel coding error indicator from the transceiver PLL_EF_CLK FAME_NUMBE 0 1 SE_TX_K[1] SE_TX_K[0] SE_TXD Figure 11: Serial Line Transmit Interface Timing x761_11_ ECOVEED_CLK SE_X_ISK[1] SE_X_ISK[0] SE_XD SE_X_E SE_X_EALIGN_EN Figure 12: Serial Line eceive Interface Timing x761_12_ XAPP761 (v1.1.1) May 9, 2007

13 XCPI eference Design Status Monitoring Interface The status interface can be connected to LEDs for easy debugging. They can, of course, also be connected to the general-purpose I/O of a processor or another logic module. The alarm module both asserts and deasserts the status code, as applicable. The serial line interface signals are described in Table 10, with the timing illustrated in Figure 13. Table 10: Status Monitoring Interface Signals Signal Width Dir Clock Description stat_alarm 1 O System ef Clk An alarm has been detected stat_code 4 O System ef Clk Status code generated by the XCPI reference design: eset state L1 synch achieved Protocol version agreed L2 set up Passive mode Active mode, CPI is up PLL_EF_CLK STAT_ALAM STAT_CODE x761_13_ Figure 13: Alarm Timing XCPI eference Design esource Utilization The XCPI reference design has been targeted to the Virtex-II Pro family of devices. The size of the XCPI reference design is highly dependant on the parameters set and the number and type of interfaces used. The examples Table 11 show typical resource utilization when supporting different numbers of antenna carriers with varying interface bit widths, and with and without Ethernet support. Table 11: Estimated XCPI eference Design esource Usage Example Antenna Carriers I/Q Bit Width TX X HDLC Ethernet Size Estimate (Slices) Size Estimate (BAM) A 2 20 x 1 10 x 2 Y N B 3 8 x 1 4 x 2 Y N C 3 8 x 1 4 x 2 Y Y D 6 20 x 1 10 x 2 Y N E x 1 10 x 2 Y N F x 1 5 x 2 Y N G x 1 10 x 2 Y N XAPP761 (v1.1.1) May 9,

14 XCPI eference Design The results given here assume that the TX I/Q interfaces are identical in bit width, and similarly for the X I/Q interfaces. However, this need not be the case. The XCPI reference design can be configured to support any combination of I/Q interface widths. The results were obtained targeting the reference design to an XC2VP7 device, as supplied on the ML321 development board, using the Xilinx ISE 6.2i (plus Service Pack 2) tool set. Note: Due to the performance capability of the ocketio multi-gigabit transceivers, a -6 or -7 speed grade Virtex-II Pro FPGA will be required in order to support the highest Mbaud line rate. If an external transceiver is used, however, any Virtex-II Pro speed grade can be used to support all line rates. Design Verification The verification has been performed with a Xilinx-developed testbench, employing the MicroBlaze soft processor, and running in an XC2VP7-6-FF672C FPGA as supplied on the ML321 development board. The verification model employs the hardware in the loop concept for fast and complete verification in silicon. An application note documenting the demonstration and verification harness is planned for a future date. Clocking Structure and s The XCPI reference design requires separate clocks for the transmitter and receiver modules. Typically, however, the frequency of these two modules is identical, and this is assumed in the following information. These frequencies are dependant upon the line rate, and also dictate the operating frequency of the reference design though different options exist, depending on the use model of the Virtex-II Pro MGT. In addition, a third clock of 25 MHz is required if the fast management interface is employed. The main blocks of the design operate at MHz or MHz (depending on the selected data rate), derived from the input reference clock. Details of the clocking structure requirements of the Virtex-II Pro MGTs are documented in the ocketio Transceiver User Guide [ef 5]. Note: A future revision of this reference design supporting auto-negotiation will provide a common clocking structure that supports all three line rates. Please contact cpri@xilinx.com or your Xilinx Field Application Engineer for more details. Example MGT Configuration for Data ate of Mbaud This table summarizes the settings for the MGT component for the MBaud rate. Table 12: MGT Configuration, MBaud Configuration Value Mode ate EFCLK USCLK USCLK2 XECCLK Two Byte Half ate 61.44MHz 30.72MHz 61.44MHz 30.72MHz 14 XAPP761 (v1.1.1) May 9, 2007

15 XCPI eference Design Example MGT Configuration for Data ate of Mbaud This table summarizes the settings for the MGT component for the MBaud rate. Table 13: MGT Configuration, MBaud Configuration Value Mode ate EFCLK USCLK Two Byte Full ate MHz MHz USCLK MHz XECCLK MHz Example MGT Configuration for Data ate of Mbaud This table summarizes the settings for the MGT component for the MBaud rate. Table 14: MGT Configuration, MBaud Configuration Value Mode ate EFCLK USCLK USCLK2 XECCLK Two Byte Full ate MHz MHz MHz MHz eceive Clock ecovery In normal operation, the CPI interfaces transmit and receive data are synchronous to each other, and hence can be derived from a single clock. For the E module application (see Figure 1, page 1), there is no available local reference clock to operate the physical and data link modules. The receive portion of the design must therefore operate from a recovered clock. An external PLL circuit is provided to ensure that the receive MGT has a stable reference, as described in the ocketio Transceiver User Guide [ef 5]. The flow diagram in Figure 14 shows how this design should be included. TX_P TX_N X_P X_N Xilinx ocketio Multi-Gigabit Transceiver USCLK2 USCLK FPGA DCM X_CLK_IN 61.44/ MHz FPGA Boundary X_EC_CLK External Voltage-Controlled Oscillator 61.44/ MHz External Phase-Locked Loop Control Low Pass Loop Filter x761_14_ Figure 14: External Clock ecovery PLL Block Diagram XAPP761 (v1.1.1) May 9,

16 XCPI eference Design Design Hierarchy To ease implementation and better facilitate user modifications, the physical hierarchy of the reference design, Figure 15, differs from the functional overview shown in Figure 2. The following section explains the design implementation hierarchy and provides details of the functions of each of the sub-modules. XCPI Transmitter Functional Description The entire transmit side excluding the Ethernet interface operates at the system reference clock pll_ref_clk frequency. This clock is 1 /20th of the line rate: that is, MHz, MHz, or MHz. tx_ctrl tx_ctrl controls all data transmission. A PicoBlaze controller ( Software-Configurable Modules, page 20) handles the start-up negotiation, the management interface, and alarm handling. eset signals are also generated for the Ethernet buffers. Control words 0 to 3 written by the rx_synch module on the receive side are read by the PicoBlaze controller and responded to accordingly. Similarly, up to four control words at a time are written to the transmitted data stream. The status signals loss_of_signal and loss_of_frame are also read from the rx_synch module, synchronised, and used in the start-up negotiation. Signals stat_alarm and stat_code signals are generated to indicate where in the start-up process the module is. Signals tx_hdlc_rate and tx_eth_pointer are determined in the start-up phase. The tx_ctrl module sets these for the benefit of the tx_hdlc and tx_eth modules. Finally, a management interface is provided to enable status information to be read and to allow the setting and reading of alarms. This management interface follows the Fast Simplex Link specification of the Xilinx MicroBlaze soft processor as documented in XAPP529 [ef 4]. Note that there is no frame synchronization input to the tx_ctrl module, as this module does not do any "per frame" work. Thus, the module does not have any real-time requirements. tx_synch The tx_synch module handles the generation of the signals, hfn_tx_nr and basic_frame_nr signals. The former is used to determine on which clock edge the data is read from the I/Q channels by the tx_iq interfaces; the others are for internal synchronization. As hfn_tx_nr is automatically generated from bfn_tx_strobe, this signal cannot be directly controlled by the user. The generation of iq_tx_enable does require that an outside entity asserts bfn_tx_strobe for one chip period of ~260 ns (that is, 8/16/32 periods of the system reference clock). tx_iq The tx_iq module receives user data to be transmitted over the CPI link. There is one tx_iq module for each I/Q channel used, the number and bit width of which is statically configured at compile time, as is the starting bit position. Bit position 0 is the first bit after the control word. The speed_sel signal is also needed because the module needs to know in which octet the first I/Q is placed. This signal varies with line speed. The input of the module is a parallel version I and Q data (4 10 bits as required). If 2x oversampling is used, the data width can be doubled (8 20 bits) and the bits interpreted accordingly. The input data word is sampled on assertion of iq_tx_enable. The output of the tx_iq modules are a delayed and shifted version of the input I/Q data such that the output can be fed directly to the transceiver. Sixteen bits are transmitted at a time. All bits that are not part of the I/Q channel are set to zero, to aid multiplexing in later stages XAPP761 (v1.1.1) May 9, 2007

17 XCPI eference Design tx_synch tx_modules tx_iq (1 to 24) tx_hdlc tx_mux To MGT eth_txif tx_eth tx_ctrl 25 MHz Domain rx_synch rx_modules eth_rxif rx_eth rx_hdlc From MGT rx_iq (1 to 24) x761_15_ Figure 15: Physical Design Hierarchy tx_hdlc The tx_hdlc module provides a serial interface to a separate HDLC controller to support the slow management interface requirement of the CPI specification. hdlc_tx_enable is asserted at even intervals, dependant on the hdlc_rate and speed_sel signals. The serially read data is multiplexed into the output data stream according to the signal basic_frame_nr. ate adaptation is supported by asserting hdlc_data_valid when the output is valid, an approach supported by most HDLC controllers. This, however, can be disabled if required. eth_txif eth_txif acts as the receiver for Ethernet packets when implementing a Fast Management Interface and operates in the 25 MHz eth_ref_clk domain. XAPP761 (v1.1.1) May 9,

18 XCPI eference Design Ethernet traffic is received into an internal packet buffer from an external MAC via an MII interface. The packet buffer can store two packets in total. When a complete and error-free packet is received and stored, an internal packet counter is updated and a pulse on the tx_eth_packet_was_written is generated. Further, the packet size and a write strobe are sent to the tx_eth module. If the packet buffer is full or a transmission on the MII interface is in progress (eth_tx_en is active), eth_crs is asserted. There is currently no detection of a packet going in the opposite direction on the MII interface (i.e. eth_rx_dv is active), but this can be configured by the user if required. Simple flow control can be supported using the carrier sense signal eth_crs if connected to a half-duplex Ethernet MAC; however, there is no way to guarantee that the packet is not dropped during transmission. tx_eth The tx_eth module formats and multiplexes the Fast Management Ethernet data into the CPI data stream Data is received from eth_txif. Upon detection of tx_eth_packet_was_written, the received data is encoded using 4B/5B encoding; starting and ending stream delimiters are added, according to the Ethernet and CPI specifications; and the data is transmitted in serial form on cw_serial_eth, based upon the assertion of tx_eth_pointer, basic_frame_nr and iq_tx_enable. The serial data is sent so that it can be directly inserted into the control word of the basic frames. Outside the valid window, the serial bits are all zero. tx_mux The tx_mux module multiplexes the received and newly formatted I/Q, HDLC, and/or Ethernet data into the final CPI data stream. Multiplexing of the serial management data is achieved by logically Oing the inputs cw_serial_hdlc, and cw_serial_eth together, and then converting to a parallel data stream. Final multiplexing is done on 32-bit boundaries, though some of these bits are then later zeroed, depending on line speed. CPI control bits are first multiplexed into the data stream as follows: For sub-channel 0, either a K28.5, the hfn_tx_nr or High/Low part of bfn_tx_nr For sub-channel 1, slow management information dependant upon hdlc_rate For sub-channel 2, fast management information. When the frame to be transmitted is the first basic frame in a hyper-frame, a signal indicating that a K-character should be transmitted is also set active. CPI payload data is then multiplexed into the data stream. Multiplexing is performed by logically Oing together the outputs from the tx_iq modules. The design principle for this multiplexing is that all the other modules should have their outputs set to zero when their outputs should not be used. This enables a distributed decision process for each dataflow for enhanced scalability. XCPI eceiver Functional Description The receive side of the XCPI reference design provides a 16-bit interface to a Multi-Gigabit Transceiver (MGT). The MGT itself is not included in the reference design, but example implementations are distributed with the reference design. The clock recovered from the MGT is used throughout the entire receive side, and also in the I/Q and the HDLC interfaces. The Ethernet interface uses a separate 25 MHz clock, and the crossing between the various clock domains is implemented via an asynchronous packet FIFO XAPP761 (v1.1.1) May 9, 2007

19 XCPI eference Design For maximum symmetry, the recovered clock is assumed to be 1 /20th of the line speed, regardless of speed selected. This provides MHz, MHz, or MHz clocks. rx_synch The rx_synch module is responsible for the synchronization of received data. The input is 16-bit 8B/10B decoded data together with a comma detection signal, which should be asserted at the same time as the first octet of the basic frame. Also expected is an error signal for each word. These error signals are counted. An excessive number of errors in each hyper-frame (arbitrarily set to 16, but modifiable by the user) resets the synchronization state machine. An additional input signal, loss_of_laser, can also reset the state machine. An output signal to the MGT is provided that enables the alignment of commas to the lower octet. This signal is only enabled when the reference design is out of synch, at which point the MGT should then realign to any comma it finds. The signals basic_frame_first_word, basic_frame_number, bfn_rx_strobe, bfn_rx_nr (which is delayed almost one hyper-frame relative to the strobe and I/Q data), and hfn_rx_nr (which is also delayed almost one hyper-frame) are generated for use in downstream modules. The rx_synch module also saves received control information from the first four sub-channels that is later used by the transmit side controller. A "safe" signal is provided so that the transmit side can sample the dual-port memory used for this purpose when the receive side is not writing to it. Sub-channel information is also stored for the benefit of the downstream receiveside modules hdlc_rate and ethernet_pointer. These modules reflect what is received in the respective sub-channels. All control words are serialized and transmitted from this module. It is the function of the downstream modules rx_hdlc and rx_eth to retrieve the correct data via the use of basic_frame_number and basic_frame_first_word. rx_iq The rx_iq module presents CPI payload data to the user. There is one rx_iq module per I/Q channel, statically configured with respect to size and the starting bit position. Bit position 0 is the first bit after the control word. The signal speed_sel is also used to determine in which octet the first I/Q is placed, as this varies with line speed. The output of the module is a parallel version of the I and Q data. If 2x oversampling is used, the data width of the I/Q port is doubled and the presented bits must be interpreted accordingly. The data word outputs are only guaranteed to be stable when the iq_rx_enable signal is asserted. rx_hdlc The rx_hdlc module extracts the slow management interface data. No processing of the received HDLC bits is performed, as it is assumed that an HDLC controller is attached to the XCPI reference design. The input signals speed_sel, hdlc_rate, basic_frame_number, and basic_frame_first_word are used to determine the data to be selected from the received data stream. ate adaptation is supported in a similar manner to the transmitter side, by asserting hdlc_data_valid to indicate that valid data is present on the output. If preferred, this rate adaptation function can be disabled. rx_eth The rx_eth module is one of two modules responsible for extracting the fast management information from the CPI data stream XAPP761 (v1.1.1) May 9,

20 XCPI eference Design Operating in the received clock domain, it selects the correct bits from serialized control words by the use of speed_sel, rx_eth_pointer, basic_frame_first_word, and basic_frame_number. These bits form a 5B/4B-encoded data stream. The starting stream delimiter and ending stream delimiter are detected according to the Ethernet specification for 100 Mb/s ethernet. If any error is detected short packet, coding error the packet is silently dropped. If the packet is correct, it is stored. Two packets can be stored at a time using a ping-pong buffer technique. In addition, the packet size (in nibbles) is also stored. When a packet is received, the signal rx_eth_packet_was_written is asserted to the eth_rxif module, which synchronizes this pulse and updates internal counters. In addition, the rx_eth module updates a second internal counter that keeps track of which buffers to use next. eth_rxif The eth_rxif module retrieves valid packets from the rx_rth module and presents them to the user interface. It is expected that an Ethernet MAC is connected to this interface. This module works in the 25 MHz domain of eth_ref_clk. When an rx_eth_packet_was_written signal from the rx_eth module is asserted, an internal counter is incremented and the buffered data is retrieved from rx_eth via the appropriate assertion of rx_eth_packet_nr and rx_eth_packet_addr. This data is then transmitted on the MII interface connecting to the external MAC, and the rx_eth_packet_was_read signal is asserted to the rx_eth module. The eth_rxif module works in full-duplex mode. If a half-duplex Ethernet interface is required, this is easily configurable and could be adopted. A collision is then indicated by setting the eth_rx_er signal active. Note: The CPI specification does not include any flow control mechanism for Ethernet. As a consequence, even though packets might be transmitted at an average speed well below 100 Mb/s, the peak speed could still be greater than this, and Ethernet packets might unavoidably be dropped. To enable maximum Ethernet throughput, the XCPI reference design does not verify that the external MAC is sending when placing data from the eth_rxif module onto the MII interface. Doing so would not empty the buffer as quickly as possible. As Ethernet packets with bit errors are dropped before they are stored in the packet buffer, the signal eth_rx_er is never active. rx_modules All the above modules are contained in the rx_modules module. All reset signals coming into this module are synchronized to the appropriate clock (eth_ref_clk or recovered_clk), depending on the logic being driven. Software-Configurable Modules Start-Up, Control, and Management To control the entire XCPI start-up and a maintenance interface, a PicoBlaze soft controller is used. This is a small, embedded 8-bit controller, where the program is stored in a block AM. Details can be found on the Xilinx website [ef 6]. The assembly code is included in this reference design, but the development software is not. The required KCPSM2 development environment can be downloaded from the Xilinx Web site. The code is built on the CPI-defined state machine, and includes subroutines for: Management interface handling. The subroutine reads and writes from the FSL FIFOs and acts according to instructions. Alarm handling. The subroutine checks the incoming alarms from the receive side and from the CPI control word, setting output status accordingly XAPP761 (v1.1.1) May 9, 2007

21 Compliance with CPI v1.2 Specification These subroutines also generate the outgoing alarms LOS and LOF, and are repeatedly called for each state that the CPI start-up sequence enters. Link Auto-Negotiation Support for auto-negotiation of the CPI line rate is slated for a later revision of the XCPI reference design. Current plans call for the auto-negotiation algorithm to be implemented using the Xilinx PicoBlaze 8-bit microcontroller reference design, as described above. This design allows user software control and easy modification of the algorithm. Please contact cpri@xilinx.com or your local Field Applications Engineer for further details. Compliance with CPI v1.2 Specification XCPI Compliance with CPI Functional and Timing Specifications The following tables summarize the functional and timing compliance of the XCPI eference Design with the CPI Specification v1.2 [ef 1]. Table 15: XCPI & Supported adio Standards Compliance Number Definition Value Xilinx Compliance and Support -1 adio Standard and elease 3G UTA FDD elease 5 Outside scope of XCPI reference design. Table 16: XCPI and Operating ange Compliance Number Definition Value Xilinx Compliance and Support -2 Cable Length (Lower Limit) 0m Supported. -3 Cable Length (Upper Limit) >10m Length dependant upon parameters specific to the implementation, and must therefore be tested per implementation. Table 17: XCPI Topology, Switching, and Multiplexing Compliance Number Definition Value Xilinx Compliance and Support -4 Topology Star Topology XCPI provides point-to-point communication, enabling support of all topologies. XAPP761 (v1.1.1) May 9,

22 Compliance with CPI v1.2 Specification Table 18: XCPI Bandwidth, Capacity and Scalability Compliance Number Definition Value Xilinx Compliance and Support Number of Antenna Carriers per Physical Line Number of Antenna Carriers per Physical Line Number of Antenna Carriers per Physical Line Number of Antenna Carriers per Physical Line Number of Antenna Carriers per Physical Line Number of Antenna Carriers per Physical Line 4 Fully supported. 6 Fully supported. 8 Fully supported. 12 Fully supported. 18 Fully supported. 24 Fully supported. -11 Minimum Uplink I/Q Sample Width 4 Fully supported as design parameter. -12 Maximum Uplink I/Q Sample Width 10 Fully supported as design parameter. -13 Minimum Downlink I/Q Sample Width 8 Fully supported as design parameter. -14 Maximum Downlink I/Q Sample Width 20 Fully supported as design parameter Minimum Transmission ate of M-Plane Data Minimum Transmission ate of C-Plane Data 200 Kb/s Fully supported. 25 Kb/s Fully supported. Table 19: XCPI Synchronization and Timing Compliance Number Definition Value Xilinx Compliance and Support -17 Maximum Allowed Cut-Off Frequency 300 Hz Compliance determined by clocking structure employed external to the FPGA. -18 Maximum Contribution of Jitter ppm Compliance determined by clocking structure employed external to the FPGA. -19 Absolute Delay Accuracy ±T C /32 To be supported in subsequent release of XCPI reference design. -20 ound-trip Absolute Accuracy ±T C /16 To be supported in subsequent release of XCPI reference design. Table 20: XCPI Delay Calibration Compliance Number Definition Value Xilinx Compliance and Support -21 Accuracy of the ound- Trip Delay Measurement ±T C /16 To be supported in subsequent release of XCPI reference design XAPP761 (v1.1.1) May 9, 2007